Open
Description
I have a fixed JSON structure that I can't change:
{
"@type": "Organization",
"@id": "http://example.com/id/60747862",
"id": "60747862",
"name": {
"en": "MyName"
}
}
Now I would like to map this correctly to the Registered Organization Vocabulary.
The ideal result should be:
<http://example.com/id/60747862> a rov:RegisteredOrganization ;
rov:registration <http://example.com/id/60747862/registration> .
<http://example.com/id/60747862/registration> a adms:Identifier ;
skos:notation "60747862" .
However, using JSON-LD context, all I am capable of doing without changing the JSON structure is:
<http://example.com/id/60747862> a rov:RegisteredOrganization ;
skos:notation "60747862" .
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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
gkellogg commentedon Jul 1, 2020
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.
mathib commentedon Sep 20, 2021
@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 :)
gkellogg commentedon Sep 20, 2021
@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.
mathib commentedon Sep 22, 2021
@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.
Can you give an example here?
gkellogg commentedon Sep 22, 2021
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.