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

Re: [JSON] User segments update

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 24 Mar 2011 22:21:41 +0000
Cc: RDF Working Group <public-rdf-wg@w3.org>
Message-Id: <66995946-A7C0-4E66-A3D3-7E442C13135D@garlik.com>
To: Manu Sporny <msporny@digitalbazaar.com>
On 2011-03-23, at 14:58, Manu Sporny wrote:

> On 03/23/2011 10:40 AM, Sandro Hawke wrote:
>>> http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments#Potentials_that_Manu_Sees
>>> Notice the expansion of the green box to the left. I think accomplishing
>>> that goal is very do-able, I'll try to explain more (with examples) when
>>> I get some time to write about it.
>> Um, I don't think that's right.
> Maybe :)
>> A-3/4/5/6 --- why do column A people, who don't need or want RDF, need a
>> way to transform JSON to Triples?
> They don't, but the publishers that want to reach the audience that
> wants RDF /could/ encode the information in a way that doesn't bother
> Column A people, but also meets the needs of column B people. That is -
> one solution is applicable to both Column A and Column B. That is, the
> markup looks like this to both columns:
> {
>   "#": { ... MAPPINGS ... }
>   "name": "Sandro Hawke"
> }

I honestly don't see much value here. We're a very RDF heavy company, and use JSON from the Twitter API for e.g., but I've never thought it would be helpful to get RDF out - we'd have to turn it into something else anyway, handling graphs in most mainstream programming languages is a pain!

We do, in some applications, turn data From Twitter into RDF so we can put it in a triplestore, but the RDF we generate is not that similar in structure or content to the JSON data we get from Twitter.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Thursday, 24 March 2011 22:22:15 UTC

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