Re: JSON-LD & nested structure

> On Aug 17, 2016, at 5:20 PM, james anderson <james@dydra.com> wrote:
> 
>> 
>> On 2016-08-18, at 01:52, Gregg Kellogg <gregg@greggkellogg.net <mailto: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.

Algorithms are described as working on “language-native” data structures, not JSON.
All algorithms described in this section are intended to operate on language-native data structures. That is, the serialization to a text-based JSON document isn't required as input or output to any of these algorithms and language-native data structures must be used where applicable.

A processor parses JSON into a local data structure and the algorithms work across that deserialized data.

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

Indeed, most JSON-LD algorithms require that all data be deserialized and properly ordered. Most notably, this is a part of Expansion, Compaction, Node Map Generation, To RDF and Context processing. Materializing is certainly required for Compaction and Framing.

In practice, ordering can be relaxed for Expansion when used for RDF generation.

Ordering, and other considerations for streaming profiles, isn’t something we can address in the Framing document, as it depends on the underlying 1.0 algorithms, which do manifest and order. Some consideration for streaming profiles for JSON-LD might be good to address in a next version, and we’re collecting feature requests at http://github.com/json-ld/json-ld.org/issues. However, removing ordering requirements for Compaction and Node Map Generation is likely not feasible if textual reproducibility is needed (which it is now).

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

@last is well-defined due to ordering requirements.

Gregg

> best regards, from berlin,
> ---
> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com <http://dydra.com/>