W3C home > Mailing lists > Public > www-rdf-logic@w3.org > November 2000

Re: names, URIs and ontologies

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Wed, 01 Nov 2000 11:22:39 +0000
Message-ID: <39FFFCFF.EEB47983@hplb.hpl.hp.com>
To: pat hayes <phayes@ai.uwf.edu>
CC: www-rdf-logic@w3.org
Pat Hayes wrote:

> Now, that is the part of the plan which seems mysterious to me. Where
> are these 'standard namespaces' to be found? Who will provide them?
>
Isn't this part of the job of DAML? You seem to be asking for a namespace in
which anyone can reference any English proper noun and allow ontologies and
reasoning systems to do what they can with it, knowing it is a proper noun and
not just a logical variable. There are at least two ways you could chose to do
this - define a URN namespace or pick an anchor URL.

1. URN namespace
First, URIs really aren't just URLs they can also be URNs as well. You may not
have seen many go past your browser but in fact there are several URN schemes
in active use. For example, Digital Object Identifiers (see
http://www.doi.org/) which can refer to things like books and generic creative
works as well as actual web publications. Secondly, URN's do not *have* to be
resolvable to actual URLs. The original intent seems to been that they should
but it has taken a long time for this resolution machinery to start to get
deployed and you can have a legal URN scheme without having a resolution
service to turn it into a URL.

Thus, DAML could simply declare that the Namespace IDentifier daml-name (say)
can be used to refer to any English proper name. Then we could all immediately
start using URIs like "urn:daml-name:Boston".

There is a mechanism for formally registering this Namespace IDentifier. It is
described in RFC2611. In a nutshell someone in DAML would fill in a template
describing the operation of the namespace and register it with IANA. The
template has to describe the syntax of the identifiers within the namespace,
the way in which names can be assigned and how names are resolved. For
"daml-name" I would suggest the answers to these questions are, in order,
"opaque" (any syntactically legal name can be used), "open assignment" (anyone
can assign a name in the name space) and "not resolvable" (no mechanism for
trying to get a URL corresponding to the URI). Once you had done this no one
need ever go through any process to use arbitrary names within the "daml-name"
namespace. Indeed, even bothering with this first step of registering the
overall namespace isn't a prerequisite to you actually using it - there are
lots of urn schemes in practical use which I'm sure have never been
registered.

2. URL Anchor
An alternative approach is to use a traditional URL-type web address to
disambiguate your "namespace", for example pick "http://www.daml.org/names".
Thus you could define that DAML ontologies should all use identifiers like
"http://www.daml.org/names#Boston". You can do this even if whatever resource
is at "http://www.daml.org/names", if any, doesn't actually contain anything
referring to Boston. You are just using it as a unique prefix to disambiguate
from the case where I do actually want to refer to a specific web resource
which happens to have "Boston" in its URI.


In both of these options it is up to DAML, or the overall community involved
in this work, to agree that allowing ontologies to refer to English proper
nouns (with attendant implicit connotations) is a Good Idea and to pick one of
these naming conventions that we'll all use for that purpose.

Hope I'm not just confusing things further.
Dave Reynolds, HP Laboratories

P.S. Having said all that about not resolving names it might actually be
interesting to provide a lookup service to which you could send one of these
proper names to and get back a (natural language) list of known meanings by
combining dictionary, encyclopaedia and gazetteer entries. But what you get
back of course, is not the thing itself but more description, so it is not
resolution in the sense of URN resolution services.
Received on Wednesday, 1 November 2000 06:22:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:32 UTC