Re: Yet another serialization format?

On 6/29/11 11:50 AM, Markus Lanthaler wrote:
>> I think applying "out-of-band" annotations to "current"
>> JSON is not what I mean by a graph representation. Each
>> node has to have an ID. Otherwise you've got a tree.
> "Out-of-band annotation" as you call it doesn't prevent every node to have an ID in any way. It's just a separation of concerns. Or did I miss something? It is just so that the description of how the representation has to be interpreted is stored in a different document. It's basically the machine-readable counterpart of descriptions as the following ones:
>
> - https://developers.facebook.com/docs/reference/api/album/
> - https://developer.foursquare.com/docs/responses/user.html
> - http://dev.twitter.com/doc/get/users/show
>
> Since all of these APIs are RESTful every representation has an unique URI, by using a fragment identifier you could also link directly to subparts of such a JSON representation.
>
>
>

Let take the the Facebook URL: http://graph.facebook.com/kidehen, that 
resolves to a JSON based graph (not linked data since the properties and 
values are all literals and URIs do not resolve to representations of 
their referents).

Here's what we get:
{
    "id": "605980750",
    "name": "Kingsley Uyi Idehen",
    "first_name": "Kingsley",
    "middle_name": "Uyi",
    "last_name": "Idehen",
    "link": "http://www.facebook.com/kidehen",
    "username": "kidehen",
    "gender": "male",
    "locale": "en_US"
}

Now for this to be Linked Data, you need to have something along the 
following lines re:

1. Data Object Name
2. Data Object Representation Address.

Simple tweak by just adding a URI based Name that resolves to 
representation of its Referent:
{
    "uri": http://graph.facebook.com/kidehen#this,
    "id": "605980750",
    "name": "Kingsley Uyi Idehen",
    "first_name": "Kingsley",
    "middle_name": "Uyi",
    "last_name": "Idehen",
    "link": "http://www.facebook.com/kidehen",
    "username": "kidehen",
    "gender": "male",
    "locale": "en_US"
}

Of course, you can work through all the literal properties generating 
their HTTP URI name based equivalents or derivatives. Basically, here's 
what we've done via our middleware:


1. 
http://linkeddata.uriburner.com/about/html/http/graph.facebook.com/kidehen#this 
-- profile page description

2. 
http://linkeddata.uriburner.com/about/html/http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen 
-- profile page primarytopic description .

Taking this further with my personal instance which does actually 
support JSON-LD based graph serializations re. SPARQL DESCRIBE and 
CONSTRUCTs, you can do this:

1. go to: http://idehen.net/sparq
2. paste in: define get:soft "replace" select distinct *  from 
<http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen> 
where {?s ?p ?o} -- this populates the quad store (you only do this one 
time, so you can actually skip this step since I've already done it)
3. enter: describe 
<http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen>
4. http://idehen.net/c/BLZVQR  -- SPARQL URL with the DESCRIBE graph 
serialized in JSON-LD format .

Hope this clears up matters re. Linked Data and the critical role of 
URIs that resolve to Referent Representations that take the form of a 
graph pictorial that can be serialized in a variety of formats which may 
or may not be members of the RDF family of serialization formats.

-- 

Regards,

Kingsley Idehen 
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Wednesday, 29 June 2011 12:54:13 UTC