Re: tags

At 09:00 PM 1/23/2002 +0200, Patrick Stickler wrote:
>But since tag: is not a hierarchical URI scheme, one cannot use
>existing APIs and libraries that are able to recognize and parse
>hierarchical URIs. You then have to roll your own for the tag
>scheme, and any other scheme that "allows" you to have proprietary
>hierarchical syntax.

I have some sympathy with the idea that we should have specified tags to be 
of the form, for example, tag:timothy@hpl.hp.com/2002/01/23/whatever....

... for the sake of syntactic uniformity -- while keeping all the other 
properties of tags. But it wouldn't buy us anything else because tags are 
only ever compared or resolved in their entirety. And I still don't agree 
with you about the mandatory status of dates, for the same reasons as before.

> >>
> >> I don't follow. How do you retrieve a digital resource
> >> "from" a non-digital resource?
> >
> > You read the identifier with a sensor (e.g. a camera, barcode reader, ...)
> > and send the identifier to a resolver, which looks it up and returns the
> > URLs of one or more corresponding resources.
>
>I don't see how the entry method has anything to do
>with the nature or interpretation of the identifier.

Hmmm. I answered your question exactly but now I'm to be upbraided because 
it wasn't the question you meant :).


> >> Do you mean e.g. a book which may both be printed and available
> >> in digital form?
> >
> > That would be one example. But one could associate (the identifier on) the
> > book with many other types of digital resource, depending upon the
> > application. Tag has nothing to say about the allowed types of binding.
>
>It appears that we are not talking about the same thing.
>
>You seem to be using the URI to retrieve metadata about
>the resource, not the resource. As with barcode or other
>entry methods, I don't see how that has anything to do
>with the nature of the URI itself.

I'm philosophically opposed to the notion that there is such a thing as 
"the" resource. There are names; there are naming contexts that map names 
to other names or to resources; and there are resources (addressible 
functions). "The" resource that you speak of can only mean "the resource 
that this name maps to in this context".

So which context are you talking about -- the one that gives you or your 
community the type or status of answer you want? Or the one that the 
minting authority wants to associate with the identifier? I agree that I 
would like my client to be able to determine the minting authority's 
resolver for a name that it minted, in case I wanted its resource. There 
are several ways of achieving that, essentially by agreement to a 'root' 
context that maps naming authorities to resolver addresses. But the minting 
authority's context is just another naming context.

Cheers,

Tim.



Tim Kindberg

mobile systems and services lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126
usa

www.champignon.net/TimKindberg/
timothy@hpl.hp.com
voice +1 650 857 5609
fax +1 650 857 2358

Received on Wednesday, 23 January 2002 14:58:08 UTC