Re: naive question: why prefer absolute URIs to # URIs for linked data?

Noah Mendelsohn wrote:
> On 10/21/2011 8:28 AM, Nathan wrote:
>> The only potential clarity I have on the issue, and why I've clipped 
>> above,
>> is that I feel the /only/ property that distinguishes an "IR" from 
>> anything
>> else in the universe, is that it has a [transfer/transport]-protocol as a
>> property of it.
> 
> Really? Let's imagine something that's pretty clearly a document, e.g. 
> the text of the US Declaration of Independence. Let's say someone, for 
> whatever good or bad reason, decides to mint a URN to identify it. I 
> would claim:
> 
> * It's clearly within the scope of what was intended by an IR. I was 
> careful to say that the resource in question is the text of the 
> declaration, that text can easily be conveyed in a message using an 
> encoding like ASCII, unicode, etc.
> 
> * There is not necessarily a transfer/transport protocol associated with 
> it, and if there were, the choice of protocol(s) might evolve over 
> decades or centuries.
> 
> The distinguishing characteristic of an IR is that it is ammenable to 
> (having it's "essence" [1]) conveyed in a message. It is not required 
> that the means of doing so are spelled out in advance, stable over time, 
> or in fact ever realized in practice. The declaration is an IR, IMO, 
> whether or not we choose to deploy it using HTTP at a given time. 
> And...because it is an IR, status code 200 is appropriate should we at 
> any point wish to use HTTP.
> 
> I think the distinction is important.

Is something an IR if it is not on the web?

If yes, is that any concern, and does it have any technical impact?

If no, then does the following hold for any IR on the web: If an 
interaction with the thing named <p:y>, using protocol 'p:', is
successful, then <p:y> is an "information resource".

Received on Friday, 21 October 2011 16:15:19 UTC