Tom (and others):
I perceive some lack of discipline in your suggestion here and in your
earlier note [1]. But, before I get into yammering about that, I'll try
to lay out what I find convincing principles.
I find Andy Powell's arguments in [2] very appealing. That is, getting
rid of version numbers and/or dates from the namespace URIs entirely and
keep them as simple as possible. I, like others, find the available
information about namespace URIs pretty confusing and contradictory
(e.g., they should never resolve to anything, they should always resolve
to something, they can sometimes resolve to something, they should
resolve to some index, etc.), but my impression is the following. A
namespace is an identified concept space, sort of like the works in the
IFLA FRBR world. They are distinct from resolvable resources, which are
sort of like the manifestations in the FRBR world. The notion of a
version of a concept is a little hard to get your hands around, as
opposed to a version of a manifestation. Shakespeare clearing up some
mispellings and changing a few character names in Hamlet doesn't version
the concept Hamlet, it versions the manifestations (e.g. creates new
editions). Similarly, just because we diddle with some of the
definitions of the Dublin Core that doesn't mean that the concept
itself, reflected by the concepts identity its namespace URI, changes.
Now for the lack of discipline. You suggest two namespaces: one for the
legacy Dublin Core (DC Classic?!) and one for other. The former seems
to be some historical artifact, the latter seems to be everything we
incrementally add as we "add new elements". Yet, if a namespace is
analogous to a concept space and a concept has some binding semantic
integrity (we hope), surely your criteria for placement in these
namespaces is troubling.
We started the DC in 1994 with the notion that the 13 (soon to become
15) elements were "core" to discovery of Web resources. Admittedly we've
stumbled around in this area and made a good number of mistakes but I
would hope that the "concept definition" or "binding semantics" of
http://dublincore.org/elements (or whatever URI we come up with) is more
than "a legacy set of elements that back in the 1990's we thought made
sense". If that is the case, then let's indeed admit that and define a
whole new concept/namespace whose conceptual defintion is clearly "core
elements for resource discovery" and deprecate the original set of
elements.
The "other" namespace is even more scarey. This implies a form of
creeping functionalism as (quoting you) "new elements accrue". The idea
of new elements trickling in and adding them to a catch all namespace
seems to violate conceptual integrity and the work we did back in 1996
at Warwick to establish some framework for modularity for metadata in
different scopes. With the coming of RDF and XML namespaces, I thought
we now had the mechanisms to realize this modularity. If the DCMI is
planning to accrue elements willy-nilly and through them in a catch all
"other" namespace, then we need to step back and consider our founding
principles. A wiser approach would be to step back, understand what is
the modularity we wish to achieve and create namespaces and sets of
elements to populate those namespaces in some organized fashion. I
expressed this concern to you when I heard that the DC Usage committee
had decided on "audience" as a "new element" without understanding where
the new element sat and what its relatinship to the "core elements".
Finally, I'm confused about the concerns about changing our legacy
namespace URI. WOuldn't it possible to maintain the old namespace URI
(the one with the version # in it) and have it co-exist with a new
non-versioined namespace URI? Isn't having two namespace URIs for the
same concept ok? After all, the US government seems perfectly
comfortable with me having a SSN and a Passport #, along with a NYS
license ID#, etc. Surely we can accomodate this in our infrastructure.
Carl
P.S. This same discussion is going on in OAI [3] where we are equally
confused about namespace URIs, decided to follow DCMIs precendent of
having version numbers in our URIs and now are reconsidering that.
[1]
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0105&L=dc-architecture&F=
&S=&P=3268
[2]
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0105&L=dc-architecture&F=
&S=&P=2939
[3] http://www.openarchives.org
> -----Original Message-----
> From: Thomas Baker [mailto:[log in to unmask]]
> Sent: Saturday, June 02, 2001 4:45 AM
> To: [log in to unmask]
> Subject: Re: DCMI namespace URIs
>
>
> On Thu, 31 May 2001, Wagner,Harry wrote:
> > I have to agree with Dan on this. It is apparent (to me
> anyway) that we are
> > not going to find a naming convention that satisfies
> everyone. Let's go
> > with what the current draft has -
> 'http://purl.org/dc/elements/1.1/' and
> > move forward.
>
> This is consistent with my proposal, which considers the "1.1"
> namespace to be a legacy product that will remain (for now at least)
> stable and "at the core" of a larger, growing vocabulary.
>
> Putting all new elements -- not just qualifiers -- into a separate
> namespace saves us the embarrassment of implying that "the Dublin Core
> 1.1" now has 16 elements, wait... 19, oops make that 21...
>
> And it relieves us of the need to assign a new property to one of two
> namespaces based on whether it is an entirely new property (in which
> case it would go into dc:) or a subproperty of an existing
> dc: property
> (in which case it would go into dcq:). Hence:
>
> dc: http://purl.org/dc/elements/1.1/ - the legacy "Core"
>
> dcq: http://purl.org/dc/other/ | choose
> http://purl.org/dc/terms/ | one
>
> dcmitype: http://purl.org/vocabularies/dcmitype/ | choose
> http://purl.org/dcmitype/ | one
>
> If we stick with http://purl.org/dc/elements/1.1/, then for
> the sake of
> consistency I would prefer http://purl.org over http://dublincore.org.
>
> Tom
>
> ______________________________________________________________
> _________________
> Dr. Thomas Baker
> [log in to unmask]
> GMD Library
> Schloss Birlinghoven
> +49-2241-14-2352
> 53754 Sankt Augustin, Germany
> fax +49-2241-14-2619
>
|
