Summary
Use SHACL shapes not just for validation after transformation, but as a transformation specification that drives the mapping process itself. This inverts the usual flow: instead of 'transform, then validate,' the target SHACL shapes guide the transformation towards the desired RDF model.
Motivation
Currently, transforming non-RDF data (CSV, JSON, XML) to RDF requires manually writing SPARQL CONSTRUCT queries or RML mappings. The user must understand both the source schema and the target RDF model, and there is no feedback loop between the transformation and the desired output shape.
SHACL shapes already describe what valid RDF should look like – required properties, value types, cardinalities, controlled vocabularies. This is exactly the information needed to guide a transformation, not just check its result.
Proposed approach
- Define the target model as SHACL shapes – these become the transformation specification
- Analyse source data (CSV/JSON/XML) against the SHACL shapes to identify potential mappings
- Generate or suggest SPARQL CONSTRUCT queries that map source fields to the target model
- Validate the transformation output against the same SHACL shapes – violations become feedback for iterative refinement
- Iterate until the output conforms to the target shapes
This creates a SHACL-driven feedback loop: shapes → mapping → transformation → validation → refined mapping.
Research questions
- How much of a SHACL shape's constraints can be meaningfully used to drive transformation (vs. only validation)?
- Can we automatically infer mappings from source data structure + target SHACL shapes?
- What is the right level of automation vs. user guidance in this loop?
- How does this interact with LDE's streaming pipeline architecture and backpressure?
Prior art
No existing tool uses SHACL as a transformation specification in this way. Related work:
- SPARQL Anything / Facade-X – handles the technical conversion but requires manual query writing
- RML – declarative mappings but not SHACL-driven
- SHACL validation – used post-hoc, not as input to transformation
Context
This idea emerged during preparation of the NLnet grant proposal for LDE. It represents a genuinely novel R&D direction that combines LDE's existing SHACL and SPARQL capabilities.
Summary
Use SHACL shapes not just for validation after transformation, but as a transformation specification that drives the mapping process itself. This inverts the usual flow: instead of 'transform, then validate,' the target SHACL shapes guide the transformation towards the desired RDF model.
Motivation
Currently, transforming non-RDF data (CSV, JSON, XML) to RDF requires manually writing SPARQL CONSTRUCT queries or RML mappings. The user must understand both the source schema and the target RDF model, and there is no feedback loop between the transformation and the desired output shape.
SHACL shapes already describe what valid RDF should look like – required properties, value types, cardinalities, controlled vocabularies. This is exactly the information needed to guide a transformation, not just check its result.
Proposed approach
This creates a SHACL-driven feedback loop: shapes → mapping → transformation → validation → refined mapping.
Research questions
Prior art
No existing tool uses SHACL as a transformation specification in this way. Related work:
Context
This idea emerged during preparation of the NLnet grant proposal for LDE. It represents a genuinely novel R&D direction that combines LDE's existing SHACL and SPARQL capabilities.