This adds a @nest member to term definitions used for _transparent properties_

[gkellogg]

This introduces the @nest keyword, used for folding contained properties to the enclosing node object, and allows for @nest in a term definition, to introduce such nesting when compacting.

Fixes #246. This also is an alternative to PR #451 and is (mostly) independent of #449).

In contrast to #451, having a parallel @nest term definition property allows this to be used in conjunction with @container (but not for @reverse compaction).

There are several new expand, compact and error tests for this feature.

Formatted HTML versions are available for JSON-LD, and JSON-LD-API on my personal fork.

[davidlehn]

move up sorted with other @ values

[gkellogg]

Good call, the @ was added later. Should be good now.

[davidlehn]

move up sorted with other @ values

[dbooth-boston]

It may be worth considering a different keyword, instead of @nest, in case the ability to handle semantically significant nested properties is eventually added to JSON-LD, such as distinguishing the different uses of the "location" property below (vehicle.location versus file.location):

{
  "@context": ...
  vehicle: {
    make: "Honda",
    location: "123 Main Street, Cambridge MA"
  },
  file: {
    type: "text/html",
    location: "/tmp/foo.html"
  }
};

It seems like the functionality in this PR is more akin to 'flatten'. Not sure what other keywords might chosen instead.

[gkellogg]

@dbooth-boston Flattening is an entirely different concept, which takes nested node definitions and flattens them so that nodes only reference other nodes, rather than include them.

@dlongley suggested @preserve, but that has a different use in framing.

However, the use case you may be looking for could be handled using scoped contexts, there interpretation of "location" is different for "file" vs "vehicle". This was the subject of a recently merged change. But, that does imply that both "file" and "vehicle" refer to different entities, rather than are each properties of the containing node, which is more consistent with what I think you want.

As for a @nest alternative, I'm open to suggestions.

[dbooth-boston]

I was thinking of _.flatten from http://underscorejs.org/#flatten -- not the JSON-LD concept of flattening. I should not have used that word. Sorry for the confusion!

Yes, the use case I was mentioning would be the ability to distinguish between properties (of the same name) by their object ancestors, as illustrated above. This came up a couple of years ago when we were originally trying to see if FHIR/JSON could be adapted to be JSON-LD. We concluded that it could not without either changing the existing property names or inserting additional @contexts into the instance data -- neither of which would be palatable to the vanilla FHIR/JSON folks.