W3C home > Mailing lists > Public > uri@w3.org > May 2001

Re: Should tags be URNs? (was Re: Proposal: 'tag' URIs)

From: Michael Mealling <michael@bailey.dscga.com>
Date: Tue, 1 May 2001 10:06:55 -0400
To: Tim Kindberg <timothy@hpl.hp.com>
Cc: michaelm@netsol.com, Sandro Hawke <sandro@w3.org>, uri@w3.org
Message-ID: <20010501100655.A4005@bailey.dscga.com>
Ok, I finally have time to get back to this...

On Sat, Apr 28, 2001 at 10:40:11AM -0700, Tim Kindberg wrote:
> At 09:31 PM 4/27/01 -0400, Michael Mealling wrote:
> First, let's take the following statements:
> (1) URNs are persistent.
> (2) URNs are location independent.
> The thing that strikes me immediately about (1) is that it's a category 
> mistake. No name -- URN or otherwise -- is either persistent or 
> non-persistent. What persistence can be predicated of is a _binding_ of a 
> name to a resource.

Correct. When we talk about a URN being persistent we are talking about
the binding to its Resource.

> Thus, my bicycle has a serial number etched on its frame. If someone stole 
> my bike and filed out the serial number would we say ''0234789036 (or 
> whatever) isn't persistent?'. Of course not: we'd refer to the 
> vulnerability of that type of binding of the identifier to the bicycle, and 
> may even talk literally of how to design better ways of making the binding.

I'd actually say that the etching of the number on the frame wasn't
the actual binding. The binding is abstract. Its just a feature that
the object also has a field on it that contains its identifier. If
someone files the number off does that change the fact that that bike
has that serial number? No. It still has that serial number its just that
you can't figure out what that serial number is by examining the 

> Taking statement (2), Michael pointed out to me that what was meant was 
> that the identifier does not contain the address where the identifier is to 
> be resolved. That is a highly desirable property that needs a name. While 
> 'location independence' is not an unreasonable name for it, I made the 
> mistake (actually, a category mistake) of taking it to mean "no matter 
> where one presents that name to the system, the result will always be the 
> same". Maybe it was just me being stupid (it's not as though I haven't seen 
> Michael's definition before).

Not stupid. These words are very slippery which is one reason the URN 
group(s) took so long...

> Now let me take something else that Michael says (Michael, I'm not trying 
> to pick on you!):


> "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. "
> This raises several questions for me.
> (A) What is it to 'identify a resource' and to 'use a name'?

Again, slippery words, but I'll define the way I'm using them here:
'identify a resource' is something that the URI does inherently. 'use a name'
is a function that I use a URI for. I can treat any identifier as a name for
something else (some strings are better at it than others but that doesn't
mean you can't use it as that way). URIs are, by definitioin, identifiers.
If I take that identifier and use it in a way that is 'location independent'
and doesn't require resolution then its being treated as a name. A good
example is XML Namespace names. You can put any identifier in there but
the spec says its treated as a name. 

> (B) Why 'their resource', not 'resource_s_'?

A URI identifiers one and only one abstract Resource (note the capitalization).
It is up to the Resource to be defined as being plural or not. I can see
two definitions of the word 'resources' there. One is where the resource
is a compound object. The other is that the thing identified has multiple
representations depending who you ask. The binding is still to one single
abstract concept. Its just that in both cases the abstract concept is 
fairly complicated and multi-faceted.

> As I'm sure everyone on this list is aware, their is philosophical 
> literature dating back to the ancient Greeks and continuing to the present 
> time on the topic of (A). I think that that discussion is interesting and 
> relevant to our debate. But as a computer scientist -- someone who is in a 
> position to design the 'artificial' rather than analyse the 'phenomena of 
> the world as we find it' -- it seems to me that we can answer those 
> questions by _assertion_.
> I  thus propose that we make _bindings_ first-class objects. A binding is a 
> tuple:
> <uri, resource, principal, descriptionOfBinding, expiryDate, signature>

This may be fine for your application but URIs only define two things:
the URI and a Resource and that they are bound. If you go beyond that
you create semantics that some systems won't accept. Now, the 'tag:'
scheme can define them to be specific to that scheme...

> This tuple says: 'principal' asserts the binding from 'uri' to 'resource'; 
> that binding terminates at 'expiryDate'; humans may think of this as 
> 'descriptionOfBinding' -- signed 'signature' (of 'principal').
> Thus, to 'identify a resource' is to make such a binding. To 'use a name' 
> (in the sense Michael used it above) is also to make such a binding.

For the argument at hand, yes. This 'binding' function is universal for
all URIs. Its what they do... But, as you do below, you can't 'write down'
a Resource. Its an abstract thing. You can describe it. You can show
me representations of it. But you can't write it down itself.

> So, here are some bindings:
> <tag:champignon.net;1:tims-home-page, http://champignon.net/TimKindberg/, 
> Tim Kindberg, "Tim's home page", 2001-12-31, "signed TK">
> <tag:champignon.net;1:tims-home-page, http://publicationsInc/2346590, 
> Publications Incorporated, "Tim Kindberg's publications", 2002-12-31, 
> "signed Publications Incorporated">
> /* comment: (imagine) this company keeps an up to date list of publications 
> for me, so someone encountering my home page can, through this binding, 
> find that list */

So you are binding the URI in the first part to the URI in the second
part, treating the URI as a Resource which, in essence, is creating
a relationship between URIs. 

> Uh-oh: the same URI used to 'identify' two resources! And neither binding 
> is persistent!

Huh? I don't see a Resource here. I just see two URIs....

> I claim that this state of affairs is reasonable. I stick a (barcoded) tag 
> in my home page, and now a whole world of heterogeneous resolution services 
> can take that tag and give a variety of different results (resources).

Sure. But that tag only identifies one abstract thing (you?). Its just
that you use a variety of methods to find out metadata about the 
abstract Resource.

> BUT there's something important that has to obtain to make this reasonable. 
> After all, if you were to stick tag:champignon.net;1:tims-home-page on your 
> home page, or on your bicycle..... chaos might ensue.
> I need help here, but it seems to me that there should be a notion of an 
> 'original binding': I mint a tag and I bind that tag to a resource that I 
> own, in such a way that that resource will only ever appear with that tag. 
> Eg: I physically bind it to my bicycle, or I insert it in my home page, or 
> I use it as an xmlns in a dtd that I make.

You can't stop this. Just the same way that I can file the serial number
off of the bike. You can make it difficult. You can even sign the thing. But
you can't stop someone from assigning another identifier to some set of bits.
This is subltly different but it is important to note that the relationship
between a URI and a Resource is 1:1. 

> Now, *you* may bind that same identifier to whatever you like. It's your 
> (or your community's) business. But *you* may not 'originally bind' your 
> tag to *my* resource.

Ok. That just confused me. What identifier is 'the same identifier'?
I can assign URIs to any Resource I want at any time I want. But because
URIs don't define equivalence other than at a character encoding level,
you can never state that two Resources are equal unless its an assertion
thats part of some specific application's policies, semantics and processes.

> So, Michael and everyone else: should tags be URNs?

I think they are. They have all of the correct semantics for one. But
I'm still not clear on the above enough to know if we're not talking
past each other....


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 Tuesday, 1 May 2001 10:17:46 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:39 UTC