Re: partial comments on JSON-LD document

On Oct 20, 2012, at 2:32 PM, Peter Patel-Schneider <pfpschneider@gmail.com> wrote:

> I found the following uses of arrays in JSON-LD
> 
> A.0 node definitions
> A.1 @context value
>     @type value    
>     @graph value
>     property value
> A.3 @language value
> A.5 @list value 
>     @set value    
>     @set value part
> A.6 expended term def

Appendix A attempts to relate the grammar of JSON-LD, not the semantics. The semantics are defined in the referenced sections in the body of the document. As such, as Markus indicated, all JSON arrays are to be interpreted as unordered, with the exception of lists, both explicit (using "@list") and implicit, where there is a term definition that defines @container: @list.

This appendix is already pretty long, and the task force resolved to simplify it by moving any non-duplicated examples into the body of the document. IMO, as a grammar, describing the interpretation of the syntactic structures seems either inappropriate or redundant.

> It is especially important that all of these have tests indicating their
> ordered status.   There needs to be discussion of their ordered status in
> the text of the document.

All of the toRdf- tests show that the result of RDF conversion is unordered (i.e., does not use rdf:first/rdf:rest predicates).Those that do use explicitly ordered lists do use rdf:first/rdf:rest predicates. I think that's adequate.

> It seems to me that there are quite a few problems with JSON-LD
> - no definition for @set or @list definitions

Section 3.3 Syntax Tokens and Keywords [1] defines the following:

@list Used to express an ordered set of data. This keyword is described in the section titled 4.9 Sets and Lists.
@set Used to express an unordered set of data. This keyword is described in the section titled 4.9 Sets and Lists.

> - no discussion on multiple node definitions with the same id

True, this becomes apparent when examining the Flatten API method [2] though.

However, I do think that making this explicit in the syntax document is a good idea.

> - no idea of what an array of sets or lists is

Arrays of sets are allowed as a way of providing meaning to legal JSON constructs. It's not called out explicitly within the syntax document. When converted to RDF, the arrays are effectively flattened, making them all objects of the same subject and predicate.

Lists of lists is specifically not supported, and there's an API exception LISTS_OF_LISTS_DETECTED when this is encountered through various API methods. There are also tests which test for this, although we probably need more coverage.

Adding a brief explanation of this to the syntax document discussion of sets and lists is reasonable.

> - no link from array property values to 4.9

>From which section(s)?

> - no idea of how to handle @set or @list values

If by "handle", you mean how to process them, that is pretty explicit in the API document. The syntax document is more concerned with grammar.

> - null values

>From a note in 3.4 [3]:

[[[
The null value is processed in a special way in JSON-LD. Unless otherwise specified, a JSON-LD processor must act as if a key-value pair in the body of a JSON-LD document was never declared when the value equals null. If @value, @list, or @set is set to null in expanded form, then the entire JSON object is ignored. If @context is set to null, the active context is reset and when used within a context, it removes any definition associated with the key, unless otherwise specified.
]]]

The API document has more explicit instructions for processing null, either in the context, or in the body of the document.

> Some things that I noticed:
> 
> JSON-LD allows nested named (and unnamed) graphs!  

This is a syntactic expression, the processing rules flatten this out so graphs do not contain graphs. This is similar to how in Turtle BNode subjects can refer to BNode objects, but the BNodes are in no-way in the context of the original subject.

> "unlabeled node" should be "blank node label"

This is pending other RDF Concept alignment issues. Section 4.12 [4] makes it clear that unlabeled node and blank node are the same thing.

> @graph is not needed "to express a set of JSON-LD node definitions that may
> not be directly related to one another".  This wording should be changed.

It should definitely defer to the RDF Concepts discussion on named graphs, as this is purely a JSON-LD syntactic expression.

> Is there any prohibition on multiple node definitions with the same @id?
> There should not be.  But then, there is no need to call out node
> references.

No, there is no prohibition, and Flatting and Framing explicitly reconcile this.

> Why have both
> "foo" : [ 1, 2, 3 ]
> and
> "foo" : { "@set" : [ 1, 2, 3] }

Purely syntactic sugar, so that {"@set": [1, 2, 3]} parallels {"@list": [1, 2, 3]}. It is removed during expansion.

Gregg

[1] http://json-ld.org/spec/latest/json-ld-syntax/#syntax-tokens-and-keywords
[2] http://json-ld.org/spec/latest/json-ld-api/#flattening
[3] http://json-ld.org/spec/latest/json-ld-syntax/#the-context
[4] http://json-ld.org/spec/latest/json-ld-syntax/#identifying-unlabeled-nodes

Received on Saturday, 20 October 2012 22:20:10 UTC