Open jakubklimek opened 4 years ago
This could be something to consider in framing, but it likely involves the introduction of variables, which weaver rejected in the past a SPARQL construct might be used to do this, and then frame the results.
Expansion would be a possible route, although inverting this through compaction seems overly challenging.
It might be worth considering what would need to change in framing to support this use case.
Other than Notation3, I can’t think of another RDF serialization which supports property paths.
@gkellogg : why wouldn't it be a good idea to have support for something like property paths in JSON-LD contexts? That would make JSON-LD much more flexible to deal with application-specific JSON structures. JSON-LD contexts can in those cases be seen as a lightweight mapping language. Other RDF serializations don't have this "mapping" functionality at all, so it's maybe not that relevant to make comparisons, no?
Adding the property path feature would really make it easier to map a concise legacy JSON to all correct terms and patterns that should be used when trying to be compliant with a certain ontology model.
Curious to your points on this discussion :)
@mathib what do you imagine this might look like? It would be good to have a use case.
Property-scoped contexts create a kind of property path, in that values within cascading objects can be interpreted based on the associated scoped context.
In the N3/SPARQL sense, a term described as a property path, might expand to cascading/embedded node objects through that path, but I'm not clear on how this would be useful in defining the data itself. In N3/SPARQL, they're used for querying.
@gkellogg thanks for raising your points. It seemed like I was a bit naïve and too fast in my question. Indeed, when a property path would be introduced in the data itself as syntactic sugar, that would result in a blank node in the middle without any possibility (inside the JSON or in external RDF documents) to say something more about that node, unless the JSON-LD would be loaded in a SPARQL engine with support for update queries.
Property-scoped contexts create a kind of property path, in that values within cascading objects can be interpreted based on the associated scoped context.
Can you give an example here?
Example 45 from the spec shows a basic property-scoped context that defines a context that is applied under interest. Here, it only sets the @vocab
to use, but it can also define further properties, which in turn contain property-scoped contexts, ad infinitum. This forms a kind of property chain, but doesn't automatically insert new nodes when expanded, just allows the terms within each node to be defined relative to the closest property.
{
"@context": {
"@version": 1.1,
"name": "http://schema.org/name",
"interest": {
"@id": "http://xmlns.com/foaf/0.1/interest",
"@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}
}
},
"name": "Manu Sporny",
"interest": {
"@id": "https://www.w3.org/TR/json-ld11/",
"name": "JSON-LD",
"topic": "Linking Data"
}
}
I have a fixed JSON structure that I can't change:
Now I would like to map this correctly to the Registered Organization Vocabulary.
The ideal result should be:
However, using JSON-LD context, all I am capable of doing without changing the JSON structure is:
I miss the ability to "expand" the JSON property into a path
rov:registration/skos:notation
, optionally with the indication of the type of<http://example.com/id/60747862/registration>
. Of course, something like an IRI template would also be nice so that I could actually construct the<http://example.com/id/60747862/registration>
IRI.