Interpreting keys in a @set as @ids or triple objects (RDF)

[vcharpenay]

I've come across this issue several times while trying to interpret raw JSON as JSON-LD and haven't found any practical solution to it.

Case 1 (index key as @id)

Let's say I have a JSON structure like this (minus the context):

{
  "@context": {
    "ex": "http://example.org/",
    "properties": { "@id": "ex:properties", "@container": "@set" }
  },
  "properties": {
    "foo" : { },
    "bar" : { }
  }
}

In this structure, foo and bar are identifiers for the sub-objects. So I declare "properties": { "@container": "@index" } in my context. However, these IDs are also relevant in RDF and I'd like to keep them while deserializing to RDF. Here is the result I'd like to see (either as blank nodes or as relative URIs, depending on the application):

_:b0 ex:property _:foo
_:b0 ex:property _:bar

I believe I can't do that with the current JSON-LD specification.

Case 2 (index key as triple object)

Similarly, I often need index keys to be turned into triple objects (often in a type statement). The Vehicle Signal Specification (VSS) is a good example. A VSS object is supposed to describe all available signals in a vehicle in a tree structure where branches are vehicle parts. Here is the first level of a typical VSS object:

{
  "children": {
    "Body": {},
    "ADAS": {},
    "Chassis": {}
  }
}

If I had a way to declare that each key should be the object of a type statement, I would then just have to deserialize the VSS object using a context like "@context": { "@vocab": "http://genivi.org/ns/vss#" } to get the following triples:

_:b0 vss:children [ a vss:Body ],
_:b0 vss:children [ a vss:ADAS ],
_:b0 vss:children [ a vss:Chassis ]

Proposal

I believe solving this issue would only require a few declarations in the context (I haven't thought in details about the added complexity on the RDF deserialization algorithm, though).

In the first case, the simplest solution would be to allow "@container": "@id" (blank node IDs or IRIs? Needs to be defined). In the second case. allowing "@container": "@type" would do most of the job since, from my personal experience, this is the case I've encountered the most.

However, if on wants to allow arbitrary properties as predicate, one could allow any IRI in the container definition, like "@container": "https://schema.org/productID". I know there are already a few issues associated to @container (at least #246 and #397) and integrating them all would make things pretty complex. But considering even the first case in JSON-LD 1.1 would be of great help!

[gkellogg]

@vcharpenay Interesting use cases. I'll add it to the list for consideration in 1.1. As you note, the key is to try to do the most good with the least disruption to JSON-LD.

Thanks for taking the time to write up the use cases.

[gkellogg]

This is also related to #195, for having a @graph container type.

Issue #246 it's a couple of issues, including defining arbitrary keys to work similar to @index. A related feature to set @container directly in the context, and use @container: @id to make the top-level object be an @id index.

I can certainly see allowing @content: @id (or @type) in term definitions, and perhaps at the top-level, as something desirable, but need to work through the compaction implications.

[gkellogg]

(Moved from #246).

So, I've spent some time trying to make indexing work for arbitrary keys. While, in principle, it's possible, the complexity for arbitrary properties is proving to be more complex than seems reasonable:

• To understand the expected values of a property, it's necessary to retain the compacted version of that property; this allows you to fine the @type associated with that property to select appropriate values that can potentially be used in a map.
• Potentially, the actual IRI for that property could change, due to an intervening re-definition of the associated term.
• During term selection, each non-keyword property of an object value needs to be compacted to determine if it could be used as a container.

In the end, I think the complexity involved is too great.

I am, however, proceeding to allow indexing on @type and @id.