Ignoring semantically meaningless nesting

[digikim]

Thanks for the great work with JSON-LD! However, when trying to use JSON-LD for to present data in the company I'm working in, I noticed the following missing feature:

FEATURE PROPOSAL: ABILITY TO DEFINE ANY KEY AS AN INDEX KEY

In addition to JSON-LD's existing index container structure, I propose that any key under a JSON-LD node could be defined as a index key.

This would help clustering data under a node into coder friendly logical groups without messing up the Linked Data interpretation with e.g. blank nodes. I encountered the need for this feature at our company where our problem is that the amount of attributes a single JSON-LD node can have can potentially be quite many, say, tens or hundreds of attributes.

As far as I know, this can not be currently done with JSON-LD without 1) ending up with blank nodes or 2) the need to create a deeper JSON structure by using a separate index term (using "@container":"@index") which then contains the data underneath.

In addition, if a single key could be defined as a index term, this would make it more flexible to attach the JSON-LD Linked Data interpretation to even a wider amount of existing JSON data, without having to change the structure of such data (and without ending up with e.g. lots of blank nodes).

DEFINING AN INDIVIDUAL INDEX KEY IN @context

The "@context" definition could be done e.g. using the existing reserved keyword "@index" in the following way:

"indexkey":"@index"

which should be interpreted in the following way: 1) the "indexkey" is an index key and should be skipped when traversing the JSON tree while doing the JSON-LD to RDF interpretation, 2) any data directly under the "indexkey" should be interpreted as data directly attached to the node of the indexkey (same RDF subject).

EXAMPLE

To give a full example, in the following a single key "labels" is defined as an index index key to help grouping the data into coder friendly logical groups without messing up the Linked Data interpretation):

{
  "@context": {
     "labels":"@index",
     "main_label":"http://example.org/my-schema#main_label",
     "other_label":"http://example.org/my-schema#other_label",
     "homepage":{ "@id":"http://example.org/my-schema#homepage", "@type":"@id"}
  },
  "@id":"http://example.org/myresource",
  "homepage": "http://example.org",
  "labels": {
     "main_label": "This is the main label for my resource",
     "other_label": "This is the other label"
  }
}

This example JSON-LD should generate the following RDF triplets:

<http://example.org/myresource> <http://example.org/my-schema#homepage> <http://example.org>. 
<http://example.org/myresource> <http://example.org/my-schema#main_label> "This is the main label for my resource".
<http://example.org/myresource> <http://example.org/my-schema#other_label> "This is the other label".

[gkellogg]

There are several reasons why this might be a good idea, although it's pretty late in the process to be making such changes. Unfortunately, it's not as simple as setting "indexkey": "@index", as this syntax is what creates a keyword alias, but it might be done with a container-mode, for example:

{"@context": {"indexkey": {"@container": "@reverseindex"}}

This would allow us to handle JSON syntaxes such as Microdata-JSON, which use a "properties" keyword and store all the properties underneath:

{
  "items": [
    {
      "type": [
        "http://schema.org/Person"
      ],
      "properties": {
        "name": [
          "Jane Doe"
        ],
        "image": [
          "http://example.com/janedoe.jpg"
        ],
        "jobTitle": [
          "Professor"
        ],
        "address": [
          {
            "type": [
              "http://schema.org/PostalAddress"
            ],
            "properties": {
              "streetAddress": [
                "\n      20341 Whitworth Institute\n      405 N. Whitworth\n    "
              ],
              "addressLocality": [
                "Seattle"
              ],
              "addressRegion": [
                "WA"
              ],
              "postalCode": [
                "98052"
              ]
            }
          }
        ],
        "telephone": [
          "(425) 123-4567"
        ],
        "email": [
          "mailto:jane-doe@xyz.edu"
        ],
        "url": [
          "http://example.com/www.janedoe.com"
        ],
        "colleagues": [
          "http://example.com/www.xyz.edu/students/alicejones.html",
          "http://example.com/www.xyz.edu/students/bobsmith.html"
        ]
      }
    }
  ]
}

In this case, aliasing "items" to "@graph", "type" to "@type", "properties" as a reverse index and "@vocab" to http://schema.org/ would pretty much just make this valid JSON-LD.

If we were going to make some changes to the spec, we could also re-consider something like id-maps "@container": "@id", which would allow a top-level object with indexes treated like "@id" properties within objects (See issue#134). This would make JSON-LD essentially a super-set of RDF/JSON. To do it, "@container" would need to be used as an outter keyword within a context, such as the following:

{
  "@context": {
    "@container": "@id"
  },
  "http://subject": {"http://predicate": "http://object"}
}

A similar idea was rejected in September: http://json-ld.org/minutes/2012-09-04/#resolution-1

[digikim]

Thanks for the good remarks and the excellent example, @gkellogg!

Of course, this is "only" a syntax question, but I think the suggested "@container":"@reverseindex" structure seem slightly complicated. How about defining instead a new term @keytype for defining the type of the key and use it as follows:

{"@context": {"indexkey":{"@keytype":"@index"}}}

with a shorthand representation:

{"@context": {"indexkey":"@index"}}

The keyword @type is used in @context context for defining the type of the value so I think this @keytype would be quite logical and would avoid defining a reverse keyword like @reverseindex.

Regarding the alias issue: @index keyword is only used inside @context and therefore I don't see why it should be needed to make an alias of the @index keyword. I think the alias mechanism is only relevant when the aliased keywords will be used outside the @context definition (e.g., alias of @id or @type).

[RickMoynihan]

@gkellogg Wondering if the @reverseindex idea is on the roadmap for inclusion or not. I have a use case for something like this too with RDF data cubes. Basically qb defines a component spec, and I'd like to generate the triples for that, but not disadvantage JSON users with what to them will be a relatively pointless level of indirection, when accessing dimension @ids.

[gkellogg]

Hi Rick, @reverseindex is definitely up for consideration in a 1.1 CG spec; just haven't had time to work on details myself just yet.

[gkellogg]

For a first-cut at implementing this, I'm expanding @container within the context, to include @id and @type in addition to @set, @list, @index, and @language. I'm also allowing any absolute IRI or Blank Node label. For @id, @type, IRI and BNodes, this would allow any object containing an IRI or BNode value (node reference) to be used as an index value. For example:

{
  "@context": {
    "@vocab": "http://example/",
    "idindex": {"@container": "@id"},
    "typeindex": {"@container": "@type"},
    "iriindex": {"@container": "prop"}
  },
  "idindex": {
    "a": {"label": "Object with @id 'a'"},
    "_:b": {"label": "Object with @id '_:b'"}
  },
  "typeindex": {
    "a": {"label": "Object with @type 'a'"},
    "_:b": {"label": "Object with @type '_:b'"}
  },
  "iriindex": {
    "a": {"label": "Object with <prop> 'a'"},
    "_:b": {"label": "Object with <prop> '_:b'"}
  }
}

Which would expand to something like the following:

[{
  "http://example/idindex": [
    {"@id": "a", "http://example/label": [{"@value": "Object with @id 'a'"}]},
    {"@id": "_:b", "http://example/label": [{"@value": "Object with @id '_:b'"}]}
  ],
  "http://example/typeindex": [
    {"@type": "a", "http://example/label": [{"@value": "Object with @type 'a'"}]},
    {"@type": "_:b", "http://example/label": [{"@value": "Object with @type '_:b'"}]}
  ],
  "http://example/iriindex": [
    {"http://example/prop": "a", "http://example/label": [{"@value": "Object with <prop> 'a'"}]},
    {"http://example/prop": "_:b", "http://example/label": [{"@value": "Object with <prop> '_:b'"}]}
  ]
}]

There are corner-cases for expansion when the property used as an index also appears within the object value. And for compaction, when the index item has more than one value, or value is not an IRI or Blank Node (either it's an error, or use the first value as an index based on input ordering).

Note that this does not yet consider @reverseindex.

[gkellogg]

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 which is also requested in #430.

[digikim]

Thank you very much for considering the feature suggested in the opening of this thread (and in different forms by others, too). It has been a few years since I wrote the opening to this thread so remembering the details took some time. The original idea was, as I interpret myself :), the following:

Problem: How to make it possible to group JSON-LD properties (especially if the RDF subject object contains hundreds of properties).

Solution suggestion (trying to reformat it to make it more clear and easier to understand, with some new suggestions):

{
  "@context": {
     "@vocab": "http://example/vocab#",
     "group1": { "@container": "@group"},  // for example, lets call it a "@group" ?
     "group2": { "@container": "@group"},
     "group3": { "@container": "@group", "@vocab": "http://example/vocab2#" }, // vocabulary override
     "group4": { "@container": "@group", "f": "http://example/vocab3#something" } // vocabulary override
  },
  "@id": "http://example/mything",
  "group1":{  // no RDF semantic meaning
     "a": "Value A1",
     "b": "Value B1"
     "c": "Value C1"
  },
  "group2":{  // no RDF semantic meaning
     "c": "Value C2",
     "d": "Value D2"
  },
  "group3":{  // no RDF semantic meaning
     "d": "Value D3"
     "e": "Value E3"
  },
  "group4":{  // no RDF semantic meaning
     "f": "Value F4"
  }
}

Which would generate the following RDF triplets:

<http://example/mything> <http://example/vocab#a> "Value A1".
<http://example/mything> <http://example/vocab#b> "Value B1".
<http://example/mything> <http://example/vocab#c> "Value C1".
<http://example/mything> <http://example/vocab#c> "Value C2".
<http://example/mything> <http://example/vocab#d> "Value D2".
<http://example/mything> <http://example/vocab2#d> "Value D3".
<http://example/mything> <http://example/vocab2#e> "Value E2".
<http://example/mything> <http://example/vocab3#something> "Value F4".

If both groups contains a key with the same IRI interpretation, this would create two RDF triplets. By allowing vocabulary overrides, the property IRIs could be different between groups.

Do you think this could work? As far as I know, this can not be made with the current version of JSON-LD (although I have not been working that much with JSON-LD for the past year or so, so I am a bit rusty in JSON-LD at the moment).