Re: The lost meaning of the HTTP protocol in URIs

On Sunday, Sep 14, 2003, at 19:59 Europe/Rome, Tim Berners-Lee wrote:
>

> On Saturday, Sep 13, 2003, at 15:56 US/Eastern, Stefano Mazzocchi 
> wrote:
>
>>
>> From the current state of affairs, the web is based on URIs. From 
>> what I see, this is unlikely to change and I'm cool with this, 
>> expecially because URIs that are general enough to indicate anything, 
>> even concepts that are not "locatable".
>
> What do you mean by, "not locatable"?  There are things, like abstract 
> concepts,
> which may not be objects you find on the web, but they are things
> which one describe.

Sorry, I used the wrong terminology. I meant "dereferencable".

>> Then, please, tell me: if these concepts are not locatable, why are 
>> we supposed to use the HTTP protocol to indicate them?
>>
>> I know, I know: in order to keep them unique using the domain name 
>> facilities... but ask yourself why in hell a namespace URI such as
>>
>>  http://www.w3.org/1999/xslt
>>
>
> The XSLT namespace is in fact
>
> http://www.w3.org/1999/XSL/Transform

I stand corrected. Sorry.

> An engineer who comes across a document which
> uses that namespace can look it up, and get information
> leading him or her to the XSTL specification.
>
> This is useful.  So while a namespace seems like an abstract
> concept, to actually refer to it by the name of something
> which can be looked up is variable.

[I assume you meant 'valuable']

> In the semantic web, information can be used not only be
> a person, but by a machine. So while the concept
> of "two-digit US state code" may be a an abstract property,
> in fact one can find the list of them and the correlation with
> various other properties.  This is powerful.

Very true.

But the above triggers another question: what is the difference between 
an HTTP URI and an HTTP URL, if the first is supposed to be 
dereferencable as well?

[I know this is a rather philosophical question, but anyway]

>> is not
>>
>>  uri://w3.org/xslt/1.0
>>
>> where:
>>
>>  1) there is no misleading since the protocol clearly indicate its 
>> "unlocatable" status
>
> You presumably mean that no one should ever look up what the
> owner of the name said about it.
> You need the "urn:" prefix not "uri:".
> But betware that many urn: subschemes are actually less useful
> because they are waiting for some sort of lookup mechanism,
> and to the extent they have such a mechanism, they become just clumsier
> versions of http:

Good point.

>>  2) the domain-based uniqueness is maintained, no, improved, given 
>> that virtualhosts are not considered meaningful (there is no location 
>> taking place, just unique identification)
>
> The difference is an attitude of mind, and a mode of use.
> Think of what you would like from your "uri:" space above, and use 
> http:
> space like that.
>
> Use them like names not like locations. They are not locations.

But you say that they are better than names because they might act as 
locations. Did I understand correctly?

>>  3) version numbers are used instead of years. this makes them much 
>> easier to remember (you remember the version of the namespace you 
>> want to associate your content with, not the year that version was 
>> published [unless the year *is* the version, like in 
>> win95/98/2000/2003, but it's not the case here])
>
> That is a question of web site management.
> The advantage of years is that in 100 years time, when someone
> wants to reuse they string "xslt", they will not have a problem.

I see.

Thanks for taking the time to answer.

--
Stefano.

Received on Friday, 19 September 2003 18:02:18 UTC