Re: Proposal: 'tag' URIs

On Fri, Apr 27, 2001 at 10:45:24PM -0400, Sandro Hawke wrote:
> > > 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.
> 
> I'm trying to understand how the first kind of weather identifier fits
> in with the definition of URN persistence.  The denotation of "the
> weather that currently exists 'today'" depends on the time at which
> the term is interpretted.  That doesn't sound like a URN.  It's no
> more persistent than "http://www.cnn.com".

Its persistently bound to the Resource it identifies. That Resource
may be a dynamically changing object like CNN or a report that contains
whatever the current weather is. URIs identify abstract concepts that
may (or may not) have some physical or network representation. In this
case the abstract concept is whatever the weather is at any given time.
The Resource can have a time component. Heck, the Resource can even
cease to exist, but the URN is still bound to the Resource even if it
doesn't exist anymore...

> I asked if you can use a URN to denote the recipient, and you said
> "sure", but then you said that it could denote the recipient
> *container*.  Isn't that a different thing?  

Yes. But it can do both...

> Can [0-9]* denote a negative number?  "Yes" it can denote a 
> negative number's additive inverse.  Which is really "No".

You're confusing the identifier with the thing you are identifying and,
in the case where the thing you are identifying is a container, with
the thing that is in the container. All three can have their own
seperate identifier if that's what you need...

> I'm not trying to be difficult here.  Usually arguing semantics is the
> last refuge of someone who's really upset about something else,
> but I'm pretty sure this is a real issue.

It is a real issue since it comes up very often. The first hurdle we
have to get over is that there is some kind of limitation to what
URIs or URNs can identify. There isn't. Any URI can be bound to anything
in the conceivable universe, which includes the concepts of nothingness
and also the identifier itself. I can assign a URI to ever single character
in an email message, and then assign one to each word grouping, to each
paragraph, to the whole thing, to the idea of the message, to the sender,
the recipient, the recipients pet poodle, etc.

> In Newtonian mechanics (as I remember it from long ago), if you want
> to represent the position of an object which can move along a line,
> you can do it like x(t).  The value of "x(t)" itself varies as time (t)
> varies, but x (the function), like every other "variable" in
> mathematics, does not actually change with time.  If you ever say
> x(t)=c you're saying that the object can never move.   But I want to
> be able to say x(t)=@@C, where @@C is a true variable, a shorthand for
> x(t).    (I just picked @@ because I don't think it's anywhere in
> mathematics, and this doesn't belong in mathematics.) 

And URIs don't adhere to Newtonian Mechanics. They're to simple. They simple
identify and there is no limitation to what they can identify and why.
Or, to actually use your notation, @@C is a URI because you are simply
saying that @@C is a new variable that represents that function (there's
a mathematical term for that but I can't remember it). Thus saying @@C +
@@D would be adding two equations. This is what URIs do inherently. They're
simply variable names. There are certain classes of these variable names
that you can do things with on the Internet and find out what they
currently identify but that's not required in order to just use it the
way you are here...

> > > (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...
> 
> And the reason I want to say x(t)=@@C is because of RDF's "triple"
> model, which means I can't use a structure like x(t) as an identifier
> (as I could in Lisp, Prolog, etc); I need to use something like @@C.
> 
> If I want to say x(t)=y(t) in RDF, I say something like:
>    x timevar @@X
>    y timevar @@Y
>    @@X equal @@Y
> but if @@X and @@Y are URNs, then their denotation is "persistent". 

Nope. What is persistent is that you can always call use @@X and we'll
always understand that you always mean x(t), not that x(t) is persistent.
The persistence semantic of URNs has everything to do with the identifier
and absolutely nothing to do with the persistence of the thing its identifying.

> I
> need @@X and @@Y to vary over all places in space, so @@X might denote
> Boston, MA at one moment and Reston, VA at another.  That doesn't
> sound like URN "persistence".

Yes it is. Again, persistence with respect to URNs has nothing to do with
the Resource and everything to do with the identifier....

> I should work this through an example RDF representation of a web page
> being edited (where I'll need identifiers for, say, the text of the
> page which changes), but I've got to run.

Again, you can assign a URI to any conceivable part of that process. Its
just a variable....

-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 23:15:39 UTC