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).

[gkellogg]

Okay, perhaps because of the original statement, this issue and #430 are confused. #430 is concerned with extending the existing @container mechanism to allow things other than @language and @index to be used as index values. What you're requesting, which is definitely something for us to do in 1.1, is an inverse index, where the container is assumed within the values, and the indexes are the properties. What you seem to want is a "property" that has no semantic meaning (like @index), and the keys of it's value object are treated as properties for which this index is applied. Using something like "property": {"@container": ["@inverse", "@index"]} might be a way to describe this behavior. (Specifices are to be debated, could be @inverseIndex, @inverseLanguage, ... for example, or co-opt the existing @reverse keyword).

I'll move the other discussion to #430.

[lanthaler]

The way I read digikim's comment, this isn't that much about containers, but more ignoring the property/nesting. We could do, something like:

{
  "@context": {
     "@vocab": "http://example/vocab#",
     "group1": "@nesting"
  },
  "@id": "http://example/mything",
  "group1": {
     "a": "Value A1",
     "b": "Value B1",
     "c": "Value C1"
  }
}

which would be equivalent to

{
  "@context": {
     "@vocab": "http://example/vocab#",
     "group1": "@nesting"
  },
  "@id": "http://example/mything",
  "a": "Value A1",
  "b": "Value B1",
  "c": "Value C1"
}

This semantically meaningless nesting is a common pattern in JSON. See for instance _links and embedded in HAL, or properties in Microdata JSON

[niklasl]

That sums it up well I think, @lanthaler. Perhaps though, lingering on the container concept, and specifically to save us from a new keyword, it could be:

{
  "@context": {
     "@vocab": "http://example/vocab#",
     "group1": "@container"
  },

seeing that a "nest" is a kind of container, in a loose sense. Not sure about the clarity, that might be quite some overloading of meaning. Worth to consider though.

[dlongley]

I don't know that we want to reuse @container for this -- as I'm thinking that we may want to reuse whatever we name this in another place where @container may not make much sense at all. Whatever name we pick for this, it could also be used in a feature that is similar to @vocab but where we essentially say: "Don't drop any terms in this document that aren't defined, but also don't give them any semantic meaning (they are for JSON structure only, they're not in the data model)."

In other words, I can see people wanting to be specific about particular structure-only terms -- but they may also want a catch all for this. With that in mind, I think it may be odd to say that every undefined term is a @container. In fact, many undefined terms may only point at values (that would still be preserved by this feature).

[gkellogg]

@container is only used within term definitions now. As I understand @niklasl's thought, @container (or @nesting) would persist in the expanded form, but would be meaningless when generating RDF. Notionally, @container means to (recursively) apply the @id of the containing object to the @container1 values.

The downside is that @container (or whatever we choose) persists when expanding, and you using this in framing might cause some challenges.

Alternatively, @container does lift properties up a level (recursively), but is still not round-tripable.

Creating some kind of inverse container would allow existing practice for @language and @index maps to round-trip. That's where I was going with @container: [@inverse, @index] for example.

If the group doesn't think that round-triping is important anymore, or that preserving @context through both expansion and framing is the way to go, then both @niklasl's and @lanthaler's suggestions might be fairly easy to implement.

[gkellogg]

I've completed an implementation in my library. It uses the @nest keyword, which is transparently removed when expanding data. You can also declare a property "@container": "@nest", which creates the nesting on compaction for all properties that have this container type defined. It uses any alias for @nest which is current in the active context.

I'll work on a PR on top #449.

The following is a description which can go in a "Transparent Nesting" section in the Syntax document:

---

Many JSON APIs separate properties from their entities using an intermediate object. For example, a set of possible labels may be grouped under a common property:

{
  "@context": {
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "labels": "@nest",
    "main_label": {"@id": "skos:prefLabel"},
    "other_label": {"@id": "skos:altLabel"},
    "homepage": {"@id":"http://schema.org/description", "@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"
  }
}

In this case, the labels property is semantically meaningless. Defining it as equivalent to @nest causes it to be ignored when expanding, making it equivalent to the following:

{
  "@context": {
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "labels": "@nest",
    "main_label": {"@id": "skos:prefLabel"},
    "other_label": {"@id": "skos:altLabel"},
    "homepage": {"@id":"http://schema.org/description", "@type":"@id"}
  },
  "@id":"http://example.org/myresource",
  "homepage": "http://example.org",
  "main_label": "This is the main label for my resource",
  "other_label": "This is the other label"
}

Similarly, properties may be marked with "@container": "@nested", to cause them to be nested. Note that the @nested keyword can also be aliased in the context.

 {
   "@context": {
     "skos": "http://www.w3.org/2004/02/skos/core#",
     "labels": "@nest",
     "main_label": {"@id": "skos:prefLabel", "@container": "@nest"},
     "other_label": {"@id": "skos:altLabel", "@container": "@nest"},
     "homepage": {"@id":"http://schema.org/description", "@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"
   }
 }

In this way, nesting survives round-tripping through expansion, and framed output can include nested properties.

[niklasl]

My main (possibly overly frugal) concern was to avoid a new keyword. Roundtripping in some way is valuable, and I think your solution @gkellogg is better.

However, I think the "@container": "@nest" looks a bit strange, seeing as @container has hitherto been used to describe the nature of the (structural) value. Also, perhaps more crucially, I imagine in many (most?) cases you'd like many different "nests". How about using the name of a @nest term as a reference in the terms belonging to it, by using "@nest": "<the-nest-term>"?

Example:

 {
   "@context": {
     "skos": "http://www.w3.org/2004/02/skos/core#",
     "labels": "@nest",
     "linking": "@nest",
     "main_label": {"@id": "skos:prefLabel", "@nest": "labels"},
     "other_label": {"@id": "skos:altLabel", "@nest": "labels"},
     "homepage": {"@id":"http://schema.org/description", "@type":"@id", "@nest": "linking"}
   },
   "@id":"http://example.org/myresource",
   "labels": {
      "main_label": "This is the main label for my resource",
      "other_label": "This is the other label"
   },
   "linking": {
     "homepage": "http://example.org"
   }
 }

Actually, that way it wouldn't even be necessary to declare the nests themselves, other than naming them in the terms belonging to them. But omitting that might make the feature more obscure.

(Note that in theory, I would recommend against "nests" within instance data for this very reason. I'd say that belonging to a nest (group/section/category) in this way is a property of a term (e.g. "prefLabel is part of the 'labels' nest"). That "really" belongs to information at the vocabulary level. Using it at the instance data level sort of conflates data with presentation. But in practice I can see how this would not be considered easy enough, and we know that this design does exist in the wild. So I'm not really against it in practice.)

[asbjornu]

I'm just thinking, wouldn't @ignore be a more versatile keyword to use for the proposed purpose here than @nest? I haven't thought up other use-cases yet, but I imagine there might be situations where @ignore may make sense where @nest won't.

[niklasl]

@asbjornu That sounds more like the already existing mechanism of setting a term to null, which causes expansion to drop it (and its value) entirely.

This use case is about grouping of real terms, and I'm not sure @ignore signals that. We need something to signal an instruction to "traverse", or "descend into" a group, for which @nest seems applicable.

And in my suggested change, it also works in conjunction with the desire to allow round-tripping (actually, for directing the compaction algorithm to perform the grouping), by connecting the term members to each nest.

[dlongley]

I think we used the keyword @preserve somewhere in framing. That's another option.

[asbjornu]

@niklasl: I see, thanks for explaining. I just think @nest is such a narrowly defined keyword that it might be worth exploring other naming options and what use cases they might allow us add support for in the future.

[gkellogg]

Naming is, of course, one of the two hardest problems in computer science 😄.

• @preserve serves a different purpose, IMO, and nesting doesn't seem too much like what @preserve does.
• @ignore is inappropriate (as @niklasl says) as we are not ignoring the content, same with simple non-expansion.
• @nest is at least a stand-in for some term that might represent this unique concept.

As for tying it to the @container mechanism, I do think that it is in line with how @container is actually used now

• Two ways are used for interpreting array values: @set and @list
• Two ways (four now) are used for managing objects used to index other objects: @index, @language, @id, @type.

In this sense @nest is just another way to index into values, most like @index.

That said, using @nest as the property with the value being the term to use for nesting seems reasonable. I'm not keen on using "@nest": "labels", as this inverts the otherwise consistent mechanism for defining terms. But, perhaps the term creation is implicit. This style also allows for compaction to use more than one label for nesting properties.

Perhaps we can get more feedback on two things: the choice of the keyword (@nest, @preserve, ...) and the use of the existing @container mechanism, or introducing a new mechanism within an extended term definition.

Not surprisingly, I prefer the way I stated it.

[gkellogg]

So, having implemented it, @niklasl's variation has the advantage of allowing both contains and nesting to be used. The Expansion algorithm is unchanged from #451. Compaction has a slight difference, but is not significant. @nest does not play a role in term selection when compacting, unlike #451.

[gkellogg]

Looking at some alternatives for @nest:

• @absorb
• @admit
• @assimilate
• @blend
• @collect
• @collapse +1
• @comprise
• @embody
• @enclose
• @encompass
• @fuse
• @grab
• @has
• @hold
• @incorporate
• @involve
• @lift
• @merge
• @nest +1
• @squash
• @subsume
• @takein
• @transparent +1

Please indicate your preference(s).

cc/ @dbooth-boston

[gkellogg]

Also, while we're giving preferences. Please choose between:

• @nest as a container (Ignoring semantically meaningless nesting #246)
• @nest as a term property (Treat reverse term definitions more like regular definitions #253)

[dlongley]

Looking at the commit message:

"This adds a @nest member to term definitions used for transparent properties"

I also nominate @transparent as a possible name.

[workergnome]

@nest makes the most sense to me. Preference to term property over container.

[dbooth-boston]

Some other possible names: @collapse @squash @lift @skip

[squash]

Please don't tag random people.

[asbjornu]

My preference is @collapse. To not tag people, quote the keywords in backticks as such:

`@keyword`

[gkellogg]

@dbooth-boston I added those other than @skip, which would (to me) imply that the content should be skipped, not the nesting. I'm editing the list with stated preferences and new suggestions.

[gkellogg]

When considering names, consider that the term is used for both expansion and compaction. When compacting, it will introduce the layering; it's removed on compacting.

[dlongley]

Text related to this feature that I can imagine making sense to people:

When authoring JSON-LD documents, you may find that you sometimes want certain JSON properties to create structure in your document, but you don't want them to mean anything in the data model. Unforunately, when this happened with JSON-LD 1.0, you had to resort to using a less convenient JSON representation of your data in order to make sure it was JSON-LD compliant.

In JSON-LD 1.1, you can make properties "transparent" by using the @transparent keyword. JSON-LD processors can pass through transparent properties to find other information in the data model without modifying them or disrupting your document. Transparent properties now make it even easier to interpret a JSON document as JSON-LD.

[dbooth-boston]

@dlongley, in your proposed text above, I suggest: s/mean anything/appear/

Also, one other name to consider: @invisible. Then we could say: "You can make properties 'invisible' by using the @invisible keyword".

[digikim]

How about @structure?

[digikim]

(Sorry for tagging by mistake. I used escape before the at sign which was incorrect.)

[niklasl]

I think it is important to convey that these terms are not properties, per se (in the RDF sense, nor in the JSON-LD node sense, I believe). They directly represent a nested structure (somewhat akin to @graph and @context, and @container keys).

So I prefer @nest, used as a term property (if that means that apart from declaring them as nests, we relate terms to be included in that nest using the @nest keyword in term definition, with the intended nest term as value).

(Having thought about it, I strongly think we should keep having them declared explicitly (as @gkellogg also does in the implementation). Otherwise one has to inspect a context at depth to find out if a term represents a nest, instead of just looking up the term to find out what it means.)

[digikim]

Btw, could there be some other JSON structures in addition to "nesting/collapsing" that do not have a semantic meaning in RDF?

Coming back to containers: isn't this the case with index containers too that the keys do not have a semantic meaning in RDF? Therefore, index and nesting are quite close to each others...

Would it make any sense to consider nesting to be a specisl case of indexing where the subject of the indexed (JSON/RDF) object is the same as the parent object?

Container=nestindex or
Container=collapseindex :)

[msporny]

Would it make any sense to consider nesting to be a specisl case of indexing where the subject of the indexed (JSON/RDF) object is the same as the parent object?

Yes, and I'd prefer that this is the case. Can we extend @index with some decoration that asserts what the @id should be set to?

This is what we have today with @index:

  "foo": {
    "@id": "vocab:foo",
    "@container": "@index"
  }

We could add a new mode:

  "foo": {
    "@id: "@id"   <-- means, use the ID on the node as the subject instead of the parent?
    "@container": "@index",
  }

This fits into the @index mental model and doesn't require a new term. Downside is further overloading of @id. However, the more esoteric a use case, the more I think overloading of keywords is acceptable. I've put very little thought into this and haven't read the majority of this thread, so apologies if this is re-hashing something that has already been discussed.

[gkellogg]

Btw, could there be some other JSON structures in addition to "nesting/collapsing" that do not have a semantic meaning in RDF?

Currently, if a property does not expand to an IRI or BNode, it, and it's contents are ignored, so that is a way of having content with no semantic meaning.

Coming back to containers: isn't this the case with index containers too that the keys do not have a semantic meaning in RDF? Therefore, index and nesting are quite close to each others...

The @index mechanism, or similar, can't be used for framing JSON (or RDF) data that doesn't include an index. One of the advantages of the @nest (or @container: @nest) mechanism is that you can take data that doesn't include such non-semantic indexing content, and get it to conform to the structure you want.

Would it make any sense to consider nesting to be a specisl case of indexing where the subject of the indexed (JSON/RDF) object is the same as the parent object?

This is pretty much what the @nest mechanism does, as you can have pretty much any content in there and consider it to be part of the same object. If it was another node object with implicitly the same subject, you would need to flatten to bring the properties together, and you'd still need some property to connect them.

@msporny That mechanism looks pretty confusing to me, and I think we're otherwise settling on PR #453 and just trying to fix terminology. I'd really hate to go back to the drawing board at this time, as this mechanism just works and is nicely orthogonal to @container.

So far, I'm seeing support for the following:

• @nest: +3
• @collapse: +1
• @transparent: +1 (I could be convinced to change to this, as @dlongley's text is interesting, but in the end, a shorter term is easier to deal with!)
• @structure: +1

I propose that we accept PR #453 as is using @nest. Then, if people feel strongly about choosing a different term later on, we can open a new issue for that. Getting this done will allow us to move on to other open issues.

[gkellogg]

At the TPAC discussion on JSON-LD 1.1, there were some complaints on the name of the @nest keyword. I'm re-opening this to allow the CG to re-consider an alternative name for this keyword. The previous issue showed that, among 6 votes, @nest came out ahead, but with more review, something else may emerge.

[gkellogg]

Deferred to WG due to https://json-ld.org/minutes/2018-04-10/#resolution-3.

[gkellogg]

Closed in favor of w3c/json-ld-syntax#3