What I meant to say is that what a URN refers to is really the provence of
the publisher. What is at issue here, I feel, is not what the URN refers
to as much as how the URN is used.
In the best of all possible worlds, URNs are most valuable as pointers to
static resources because there is a strong tendancy to use them to refer
to the entire product *and* as a base for references to portions of
products.
If a URN can be assumed to point to something which must be taken as a
whole (atomic), there is no problem. The content may change at the whim of
the publisher, and the URN is still a valid reference because there are no
dependancies associated with that URN.
If a URN can be used as a base for further pointers into a product, the
relationship between the whole document and its parts must not change or
else these pointers may become invalid. If this relationship does change,
there must be a new URN. (If a URN refers to something which contains
other URNs, is there a requirement that the first URN be marked static? I
think so. Or else, I think we need to have a hierarchy of dependance of
URNs, ie. these URNs are valid as long as this one has not changed.)
So there seems to be an argument here for URNs to refer to leaves and
never to branches (atomic elements and never collections of other products)
unless there is some way that the branch URN can be guaranteed to be static
or we have a method of representing URN dependancies.
--------
I believe that there is a real value in having some way of refering to a
truly static resource. Within a static resource, links to internal
content are guaranteed to be valid as long as that resource can be
retrieved. This is a very important aspect of the problem, because if we
cannot guarantee that links to portions or pieces of a product will remain
valid, we must always refer to the product as a whole or run the risk of
creating invalid pointers.
Put another way, I need to be assured that these instructions will allow
me to retrieve this thing. If the thing to which I refer is a whole file,
or a complete product, the instructions are valuable. If, on the other
hand, the thing I wish to retrieve is a part of a whole and those
instructions are based on the structure of the whole, I need to be assured
that the relationship of the whole to its parts has not changed or those
instructions no longer refer to the thing I intended.
Can this be answered by some information associated with the URN which
states that the product to which it refers is static?
----------------
Micheal Mealling brings up the idea that a URN might refer to a service,
which by its very nature is dynamic. There is a distinction here, I feel,
between a service and its content. The service itself is static -- it exists
over time and does not change. So the reference to the service is static.
The content of a service is the dynamic part.
I think what I am trying for here is that the service itself is the
product, one which provides access to other potential products. As a
product, the service can be assigned a URN, but that URN cannot guarantee
the content of that service.
In the final analysis, all of this is all left up to the publisher. If I
publish a paper which people refer to parts of, and I change that paper
(its content) without creating a new URN to it, I have potentially
invalidated those references others have made to portions of my paper. It
is my responsibility, as publisher, to make sure that, if I feel this is a
BAD THING, it does not happen.
</rr>