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

On 06/03/11 20:38, Brian Peterson wrote:
> 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. 

I think this is the case with most specs - people don't read the spec
because they just read a tutorial and download some library that is
conformant with the specification.

> The spec is so simple that intro articles
> tend to be longer than the spec! (http://www.json.org)

Brian - that is not the JSON spec. That is the JSON website, please
don't keep conflating the two. Granted, the IETF JSON specification is
just 10 pages long:

http://www.ietf.org/rfc/rfc4627.txt

If you print out the JSON-LD specification, it's currently 19 pages in
length. 5 of those pages are examples. So, the JSON-LD specification is
14 pages long, the JSON specification is 10 pages long.

Is your concern specification length or complexity?

> Make it explicit that there is a simple JSON-LD, an intermediary
> JSON-LD, and an advanced JSON-LD for the hard cases. 

Are those 3 different conformance levels? What goes in each conformance
level?

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

Typically, when simple specs like JSON-LD do that - you get a number of
non-interoperable implementations. You also eventually get
implementations that end up dominating in the market because they
implement all levels of conformance. There is a set of growing pains
over time that developers have - requiring them to switch parsers as
they find a need for the more advanced features.

> 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

I agree with these parts.

> Use 3 special keywords: @context, @iri, and @type. 

Are you suggesting that we get rid of @base, @profile, @vocab, @literal,
the ability to specify an IRI, @language, and @datatype?

I can see a good argument for getting rid of @base and @profile.

We can say that we won't support @base until there are a larger number
of people that require it.

I think that @profile can be replaced with @context:

   "@profile": "http://example.org/myprofile"

is pretty much the same as:

   "@context": "http://example.org/myprofile"

We could even support multiple profile loading, like so:

   "@context": [ "http://example.org/myprofile1",
                 "http://example.org/myprofile2" ]

Getting rid of @literal and @language would make it impossible to
specify which language a piece of data is in (which is incredibly
important for internationalization). Not allowing people to specify
their native language information is imperialistic. It removes one's
right to express data in their own language in an inter-operable way.

@vocab is how people would use something like schema.org in JSON-LD.
Many people don't want their processors to hit the Web and download a
profile. For those use cases, they can use @vocab or use absolute IRIs
everywhere.

Not being able to specify @datatype makes microsyntaxes for things like
measurements an inevitability. How do you specify "7 meters" across
every language on the planet in an inter-operable way without datatype?
How do you do it without writing an uber-parser for measurements?

Only being able to specify an IRI through a context or profile @coerce
seems overly limiting. If we are going to support @datatype, or @literal
and @language, we might as well support the other native Web type - the IRI.

Thoughts?

> Possibly limit
> contexts as mappings from keywords to URIs, not as namespace prefix
> definitions and CURIEs. 

Contexts /are/ mappings from keywords to URIs. It just so happens that
you can use those keywords as a CURIE prefix. Removing CURIEs entirely
from the specification is an issue for Web Payments and PaySwarm.

> Possibly allow for @coerce in contexts. Possibly
> do not support embedding contexts in your resource (or at least
> discourage it). 

How would we discourage it?

> Do NOT have bnodes. Do not have CURIES. JSON objects are
> resources, array values are multiple values to the keyword property.

If we don't have bnodes, there are a certain class of very important
problems that become impossible to solve. For example:

100 people know the same person, but that person doesn't have an
identifier. How do you represent that without bnodes? That problem is a
fairly basic social web problem.

Here's another issue - if we don't have bnodes, we would have to
generate a unique, dereferenceable  identifier for every digital
signature every created on PaySwarm. This number could be as high as
millions to billions of digital signatures a day. We would have to
define an algorithm that generates these identifiers and ensure that all
implementations run the algorithm correctly. We could do that, or we
could just support bnodes.

CURIEs are optional - JSON-LD makes it so that you don't have to use
them if you don't want to use them. If you want, use a profile and terms
defined in that profile.

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

That's fine, I think that would be a great introduction to JSON-LD.

> It becomes a selling point that the JSON-LD spec is as short as the
> original JSON spec. 

It would be nearly impossible to make the JSON-LD spec as short as the
JSON spec. JSON-LD does a great deal more than just regular JSON. Where
is your waterline between implementable and non-starter?

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

I agree that this is what we should shoot for... how we get there is
what we need to figure out.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Friday, 17 June 2011 16:24:51 UTC