Weibel,Stu <[log in to unmask]> wrote:
> http://dublincore.org/documents/2001/03/09/dcmi-namespace/

Adding on to the other comments you've heard today, I believe a large part
of this proposal is a serious mistake. I want to thank everyone who worked
on it for helping to move the process forward, but I feel that many of the
suggestions provided go against the will of the larger DCMI community and
may have negative effects on many implementers.

The document states:
> A DCMI metadata package is a discrete collection of DCMI terms identified as a
> group for management purposes.  Each DCMI package has its own sub-namespace
> within the DCMI registry namespace.

This seems to imply that each DCMI package would be in a subdirectory of a
more general Dublin Core namespace. This seems to be contrary to the system
of date-based namespaces that the document later proposes.

> http://purl.org/dc/elements/1.1/#title

Tod has already motioned to change this, so I will do little more that
support that effort.

> http://dublincore.org/2000/03/13/dces
> http://dublincore.org/2000/03/13/dcq
> http://dublincore.org/2000/03/13/dctype

I feel that this set of URIs is the wrong path to go down. We already have
chose a URI scheme for the element sets, and the old site had a similar
namespace set up for the qualifiers. To change this pattern now with
seemingly no benefit seems rather silly. I'd recommend the following
pattern:

    http://purl.org/dc/
    is the DCMI Registry namespace

    http://purl.org/dc/elements/
    is the namespace for the Dublin Core elements

    http://purl.org/dc/elements/1.1/
    is the namespace for the Dublin Core Elements Set Version 1.1

    http://purl.org/dc/qualifiers/1.0/
    is the namespace for the first version of the Dublin Core Qualifiers

This pattern can be extended and continued as seen fit. While we still need
to decide the proper use of the first two namespaces, at least this pattern
gives us the option to transition to a more general system if need be.

Furthermore, it continues the pattern that implementers expect (and in some
cases are already using). In addition, the use of PURLs implies persistence
of the Dublin Core elements even after the DCMI or dublincore.org is gone or
changed. AFAICT, there are no persistence policies in place for
dublincore.org namespaces. I feel this is a grave mistake. Finally, the PURL
URIs are simpler -- they can be understood by most anyone, they are shorter,
and they are easy to remember (especially beneficial to us who program DC
tools, or write files using DC and get annoyed at having to look up
namespaces every couple days). It's very difficult for me to have to
remember the arbitrary date 2000-03-13 and I see no reason to force this on
other people. Typos (and thus bad data) are much more likely to be
introduced with such complex names. It'd be easy for someone to use:
    http://dublincore.org/2000/3/13/dces
instead of:
    http://dublincore.org/2000/03/13/dces
since the leading zero is often omitted by most people.

So there are many arguments for continuing with the PURLs. I see no
arguments against them, or for this new system.

> It is important to recognize that the date-stamp component should not be
> construed as a version identifier or even as a date-stamp identifying the
> inclusion of a given term in a given DCMI metadata package, but rather as an
> administrative device signaling the instantiation of a given package.

I feel that this will be problematic, since there will be no easy way to
associate the arbitrary date of a namespace with the version of the spec it
is meant to represent. In fact, neither the proposal, nor the namespaces
themselves state which version they represent, so there is no way of
knowing!

> Changes of definitions of DCMI terms will be reflected in metadata registry
> declarations as a result of a formal approval process within DCMI. If, in the
> judgment of the DCMI Directorate, such changes of meaning are likely to have
> substantial impact on either machine processing of DCMI terms or the
> functional semantics of the terms, then these changes will be reflected in a
> change of namespace identifier for the DCMI term or terms in question.

Just to make sure I understand this correctly:

If DCMI were to change the semantics of dc:contributor to mean a person who
talks a lot about the resource, then they would create a new namespace and
place the new contributor in it. The other DC elements would remain in their
namespace. Documents would have to use two namespaces if they were to mix
both old DC elements and the new contributor element.

Is that correct?

> Changes in approval status have no impact on namespace identifiers for DCMI
> terms

The above sentence is missing an ending period.

One final question is that while you state the namespaces for DCMI terms,
and you state that they also have unique URIs in the DCMI registry, you
imply, but never state that these URIs will be the same. Furthermore, you
never describe what will be available when you dereference these URLs.

This may be on purpose, and if so, I suggest that you describe how it will
be decided what should exist at these URIs. I have a feeling that I and
others will want to comment on it. ;-)

Thanks again for helping to move the process forward!

-- 
[ Aaron Swartz | [log in to unmask] | http://www.aaronsw.com ]