Re: Proposal: 'tag' URIs

On Fri, Apr 27, 2001 at 09:07:45PM -0400, Sandro Hawke wrote:
> > > There are lots of "arbitrary" URIs not using URN syntax, like
> > > "mid:" and "data:".  Are those historical anomolies, which really
> > > should have been URNs?  
> > 
> > For those of us who use URNs, probably. But we're not going to make
> > a huge stink about it. They're all URIs and thus exist in the same
> > 'layer' of the web and have the same very basic semantics.
> ...
> > URNs do more than that. Infrastructure and systems are being deployed
> > now that provide all sorts of things for URNs (and URIs in general).
> > For example, we're setting up a URN based service called a Personal
> > Internet Name which is a permanent name for a individual or organization.
> > The ISBN organization is in the process of registering a URN for
> > all ISBN numbers...
> ...
> > And that's why we have URNs. Its a framework within which you can
> > define your own namespace but which defines a more specific set of
> > semantics (persistence, location independence, etc) than URIs in the general
> > case. 
> 
> What's the advantage of having URNs be syntactically distinct from
> non-URN URIs?  It made sense in the days when more people thought URLs
> and URNs were really different beasts, but now that we seem to
> understand differently -- as you say the infrastructure really applies
> to URIs in general -- who (which peice of software) needs to know if a
> particular URI has URN semantics.

All URIs regardless of the scheme have the basic semantic of 'identifying
their Resource'. URNs have the additional semantics of 'a) you never have
to resolve it to use it and b) you can safely assume that the name will 
never be re-used. The advantage of making a specific URN scheme is
that if I find something that is a URN I can safely make assumptions based
on those semantics. If each namespace id below a URN were simply created
as a seperate URI scheme I could not assume that one schemes idea of persistence
matched anothers....

> I'm fine with "tag:" being a URN scheme if I see some practical use for
> those extra four characters.

You get the fact that people know the semantics of the namespace you exist
under. You'll know that people will be given a fairly big hint that they
shouldn't try using that domain-name looking thing directly. 

> Or...  Hmm.  I don't want tags to have ANY semantics.  You're saying
> URNs are presistent and location independent -- that urn:x always
> denotes the same object regardless of the time and place of
> interpretation, right?  

Right. What that object is and whether or not its abstract or not is
up to you. All URIs denote something in the abstract anyway....

> Hrm.  What if we want a term
> (tag:sandro@w3.org/1-4-27/you) which, when used in a message, denotes
> the recipient of the message.  The term denotes a different recipient
> if the same message is transmitted again, to someone else.  That can
> be a tag URI.  Can it be a URN?  

Sure. In this case the URN (or tag) is denoting the recipient container.
What's actually in that container can be different from second to second.
Its the old concept of an identifier that identifies the weather that
currently exists 'today', an identifier that identifies the conditions on
4/27/2001 and will always do so, and another that identifies the weather map. 

> (There's a weirdness here between denoting the recipient and denoting
> the concept of denoting the recipient.   I'm trying to do the former;
> URNs could clearly do the latter, which might be sufficient for all
> applications.)

Its sufficient because everything, no matter how abstract, can be given an
identifier, even another identifier. This is what makes things like RDF
so interesting...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Friday, 27 April 2001 21:35:09 UTC