RE: Comments on the complexity of the JSON-LD spec

I wish it were so, but I just can't agree. I might have agreed with you 2
years ago, but not now. If a developer hasn't, it's because JSON is so
simple they don't need to. The spec is so simple that intro articles tend to
be longer than the spec! (http://www.json.org)

 

Make it explicit that there is a simple JSON-LD, an intermediary JSON-LD,
and an advanced JSON-LD for the hard cases. Allow tools and utilities to be
compliant with the various levels of standards, letting them expand to
support the hard cases when there is a need. Allow the average developers to
understand as much as they need, without cluttering with cool features or
border cases. Make it so that a developer that knows JSON can understand
what JSON-LD is doing without any reference documents:

 

Use 3 special keywords: @context, @iri, and @type. Possibly limit contexts
as mappings from keywords to URIs, not as namespace prefix definitions and
CURIEs. Possibly allow for @coerce in contexts. Possibly do not support
embedding contexts in your resource (or at least discourage it). Do NOT have
bnodes. Do not have CURIES. JSON objects are resources, array values are
multiple values to the keyword property.

 

Now an average developer can look at this kind of JSON-LD object and pretty
much see what it is doing - except for the 3 '@' keywords it's just JSON.
They probably ignore the @context (and it is easy to ignore because it is
just a link). Possibly someone tells them @iri is the IRI for your resource.
They might need someone to say "@type is like Microdata ITEMTYPE or RDFa's
@type". And that's it. 

 

It becomes a selling point that the JSON-LD spec is as short as the original
JSON spec. But you leave the door open to doing much more. It is so simple
that there isn't any reason _not_ to do JSON-LD if you are doing JSON. 

 

BP

 

From: public-linked-json-request@w3.org
[mailto:public-linked-json-request@w3.org] On Behalf Of Dave Longley
Sent: Friday, June 03, 2011 5:50 PM
To: public-linked-json@w3.org
Subject: Re: Comments on the complexity of the JSON-LD spec

 

On 06/03/2011 02:24 PM, Brian Peterson wrote: 

I believe that the popularity of JSON is based primarily on its simplicity.
IMHO, JS developers and other consumers of JSON are going to expect
simplicity. A JSON-LD specification that is 10x longer than the original
JSON specification is going to be a non-starter for the majority of JSON
developers - a big majority. Honestly, I think the first JSON-LD spec should
fit in an email (a short email, unlike the ones I tend to write).


I definitely agree that much of JSON's popularity is due to its simplicity.
However, my opinion is that most JS/JSON developers probably haven't looked
at the JSON spec. Most JS developers certainly haven't looked at the
ECMAScript spec.

If a developer does have a question, then I'd expect them to be much more
likely to look at examples on the web or a "howto" page than the spec. I
don't think we should confuse the JSON-LD specification with a primer or
document that shows consumers how to use JSON-LD. The spec doesn't have to
be and probably shouldn't be that primer. The spec is for implementers of
the tools that JSON-LD consumers will use. For consumers, there can be as
many or as few example web pages or primers as are necessary to break up the
complex from the simple features of JSON-LD.




I got through sections 1 and 2 only because I'm familiar with W3C
specification documents, but you started to lose me around section 2.4. I
scanned over section 3 and landed on 3.3, Microdata, only because I just
heard about schema.org. My thoughts reading that section is that the authors
of JSON-LD didn't take into consideration that URIs might work in Microdata
because it is HTML based, but they don't fit as keywords in JSON. Developers
never use URIs as keywords in JSON.


URIs as properties was actually one of the most discussed issues when
designing JSON-LD. I'd say that there's significant agreement within the
JSON-LD community that using URIs as keywords is a largely foreign concept
to JS/JSON developers. This was one motivation for creating the @context
feature in JSON-LD. Over time, various methods have been discussed for
mapping keywords to URIs using this feature, and the current revision of the
spec lets you specify whatever keyword or CURIE (if you are comfortable with
CURIEs) mappings you want to. You can also annotate existing JSON objects
with a JSON-LD @context after the fact. This allows you to specify which
vocabulary term to map each keyword to so that your object can then be used
as Linked Data.




 

Then you lost me at section 4. A processing algorithm for a JSON-based
format that requires 12 term definition, 11 specialized keywords, and 20
steps is just a non-starter. I'd use it if my team lead made me, but I would
never chose to include it in a service I'm developing. 


Consumers of JSON-LD never need to know that that algorithm is being used.
Only someone who is implementing a JSON-LD processor needs to know about it.
A JSON-LD processor may take JSON-LD as input and output a list of triples.
My guess is that most simple consumers of JSON-LD would not be working with
lists of triples anyway, but even if they were, they would never need to
know the algorithm that was used to convert JSON-LD to such a list. All they
would do is make an API call. Think of it this way, in order to consume JSON
you don't need to know all of the steps necessary to write a JSON-parser.
You just call JSON.parse().

-Dave



-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com