Why JSON-LD? (was: Re: Agenda: Web Payments Telecon - Friday, February 10th, 2012)

On 02/08/2012 11:55 PM, David Nicol wrote:
>> The PaySwarm spec has been split into three separate documents[1].
>
> Well done! It is much clearer now.

Glad to hear it. :)

> I have noticed that the paragraph introducing JSON-LD is the same as
> the introductory paragraph at json-ld.org <http://json-ld.org>.
>
> Aside from pointing out that data have no agency and thus cannot
> accept help

I'll try and come up with different wording...

> I don't want to criticize this paragraph in this forum

Perhaps the JSON-LD mailing list?

http://lists.w3.org/Archives/Public/public-linked-json/

> The wire-level format for data transmitted within Payswarm is JSON
> (Javascript Object Notation.) Invariant key/value pairs and key names
>  have been selected to conform with JSON-LD, and a schema document
> parseable with JSON-LD tools has been registered with purl.org
> <http://purl.org>.

Hmmm, that's not quite what's going on here. I think Melvin is spot on
when he says that we haven't explained why we're using JSON-LD (and
Linked Data) well enough. We probably should have quite a bit more
reasoning, either in a spec or in a FAQ. To summarize, here are the
three main reasons we use JSON-LD:

* Web-native data model (IRIs as identifiers - good for the Web)
* Works with existing JSON tools (good for Web developers)
* Decentralized Extensibility (good for innovation)

JSON doesn't fit the first and last bullet point well. The other Linked
Data formats don't fit the second bullet point well.

JSON-LD uses IRIs for identifiers, which means that it supports
follow-your-nose (the ability to start at one document and discover
other resources by de-referencing links to other documents). This sort
of dereferencing is at the heart of decentralized systems and is used
extensively in the PaySwarm specs.

JSON-LD was designed to be compatible with the existing JSON toolchains
and layer on top of regular JSON documents if necessary. It was designed
to give Web developers access to Linked Data without requiring them to
learn a great deal about it. JSON-LD is basically the power of a
graph-based data structure, expressed as simple key-value pairs.

Since JSON-LD uses IRIs for object properties, you can expand the
functionality of a JSON-LD document without worrying about property name
clashes or if the system will accidentally use the term you use in the
future. JSON-LD provides a future-proof mechanism for expanding the
functionality of the objects used in PaySwarm (things like Assets,
Transfers, Transactions, Listings, and Contracts).

All of these come into play when you want to innovate on top of the
platform - it's just something that regular JSON does not do a very good
job at. Yes, you can quarantine a part of a JSON document off and state
that "any extensibility stuff goes here", but that's not a very elegant
solution. JSON-LD is elegant in that it allows you to extend the
document where it makes the most amount of sense for your application.
It allows innovation at the edges and if the innovation becomes
mainstream, it allows that innovation to be absorbed into the
standardized system without breaking backwards-compatibility with the
documents that are already out there.

At this point, you are either nodding your head in agreement, or you
don't think what I'm saying makes one bit of sense. In the latter case,
you may want to read the JSON-LD Requirements document:

http://json-ld.org/requirements/latest/

and the JSON-LD Syntax specification:

http://json-ld.org/spec/latest/json-ld-syntax/

I don't promise that those documents will shed any further light on the
situation... but they might help you understand the possibilities with
Linked Data vs. regular JSON.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/

Received on Friday, 10 February 2012 01:20:34 UTC