Subject: Re: URx Questions

From: Patrick Stickler <[email-masked]>
Date: Mon, 21 Jan 2002 09:29:47 +0200

On 2002-01-21 5:37, "ext Sean B. Palmer" <[email-masked]> wrote:

> Hi Patrick,
>
> Sorry for taking so long to go through your recent URx publications;
> here are some fairly innane questions, and some general comments.
>
> My first Q is about the hierarchial URN scheme. Michael pointed out
> that they can have domain names as authority components, which isn't
> all that persistent. UUIDs would be alright, but they're fairly
> difficult to generate. The other option is a tag-esque "domain,date"
> component - which brings me to the question: how does "hrn:" differ
> from "tag:"?

As I pointed out in an earlier response, the use of the web
authority does not make an 'hrn:' non-persistent, as the
web authority in an 'hrn:' represents only the minting
authority, and not the resolution authority. In an 'http:'
URL, a web authority is both, and thus if it changes or
becomes inactive, the resolution authority becomes invalid
and thus persistence is impacted.

'hrn:' URNs do not have that problem, even though web authorities
may be used, because the web authority remains historically valid
and even if it becomes inactive, that has no impact on the
persistent validity of the 'hrn:' URN.

See section 3 of draft-pstickler-uri-taxonomy-00 regarding
these distinctions.

The benefit of allowing a web authority as the minting authority
is that it provides a far less centralized method of "namespace"
than 'urn:' NIDs or purchasing of URIs from NID owners (e.g. DOI,
ISBN, etc.). With 'hrn:'s, anyone can mint a mnemonic URN
based on a web authority, or a non-mnemonic (or partially
mnemonic) URN based on a UUID easily and without fear of
collision. And those URNs can be hierarchically defined to boot.

'hrn:' = "URN Power to the People" ;-)

> I presume that the hierarchial aspect is what you're
> after, although I'm not sure what the relationship between the
> segments is.

Hierarchy was one desired characteristic. Minimially-centrallized
minting was another (i.e. based on any web authority, not having
to register a namespace or pay some agency that has a namespace).

Per above.

> Why not use ":" as a hierarchial segment delimiter in
> "tag:"?

Because there already is a standard syntax for hierarchical URIs and
many APIs and libraries exist for parsing such hierarchical URIs into
their components.

Why introduce another hierarchical syntax if the present standard
does the job?

> Note that "tag:" was going to be registered as a URI, and URN
> NID.

I understand that. But it appears to me that it is only the
contemporary view that forces this redundancy. You should be
able to register it simply as a URI with a classification of URN.

Or, you can register it as an NID of the 'urn:' scheme.

Why do both?

Having both 'xxx:foo' and 'urn:xxx:foo' is sure to result in
alot of needless overhead.

> Next Q: I can't work out what "voc:" is for, if anything. The draft
> states: "This provides a more robust and safe treatment of unqualified
> names than the 'online:' or 'genid:' treatments employed by most RDF
> systems to date.", so it sounds as if they're meant to be replacements
> for anonymous nodes... but the structure of the URIs suggests
> otherwise.

The use of 'voc:' in RDF for providing non-collisive identifiers
for local (not anonymous) resources is very much a fringe use.

The 'voc:' URT scheme is intended for vocabularies. See the
examples in the I-D. That should clarify its intended usage.

In short, for the URIs of all element and attribute names of all
XML content models, for the URIs of all resource names of all
RDF schemas, for the URIs of all controlled vocabularies
and taxonomies such as ISO language and country codes, TGN
geographic names, etc. etc.

I.e. for all abstract identifiers.

I think that the 'voc:' URT scheme is the most important of
all of the newly proposed schemes, and has the widest application.

> I've also been wondering about the taxonomy in general. A lot of
> people will tell you that an HTTP URI is just as good a persistent
> identifier as any URN - it's the social contract that matters, and
> HTTP URIS are widely deployed. The URN/URL/URP taxonomy feels rather
> artificial to me, and I fear that creators of new schemes will have to
> beg to you as the arbiter of where a new scheme belongs.

I agree that before such a taxonomy would reach the maturity
of a standard that it would need more precise definition. I think
though that the criteria distinguishing the proposed classes is
fairly straightforward.

If your URI scheme denotes a point of access, it is a URL. If it
denotes an indirect access key, it is a URN, if it does not resolve
(is self contained) it is a URP.

I.e.:

   URL     direct resolution
   URN     indirect resolution
   URP     no resolution

> [BTW, I'm not
> sure I would have chosen the acronym "URP". Every time I write it, I
> feel like excusing myself afterwards].

It does seem to give a few folks indigestion ;-)

> For example, you've listed ESL as a URV. I can see the motivation
> behind that, and I would agree - if not for the fact that ESL could
> easily have been submitted as a URN NID.

But why? Is the primary and fundamental purpose of an 'esl:' URI to
denote some other web resource independent of its location?

> At the moment, I am one of
> those who feel that the boundary between URP and URN is not all that
> solid. [In fact, I wonder why there isn't a "uri-x:" alternative of
> "urn:urn-x:".]
>
> I'm not sure what the utility of the "qname:" scheme is. In fact, many
> of the drafts are lacking in describing the utility of the schemes
> themselves. Whilst this seems to be common practise, it's something
> that I battle against. All new schemes should have a detailed space
> describing their purpose and motivation, because it obviates arguments
> later on. If you could prepare a summary of the aims of each scheme,
> that would be rather useful.

All of the schemes have specific utility but I tried to avoid being
too specific with regards to all possible applications, keeping each
I-D focused on the essential technical details regarding the URI
scheme in a generic fashion that would be as future-flexible as
possible.

I am actually working on a more descriptive account of where/how each
is used, which, if I get it done in time, I will likely submit for
the SW track at WWW12.

Cheers,

Patrick

--

Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: [email-masked]

---

From: Tim Kindberg <[email-masked]>
Date: Mon, 21 Jan 2002 08:42:55 -0800

> > component - which brings me to the question: how does "hrn:" differ

As one of the people who devised tags --
http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-01.txt -- I'm
having trouble understanding Patrick's hrn: design and his comments below.

One of the rationales for tag: has always been to separate minting from
binding and make minting convenient for humans, so we seem to share that.
An important aspect of minting, obviously, is a guarantee of uniqueness.
Email addresses and domain names belong to at most one entity at a time and
are thererfore suitable 'seeds' for uniqueness -- hence we use them in
tags. But they're not uniquely assigned over time. Therefore we qualify
them with a date on which they're assigned:

tag:[email-masked],2002-01-21:ikaika, which is a name that I have just
assigned for my dog, is guaranteed to be unique now and forever, because I
own that email address on today's date. No-one -- in particular, a
[email-masked] at HP in the year 2034 -- is allowed to mint a tag for
any date other than one on which they own the email address/domain name, so
they can never legitimately choose the same name.

In contrast, the person who holds abc.com in 2034 might 're-mint'
hrn://abc.com/288918293/3/en/global/docbook. At least, there may be no
records of what previous owners of abc.com have minted, so the new minter
can't be sure.

As for the hierarchical nature of hrns -- sure, hierarchies are nice. But
why mandate a syntax to that extent for the 'local' part of the identifier?
It's nobody else's business; it just has to be unique.

By the way, tag: is in the RFC editor's queue. It's also somewhere in the
urn nid registration process.

Tim.

>is used, which, if I get it done in time, I will likely submit for

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/
[email-masked]
voice +1 650 857 5609
fax +1 650 857 2358

---

From: Patrick Stickler <[email-masked]>
Date: Tue, 22 Jan 2002 16:26:24 +0200

> records of what previous owners of abc.com have minted, so the new minter

I fully appreciate the benefit of guarunteed global and temporal
uniqueness (hence support for UUIDs), but I feel that there are
other means of anchoring names in time, not just by date, such
as version numbers, and there is nothing to prevent you from including
a date in an 'hrn:' root, similar to 'tag:' -- it simply isn't
manditory.

While the goal of persistence is one that all URN schemes should
embrace, there are different degrees of persistence and different
degrees of uniqueness, and given the intended use of 'hrn:'s felt
it reasonable (if not proper) to leave it up to the minting
authority to decide what degree of persistence is optimal.

> It's nobody else's business; it just has to be unique.

I'm not sure I follow you -- though per my unsure understanding,
you would like to leave everything beyond the authority portion
opaque?

Well, there's no restriction about having "local" syntax for
partitioning of any sort, and you can have any valid URI string
(sans '/' characters) in your local part, with just one level
of naming.

Having a standardized representation for hierarchy, though,
is very useful for scoping identifier models which define the
identity of resources in terms of superordinate context.

E.g. work/expression/realization/instance is a common hierarchy
in the library/literature fields.

We use a similar hierarchical, scoping identity model for
modular digital resources here at Nokia.

> urn nid registration process.

I am well aware of that, and wish the 'tag:' URI scheme
well. In fact, I referenced it specifically in my I-D
http://ietf.org/internet-drafts/draft-pstickler-uri-taxonomy-00.txt

I will admit, however, that the intended purpose and utility
of the 'tag:' and 'hrn:' URN schemes do overlap, and one
advantage of the 'hrn:' scheme (having of course a biased
view) is that the semantics of the 'hrn:' scheme expect an
instance of that scheme to denote a retrievable digital
resource whereas the 'tag:' URN/URT scheme may be used for
either digital or non-digital resources, which introduces
problems for software applications needing to decide what
to do with one.

Regards,

Patrick

--

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Tue, 22 Jan 2002 08:46:44 -0500

> records of what previous owners of abc.com have minted, so the new minter

Actually, the "guarantee" of uniqueness is only as good as the
minting authorities make it... the spec doesn't require you to use
today's date in the URI, only some date when you were in control of
the given address -- in 2034, ABC would be able to continue to issue
tag:abc.com,2001 URIs if they wished (whether or not they still owned
that domain name in 2034, given that they owned it in 2001), and they
might reuse one due to forgetfulness or because URI issuing was
placed in the charge of some knucklehead marketing type who says "I
don't *care* if we used that same URI 20 years ago for something
else... nobody remembers that ancient history, and I like how it
looks, so I want to use it now, and I'm the boss!"

Even when people use today's date in tag: URIs, some might be
sufficiently absent-minded to use the same one twice within the same
day, or have the issuance be done by a discoordinated organization
where one hand doesn't know what the other is doing and different
people keep stepping on one another's toes.

Thus, no standards document is truly going to guarantee uniqueness of
URIs... it's up to the people who issue and use them.

> urn nid registration process.

I'd like to know just "what's the deal" with these dual URN namespace
/ URI scheme registrations.  If they're approved this way, which form
are the users and developers supposed to use, the urn:foo: one or the
foo: one?  Does it depend on whether the user anticipates that the
resource will, some day, be possibly resolvable on the Internet?  It
seems like these dual-nature URI schemes will result in there being
multiple URIs for the same resource as the urn: part gets added and
dropped capriciously.

--
== Dan ==
Dan's Web Tips: http://www.dantobias.com/webtips/
Dan's Domain Site: http://domains.dantobias.com/

---

From: Tim Kindberg <[email-masked]>
Date: Tue, 22 Jan 2002 09:25:28 -0800

>people keep stepping on one another's toes.

And neither does our draft state that users should not stick pins in
themselves. I take it for granted that identification relies on many
factors that have to do with 'good practice'. As systems designers we can
only try to create openings that prove (or don't prove) to satisfy a need
and that are within the limits of people's budgets and competencies.

>multiple URIs for the same resource as the urn: part gets added and

Each scheme that has, for one reason or another (mostly trying to keep
their heads above the mire in the boggy mess that is URL-land), pursued
dual registration, should specify whether foo:x is the same as urn:foo:x. I
believe that we're lacking in that respect and I'll fix it. By the way, we
view the one namespace as a simple embedding of the other, so tag:x and
urn:tag:x are the same _identifiers_ (I didn't refer to bindings), for all x.

Tim.

Tim Kindberg

---

From: Tim Kindberg <[email-masked]>
Date: Tue, 22 Jan 2002 09:38:18 -0800

>a date in an 'hrn:' root, similar to 'tag:' -- it simply isn't

But 'version numbers' don't necessarily cross organisations whereas dates
do. Our view is that you have to mandate some type of framework for the
coherence of the name space.

>you would like to leave everything beyond the authority portion

That's what we do.

>(sans '/' characters) in your local part, with just one level

But my point is: why frame or constrain where there is no global need to do
so? We should agree on as little as possible (Occam's Razor for naming
schemes).

>in the library/literature fields.

I'm happy to let such communities develop their own standards but it's none
of my business.

>problems for software applications needing to decide what

One of our intended use models is indeed that people can attach tags to
physical entities but the point of doing so is for users to retrieve
digital resources from them
(http://www.hpl.hp.com/techreports/2001/HPL-2001-95.html). So I don't see
the difference.

Cheers, Tim.

Tim Kindberg

---

From: Patrick Stickler <[email-masked]>
Date: Wed, 23 Jan 2002 12:21:13 +0200

On 2002-01-22 19:25, "ext Tim Kindberg" <[email-masked]> wrote:

>> minting authorities make it... ...
>
> ... I take it for granted that identification relies on many

In principle, I fully agree, though in practice, I prefer
solutions that facilitate and encourage what is percieved
as optimal without mandating or forcing what is percieved
as optimal, because needs/understanding change and
needs/opinions vary.

Thus, you can create an 'hrn:' that is, according to the UUID
specification, guarunteed to be globally and temporally unique
(presuming a valid implementation) while still adding mnemonic
components to it if desired. E.g.

  hrn://-/f81d4fae-7dec-11d0-a765-00a0c91e6bf6

or

  hrn://-/f81d4fae-7dec-11d0-a765-00a0c91e6bf6/Chapter1

One can also, as per 'tag:', anchor one's 'hrn:' temporally by
date, e.g.

  hrn://abc.com/2002/FinancialReport/Introduction

or at higher resolution

  hrn://abc.com/2002/01/22/FinancialReport/Introduction

Or one can use other means to denote temporal ordering, such
as version numbering, e.g.

  hrn://abc.com/InductionGuide-v2.7

Or one can use proprietary components that ensure temporal
uniqueness, such as managed sequences of identifiers, e.g.

  hrn://abc.com/abcid_881819923819/Chapter1

Or one can simply trust that the name is so significant within
the context of the minting authority that it will never be
reused, and thus ambiguity will never arise, e.g.

  hrn://[email-masked]/resume

In short, it's up to the minting authority to decide just
how strict or loose the requirements are for temporal and/or
global uniqueness -- with each of the options having more or
less overhead to use (granted, some discussion regarding
global and temporal uniqueness and how to best achieve that
would likely be a good addition to the final 'hrn:' RFC, and
I've made a note of that).

A generalized URN scheme must provide the utility and
flexibility needed to accomodate common naming practices while
still providing for the needs of most or all users, including
absolute temporal and global uniqueness if so desired/needed.

With regards to temporal anchoring, 'tag:' seems to me to be
too "mothering" and not general enough. And as has been pointed
out, does not provide a form that garuntees against accidental
collision within the same authority (e.g. UUID). Thus, 'hrn:'
is both more general and more precise than 'tag:'.

If absolute temporal and global uniqueness is paramount, there
are other URN schemes that can be used, and agencies that will
ensure that uniqueness for all instances of such schemes no
matter what, but for a price (e.g. DOI, ISBN, etc.).

>> / URI scheme registrations.  ...
>
> ... By the way, we

It's nice that *you* view them as the same, but how are applications
(or humans) to know that they are the same?

I think that the IETF should *heavily* discourage, if not disallow
dual registration of equivalent URI and URN NID schemes.

Cheers,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Wed, 23 Jan 2002 12:43:47 +0200

> coherence of the name space.

But "mandates" in general seldom succeed. You must support the
practices and traditions of the minting authorities.

It is up to the minting authority to determine what is needed,
and in my experience, it is seldom that the current practice
does not suffice.

Forcing all organizations worldwide to change the way they
construct identifiers (apart from educating them on the issues
relating to globally and temporally unique idenfiers in a
web context and showing them how they can best achieve that)
is not going to work.

Most large organizations have very well established methods for
achieving unique names within the scope of that organization, and
the 'hrn:' scheme is a way for them to capture those methods in
a URI without having to re-engineer those methods or processes
(unless they choose to).

>> you would like to leave everything beyond the authority portion

But why should the rest of the world also live with that
restriction. Many folks *need* hierarchical identifiers.

> so? We should agree on as little as possible (Occam's Razor for naming

Where on earth do you get the idea that there is no need to
do so. Just because you don't need to, or just because
everybody doesn't need to, does not mean it is not a widespread
need.

> I'm happy to let such communities develop their own standards but it's none

Then why are you commenting on the 'hrn:' scheme?

It is a standard for global naming for communities which
desire hierarchical URNs.

If you don't care about hierarchical URNs, then you
shouldn't care about the 'hrn:' URN scheme. No?

> (http://www.hpl.hp.com/techreports/2001/HPL-2001-95.html). So I don't see

I don't follow. How do you retrieve a digital resource
"from" a non-digital resource?

Do you mean e.g. a book which may both be printed and available
in digital form?

In such a case, we have several "entities", we have the abstract
work, and an expression of that work (e.g. in a given language),
and for that expression, two manifestations, one which is physical
and one which is digital. Only the last, the digital manifestation,
would be a URN denoted resource, leading from the definition of
a URN as an indirect point of access for a digital (web) resource.

C.f. http://www.ifla.org/VII/s13/frbr/frbr.htm

Regards,

Patrick

--

---

From: Tim Kindberg <[email-masked]>
Date: Wed, 23 Jan 2002 09:16:16 -0800

At 12:21 PM 1/23/2002 +0200, Patrick Stickler wrote:
>too "mothering" and not general enough.

You seem to have missed the point of tag. Without date qualification (or
something much more laborious), an entity that holds an authority name
could pollute the namespace of another entity that earlier held it. The
restriction is solely to guard against that. It is not exactly a
resource-hungry restriction.

Of course, if you really want to, you could buy some DOIs instead (assuming
that _they_ will always be around). But we wanted to allow individuals and
small organisations to participate in naming at little or no cost -- that
includes those who possess only an email address (or domain name). Email
addresses are quite frequently given up as users change ISPs so the chances
of someone else getting the same authority name are not negligible.

>And as has been pointed
>collision within the same authority (e.g. UUID).

<repeat my earlier remarks>

>dual registration of equivalent URI and URN NID schemes.

I agree with you. Tag is not where it is by overall design but by where and
how we thought we could add value at the time. I think it's a mess that we
have both registrations going but 'the system' is a mess and I'm not yet
sure what to do to right our situation. I'm hoping that one or other
registration will reach a stage when the solution to the problem becomes clear.

Cheers,

Tim.

Tim Kindberg

---

From: Tim Kindberg <[email-masked]>
Date: Wed, 23 Jan 2002 09:18:49 -0800

>restriction. Many folks *need* hierarchical identifiers.

? tag doesn't deny them that: whatever follows the <authority,date> may be
hierarchical.

>Then why are you commenting on the 'hrn:' scheme?

I was talking about the tag scheme. But I'm also entitled to point out what
I believe to be deficiencies in other proposals. I thought that that what
this forum was for.

>"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.

>Do you mean e.g. a book which may both be printed and available

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.

Tim.

Tim Kindberg

---

From: [email-masked]
Date: Wed, 23 Jan 2002 13:11:37 -0500

> URLs of one or more corresponding resources.

In that case, the URI of the original offline resource is *not* being
dereferenced to an online resource that is "at" that URI; the
paradigm rather seems to be more that of hyperlinks, where various
online resources, at different URIs, can be "linked from" or
"associated with" the offline resource.  In that case, the offline
resource's URI is the URI of that resource, not of the things it
points to or that have been associated with it.  When you scan it and
find associated links, you're not "resolving" the original URI as a
URN might be, where it leads you to a current instance of the
original resource, but rather you're using it as a launching point to
find other resources that are relevant to the original one, each of
which has a URI of its own (a URL, or maybe a URN that can be
resolved to a URL).

So, if I decide to assign URIs to each comic book in my collection, I
know that I can't actually retrieve the comic book by typing that
into a browser (or even scanning it from a bar code I've attached to
the plastic bag I'm storing the comic in), but there might be online
things associated with it, both private to me and public, such as a
database record of when, where, and for how much I purchased it, a
review of the storyline, a scanned graphic of the cover, an Ebay page
where I'm currently trying to sell it, etc.; a smart user agent might
be able to retrieve those things, but the URI of the comic itself
wouldn't be the URI of any of them, just associated with it... just
like the URLs I link to from my Web pages aren't the URLs of my Web
page itself but merely other resources I'm associating with it.

--
Dan Tobias, Programmer/Webmaster

---

From: Tim Kindberg <[email-masked]>
Date: Wed, 23 Jan 2002 10:44:58 -0800

At 01:11 PM 1/23/2002 -0500, [email-masked] wrote:
>"associated with" the offline resource.

The paradigm is like hyperlinks; I call them 'physical hyperlinks': instead
of associating text (in a Web page) with a URI, we associate a physical
object with a URI. That physical association, like a textual association,
is significant at a human level but it's irrelevant to what happens in the
system when the underlying URI gets resolved. The rest of what you say
isn't clear but doesn't seem to make any important distinctions for me. The
URI is resolved to a resource in exactly the same ways that any URI is
resolved to a resource.

>the plastic bag I'm storing the comic in),

I think you're making an artificial distinction by setting up some type of
Platonic resolution result and comparing it with other possible resolution
results. It's not mathematically possible to 'know' anything a priori about
the possible results of resolving an identifier except in some specified
naming context. I can always construct a naming context that maps a given
identifier to an (arbitrary) given result, and construct a 'browser' that
acts as a client to that naming context. The fact that we use browsers of a
certain type pointed to certain naming contexts is a convention driven by
the application concerns of the times -- and they may change.

Cheers,

Tim.

Tim Kindberg

---

From: Patrick Stickler <[email-masked]>
Date: Wed, 23 Jan 2002 20:54:25 +0200

> of someone else getting the same authority name are not negligible.

I fully understand the motivation and benefit of the tag date qualification,
I just don't see that it has to be manditory. I think I gave sufficient
examples to justify that view.

And if a minting authority is truly concerned with absolute temporal
uniqueness, they can either include date components in their hrn or
use the UUID form.

You seem to argue that because date qualification is not manditory,
it's not possible, or that hrn's can't achieve temporal uniqueness
without it.

> registration will reach a stage when the solution to the problem becomes

It seems to me that the deciding criteria whether one registers
a URN scheme as a top level URI scheme or a 'urn:' NID is whether
one plans to use DDDS for global, transparent resolution.

If so, then the NID makes sense. If not, then I see no reason
to bother with NID and go with URI registration (though the
latter is rather scary and laborious).

Whether DDDS can be used or extended to support arbitrary URN
schemes will be an interesting exercise.

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Wed, 23 Jan 2002 21:00:41 +0200

> ? tag doesn't deny them that: whatever follows the <authority,date> may be

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 believe to be deficiencies in other proposals. I thought that that what

Absolutely. Though on this point you appeared
to be arguing
that a general, hierarchical URI scheme was not
needed.

> 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.

> 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.

Cheers,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Wed, 23 Jan 2002 21:05:10 +0200

> URI is resolved to a resource in exactly the same ways that any URI is

The URI might be resolved to *a* resource -- namely a description
of the resource, related resources, etc. -- but it does not seem
to resolve to *the* resource itself.

Thus, your URI is not a URN, but a URP of some sort, denoting
a non-digital, non-retrievable resource about which you can say
things.

Eh?

> the application concerns of the times -- and they may change.

But it is precisely to capture the intent of the minting
authority with regards to a resource that we need semantically
distinct URI schemes, and for economy and order, URI classes.

So that applications know what *should* happen, even if they
can't know what *will* happen.

Patrick

--

---

From: [email-masked]
Date: Wed, 23 Jan 2002 14:34:28 -0500

> scheme, and any other scheme that "allows" you to have proprietary

To what purpose would one wish to have software automatically parse
out the hierarchical levels of a non-URL URI?  Even with URLs, with
their specified hierarchy, you can't always reach a useful resource
by simply paring off levels from the hierarchy, though users
sometimes try it in their attempts to get around sites with poor
navigation structures.  (There's a Bugzilla entry for the Mozilla
browser that suggests adding an "Up" button that does this hierarchy
slicing, with much debate over whether this is desirable or not --
many seem to think power users will find it useful but novices will
get too confused.)  While this has some (intermittent) utility for
URL navigation, what purpose would it serve for other URI types?

In general, I'd like to see more detailed description in the
proposals for new URI schemes and URN namespaces of just what
purposes these schemes can be used for.  There are lots of intriguing
ideas for namespaces in these proposals, but they tend to be rather
light on specifics about just what practical use they are.  Some
concrete examples of uses to which they may be put would be helpful.

--
Dan

---

From: Tim Kindberg <[email-masked]>
Date: Wed, 23 Jan 2002 11:58:00 -0800

>scheme, and any other scheme that "allows" you to have proprietary

I have some sympathy with the idea that we should have specified tags to be
of the form, for example, tag:[email-masked]/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.

>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 :).

>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

---

From: Patrick Stickler <[email-masked]>
Date: Wed, 23 Jan 2002 22:55:58 +0200

I am working on a paper that outlines the URI schemes based
on their potential applications, and hope to have that
done by the end of February (unfortunately, I have to fit
it in and around alot of other, higher priority work).

But when it gets near final draft stage, I'll post it here
for folks to rip up (er, comment on ;-)

Cheers,

Patrick

--

---

From: Patrick Stickler <[email-masked]>
Date: Fri, 25 Jan 2002 12:25:06 +0200

> that this name maps to in this context".

Whether or not several names, possibly contextual, correspond to the
same "thing" in the universe does not mean that a given name does
not correspond to one and only one thing.

Names may only be valid or interpretable within a given context, but
I do not agree that the same name in different contexts can correspond
to different "things".

One may use a name as a referent in various operations, such as
retrieving information *about* that thing, but that information
retrieved is not *the* thing itself.

A name identifies a resource. A resource may either itself be
retrieved or used as the context or focus of the retrieval of
other resources. I think this distinction is fundamental to
the expected and required behavior of the web and semantic web.

A name cannot in one context identify a resource and then in
some other context directly identify some other resource, even
if the other resource is related in some way to the first.

Patrick

--

---

From: Tim Kindberg <[email-masked]>
Date: Fri, 25 Jan 2002 08:13:37 -0800

>I do not agree that the same name in different contexts can correspond

So /etc/passwd is guaranteed to be the same file on all UNIX computers? So
we have to give up the independence of bindings of names like 192.168.0.*?

If you want the Web to be different then you have to define the property of
the Web that makes it so.

I believe that we do need a way of getting a default binding -- a mechanism
whereby software can automatically get the address of the resource bound by
the name's minting authority. But the software that I have as my client
should equally be capable of using alternative naming contexts to reach
alternative resources. Let's have a market of naming contexts just as we
have a market of web sites. I shouldn't have to have new software to take
advantage of a new naming context. E.g. imagine that a film has a
globally/temporally unique name; now imagine all the sites/naming-contexts
you might want to get resources from, using that same identifier. Even if
you insist on saying that those other resources are likely to be 'metadata'
about the minting authority's resource, they're still separately managed
resources.

Tim.

Tim Kindberg

---

From: Martin Duerst <[email-masked]>
Date: Sun, 27 Jan 2002 22:34:02 +0900

>if the other resource is related in some way to the first.

So what exactly is the resource in a web site that's language-
negotiated (e.g. set your browser's preference to have
Japanese and French higher than English, and browse through
the Apache documentation).

The resource is e.g. 'documentation of module FOO' independent
of language. It is NOT some sequence of characters/bytes,
because there is no single entity to uniquely and consistently
represent this resource. Resolving the resource doesn't
give you something you can call 'the resource', it's just
one possible variant. The resource only exists in our
imagination.

How does that fit into your model?

Regards,    Martin.

---

From: Patrick Stickler <[email-masked]>
Date: Mon, 28 Jan 2002 13:51:18 +0200

> we have to give up the independence of bindings of names like 192.168.0.*?

My apologies, I was thinking URI and wrote "name".

My argument was that URIs are global names with consistent meaning. A URI
cannot mean different things in different contexts, as the intended scope
of URIs is to be globally consistent.

Patrick

--