Re: [JSON] Re: Getting started

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/

Received on Thursday, 24 February 2011 05:40:02 UTC