RE: Yet another serialization format?

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

What exactly do you mean by "URIs do not resolve to representations of their referents"? I'm a bit confused.. are you talking about the missing #this or #me fragment? At least your URI below (http://graph.facebook.com/kidehen#this) suggests this. I really think we should get past that #this/#me/#whatever discussion. We would like to simplify things not complicate them.

How often do mean the bits a representation consists of compared to the thing the representation is about? IHMO statements talking about the thing the representation is about should be easier than metadata about the representation about the thing.

We are talking about JSON here after all, not RDFa which adds annotations to existing documents. I would propose that for JSON-LD we see the URI of something like primary key in a database. No developer would ever would start to add a #this/#me there to specify that he isn't talking about that row in that table but about the person that row is about.

Since Richard Cyganiak wrote about this already much better than I ever could I will stop my argumentation here and just link to his mail: http://bit.ly/mwNdYa


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

I can't really see what difference that URI attribute makes!? Could elaborate on that a bit?
What makes the above really to linked data is adding some metadata :-) Just try to add a "?metadata=1" at the end:

http://graph.facebook.com/kidehen?metadata=1

Now you really get links in your representation - even though in JSON there's currently no way to define which string represents a URI. And that's something I propose to describe in an external description (call it schema, context or whatever you like). The reason why a external document is better in my opinion is the nature of JSON. It's clearly structured and hundreds of thousands of representations will follow *exactly* the same structure. If you describe that once it's enough. Of course you could also add the possibility to have that description inline in a JSON document but I wouldn't like to see @something statements spread all over the JSON document because then we could as well define JSON+ which has built in support for hyperlinks.


> [...]
> 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.co
> m/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.co
> m/kidehen>
> 4. http://idehen.net/c/BLZVQR  -- SPARQL URL with the DESCRIBE graph
> serialized in JSON-LD format .

Impressive. How much hand work was involved to get there? I mapping the attributes to foaf concepts and so on? Simple speaking what I would propose is a description format describing exactly that process. Maybe you find some time to have a look at this: http://bit.ly/seredasj


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 29 June 2011 14:29:13 UTC