RE: Using urn:publicid: for namespaces

> -----Original Message-----
> From: ext Stephen Cranefield
> [mailto:SCranefield@infoscience.otago.ac.nz]
> Sent: 10 August, 2001 15:13
> To: www-rdf-interest@w3.org
> Subject: RE: Using urn:publicid: for namespaces
> 
> 
> I wrote:
> 
> > > Therefore an unofficial syntax could be used to identify 
> namespaces.
> > > One possibility is to use the formal public ID syntax but with the
> > > language part omitted and a convention to end the ID with "::" (so
> > > that concatenation will work for QName to URI mapping):
> > > 
> > >   
> urn:publicid:-:University+of+Otago:NONSGML+Tourism+ontology+v1.0;
> > > 
> > > corresponding to:
> > > 
> > >   -//University of Otago//NONSGML Tourism ontology v1.0::
> 
> Patrick Stickler replied:
> 
> > But this is really just the same as adopting a single URI scheme
> > having a single allowed MIME type with an explicit fragment
> > syntax.
> 
> and later on:
> 
> > But again, this is imposing a single URI scheme on the SW in the
> > efforts to fix what essentially is a missing interface between
> > the syntax (QName) and semantic (resource URI) realms.
> 
> I want to be clear that I am not proposing the adoption of a "single
> URI scheme", nor am I advocating "imposing" anything.  I have no doubt
> that there will eventually be many different URN schemes in use.  I am
> simply suggesting this as an IANA-registered URN scheme that 
> can be used
> right now for namespaces.
> 
> - Stephen
> 

My sincerest apologies if I appeared to be putting words in your
mouth or if I misunderstood your posting.

With regards to the above, I'm all for standardized usage of particular
schemes for particular purposes -- I just wanted to (again) stress that 
the QName to URI mapping problem cannot and will not be solved by choice
of URI scheme because (a) it will never be possible to have a single
namespace+name concatenation method that will work with all URI
schemes, (b) we cannot burden RDF engines with knowing about URI scheme
specific concatenation (or other forms of combinatoric) functions,
and (c) we still need to provide for mapping between serialized literals
and resource URIs where QNames don't even enter into the picture.

There are/will be many criteria by which a given URI scheme is chosen
to represent a given type of resource -- but those criteria should not have
any significance whatsoever to how that resource URI behaves within any SW
context, insofar as the URI remains persistently unique. As far as the
RDF engine is concerned, it's just an opaque string. Any benefits to
be derived from parsing the string and finding structure and information
there are secondary to the fundamental operation of the SW.

Thus, insofar as RDF and the SW is concerned, the only URI scheme related
issue is one of persistent uniqueness. Everything else (however significant
to various processes and real-world applications) is IMO outside the scope
and concern of RDF. That is the benefit of RDF's adopting URIs for resource
identifiers, in that RDF doesn't have to worry about it. So no matter
what URI scheme one chooses to represent resources (even HTTP URLs!), one
simply has to be sure that those URIs remain persistently unique. Some
URI schemes may be better in that regard than HTTP URLs, but an RDF engine
won't care one way or another about the particular URI scheme so long as
the same URI always represents the same resource.

One can argue against using URLs as URNs, because of other problems that
arise (not the least being human confusion), but an RDF engine doesn't and
shouldn't care about such things). 

Figuring out which QName relates to which resource, though, at the moment
is a tougher nut to crack...   ;-)

Regards,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Friday, 10 August 2001 08:51:27 UTC