Re: JSON-LD & nested structure

> On 2016-08-18, at 01:52, Gregg Kellogg <gregg@greggkellogg.net> wrote:
> 
>> On Aug 17, 2016, at 4:33 PM, james anderson <james@dydra.com <mailto:james@dydra.com>> wrote:
>> 
>> good morning;
>> 
>>> On 2016-08-17, at 22:43, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote:
>>> 
>>> […]
>>>> 
>>>> I don't know if the Ruby implementation supports these features yet.
>>> 
>>> I believe I support all of the embedding options that Dave’s does.
>>> 
>>> BTW, on my short-term list is to try to update the Framing spec based on this common behavior.
>> 
>> 
>> if you should get to that, please distinguish between behaviour which concerns or presumes a json data model and that which concerns just the encoding itself.
>> as the document stands, there are aspects which one ignores - with bad conscience, but to advantage, when one has no json data model and there are others which, when they are implemented because they are stated so explicitly, but without a model, are just not a good idea.
> 
> James, I imagine the algorithm to be defined in a manner similar to both the existing, and other JSON-LD algorithms. As framing always involves expansion, the structure of both the frame, and the source document is well defined in terms of expanded JSON-LD.
> 
> Could you provide an example of where the existing text confuses the JSON data model and the encoding? If this is confusing in existing algorithms, can you suggest how that wording might be improved?

while the potential for confusion among an abstract model, a concrete model, and the concrete encoding applies to other issues with the documents, with respect to this issue, the concern is that the framing document presumes a concrete model.
in detail, that it is a “json” model is incidental.

the examples which spring to mind:

- if i have understood the document correctly, it stipulates that as part of the process the data be ordered by id.
there are situations in which it is possible to arrange for that without materializing a model, but that is not always the case.
in other situations, this requirement make it difficult to stream a response encoded as json-ld.

- the @link mode:
> One more thing -- I forgot there's also an "@link" embed option, which
> will cause the output to use direct object references (in-memory links)
> when embedding. This kind of output can't necessarily be serialized due
> to potential circular references, but it is often useful for applications.

- the @last mode presumes there is some state within which a reference is known to be last. @first would be as unfortunate. @never is the only one which makes sense for streamed data.
 
best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com