W3C home > Mailing lists > Public > semantic-web@w3.org > October 2005

RE: URIs in RDF (Was: New Intro to RDF)

From: Martin Hepp \(DERI\) <martin.hepp@deri.org>
Date: Mon, 10 Oct 2005 10:09:48 +0200
Message-Id: <200510100809.j9A89lo6022176@smtp.uibk.ac.at>
To: "'Jacek Kopecky'" <jacek.kopecky@deri.org>, "'Charles McCathieNevile'" <chaals@opera.com>
Cc: <tim.glover@bt.com>, <tauberer@for.net>, <semantic-web@w3.org>


>but on the Web it's easier and cheaper to create new words so changing the
meaning of old words is not so 
Exactly! In this sense, TBL's "Cool URIs don't change" should be read as
aiming at a semantic level, i.e. that the URI space should only be extended
monotonically. This should be possible, on a general scale (i.e. ignoring
the unavoidable inconsistencies of a system of Web scale), since the URI
space is not limited; and it requires only a tiny bit of discipline.

In this sense, http-prefixed URIs make a lot of sense (no matter whether
actually retrievable or not), since there is a generally accepted model of
ownership for subspaces. 

In industrial numbering schemes, such prefixed subspaces made it possible to
have unique numbering combined with distributed evolution. ISBN and EAN/UPC
are the best examples: Every publisher/manufacturer can create a new number
for the last digits in a decentralized manner and thus create a globally
unique identifier for a book or product without any lag or central registry.
The only and similarly minimal consensus is that publishers/producers are
not allowed to reuse any number once assigned to a concept to any other
concept at any time. And that works very well!

Best wishes,
martin.hepp@deri.org, phone: +43 512 507 6465
http://www.heppnetz.de / http://www.deri.org

-----Original Message-----
From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] On
Behalf Of Jacek Kopecky
Sent: Montag, 10. Oktober 2005 09:41
To: Charles McCathieNevile
Cc: tim.glover@bt.com; tauberer@for.net; semantic-web@w3.org
Subject: Re: URIs in RDF (Was: New Intro to RDF)


I agree that, technically, you can choose to use http://w3.org/ to mean
whatever, but along the same lines you can choose to say 'bread' to mean
'harley-davidson-like'. What I say means only what I want it to mean, right?

My point was, and you seem to agree with it, that there is no incentive to
do so, and every incentive to avoid doing so. 

Unless the official meaning is overruled by the public's perception, like
when many people used Yahoo for direct keyword search, not for browsing the
hierarchical directory. This is akin to language evolution and dictionary
updates, but on the Web it's easier and cheaper to create new words so
changing the meaning of old words is not so necessary.

As for assurances - there's no assurance about anything, but the Web knows
that and can deal with it, and the SemWeb aims not to forget it.

Best regards,


On Sun, 2005-10-09 at 19:38 +0200, Charles McCathieNevile wrote:
> On Sat, 08 Oct 2005 15:20:52 +0200, Jacek Kopecky 
> <jacek.kopecky@deri.org>
> wrote:
> > So I cannot choose to use http://w3.org/ to mean my car, and I don't 
> > think anything on the web gives anybody the opposite idea.
> Nonsense. Of course you can. There is a social convention that you 
> don't, and nothing more.
> I recently heard someone suggest that having 2 namespaces made RDF too 
> difficult (there are things that make it hard, but I can't see that as 
> one). I pointed out that at the risk of causing major unhappiness, he 
> could simply describe new terms in the original RDF namespace.
> There is no reason it wouldn't work, the first time. But my answer is 
> that making a system work requires a bit of cooperation, and a bit of 
> learning, in general.
> So there is absolutely no assurance that someone won't try to overload 
> your URI to mean something completely different. But there is a social 
> convention that people don't do it, which is generally respected.
> cheers
> Chaals
Received on Monday, 10 October 2005 08:10:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:40:56 UTC