W3C home > Mailing lists > Public > www-rdf-interest@w3.org > September 2000

Re: Namespace squatting: please don't

From: Dan Connolly <connolly@w3.org>
Date: Mon, 18 Sep 2000 13:49:20 -0500
Message-ID: <39C663B0.C178B442@w3.org>
To: Jonathan Borden <jborden@mediaone.net>
CC: www-rdf-interest@w3.org, jos.deroo.jd@belgium.agfa.com
Jonathan Borden wrote:
> 
> Dan Connolly wrote:
> 
> > > >
> > > > So... like...
> > > >
> > > > Hey, You Kids, Get Off My Lawn!
> > > >
> > > > -- http://www.goddamn.com/content/lawn.cfm
> > >
> > >     Since you include a URI, is this an RDF assertion?
> >
> > Er... huh?
> 
> I was being a bit too obtuse (this is approximate but hopefully makes the
> point):
> 
> (author, http://www.w3.org/1999/02/22-rdf-syntax-ns#instance, "Sergey
> Melnik")
> (authority, http://www.w3.org/1999/02/22-rdf-syntax-ns#, "Dan Connolly")
> (derived-from, http://www.w3.org/1999/02/22-rdf-syntax-ns#instance,
> http://www.w3.org/1999/02/22-rdf-syntax-ns#)
> 
> =>
> 
> (http://www.goddamn.com/content/lawn.cfm, "Dan Connolly", "Sergey Melnik")

Ah... thanks. I still had to read it two or three times,
but I think I understand now.

> This works because the particular namespace ends in neither a Letter or '_'.
> Yet suppose the offending namespace is "http://www.w3.org" now the offending
> resource is:
> 
> http://www.w3.orginstance and you no longer have rights to this name! You
> cannot rightfully assert
> 
> (derived-from, http://www.w3.orginstance,  http://www.w3.org)

Er... right. So... don't do that. i.e. don't choose
use http://www.w3.org as the namespace name for
an RDF-base vocabulary.

> My point here is that the mapping of namespace qualified element names to
> URIs as specified in M&S is broken (i.e. simple concatenation won't do).

You have demonstrated that some *uses* of the specified mapping
lead to unfortunate consequences, but not that the mapping
is broken, i.e. that it doesn't serve its intended purpose.

By analogy, we don't conclude that hammers are broken just
because you can hurt yourself if you hit your hand with one.


> The
> 'hack' that RDF uses is to constrain the namespace URI to end in neither a
> Letter or '_'. The problem is that other specs such as XLink do not so
> constrain the namespace URI,

Ah... that's a good point... it's probably worth propagating
the "your namespace name should end in a non-XML-name-character"
recommendation to lots of places.

> and it is intended to map XLink to RDF. This
> needs fixin'.
> 
> >
> > Yes, I am saying that RDF schema can be used to state
> > the intended use of namespace names.
> 
> Good. I was hoping this was the case. I have placed a proposal to map XML
> namespace qualified element names to URIs at:
> http://www.openhealth.org/RDF/QNameToURI.htm
> 
> I believe that if such a mapped URI is equated to the element name, this
> would have the desired effect of limiting who can create new element names
> within a given namespace.
> 
> For example, Jos De Roo states:
> 
> >Jonathan Borden wrote:
> 
> >> It is logical that the owner of a namespace (whatever that
> >> means) may restrict the ability of others to add elements
> >> to the namespace but where is this precisely specified?
> 
> >I don't know, but what I do know is that when there is an RDFS
> >resource out there, I can dereference it's URI and use that
> >content in my proof engine to avoid illicit term usage.
> >Thanks Jonathan, it is a very important issue for our RDF
> >based medical imaging services!
> 
>         Yes but are you using elements within some DICOM namespace for your medical
> image representations? Suppose the DICOM namespace URI does not end in '#'.
> Given the M&S definition, how can you properly dereference the DICOM element
> name into the RDFS Property (or Class etc.)?

He didn't say he could dereference element names; he said
he could dereference URIs. If DICOM chooses URIs
that don't work nicely with the RDF conventions, then
they might lose. Bummer.

[...]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 18 September 2000 14:51:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:44 GMT