Re: Role of URI and HTTP in Linked Data

On 11/10/2010 11:26 PM, Nathan wrote:
> 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.

I think you have missed the point of the second part of my original
email - I think it is flawed trying to enforce "URI == 1 thing" by some
system (especially if you want to maintain RDF as one of supported
structured data formats (I dare to say the major one)), as nothing can
be completely unambiguous (in RDF) - that is something the publisher
needs to keep in mind and work towards to.
Key is not inferring any information which would increase ambiguity
which my simple solution preserves and solves the "is this a document or
a toucan?" problem if the original data is unambiguous (if it isn't it's
not like the consumer can do anything about it anyway).

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

It is useful - I don't advocate using any other URIs then HTTP with
Linked Data, because with HTTP URIs we use the HyperText *Transfer*
Protocol which gets us some useful data, without having to cut up the URIs.

Best,
Jiri