Re: Ownership of namespaces (was: Problems I cannot get past with using relative URIs for identity.)

-----Original Message-----
From: Noah_Mendelsohn@lotus.com <Noah_Mendelsohn@lotus.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Sunday, May 21, 2000 4:38 AM
Subject: Ownership of namespaces (was: Problems I cannot get past with using
relative URIs for identity.)


>
>Tim:  as you are probably aware from our private discussions, I agree with
>almost everything you have written in the attached note regarding the
>implications (and non-implications) of use of URI's for various purposes,
>and the value of properly integrating namespaces into the mechanisms of the
>Web if we can.

Good!

> This thread does, however, remind me of one of my remaining
>concerns about such integration:
>
>You and other authors refer to a notion of the "owner of a namespace".
>That is a very important concept which does NOT, as far as I can tell,
>appear in the namespace recommendation.

You are right, the namespace document does not define the property
"ownership" for
namespaces.

Iff you allow yourself to consider a namespace a resource then
it inherits the properties of a resource.  Ressources don't explicitly
have ownership defined in hte UIR RFC, but for a namespace whose
URI is in the http: spec applies, and the HTTP spec explains how
HTTP names are delagated through the DNS system, and
DNS *does* have ownership of domains. So any resource in the
HTTP scheme can be considered to have an owner which is the
owner of hte DNS domain.  (Of course, local delegation within
and organization may occur and may evn be representd within
the opaque part of the URI but that is not visible)

This applies obviously to FTP too.

>  As long as a name is used purely
>for purposes of identity, it doesn't matter whether the original inventor
>of that name is even around 20 years later when I try to use the name
>(either processing an old document, or creating a new one conforming to a
>long-lived namespace).  Requiring namespaces to have owners over the
>long-term introduces complications over and above the creation of names.
>Maybe a good thing on balance, but I don't think we have worked it out.

Well, "you pays your money and you takes your choice".  If you need
a delageted authroity psace which does allow you to have living documnets
like the xHTML namespace, then ownerhip is a social issue which you
need a framework for. DNS+HTTP provides that.

If you want an unchangeble undereferencable space then you pick somethig
like mid: or uuid:.  These do in fact use personal information in their
creation
(hostname for mid: and ethernet address for uuid, and datetime for both)
but as the convention is that these things are not reused ever then
there is no concept of ownetrship.  (We are not talking about intellectual
propetrty rights for the resource, we are talking about ownership of the
reseource
in the sense of being the uthority for defining its identity).

I have to point out here that having all the above defined for you is
just one example of the advantage the namespace gets in being a resource.

If you do not allow yourself to consider a namespace a resource,
then you are on your own.  Any properties of the namespace, such as how
you ensure it is globally unique, and how you determine whether this
one changes with time or doesn't change with time, you have to define
from scratch in a Namespaces spec.

> As
>a point of comparison, a Java programmer can easily create programs that
>use interfaces in or even create interfaces in packages with names deriving
>from long-defunct DNS names.  All that matters is uniqueness.

Uniqueness is assured by an honor system among the programmers, which
scales reasonably well for the current size of the Java development
community.
There is no meachnism to control someone creating a package with a name
in a long-defunct domain, nor to prevent an accidental clash.

>It seems to
>me that creating an abstraction of "namespace owner" requires great care,
>and I am concerned that we are backing into it.  If there is to be a
>notion of namespace ownership, then we need to think it through properly
>and clearly document the rules.  Can ownership change, etc.?

We are not creating something. In certain circumstances we are inheriting
things from other specs. The list for discussion of URIs is uri@w3.org

> If ownership
>is to be changeable, must the creator avoid use of names with schemes such
>as http: that imply location?

(Please stop implying that http: location.  http://www.w3.org/TR is a name!)
The data corresponding to a representations of that abstract resource
(The list of W3C technical reports) is smeared over the globe.

What you mean is, should we point out that managing HTTP names
so they can be persistent needs some thought? Yes, we should
more or less everywhere generally - but not specifically in the
namespace spec. (well, maybe).

See "cool URIs don't change"
htp://www.w3.org/Provider/Style/URI
and a draft W3C persistence policy
http://www.w3.org/Consortium/Persistence

>If W3C were to crater someday, would some
>other organization have to appear to "become" W3C in order to host the
>various vocabularies that W3C left behind?

Not to become W3C but to take on custodianship of the archives.
I would hope, many organizations would share it. I would like to
have this agreed in advance.  I think I have said this before on htis list.

>The same organization for all
>of them? etc.
*** bzzzzzzzzz Error: centralization detected bzzzzzzzzzzzzzzzzzzzzzz

nope

>Interpreted in the manner that you prefer, I think it becomes very
>difficult to have a namespace named by an http: URL be usable after the
>organization that invented the name goes out of existence.  Of course, each
>URI scheme has its own characteristics, and makes its own warranties
>regarding what if anything is (potentially) retrievable.   Even with http
>there are games that can be played, but you are clearly implying that one
>reason for making namespace names real URI's is that ownership is
>conferred.  That seems to me to be a big step, and I think it raises many
>questions which have not been fully considered.  Simple uniqueness of names
>can be achieved without solving these harder problems.  Many of us thought
>that was all the namespaces recommendation was trying to do.


There is more to the aspects of identity than "simple uniqeness". I think
I discussed this in RFC1630, but I am not sure that it survived into later
standards.

>I really do understand and largely sympathize with your reasons for wanting
>namespaces to named by and truly integrated with the mechanisms of the Web.


Good.

>Whatever the other pros and cons, I think that one potential advantage of
>the straight string-comparison approach is that it does not require/imply
>any notion of ownership.  The creator's responsibility ends with ensuring
>uniqueness.  In isolation, I think that is simpler and less complicated.  I
>am not trying to draw any simplistic conclusions here, just putting the
>question on the table.  Do you think that interpretation of namespace names
>as true URI's necessarily implies long-term ownership  (especially in the
>case where a scheme such as http: is used?)    Thanks very much.


I think I have answered that these peoperties are (deliberately) quite
different for different schemes.  I am really glad that they are not
on the plate of this group to solve (assuming URIs are used).

As I have said before, if the community really thinks that no existing
URI scheme really gives the properties we want, then we can indeed
make a new scheme.  (But not quickly!)


>Noah Mendelsohn                                    Voice: 1-617-693-4036


Tim Berners-Lee

Received on Sunday, 21 May 2000 11:04:37 UTC