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