[JSON] new yellow box, proposed solution

I think we might be able to get away without the second table.

After the JSON task force meeting yesterday, it seemed to me the main
opportunity for standards in the second table on can also fit on the
first one, because of the level 7 convergence.   That is, 7A is
publishers with RDF and consumers who don't want anything to do with
RDF.   I made this a yellow box on the first table.   I'm a bit fuzzy
on some boxes in the second table, but I'm not seeing anything not
addressed in the first one, at the moment.

http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments

Thinking about this yellow box (7A), I guess the Linked Data API is
aimed at this space.  So is Steve Harris' "CONSTRUCT JSON" idea for
SPARQL.

Thinking about it yesterday, I came up with another approach, which I'll
explain now, while I'm thinking about it.  Not sure how relevant it is
to this WG.   The approach is based on the idea that we could address
these folks with SPARQL 1.1, just by defining a "simplified" json
results format.   Something like this:

Example Data in Turtle:
    _:x foaf:name "Cassia"; foaf:age 7 .
    _:y foaf:name "Aubrey"; foaf:age 8 .

Query:
  SELECT ?name ?age WHERE { ?person foaf:name ?name; foaf:age ?age }

JSON result:

[ { "name": "Cassia", "age": 7 }, { "name": "Aubrey", "age": 8 } ]

In JSON, the lang tags, datatypes, and node type would be lost, but you
could get that information if you wanted it by using a different query,
using SPARQL 1.1's new select expressions [1].  For example, if we add
this triple, with a language tag on "Ivan" (so we know how to pronounce
it):

More Turtle:
   _z foaf:name "Iván"@hu"; foaf:age 9 .

New Query:
  SELECT ?name (lang(?name) AS ?namelang) ?age WHERE ...

giving us:

[ { name: "Cassia", namelang: "", age: 7 }, 
  { name: "Aubrey", namelang: "", age: 8 },
  { name: "Iván", namelang: "hu", age 9 } ]

This puts all the RDF-knowledge into the SPARQL query, and keeps the
json RDF-free (so it's okay for Group A).   Some URLs could be set up
with fixed or parameterized SPARQL queries.  I guess this is pretty
close to the Linked Data API.   (Looking through that spec, I don't see
how things like language tags are addressed.  Ah, there's an open issue
on it, I think.)

So.   Pretty simple solution for the yellow box folks; the only standard
required is a very, very simple new SPARQL results format.  Well, and
maybe some of the other LDAPI stuff.  :-)


Meanwhile, this *might* also address parts of the green box, but it
starts to get more complicated.  The green box is about mapping between
nice-json and RDF, and some kinds of those mappings can be defined by
these SPARQL queries.   While the mapping is expressed as a way to
extract JSON from RDF, its semantics are declarative, so it could be
"run backwards"; you can (with some queries) reconstruct the RDF.

What I'm imagining here is people publishing the SPARQL query that would
have been used to generate the given JSON from some RDF.  Given that,
you can map back to the RDF.   Does this work?   First check, looking at
the JSON that twitter uses for streaming, I see... no, because its
nested; they have nested lists and objects within the values.  Hrm.
That could get complicated.

Anyway...    it's an idea.  

   -- Sandro

[1] http://www.w3.org/TR/sparql11-query/#select_expressions


On Sun, 2011-03-20 at 20:22 +0000, Andy Seaborne wrote:
> 
> On 20/03/11 17:16, Manu Sporny wrote:
> > Agenda
> >
> > 1. General discussion on what we're attempting to accomplish with
> >     the various communities and long-term (market segments)
> >     http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments
> > 2. JSON as RDF Proposal
> >     http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0447.html
> 
> That's very much making JSON appear as RDF; JSON source, RDFish application.
> 
> This can be contrasted with RDF for JSON: making published RDF 
> accessible to "normal" JSON applications, with varying degress of "RDF 
> ness" in the JSON application.
> 
> PROPOSAL: The RDF Working Group JSON Task Force will work on a way of
> making published RDF accessible to JSON applications.
> 
> Unlike a serialization of RDF in JSON may be lossy - i.e. when presented 
> to the application some details may be lost (e.g. some datatypes).
> 
> Drawn in a Sandro-matrix: with levels of data publishers:
> 
> level P1: RDF publisher willing to publish according to a fixed, 
> universal JSON presentation
> 
> level P2: RDF publisher willing to provide a JSON friendly form to all 
> applications; (i.e. one presentation, but specific to this data).
> 
> level P3: RDF publisher willing to provide a JSON friendly form based on 
> the application accessing the data (i.e. several presentations, based on 
> this data and accessing application)
> 
> Group A1: applications willing to do what ever it takes to get 
> RDF-published data (inc. read Turtle)
> 
> Group A2: applications wanting a JSON data structure
> 
> Group A3: applications willing to use a library/API
> 
>  Andy
> 
> > 3. Express all RDF in JSON Proposal
> >     http://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0450.html
> > 4. Addressing multiple, seemingly divergent communities
> >     * For example: Can we draw consensus by combining object-based
> >                    vs. triple-based formats into a single format?
> > 5. Review/Explanation/QA on proposed formats
> >     http://www.w3.org/2011/rdf-wg/wiki/TF-JSON#Inputs
> 
>

Received on Tuesday, 22 March 2011 16:26:36 UTC