- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 22 Mar 2011 20:49:06 +0000
- To: Steve Harris <steve.harris@garlik.com>
- CC: Sandro Hawke <sandro@w3.org>, RDF Working Group <public-rdf-wg@w3.org>
On 22/03/11 17:11, Steve Harris wrote: > On 2011-03-22, at 16:26, Sandro Hawke wrote: > >> 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 Part of the difference in the two segmentations is that the first has "JSON publisher" and I presume Level 7 is "json publisher willing to publish in RDF as well". The RDF is the JSON information - so skewed to lack of lang tags and datatypes. Stil useful to the semweb because it would use IRIs. In the second segmentation, the data is in RDF now. >> 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 > ... > > +1 to that. > > In a similar vein, 4store has a non-standard result format that's quite popular, which is just TSV files of Turtle constants (some people use a variant which is just STR(?var), so no<>s, type, or language). Both are perl/python/ruby/php friendly. > > e.g. > > name age > "Cassia" 7 > "Aubrey" 8 > > There's a fairly simple regex one liner which turns Turtle constants into bare strings, but sometimes you want to inject results back into another SPARQL query anyway. > > - Steve ARQ can produce TSV, with Turtle terms for V elements, lang tag, datatypes and <> for IRIs as needed. It also produces CSV - strings and numbers only, no lang tags etc etc. Andy
Received on Tuesday, 22 March 2011 20:49:45 UTC