json-ld / json-ld.org

JSON for Linked Data's documentation and playground site
https://json-ld.org/
Other
856 stars 152 forks source link

Feature request: Mechanism for mapping JSON property to RDF property path instead of just single property #736

Open jakubklimek opened 4 years ago

jakubklimek commented 4 years ago

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.

gkellogg commented 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.

mathib commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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?

gkellogg commented 2 years ago

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"
  }
}