Re: Yet another serialization format?

On 6/29/11 3:28 PM, Markus Lanthaler wrote:
>> 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..

I mean just that an HTTP scheme based Identifier that resolves to a 
Representation of its Referent. The Representation takes the form of an 
EAV/SPO graph pictorial (Attribute=Value pairs that coalesce around a 
Named Subject) with serializations formats being negotiable.

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

You are saying, in plain English, with regards to basic computer science:

Disambiguating a Name from an Address doesn't matter when constructing 
Linked Data Structures.

If that were true, I wouldn't even be able to send this email.

> 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 using Hyperlinks as mechanism for "whole data representation" 
using linked data graphs. This isn't about metadata solely, that's part 
of the problem.

> We are talking about JSON here after all, not RDFa which adds annotations to existing documents.

Yes, we are talking about JSON and not XML or XHTML, so what? This has 
nothing to do with mechanisms for data representation. It is about 
actual data representation via a variety of formats. These could be JSON 
based (e.g. JSON-LD), XML based (e.g. RDF/XML), (X)HTML based (e.g. RDFa 
or Microdata), something else like N3/Turtle, N-Triples, and many others.

The key thing is we are representing graphs and then serializing the 
graphs.

The Data Object has a Name that's distinct from its Location. Object's 
representation (graph) is negotiable.

Now back to my example:

1. http://graph.facebook.com/kidehen#this -- Name
2. http://graph.facebook.com/kidehen -- Representation Address that 
resolves to Facebook's graph representation using JSON not one of the 
RDF formats .
3. 
http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen 
-- Name that Resolves to Representation of its Referent (i.e., Linked 
Data) actual graph derived from FB graph re. actual Object 
Representation delivered via an Address .

1-3 demonstrate the following fundamental computer science operations 
via hyperlinks (in this case generic HTTP scheme URIs for Names and 
function specific URLs for Addresses):

1. de-reference (indirection)
2. address-of .

> I would propose that for JSON-LD we see the URI of something like primary key in a database.

Yes, that's what it is. But unlike an RDBMS primary key, it actually 
resolves to data (note: a record in an RDBMS table is an Attribute=Value 
pair that coalesces around the Subject Name i.e., Primary Key value).

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

If that was true, email would not exist. No program that leverages "data 
access by reference" would exist. That statement is conceptual false. I 
do sympathize with the confusion though.

#this turns an Address into a Name that resolves to its Referent. Ditto 
#me. This happens by way of HTTP URI mechanics. Its a very cheap route 
to exploiting: de-reference (indirection) and address-of operations at 
InterWeb scales.

> 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

Please read the whole thread.
>
>> 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!?

Each attribute will resolve to a representation that makes its 
definition human or machine discernible. This what the whole Linked Data 
meme is about re. extending the use of hyperlinks from Address to 
generic Names that Resolve to referents via full URI abstraction 
exploitation.

>   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

Of course not!

Linked Data is as I described above. de-referencable URIs for:

1. Subject Name
2. Attribute Name
3. Optionally for Attribute Values.

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

You don't need that journey. You just need to understand what Linked 
Data is actually delivering. Now I am not blaming you for the confusion. 
The confusion comes from RDF, http-range-14, and conflation with Linked 
Data. If these matters where separated and the narratives a little 
clearer, we wouldn't even be debating this matter.


>
>> [...]
>> 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?

That a platform feature of Virtuoso (our DBMS and Linked Data deployment 
platform combo). We have a live service called URIBurner that does this 
for you or anyone else.


> 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

Trouble is that the game isn't about metadata, its about "whole data 
representation" re. Linked Data.


Links:

1. http://uriburner.com -- hopefully self explanatory (we've given it a 
recent face lift)
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>
>


-- 

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 20:51:25 UTC