[
Lists Home |
Date Index |
Thread Index
]
URIs are names on the Web. Moreover to the extent that we can compare the
Web to a language, URIs are its words.
I'd like to name things on the Web. Not just 'documents' but I'd like to be
able to name everyday things like "cars" and "people" and talk about them on
the Web. So the questions are: Can we do this? How should we go about doing
this?
When I use URIs I use URI that have the HTTP scheme i.e. start with "http:".
This is for the simple reason that I have easy access to several HTTP
servers, and good software that manipulates HTTP URIs.
So the question becomes: Can we use HTTP to talk _about_ things that are not
themselves documents?
Now URIs include both URNs and URLs and some folks claim that URNs are names
and URLs are locators and that one should be able to tell whether something
is intended to be a name or locator depending on its prefix.
I don't spend any time working with URNs [1]. I don't see why I should use
URNs to name things like people or cars or other things that aren;t
documents. For similar reasons I have no interest in creating new top level
schemes such as "person:foo" or "car:foo" for ever class of object that I
want to name or deal with.
I want to use my trustly HTTP server to manage information about the names I
create and I want to use the trusty HTTP protocol to interact with things
that other people create and give their own names for on the Web. I'd like
to think of these things like some abstract object, and the HTTP protocol as
the RPC protocol that I might use to interact with some object, somewhere
out there in the world.
To summarize, there have been a few different suggested ways of naming
things on the Web:
1) Use HTTP URIs to name whatever (i.e. the range of http is not limited to
documents)
2) Use HTTP URIs to name documents, but name arbitrary things as fragments
of the document e.g. use HTTP URI _references_ to name whatever
3) Use URNs to name whatever
4) Use new top level schemes to name each new class of resource
It seems like there is no perfect solution to this 'problem'. There are good
arguments against each of the above proposed mechanisms for naming things.
For example:
1) It has been said that people will get confused if HTTP URIs are used to
name things other than documents, i.e. that the HTTP scheme should be
restricted to resources that are documents.
2) It has been said that fragment identifiers _only_ identify parts of
documents, i.e. fragments, and not concepts independent of some particular
representation of a resource
3) URNs aren't widely used, and I can't easily publish my names using URNs
4) It is essentially impossible for me to create a new top level scheme and
to widely deploy software that implements a new protocol designed for that
scheme.
So for practical purposes the good options I see are either (1) or (2).
Position (1) has been best articulated by Roy Fielding. Position (2) by Tim
Berners-Lee for whom a fragment identifier identifies any arbitrary _thing_
within an RDF document (e.g. application/rdf+xml when that gets registered).
I am looking for good, compelling, arguments that help me distinguish
between (1) and (2) but these arguments shouldn't just repeat (endlessly)
the positions, these positions are well known.
My current position is that in the absense of a compelling reason (i.e. that
something really breaks) there is no reason to artificially restrict what an
HTTP URI might identify. That is while an HTTP transaction always returns a
document, what that document is _about_ might be _anything_. For example,
"my homepage" refers to a document _about me_.
For the time being I'll use HTTP URIs to name arbitrary things. My initial
experience using HTTP URIs to name namespaces has been a good thing --
people have been able to discover documentation related to those namespaces
e.g. http://www.rddl.org/ but if you insist that this is wrong because
people get the namespace confused with the documentation does changing this
to http://www.rddl.org/# (ala common practice in RDF) lessen or worsen the
confusion? It seems to me that the arbitrary '#' is more confusing, so I'd
like to hear a coherent, comprehensive, and easily deployable solution --
and since I'm already paying for my HTTP server, one that doesn't cost me
more $$/month just so I can publish information.
Jonathan
Now I don't claim that any of the above URIs identify "me" as a person, but
that is just because I haven't yet published such a URI (the 'real me' is
currently anonymous :-)
mailto:jborden@attbi.com
mailto:jonathan@openhealth.org
mailto:jonathan@jborden.org
mailto:jborden@lifespan.org
mailto:jborden@med.tufts.edu
http://www.jonathanborden-md.com/jonathan-borden-cv
http://www.jonathanborden-md.com/jonathan-borden-cv.htm
http://www.jborden.org/
http://www.erieneurosurgery.com/
http://www.erieneuroscience.org/
http://www.bostonneurosurgery.com/
[1] Why I don't spend time working with URNs.
1) I don't have easy access to a server that do anything with any URNs that
I might create.
2) Client software that deals with URNs is not widespread.
3) Most people don't know what to do with them.
I've seen URNs in two contexts (this isn't intended to be a comprehensive
list of deployed URNs just where _I've_ seen them used, or talked about)
1) Michael Mealing has developed/been involved with developing DDDS and
software to work with URNs, and seems genuinely interested in developing
usage of URNs.
2) Microsoft uses "urn" prefixed URIs as XML Namespace names.
Other than that, although URNs are oft talked about, I don't oft actually
see them, nor know of software that makes general use of URNs (well perhaps
except for "urn:pubid"s but that's yet another story...)
|
