Re: [JSON] Re: Getting started

On Sat, 2011-02-19 at 22:35 -0500, Manu Sporny wrote:
> On 02/17/2011 12:04 PM, Guus Schreiber wrote:
> > - Please consider signing up for a task force [1]
> 
> I've added a section for participants on the JSON RDF Task Force wiki page.
> 
> > - I've created wiki pages for the task forces [2]. Feel free to add
> > inputs you think are missing. I suggest you send email to the list in
> > case you add stuff.
> 
> I've copied the RDF in JSON inputs to the task force page, added a
> participants section and a deliverables section. I also added a
> "Questions to Contemplate" section in the wiki and filled it out with a
> few questions that will get the discussion started.
> 
> http://www.w3.org/2011/rdf-wg/wiki/TF-JSON
> 
> Here are the questions in case folks want to start chiming in on this
> mailing list:

Nice list.

> Is it necessary for developers to know RDF in order to use the simplest
> form of the RDF-in-JSON serialization?

Fairly strong no.   They shouldn't have to know about bnodes or language
tags or all the datatypes, for instance.  

> Should we attempt to support more than just RDF? Key-value pairs as
> well? Literals as subjects?

Tough question.  I think the arguments are:

- don't go beyond RDF, because if you do, then RDF software wont know
what do with that extra stuff
- do, because it's very hard to map many existing json structures, eg
ones using numbers and meaningful strings as keys, into RDF

In other words, on this, I think we're torn between the RDF data
consumers and the JSON data producers.

> Must RDF-in-JSON be 100% compatible with JSON (aka: JSON-P)? Or must it
> only be able to be read by JSON and can thus deviate from the standard
> JSON spec?

I don't understand this one.   It should be readable by every conformant
JSON parser (not just javascript engines), which I would think would
mean it would follow the standard.    I think of JSON-P as just wrapping
a JSON expression in a function call, so I don't really see the
connection.

> Must all major RDF concepts must be expressible via the RDF-in-JSON syntax?

I'm torn between "yes" and "all the ones we don't deprecate".

(My main point in the design of JRON was to show you could include all
of RDF without particularly burdening people with features they didn't
want.)

> Should we go more for human-readability, or
> terse/compact/machine-friendly formats?

I think this is more than a 2-way trade-off.   

- terse: least important
- easy for people to read: medium important
- fast to access via code: pretty important
- easy to access via code: very important

(I'm saying "access via code" instead of "parse", because my expectation
is that people will simply write their code to use the json structure
directly in many cases.)

> Should there be a migration story for the JSON that is already used
> heavily on the Web? For example, in REST-based services?

Yes.   I think existing JSON data sources that are sufficiently well
modeled to be "almost" RDF should be able to be converted to being
really JSON RDF with very little effort.    

I'm interested to explore the possibility of "normal" JSON data sources
becoming "rdf" JSON data sources without any bytes changing.  This could
be done by having an adjacent URI declare some namespaces and possibly
other mapping information.   Maybe it could also be done by using a
central registry of namespace prefixes.  [!!]


> Should processing be a single-pass or multi-pass process? Should we
> support SAX-like streaming?

You mean, like, do the namespace declarations have to go at the front?

I guess I think streaming / single-pass is nice, but not a very high
priority.   

I see only two ways to put namespace declarations at the front, neither
of which I like:

1.  make the outermost container an array
2.  suggest people do an ordered serialization, putting certain
dictionary keys at the front, if they want the data to be
stream-processable.

Or, I guess, we could do without namespace declarations.

> Should there be support for disjoint graphs?

I don't understand this question.   Perhaps we should wait until the
graphs TF settles the nomenclature before getting into this.

> Should we consider how the structure may be digitally signed?

I don't think so.  It can be signed as bytes using normal technology and
signed as RDF using RDF signature technology (is anyone doing that); I
don't think we need a third intermediary mechanism.

> How should normalization occur?

I'm not sure what you mean by normalization.

One thing that comes to mind is that I imagine RDF being serialized with
one set of namespace prefixes and the consumer wanting to use known
namespace prefixes when accessing it, so there's a "reprefix" step the
consumer has to do first.   That's something people would need to
understand, but I don't think the spec would need to constrain it in any
way.

> Should graph literals be supported?

Probably, yes, but let's wait for the Graphs TF.

> Should named graphs be supported?

I don't think I know the difference, for a serialization.

Maybe: if a serialization associates two triples { a b c. d e f. } with
a graph g, is it:

1 -- saying that G consists of exactly those two triples

2 -- saying that G contains those two triples and might contain others
as well

I guess (1) is graph literals and (2) is named graphs.
 
(I encourage anyone who wants to reply on this issue to do it in a
separate email, with [GRAPHS] in the Subject)

> Should automatic typing be supported?

Do you mean: should "1"^^xs:int be transmitted as a javascript 1 ?  Yes,
I think so.   That means this format will alter graphs, losing the
distinction between "1"^^xs:int and "1"^^xs:integer, but I think it's
worth it for many reasons.  This distinction is lost by many
triplestores as well, and that seems to be considered acceptable.

> Should type coercion be supported?

I don't understand what that means in this context.

> Should there be an API defined in order to easily map RDF-in-JSON
> to/from language-native formats?

I think our primary deliverable is a specification of an RDF
serialization which conforms to the JSON syntax.  If some API or
reference implementation work needs to happen to make this work
successful in the community, then okay.  I'm not sure if that's
in-scope for this WG.  (Is it in scope for your under-review RDF Web
Applications WG?)

> -- manu
> 

Thanks for the excellent set of questions.  Once we refine and clarify
these a bit, we may want to document them as ISSUEs on the tracker, to
eventually be settled by WG resolutions.   Maybe we should only do that
with ones for which we see some disagreement, but it could be good to
document even easy consensus.

    -- Sandro

Received on Wednesday, 23 February 2011 14:52:36 UTC