describing property-based indexing as a variant of data indexing

[pchampin]

---

Preview | Diff

[gkellogg]

Looks like the Travis config needs a tweak; I’ll look into that.

[gkellogg]

We'll also need to update the definition of @index to show that it can be used in this way, and the grammar section on term definitions.

[pchampin]

We'll also need to update the definition of @index to show that it can be used in this way, and the grammar section on term definitions.

Yes, but we should probably discuss before on a call whether we want to keep @index or introduce another key (you and @iherman seemed to have hesitation about reusing @index here.

[gkellogg]

As I'm implementing this, I note some other things that seem to be requirements, or if not, add much more complication:

Consider the following example:

{
  "@context": {
    "@version": 1.1,
    "@vocab": "http://example.com/",
    "author": {"@container": "@index", "@index": "prop"},
    "prop": {"@type": "@vocab"}
  },
  "@id": "http://example.com/article",
  "author": {
    "regular": {"@id": "http://example.org/person/1"},
    "guest": [
      {"@id": "http://example.org/person/2"},
      {"@id": "http://example.org/person/3"}
    ]
  }
}

• We actually need to use the term definition for the @index value, so that we know how to interpret string values of the map. So "regular" and "guest" are expanded as vocabulary-relative IRIs.
• You can't use a property to index a value object, so if in the above example, the values of "regular" and "guest" were't node objects (or strings which expand to node objects or graph objects), it would be an error.
• When compacting, we need to remember "prop" as a term, rather than it's expanded value; this way, we can find values of that term to extract for indexing.

Additionally, a node object containing both @graph and some other property is not a graph object, as defined in the spec. Therefore, indexing can't apply if @container includes both @index and @graph and @index is defined on the term. Logically, this might work, but it would wreak havoc on the already overly complicated compaction algorithm, where the notion of graph object and simple graph object come into play.

There are likely more complications, and possibly some corner cases I've neglected.

[pchampin]

Gosh, I knew a bunch of worms were lurking from inside that shiny can!

Regarding the values in the index map, I'm ok to contrain them to be simple object nodes (no @graph, non @value).

Regarding the property used for indexing, my idea was that it would always have simple string values. It is tempting to use vocabulary-relative IRIs, but is there a real use case for that (beyond type indexing or id indexing)?

I think I would prefer to keep term definitions out of the picture for the indexing property, because they would bring too much complexity and too many corner cases (@reverse?). We could even require the value of @index to be an absolute IRI. This would be ugly and inconvenient, but it would hopefully prevent users from expecting a term definition to apply (although one could of course still try to add a term definition identified by the full IRI...).

When compacting, we need to remember "prop" as a term, rather than it's expanded value; this way, we can find values of that term to extract for indexing.

Sorry, I don't get it. In the expanded form, we only have expanded values, right?

[gkellogg]

I think keeping them as term definitions works. The important thing is that, in the compact view, the value of the property is expressed as a string.

The point on prop being a term when compacting is so that we know how to compact the value of "prop" to use as an index. Of course, if we only allowed simple values we could avoid this, but it seems to me to be useful to allow anything that compacts as a string to be used as an index. The main complicating area is for named graph indexing, but I think this is a vanishingly small use case.

I did consider that as an alternative to leveraging "@container": "@index", and using an "@index" value, we could allow "@container": "prop", where "prop" is a term or expands to an IRI. There's not a lot of shared logic in the algorithms for the property-index vs. @index use cases.

[gkellogg]

Okay, I think that this, and w3c/json-ld-api#78 are ready. We can always tweak further.