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

Re: Role of URI and HTTP in Linked Data

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 11 Nov 2010 14:33:33 -0500
Message-ID: <4CDC450D.1070907@openlinksw.com>
To: Pat Hayes <phayes@ihmc.us>
CC: David Booth <david@dbooth.org>, Jiří Procházka <ojirio@gmail.com>, nathan@webr3.org, public-lod@w3.org
On 11/11/10 2:01 PM, Pat Hayes wrote:
> On Nov 11, 2010, at 8:42 AM, Kingsley Idehen wrote:
>
>> On 11/11/10 9:00 AM, David Booth wrote:
>>> On Thu, 2010-11-11 at 07:23 +0100, Jiří Procházka wrote:
>>> [ . . . ]
>>>> I think it is flawed trying to enforce "URI == 1 thing"
>>> Exactly right.  The "URI == 1 thing" notion is myth #1 in "Resource
>>> Identity and Semantic Extensions: Making Sense of Ambiguity":
>>> http://dbooth.org/2010/ambiguity/paper.html#myth1
>>> It is a good *goal*, but it is inherently unachievable.
>> Are you implying that a URI -- an Identifier -- doesn't have a Referent (singular)? If so, what is the URI identifying?
>>
>> In my world view:
>> Identification != Representation. The fact that I can de-reference an Identifier en route to obtaining Data doesn't make the Identifier a Representation of the Data.
> True. But the suggestion embodied in http-range-14 is that IF you get a 'normal' 200-coded access response, THEN we should all agree that the IRI does in fact refer to the data-thing it accesses.

I agree. It's an Address, a URL, a Pointer.

> And for all its awkwardness and wierdness, this does seem like a workable and useful convention. I think its like democracy: its stinks, but all other alternatives are worse.

If we don't get a 200-coded access response, then it's something else, 
which opens up a slot for the request IRI being a Name (or even 
something else).

200 OK implies IRI in the Request is a URL (a Data Locator).

Next step, user agent retrieves data from Location (exposed by 
Content-Location: header), in a format it understands, the application 
logic of said user agent then allows it to process the data using its 
own rules which may include flipping the Address to a Name and 
designating what was as exposed via Content-Location as the Data 
Address. All of this occurs for the sole purpose of keeping the Linked 
Data graph navigable by humans or machines.

There are such a tiny handful of Linked Data tools, especially on the 
user agent side of things that I don't know why Ian's option is 
problematic, especially as it's an option, and it doesn't require a new 
HTTP response code. It gives user agents the option to disregard the 303 
response since the data can speak for itself in a language the user 
agent is supposed to understand -- if it's Structured Linked Data aware.

BTW - the democracy analogy is great, even though I don't think it 
stinks :-)

Link:

1. 
http://linkeddata.uriburner.com/about/html/http/iandavis.com/2010/303/toucan 
-- description of a Toucan with Ian's tweak applied to the user agent
2. 
http://linkeddata.uriburner.com/describe/?url=http://iandavis.com/2010/303/toucan 
- another view of the description of a Toucan that takes you places .


Kingsley
>> It's a conduit to the Data.
>>
>> [SNIP]
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> President&   CEO
>> OpenLink Software
>> Web: http://www.openlinksw.com
>> Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca: kidehen
>>
>>
>>
>>
>>
>>
>>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>


-- 

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 Thursday, 11 November 2010 19:34:06 UTC

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