W3C home > Mailing lists > Public > www-talk@w3.org > November to December 2001

RE: What is at the end of the namespace?

From: <Patrick.Stickler@nokia.com>
Date: Wed, 21 Nov 2001 14:47:51 +0200
Message-ID: <2BF0AD29BC31FE46B78877321144043114C0C3@trebe003.NOE.Nokia.com>
To: a.powell@ukoln.ac.uk, duerst@w3.org
Cc: mnot@akamai.com, www-talk@w3.org, uri@w3.org

> -----Original Message-----
> From: ext Andy Powell [mailto:a.powell@ukoln.ac.uk]
> Sent: 21 November, 2001 11:55
> To: Martin Duerst
> Cc: Stickler Patrick (NRC/Tampere); mnot@akamai.com; www-talk@w3.org;
> uri@w3.org
> Subject: RE: What is at the end of the namespace?
> On Wed, 21 Nov 2001, Martin Duerst wrote:
> > At 13:29 01/11/19 +0200, Patrick.Stickler@nokia.com wrote:
> > >Because other folks expect that an HTTP URI *is* dereferencable,
> > >hence all the (IMO needless) bruhaha over "what's at the end
> > >of a namespace".
> > 
> > At one point, I proposed here at W3C that even if we didn't
> > have anything really serious to point at for a namespace
> > uri, we should put up a page that says something like
> > "This is just a page that is here in case you tried to
> > dereference this uri, the uri is the uri for the foo
> > namespace. This page also helps to make sure that this
> > uri isn't reused for something else." I guess there might
> > be some namespaces at W3C that have something similar now.
> Martin,
> The W3C already does this.  In fact, there is a variety of 
> stuff at the
> end of W3C namespace URIs.  A few examples:
> XHTML - http://www.w3.org/1999/xhtml - resolves to HTML page
> RDF - http://www.w3.org/1999/02/22-rdf-syntax-ns# - resolves to RDFS
> P3P - http://www.w3.org/2001/09/P3Pv1 - resolves to XML schema
> SMIL - http://www.w3.org/2001/SMIL20/ - resolves to HTML page
> :-(
> So, I'll ask the same question I asked a few days back...  if 
> I make an
> RDF statement about http://www.w3.org/2001/SMIL20/, am I making a
> statement about the abstract SMIL namespace or am I making a statement
> about the HTML page that the uri resolves to?
> The only answer I got last time suggested that I'd be making 
> a statement
> about the abstract concept.  If this is the accepted view, 
> then I still do
> not underdstand how I make a statement about the HTML page that uri
> resolves to.  Presumably, the dc:creator of the abstract 
> namespace is not
> the dc:creator of the HTML page at the namespace uri - so 
> there are valid
> reasons for wanting to make RDF statements about both.  As 
> far as I can
> tell, http://www.w3.org/2001/SMIL20/ is the only uri for that 
> HTML page so
> I don't see how else I can make a statement about it.
> This feels like a very fundamental and simple question to me!  

I strongly agree with you Andy.

I've had the continual repeated impression that alot of folks
want their cake and be able to eat it too by using URLs for
dual purposes -- to denote some abstract or non-digital resource
and then also some information about the resource; and it
also strikes me as fundamentally wrong.

There are others I've encountered who may to a degree agree
that it is not quite kosher, but since it's so useful for
clever hacks and tricks, they do it anyway.

Yet there appears to be a pervasive attitude of "if I *can* do 
it, it's *OK* to do it that way" which totally misses the point
of whether it is *optimal* to do it that way and what might
be better alternatives, and the masses who don't have a clue
either way just follow the lead of the most visible characters
so we end up with a critical mass of "bad habits".


But action is better than words in most scenarios, so in fairness
to the "status quo" I guess the best way to encourage change
is to show how to do things better and make the path of evolution
obvious. That's the path I plan to tread...

I look forward to seeing where we are one year from now ;-)


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Wednesday, 21 November 2001 07:48:07 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:26 UTC