Re: [JSON] new yellow box, proposed solution

Cc += boaz <boaz@bocoup.com> who will hopefully validate or refute my
assertions about JS/JSON.

Boaz, as you're not a member of the WG, your replies will only be
visible to the WG in my replies to your replies.

* Sandro Hawke <sandro@w3.org> [2011-03-22 12:26-0400]
> 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 } ]

If you followed the precedent that unbounds are simply not mentioned,
so you'd get:

  [ { name: "Cassia",               age: 7 }, 
    { name: "Aubrey",               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.  :-)

We're relying on JSON-native representations of RDF atoms. That is,
you don't serialize "7"^^xsd:integer as "7", but as 7. This strikes me
as perfectly sensible. (Guessing at JS a bit) this would exactly
translate the primative numeric datatypes integer, float and double,
and encompass the restricted subtypes like byte, short int, long¹
without capturing the exact restriction. This captures most of the
"data-only" queries, which has the appeal of keeping the simple stuff
simple.

For non-native types, the current:

  "person":{"type":"uri", "value":"http://a.example/cassia"}
  "person":{"type":"bnode", "value":"cassia"}
  "name":{"type":"literal", "xml:lang":"hu", "value":"Iván"}

syntax would break the pattern of where the average JSON user could
look for the lexical value. OTOH, your enhanced query approach:

  "personURI":"http://a.example/cassia"
  "personBNode":"cassia"
  "name":"Iván", "nameLang":"hu"

allows the consumer to be easily fooled. (E.G. when the object of
dc:author is a BNode, I might report that label as the author's name.)
The other prob is that user has to account for all of these types in
their query, e.g. to dump a graph:
  SELECT ?sBNode ?sURI ?pURI ?oURI ?oBNode ?oLexical ?oDT ?oLangTag…
(and three more to dump named graphs).

There's also the ASP.NET precedent for serializing e.g. Dates as
  "birthdate":"/Date(12341232212)/"
which could could use ISO datetimes instead as the constructor for
Date takes seconds since epoch and iso datetimes. Is there a
package for arbitrary precision decimals? Do we care about them?

¹http://www.w3.org/TR/rdf-sparql-query/#operandDataTypes


> 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
> > 
> > 
> 
> 
> 

-- 
-ericP

Received on Tuesday, 22 March 2011 22:40:30 UTC