Re: Review: JSON-LD syntax

On Jun 24, 2012, at 2:27 PM, Andy Seaborne wrote:

> 
> 
> On 23/06/12 20:47, Manu Sporny wrote:
>>> S3.1 "A property SHOULD be labeled with an IRI" : how come it is not
>>>> a MUST? What else could they be?
> 
>> In JSON, a property can be a plain literal, and it's perfectly valid.
>> Making this a MUST needlessly restricts the language in the event that
>> somebody finds a use for plain-literals-as-properties in the future. In
>> fact, all of JSON's properties are plain literals, so you could say that
>> the use case already exists.

I actually don't think that this is correct. A property can be any string, but only strings which map to absolute IRIs are treated as predicates. This means that a property that is not mapped can be used, but is just a string, and is dropped when performing expansion. Saying that the key is a literal is not correct, IMO.

>From The Expansion Algorithm [1] 2.2.2:

[[[
If property does not expand to a keyword or an absolute IRI (i.e., it doesn't contain a colon), continue with the next property from element.
]]]

Since every algorithm described for JSON-LD uses Expansion, this effectively eliminates literals from being property values. However, it can be a named blank node (e.g., _:a), which could be considered a predicate, even though it's not valid RDF.

> What's the use case for literals-as-properties?

None that I'm aware of. 

> If it's for the future, what other features of JSON-LD are there that 
> are beyond RDF 1.1 for future proofing?

Basically, potential use of BNodes as predicates and as the value of an rdf:Type. Also, the use of Quads instead of Triples, which IMO, should be in RDF Concepts.

> What is the status of a document with @context that does not map some 
> key name?

Presuming you mean a document having an @context that does not contain a map for a key that does not have the form of an absolute IRI. Per the note above, it is dropped when expanding, and thus when transforming to RDF.

> At least a second Note is needed in section 3.1.

Considering that it doesn't, in fact, allow literals, I think we're okay.

> A property isn't just a label - it defines a set of (subject, object) 
> pairs on which it is true.
> 
> A literal defines a mapping from lexical to value space.
> 
> (Maybe defining it's value to be pairs works - I don't know - it may 
> possible because the requirement is that <I(s),I(o)> is in IEXT(I(p)).)
> 
> But as things currently stand, properties are URI as everyone agrees on 
> the meaning of the relationship so even from a non-technical point-of- 
> view this is quite important.
> 
> (it also means that there are some JSON-LD documents that can't be 
> represented as RDF)
> 
> 	Andy

It was never the intention to limit JSON-LD documents to just what RDF can represent, but I would expect that this would be the norm. In particular, we want to allow the use of JSON when does not map to RDF to allow for the use within other embedded APIs that may contain information that is not linked data.

The only way to generate Quads or Triples that are not RDF, that I can think of, is the use of BNodes as predicates, datatypes or types.

However, JSON-LD is not alone in this: RDFa uses TERMorCURIEorAbsIRI for @property, @rel, @rev and @datatype and @typeof, which includes _:a as a CURIE.

Gregg

[1] http://json-ld.org/spec/latest/json-ld-api/#expansion-algorithm
>

Received on Sunday, 24 June 2012 22:33:59 UTC