- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 09 Feb 2012 20:20:04 -0500
- To: Web Payments <public-webpayments@w3.org>
- CC: opentransact@googlegroups.com
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