If we accept the need for such a unique-ing mechanism for sub-spaces,
then I agree that dates are preferable both to metadata (eg, 'ed')
and to arbitrary numbers.

However, it's not clear to me why we need so many sub-spaces in the
first place.  If any sub-space, once created, can be expanded with new
elements at any time, then I should think this would apply to one big
sub-space as well.

When the Usage Board approves new elements, by what criteria would it
decide whether those elements are more properly to be put into a new
sub-space versus added to an existing sub-space?  Why would it matter
where a new element is placed?  Are we assuming that sub-spaces must
contain groupings that are somehow meaningful, such as "the core
elements" or "education-related extensions"?  What is the advantage in
allowing sub-space names to proliferate?  I am quite sure this is a bad
thing to do from an "explanatory" point of view, but I do not even see
the technical advantages.

Tom

On Tue, 5 Jun 2001, Dan Brickley wrote:
> That's a great argument for not putting metadata (eg 'ed') in URI names
> for metadata constructs. Datespace URIs (as used eg at W3C) aren't
> metadata in this sense, they're just a unique-ing mechanism, to make it
> cheap and uncontroversial to create new sub-spaces for identifiers. We
> might use "http://purl.org/dc/ns000000000001#" instead, for all it
> matters. Basically, we get to choose some combination of numbers and
> words. Words IMHO have always gotten DC into more trouble than numbers,
> therefore I propose we learn from our past traumas and avoid words
> wherever possible in our URIs. Dates turn out to be reasonably memorable,
> and could should we choose carry some weak semantic, such as the date some
> ns was inaugurated...
>
> Dan
>
> On Tue, 5 Jun 2001, Thomas Baker wrote:
>
> > Dear Roland,
> >
> > I'm not sure I understand your argument...
> >
> > -- Suppose we approve "foobar" on 30 June as an education-specific
> >    element put it into the namespace http://purl.org/dc/2001/06/30/dc-ed.
> >    If we later decide it really should be the "16th element" of the
> >    cross-domain Dublin Core, do we then
> >
> >     a) move it into http://purl.org/dc/elements/1.1?
> >
> >     b) create http://purl.org/dc/elements/1.2, moving forward
> >        everything from 1.1 plus the new element? or
> >
> >     c) leave it where it is, letting people simply use
> >        http://purl.org/dc/2001/06/30/dc-ed#foobar for cross-
> >        domain discovery purposes, more broadly than its
> >        original scope?
> >
> >     Under the terms of the current strawman, I would assume (c).
> >     This implies that the inclusion block for XML namespaces in the
> >     instance metadata would include
> >     http://purl.org/dc/2001/06/30/dc-ed in addition to
> >     http://purl.org/dc/elements/1.1 and any other namespaces needed.
> >
> >     I understand that from a technical point of view this is perfectly
> >     fine and it is irrelevant (to the machine) whether that inclusion
> >     block has 1, 3, or 7 namespaces.  But it feels cumbersome,
> >     error-prone, and hard to explain.  And would we want alot of others
> >     to follow our lead in naming their namespaces?
> >
> > --  I agree that the management of content and structure -- the
> >     policies -- are key.  But I should think that the policies
> >     outlined in the strawman would work fine with respect to one
> >     big namespace: Once a "name" (URI) is defined, it stays there
> >     forever.  If its meaning changes significantly, we create a new
> >     "name".  If we decide to deprecate it, we make an annotation to
> >     that effect, but the name remains.
> >
> > --  Since namespaces are allowed to evolve (within defined limits),
> >     I should think each element would need to have administrative
> >     metadata for documenting and time-stamping the changes
> >     ("versioning").  But isn't that the case regardless of whether
> >     those elements are in 1, 3, or 7 namespaces?
> >
> > Tom
> >
> > On Tue, 5 Jun 2001, Roland Schwaenzl wrote:
> > > you wrote:
> > >
> > > > Yes.  Today, we may want to put one thing into a "qualifier" box, and
> > > > another thing into an "education" box.  But a year from now we may
> > > > decide that something belongs in a different box, or that the boxes
> > > > themselves are not properly defined.  With lots of boxes, we're stuck
> > > > with labels that are almost guaranteed to become obsolete.  If we have
> > > > just one box, we avoid that.
> > >
> > > What you describe is the reason, why versioning cannot be avoided.
> > >
> > > I disagree with your conclusion.
> > >
> > > It's irrelevant, whether DC vocabulary is distributed over 1, 3 or 7 namespaces. The use and mix of various namespaces
> > > is anyway needed for applications.
> > >
> > > What's important, is the management of content and structure.
> >
> > _______________________________________________________________________________
> > Dr. Thomas Baker                                            [log in to unmask]
> > GMD Library
> > Schloss Birlinghoven                                           +49-2241-14-2352
> > 53754 Sankt Augustin, Germany                              fax +49-2241-14-2619
> >
>

_______________________________________________________________________________
Dr. Thomas Baker                                            [log in to unmask]
GMD Library
Schloss Birlinghoven                                           +49-2241-14-2352
53754 Sankt Augustin, Germany                              fax +49-2241-14-2619