Re: [JSON] Re: Getting started

Hi all,

I find myself completely (!) in agreement with Manu on his responses, including the incomplete ones.

Regards,
Dave
(Chair hat off)



On Feb 24, 2011, at 24:39, Manu Sporny wrote:

> Sandro, apologies because I now realize how confusing some of those
> questions were. I've tried to clarify and add links to make answering
> the questions less painful for other folks:
> 
> http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#Questions_to_Contemplate
> 
> Here's my input so far, I don't feel as strongly as it's probably going
> to come across below:
> 
>> Are we to create a lightweight JSON based RDF interchange format
>> optimized for machines and speed, or an easy to work with JSON view
>> of RDF optimized for humans (developers)?
> 
> We should focus on humans first, machines second. That is, I would like
> to echo what Sandro said. When posed with a path that will make it
> easier for a machine to process the markup, or easier for a developer to
> work with the markup - we should make the developers life easier in
> almost every case.
> 
> I don't think that we need another RDF/XML or N-Triples. I think TURTLE
> is great and is an example of what to strive for - it's simple to author
> for humans. Unfortunately, many Web developers tend to reject TURTLE
> because it doesn't fit into their JSON mindset. We need a JSON
> serialization that isn't going to look too foreign to Web developers -
> in the average case, it shouldn't look much different from what they use
> today.
> 
> Speed and SAX are great, but I think if we were forced to make a choice
> - I'd sacrifice both of those in favor of something that would be easier
> for developers to use. I'd rather have a format that is slow and
> requires multiple passes if it means that twice as many developers would
> use it as their RDF gateway drug of choice.
> 
>> Is it necessary for developers to know RDF in order to use the
>> simplest form of the RDF-in-JSON serialization?
> 
> No. NO. NO! If we require RDF knowledge to use the most simple form of
> this RDF in JSON mechanism, we have failed. The simplest form should
> look exactly like key-value JSON. That is not to say that every JSON
> structure could be mapped to RDF, but many of the more well-designed
> ones could map to RDF.
> 
> We should look at what's popular and figure out how to translate that
> into RDF. We must not attempt to force Web developers into an RDF
> mindset until they're ready to go there.
> 
>> Should we attempt to support more than just RDF? Key-value pairs as
>> well? Literals as subjects?
> 
> There are clever ways that we could support Graph Literals/Graph Tokens
> in JSON-LD. There are clever ways that we could support plain literals
> as predicates. If the need is there, we should try to figure out how to
> fit as many RDF features into the JSON serialization without
> overburdening the format. It will be a difficult balance to strike. The
> assumption is that these "new" features must be supported by RDF.
> 
>> Must RDF in JSON be 100% compatible with the JSON spec? Or must it
>> only be able to be read by a JavaScript library and thus be
>> JSON-like-but-not-compatible (and can thus deviate from the standard
>> JSON spec)?
> 
> RDF in JSON must be 100% compatible with the JSON spec. This may mean
> that we have to sacrifice things like Graph Literals/Graph Tokens as
> predicates - but many people on this list probably want to stay very far
> away from supporting features like that.
> 
>> Must all major RDF concepts be expressible via the RDF in JSON
>> syntax?
> 
> No. It would be nice if it did, but by doing so we might over-complicate
> the language. If we need to decide, we should err on the side of
> providing something simpler that more developers will use.
> 
>> Should we go more for human-readability, or
>> terse/compact/machine-friendly formats? What is the correct balance?
> 
> We should go for human-readability and ease of use in code. Terseness is
> nice, compactness is nice, but JSON already has that naturally - we
> shouldn't disrupt that design. Machine-friendly is at the bottom of the
> list.
> 
>> Should there be a migration story for the JSON that is already used
>> heavily on the Web? For example, in REST-based services?
> 
> Yes. It would be wonderful if we could say that the only thing required
> to migrate JSON to RDF-in-JSON is the definition of a mapping, which
> could be specified either in-band or out-of-band from the data. That is,
> much of the JSON data out there wouldn't have to change at all.
> 
> One of the innovations that has made RDFa initially successful was to
> not force web page authors to drastically change their publishing model.
> RDFa layers on top of HTML. RDF-in-JSON should layer on top of JSON.
> 
>> Should processing be a single-pass or multi-pass process? Should we
>> support SAX-like streaming?
> 
> Ideally, single pass. It would be nice to support SAX-like streaming.
> JSON-LD supports both single pass and SAX-like streaming, but due to a
> number of more complex features, it requires a bit more memory than if
> we were to cut some of those features.
> 
>> Should there be support for disjoint graphs?
> 
> Disjoint graphs are specified here:
> 
> http://json-ld.org/spec/ED/20110201/#disjoint-graphs
> 
> Yes, there should be support for disjoint graphs. Otherwise, data
> gleaned from HTML+RDFa documents, or data that is contained in a graph
> that is not fully connected, cannot be represented. This is a must-have
> feature for PaySwarm. Unfortunately, it makes the JSON-LD markup a bit
> ugly - perhaps there is a better way to do it.
> 
>> Should we consider how the structure may be digitally signed?
> 
> Digital signatures are important - one use case is digitally signing
> financial data and digital contracts represented as graph structures:
> 
> http://purl.org/commerce#Deposit
> 
> Yes. This is also a must-have feature for PaySwarm - mainly because
> we're dealing with Graph Literals/Graph Tokens that contain financial
> data that are temporal, distributed and must be digitally signed. I'll
> elaborate more in a use case.
> 
> Some have asked us why we don't just serialize and digitally sign using
> TURTLE/N3? We could, but requiring TURTLE/N3 just to have something
> digitally signed seems like overkill.
> 
>> How should normalization occur?
> 
> Normalization is required for repeatable digital signatures:
> 
> http://json-ld.org/spec/ED/20110201/#the-normalization-algorithm
> 
> The bad news is that the end result can be really ugly on the eyes.
> 
>> Should graph literals be supported?
> 
> It would be nice. We've gotten away without graph literals only because
> we have designed around the problem. If you looked at how digital
> signatures happen above (http://purl.org/commerce#Deposit) you'll notice
> that we have to embed the signature in the graph we're signing and pull
> the signature out of the graph when we're normalizing and generating the
> hash for the signature. This is a hack - having graph literals would
> allow us to digitally sign the Graph Literal/Graph Token and have the
> signature information exist outside of the graph that is being signed.
> 
>> Should named graphs be supported?
> 
> Depends on what the definition of a named graph is. If a named graph is
> something that points to Pat Hayes non-abstract representation of a
> graph, or Dan's "document", or Nathan's "named graph" - then yes... but
> the JSON in RDF serialization may not care about it. We'll be able to
> talk about this more in time.
> 
>> Should automatic typing be supported?
> 
> Automatic Typing is defined here:
> 
> http://json-ld.org/spec/ED/20110201/#automatic-typing
> 
> Yes, automatic typing must be supported in order to make it easier for
> programmers to interact with these objects.
> 
>> Should type coercion be supported?
> 
> Type coercion is defined here:
> 
> http://json-ld.org/spec/ED/20110201/#type-coercion
> 
> Yes, because type coercion allows more types of plain old JSON to be
> transformed into RDF by merely providing a map of types instead of
> requiring developers to change the data that they're publishing.
> 
>> Should there be an API defined in order to easily map RDF-in-JSON
>> to/from language-native formats?
> 
> Yes, we tried to not have an API. Some serializations of JSON-LD are
> very difficult to work with without this API. Prefix re-mapping for
> example is difficult without an API. I know a goal that we have is to
> make the basics easy to use without an API, which is possible with
> JSON-LD. However, once you buy into full-blown two-barrel RDF, the data
> structures can get cumbersome and an API can help tame most of those
> advanced data structures.
> 
> -- manu
> 
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Towards Universal Web Commerce
> http://digitalbazaar.com/2011/01/31/web-commerce/
> 
> 
> Please consider the environment before printing this email.
> 
> Find out more about Talis at http://www.talis.com/
> shared innovation™
> 
> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
> 
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
> 
> Talis North America is Talis Inc., 11400 Branch Ct., Fredericksburg, VA 22408, United States of America.

Received on Thursday, 24 February 2011 22:28:58 UTC