Re: Facebook Linked Data

On Mon, Sep 26, 2011 at 3:08 PM, Sebastian Schaffert
<sebastian.schaffert@salzburgresearch.at> wrote:
>
> The philosophical part is the distinction of
>
> http://graph.facebook.com/561666514 representing the document
> vs.
> http://graph.facebook.com/561666514# representing the person.

Whether or not that is "philosophical" the pragmatic developer is
told they can use http://graph.facebook.com/561666514 and what
data they can expect in return.

As someone who considers himself a pragmatic developer,
everything seems fine there.

> I never gave Facebook the exclusive permission to provide the
> URI for me as a person.

There can be no single URI that can be expected to identify you
as a person. Do you expect every developer on the planet to ask
what URL they should use? And to ask your permission to use it?

Now *that* seems like a philosophical question.

> At best, it describes a user account.

If I wish to create a URI that identifies you as a person, and
designate it to be "http://frobincate.me/you" then you can do
nothing about it, nor should you. It's none of your business what
URI I choose to designate you.

Of course you are free to provide your own.

> The distinction is impractical, especially if you compare it
> with the simplicity of the alternative JSON-based Open Graph
> representation.

That may be a matter of one's experience and what one wishes to
do with the result.

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

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 have no simple generic way of deciding how what I requested
> relates to what I get back. Of course I could do it
> specifically for the FB Linked Data service, but then it would
> not work for other LD services.

At this stage of the web, humans are still involved to help find
and establish effective conventions and standards. This service
was announced with a human-readable description. Hopefully as the
service is used, and other similar services, then they will
become even more useful in combination.

My sense is that will take some time, so you work with what you
have now and go forward.

> Maybe I misunderstood the interoperability vision of Linked
> Data. But if I have to follow different service descriptions
> for different services, I can also stick with RESTful services
> and JSON. The whole point of Linked Data for me would be to be
> more independent from the different service descriptions and be
> able to follow a standardised, well-defined procedure for
> getting data.

REST is a description of useful ways to transfer data.

JSON is a description of a simple format for transferring data.

Linked Data is neither of those. But those can be used to provide
linked data.

I am not sure what argument you are trying to make by saying "I
can stick with REST and JSON" because you can provide and use
linked data with or without REST and JSON.

Certainly you can ignore linked data and come up with your own
conventions or some other conventions or standards to use with
REST and JSON. Which ones, if any, are you using now? How do they
compare with the current Linked Data conventions and standards?

> Impractical is: if I write a Linked Data client application I
> have to follow different service descriptions for each Linked
> Data service I am accessing.

That's pretty much the case across the internet, and even within
a single enterprise. This level of compatibility is just now
emerging. Most applications and services do not give a hoot about
anyone's data or services but their own, because there's never
been much bang for the buck in that department.

-Patrick

Received on Monday, 26 September 2011 22:48:37 UTC