2019-02-08-action1: explore effect of @nest+@container:@id on compaction and expansion (Gregg Kellogg)

[iherman]

explore effect of @nest+@container:@id on compaction and expansion (Gregg Kellogg) (see details)

Cc: @gkellogg

[azaroth42]

cc: @pchampin

Merging the two actions

[pchampin]

Just to be sure I grasp all the implications here: is there currently a way to generate @nested properties with framing? I tried a few things in the playground, but with no luck.

[gkellogg]

Yes, it’s done during compaction. If the playground doesn’t do it, try my distiller. This is where the @nest in a term definition comes in.

[pchampin]

Ok, my bad, it works in the playground (and in your distiller indeed). I was just writing the frame the wrong way...

[gkellogg]

I looked at this in the context of the Expansion Algorithm. That algorithm finds keys which are aliases of @nest, and adds them to a hash nests, which is processed later on in the algorithm. That algorithm basically recursively looks at values and adds them to keys in the expanded result.

For this to work with something like @container: @id, it would need to have access to a separate structure (@included) which contained a hash with these ids as keys and do something similar. This would require some substantive changes to the algorithm, which would likely involve a step at the top level to identify the key used as this map and use it for processing other keys in that object, as well as embedded arrays and objects to make it available. Possible, but somewhat of a big change, also makes streaming difficult, although ensuring that this @included is appears along with other keywords (or aliases of keywords) before others would probably handle this.

The Expansion algorithm in step 9.16 would then determine if the original key which was aliased to @nest was also @container: @id (or, perhaps, @container: @included) and would then look for values which are keys in the referenced @included dictionary to work over, the way that other @nest properties are handled.

I can't really see how Compaction could undo this, so we loose the symmetry. Certainly, something could be done in Framing, in which the @included block would need to be part of the frame, and the process of framing values would need to inspect to see if values are contained in the @included dictionary and not serialize them. This could become quite complex, given the types of things which might be in an @included dictionary.

[pchampin]

I roughly came to the same conclusion, although I followed a slightly different path:

• I imagined that the "@included" key in the expanded form would contain an array of node objects (similar to "@graph").
• I imagined that each such node object would contain a member "@included": "theProperty" to allow compaction to "put them back" in the correct "nested container" property.

But all this would add too much complexity to the algorithms. All the more that it would allow more genericity than what is required by the initial use case: the @included member could appear at any level in the JSON tree. But as far as I can tell, w3c/json-ld-syntax#19 only requires the ability to have it at the root level.

So if we want address w3c/json-ld-syntax#19, we are better off with a specific keyword than trying to piggyback on @nest and @container:@id, as attractive as this generalization might have looked.