Using SPARQL CONSTRUCT for Mapping RDF Data #268
tobiasschweizer
started this conversation in
Show and tell
Replies: 2 comments 4 replies
-
I've also felt most of the pain points.
Though for these I've been using SPARQL fruitfully. For date normalization I wrote an Apache Jena SPARQL value function which I describe here. |
Beta Was this translation helpful? Give feedback.
4 replies
-
more discussion on this topic is here. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@justin2004 in kg-construct/rml-questions#15 (reply in thread)
Hi there,
I use SPARQL CONSTRUCT queries to map RDF data from a given ontology to schema.org. There are different use cases. Sometimes, we get JSON-LD files from an API. Each file contains a small graph. Using
rdflib
these small graphs can be turned into schema.org conformant graphs (theWHERE
clauses matches the originally given data and the CONSTRUCT clause rewrites it to schema.org using the bound variables). I think this is very similar (if not logically identical) to what you do with non RDF sources.Avantages:
rdflib
)Pain points:
UNION
clauses)OPTIONAL
, it slows down the transformationI figured that there are most likely some best practices when it comes to writing such SPARQL CONSTRUCT queries.
My first approach: I started with what I expected to be the "main" resource type and then defined all possible relations all in one scope. So for example:
Then I found it better (query performance, handling of complexity) to write one
UNION
clause per resource type:The thing is that then in the
CONSTRUCT
clause you cannot rewrite one graph from the "main" resource to all referred resources since variables from differentUNION
clauses are not related.However, you can just handle
UNION
byUNION
:At first, this seemed not very intuitive to me but it helped greatly reduce the query's complexity because it could be split into different parts.
?projAuthor
and?author
are independent but if the original graphs contains the data as expected both variables will be bound to the same IRI (once as an object, once as a subject), hence the relation between project and person (author) will exist in schema.org complaint RDF.However, sometimes you need restrictions that affect several
UNION
clauses, e.g. only map persons that are authors. This is where it gets a bit redundant.Please feel free to give me some critical feedback. I admit that this is a bit trial and error rather than based strictly on the specs (scoping and
UNION
) ...Beta Was this translation helpful? Give feedback.
All reactions