W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2012

Re: Review: JSON-LD syntax

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 24 Jun 2012 23:30:41 -0400
Message-ID: <4FE7DB61.5040009@digitalbazaar.com>
To: public-rdf-wg@w3.org
On 06/24/2012 05: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 think our definitions are mis-matched, which is why there may be
confusion here. I'm not attempting to state anything deep... just that
you can use a string as a "property" name in JSON.

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


  "a": "b"

This is both valid JSON and valid JSON-LD. The markup above doesn't
generate any triples, but the document does contain data. Maybe we
should call this "text-strings-as-property-names"? It makes sense in
JSON... doesn't have semantic meaning in JSON-LD or RDF... but we
shouldn't make this sort of thing "illegal".

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

For the part of JSON-LD that maps to RDF, none.

However, one /could/ argue that we /may/ decide that
text-strings-as-identifiers makes sense (I doubt it, but it could
happen). We currently allow text-strings-as-property-names because we
don't want to make the majority of currently valid JSON documents
invalid JSON-LD documents. We could also support text-strings-as-types,
numbers-as-identifiers, etc.

I know you asked for "features of JSON-LD" and I assume you meant
"current features"... but these discussions did come up before and there
are a number of things that we could allow in JSON-LD that are not there
in RDF Concepts 1.1... but we're not going there right now because the
use cases aren't there, AFAICT.

I hope this clears things up a bit instead of muddying the waters even
more. In short:

 * If you express something in JSON-LD that doesn't make sense in
   RDF-land, it will be ignored. The only thing I can think of that
   does that right now is text-strings-as-property-names, and the
   reason we do that is to not make most JSON documents illegal
   JSON-LD documents.
 * There are a number of things we could express in JSON-LD that don't
   map well to RDF 1.1 Concepts, but we are trying to not do that unless
   there is a very good reason to do so.

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

It is a valid JSON-LD document. That key, and its associated value will
not result in any Linked Data/RDF output. That is, the key will be
ignored if you convert to RDF.

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

I don't quite follow the statements above. That is, I could interpret
them a variety of different ways and I don't know which interpretation
is the one you mean.

The statements above are correct if I believe that RDF is the only way
to express Linked Data. However, JSON-LD doesn't assume RDF as the
fundamental building block and is not as strict as RDF about what a
property is and isn't... it's just a label on the edge of a graph.
Something else, like RDF, interprets that label in a very specific way.

That is, while what you say above is correct... explaining it in that
way (as a set of pairs) to most software developers could confuse them.

At this point, I don't know where we are in the conversation. Do you
understand what I'm saying? Am I missing a fundamental point you're
making? Are we talking past each other?

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
Received on Monday, 25 June 2012 03:31:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:18 UTC