I think I mostly agree with Mike's comments.

In particular I think the principle

> "metadata for a given entity should never be stored in more than one
place"

requires some qualification. It seems to me that in the context of the
Web it is inevitable that for any entity metadata about that entity will
be created by multiple agents, and made available in multiple "places".
It may even be that the aggregated sum of that metadata from several
places is contradictory, but it seems to me that is a problem that we
have to learn to manage - just as we have had to learn to manage the
existence of contradictory information published on the Web in
human-readable form.

Just picking up on one of Mike's comments:

> He says
> "For after all, an identifier is no use if it is not also a
> pointer of some sort, and in particular, a pointer to
> information about the entity it identifies." An identifier IS
> useful even if it just identifies something (as long as it
> does it well). That is what its primary role is and this is
> extremely valuable in itself. e.g. ISBN is useful wherever
> the store or library records are. Knowing that two things are
> the same or different is vital. Many people mix location and
> identification into a single URL. This is often fine but is
> not universal and if adopted as mandatory, or even best
> practice, will preclude the ability to multiply resolve identifiers.

On that last point, I don't think advocating the use of http URIs as
identifiers should be taken as implying that the only way of getting
information about the resource identified is by issuing an HTTP GET for
that URI.

The use of the http URI scheme means that given the URI alone, an
application with buillt-in knowledge of the http URI scheme has enough
information to try to obtain a representation of the resource, using the
HTTP protocol and the existing machinery of the Web. There is no
guarantee that the owner of the URI has provided a representation, but a
representation may be available.

This, it seems to me, is a very useful feature. Yes, the knowledge that
the URI is a unique name is useful in itself, and in some contexts that
is the only use I or my application needs. But the possibility that I
can obtain some information about what that name identifies, using
widely deployed protocols/systems, without developing anything new at
all, is a source of considerable added value, and one which I don't
obtain with a "non-Web-enabled" identifier scheme.

Further more, the use of an http URI to identify a resource does not
mean that the representation my application obtains by de-referencing
that URI using the HTTP protocol is the _only_ source of information
about the resource. It is one possible source of information about that
resource, but it is not necessarily the only source.

So e.g. given the URI

http://purl.org/dc/terms/alternative

I can get some information about the resource identified by that URI by
issuing an HTTP GET for that URI. The representation I obtain is an
RDF/XML document. (That's what I get today, while sitting at a PC in
Bath with a Web browser and an Internet connection - in another context
or at a different time I might get a different result.). That document
serialises a set of RDF triples representing statements about several
resources, including amongst others
<http://purl.org/dc/terms/alternative> , but it is still a reasonable
representation of that resource.

Note to DCMI: fix the MIME type! ;-).

My application could also get that same information by issuing an HTTP
GET on the following URI

http://dublincore.org/2005/06/13/dcq

My application can also get information about the resource
<http://purl.org/dc/terms/alternative> from

http://dublincore.org/dcregistry/listItemDetail?item=http://purl.org/dc/
terms/alternative

and indeed this provides a different (but "authoritative" according to
DCMI [1]) set of information about the resource. And if my application
is providing services to Japanese or Danish speakers, that set of
information might be more useful than the set I get by the simple HTTP
GET de-referencing of the PURL.

Pete

[1] http://dublincore.org/dcregistry/