Re: Facebook Linked Data

Sebastien, hello.

[trimming CCs]

On 27 Sep 2011, at 08:01, Sebastian Schaffert wrote:

>>> - I ask for http://graph.facebook.com/sebastian.schaffert and I get http://graph.facebook.com/561666514#
>>> - I ask for http://graph.facebook.com/561666514 and I get http://graph.facebook.com/561666514#
>>> - I ask for http://graph.facebook.com/561666514# and I get 404.
>> 
>> Curious. I do not get a 404 for that last one.
> 
> Because the browser (according to the standard) removes the trailing "#". But if you send a GET request manually (telnet etc) and including the # you will get a 404.

Well, what did you expect?  As you say, the client is supposed to remove the fragment before it dereferences the URL.  Including the '#' in the first line of the HTTP transaction is a protocol error.  Arguably, you should have got a 5xx response.

>> Anyway, the URL in each case is asking for data. If that data
>> happens to be a graph that contains the URI
>> http://graph.facebook.com/561666514# so what? I am not
>> understanding why you are disappointed in that.
> 
> I am disappointed because I asked for data about http://graph.facebook.com/561666514 and got back data about http://graph.facebook.com/561666514# - this is my main concern. Maybe I should ask for http://graph.facebook.com/561666514# in the first place and manually remove the trailing "#" like a browser does. But I prefer a predictable, well-defined, and universal (over all LD services) behaviour.

I think you're disappointed because your expectations may be wrong.

When you dereference the URL for a person (such as .../561666514#), you get back RDF.  Our _expectation_, of course, is that that RDF will include some remarks about that person (.../561666514#), but there can be no guarantee of this, and no guarantee that it won't include more information than you asked for.  All you can reliably expect is that _something_ will come back, which the service believes to be true and hopes will be useful.  You add this to your knowledge of the world, and move on.

How much or how little information comes back is an engineering or UI decision on the part of the service.

Or, put another way:

> But Linked Data could do better: there could be a uniform way of accessing the data and a unified contract about what comes back.


There _is_ a uniform way of accessing the data: you dereference the non-fragment bit of a thing's name and read what comes back.  And there is a uniform contract: the RDF that comes back is something the service believes may be useful/interesting to you, and should include further places to look.

Yes, it would be _nice_ if the contract were stronger, but this is the web, and the LD pattern's key insight is that this degree of _very_ loose coupling is practical and useful.

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk

Received on Tuesday, 27 September 2011 07:47:03 UTC