W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] market segments - 6B solutions

From: Nathan <nathan@webr3.org>
Date: Thu, 17 Mar 2011 18:57:51 +0000
Message-ID: <4D8259AF.8060409@webr3.org>
To: Sandro Hawke <sandro@w3.org>
CC: RDF Working Group <public-rdf-wg@w3.org>, Manu Sporny <msporny@digitalbazaar.com>
Sandro Hawke wrote:
>> However, I would like to add that imho there is a growing need to 
>> standardize something separate like jTriples and Talis' RDF/JSON for 
>> Level 7 above. 
> 
> Do you mean for 6B or 7B?   See 
> http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments
> 
> We're talking about the blue box, possibly the gray box under it.

Probably a hybrid between 6b/7b/6c/7c the lines are fuzzy between the 
two ...

>> Ideally if we produce text/ntriples or text/nquads, then 
>> it would be nice to have a JSON production of that standardized and 
>> registered as application/ntriples+json or suchlike, it could be an easy 
>> hit within minimal specification.
> 
> Yes, I agree.  
> 
> FWIW, on that front, I'm thinking the SPARQL Result Format is the
> leading contender, with just the addition of standardizing the names of
> the variables.   This has the added benefit of also giving us a JSON
> quad format with no extra work.

FWIW, I agree :) probably just the bindings content w/ standardized 
names, that would cover us in a practical way.

aside: one of my primary negative feelings towards sparql has always 
been that it's not "RDF" on the wire, this would address that in some 
cases which would be a Good Thing, a major +1 imho.

> That is, we just use:
> 
> "SELECT * WHERE { ?s ?p ?o }" for triples, and
> "SELECT * WHERE {GRAPH ?g {?s ?p ?o}}" for quads.
> 
> Trying that on a random 4store database (rather than reading the spec,
> oops), I get this:
> 
> {"head":{"vars":["s","p","o"]},
>  "results": {
>   "bindings":[
>    {"s":{"type":"bnode","value":"b100000000000004"},
>     "p":{"type":"uri","value":"http://www.w3.org/1999/02/22-rdf-syntax-ns#rest"},
>     "o":{"type":"uri","value":"http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"}},
>    {"s":{"type":"bnode","value":"b30000000000000c"},
>     "p":{"type":"uri","value":"http:not-yet-defined-sorry.example.com/resume#group"},
>     "o":{"type":"bnode","value":"b30000000000000d"}},
>    ...
> 
> and this:
> 
> {"head":{"vars":["g","s","p","o"]},
>  "results": {
>   "bindings":[
>    {"g":{"type":"uri","value":"a"},
>     "s":{"type":"bnode","value":"b100000000000004"},
>     "p":{"type":"uri","value":"http://www.w3.org/1999/02/22-rdf-syntax-ns#rest"},
>     "o":{"type":"uri","value":"http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"}},
>    ...
>  
> Part of what makes me lean in this direction is that I've been trying to
> write some javascript stuff using RDF, and I find mostly I want to do
> app-specific SPARQL queries, and just see the results in json.  So, if I
> want a whole graph, it's nice to not have to do anything different.
> 
> Although, honestly, in writing apps, so far I'm finding I'd prefer
> OO-style data to triple-style, and I've been having my serverside code
> do that conversion.   Hmm.   Not sure how to generalize that yet.

Manu and I are working on that from an API front at the minute via the 
RDF API and RDFa API, (and Manu separately via JSON-LD and PaySwarm 
work, and myself separately via my own projects and JS3 lib) - we're 
planning to have a full session on this over the weekend at some point, 
I guess it's somewhat related.

More general musing/asideness: It seems like there's an abstract 
generalization to be had which is going to be common to general sparql 
results (where you select variable names), to json objects mapped to 
rdf, to graph query implementations, and to a general graph.toObject(s) 
implementation - probably worth seeing if it can be written up or 
codified in some way.. will put some time in to that over the next few 
days and see what pops out, if anything.

Best,

Nathan
Received on Thursday, 17 March 2011 18:58:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC