W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: Role of URI and HTTP in Linked Data

From: Nathan <nathan@webr3.org>
Date: Wed, 10 Nov 2010 22:26:07 +0000
Message-ID: <4CDB1BFF.20900@webr3.org>
To: Jiří Procházka <ojirio@gmail.com>
CC: public-lod@w3.org
Jiří Procházka wrote:
> On 11/10/2010 11:44 AM, Nathan wrote:
>> Hi Jiří,
>>
>> Jiří Procházka wrote:
>>> Hi,
>>> having read all of the past week and still ongoing discussion about HTTP
>>> status codes, URIs and most importantly their meaning from Linked Data
>>> perspective, I want share my thoughts on this topic.
>>>
>>> I don't mean to downplay anyone's work but I think the role of URI and
>>> HTTP specifications (especially semantics) in Linked Data is
>>> overemphasized, which unnecessarily complicates things.
>> The URI is what makes Linked Data, Linked Data, it's the only hook to
>> the real world, and via the domain name system + domain registration
>> process gives us a hook on accountability, which is critically
>> important. 
> 
> I am by no means giving up these utilities by what I suggest.
> 
>> "#bar, as described by <http://example.com/foo>" resolves in
>> two ways:
>> (1) <http://example.com/foo> as a name for the literal description/graph
>> (2) <http://example.com/foo> as a way of saying "the author of the
>> description available at <http://example.com/foo>, stated X, and was
>> responsible as delegated by the owners of example.com", where X is (1)
>> and provable by the HTTP messages and logs. A status code of 200 vs 303
>> to some other domain or URI vs 4xx or 5xx plays a big part in that chain
>> of accountability / validity / trust.
> 
> I don't think Linked Data consumers should *have to* care about what
> status codes HTTP request returns - it shouldn't be part of the core
> Linked Data semantics. Of course it can be beneficial for clients to
> listen to them to get more information, but treating HTTP library as a
> simple function should be allowed (either it returns data or not).
> Whether someone 303s (nice verb) to a different domain, it obviously
> means he trusts it to maintain the description of his URI.

snap, I don't think they should either, I also don't think they should 
have to constantly ask "is this a document or a toucan?" - it could all
be so much easier.

ps: 303 doesn't day "you'll find it here!", it says "maybe you try here 
instead?"


>>> So lets stick with this. Lets just treat URIs as RDF does - as simple
>>> names. When we dereference an URI we get back some useful data and
>>> that's it.
>> So, that'll be like mailto: or pop: or tel: then..
> 
> I don't follow here. I don't know of any standardized ways of getting
> structured data out of such URIs.

That's the point, RDF treats all URIs the same, you're saying we should 
treat URIs as RDF does, as nothing more than a logical hook - doesn't do 
us much good practically when we want to dereference and get back some 
useful data.

>>> If we want to express, the data fetched are in fact a
>>> document, we use the wdrs:isDefinedBy property. The data fetched are
>>> just a data and any info about it should be contain in it.
>> Expressing that the data fetched is infact a document, is indeed
>> optional, but any response is always a message, a description, a
>> /literal/ thing, you can't pretend it doesn't exist, it does - to say a
>> description is anything other than that is like me saying you're an
>> apple and insisting everybody believe me. Literals are self identifying,
>> self naming, things.
> 
> I don't get what you mean here either. Are you talking about RDF
> semantics here or general ontological philosophy? If you are talking
> about RDF, then be aware that literals can have names - URIs assigned to
> literals. If talking about the latter, then I don't get you at all.
> I am advocating making Linked Data as simple as possible, avoiding
> abstract ontological definitions (in which I count the notion of
> literal). The fact that what you say is incomprehensible to me further
> strengthens me in my opinion.

Much, much simpler - "this is an email", "this is a html document", 
"this is an rdf document", "this is a book" - why are people even trying 
to assert that one of those statements is false?

> You have for example foaf:Agent which you dereference and get back the
> data amended with:
>   foaf:Agent wdrs:isDefinedBy [ wdsr:location
> "http://xmlns.com/foaf/0.1/Agent" ] .
> 
> If the data already contains:
>   foaf:Agent wdrs:isDefinedBy foaf: .
>   foaf: wdrs:location "http://xmlns.com/foaf/0.1/" .
> great, we get better info.

/foaf#Agent = "Agent, as described by /foaf" seems much simpler to me.

and nobody is going to say "Agent sameas Document"

..
Received on Wednesday, 10 November 2010 22:27:09 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC