On Mon, 4 Jun 2001, Thomas Baker wrote:

> This feels like progress...
>
> Aaron wrote:
> >I'd be perfectly happy with:
> >
> >http://purl.org/dc/elements/1.1/
> >http://purl.org/dc/terms/
> >http://purl.org/dc/type/
>
> This looks good to me (and Andy agrees).
>

I have come to this discussion a little late as I have been away,
apologies. I also have had no feedback yet from Usage Committee so am
missing that perspective.....

However on reading thro the debate it seems we are discusiing 3 issues
that need to be considered in final decision

- 'domain name' within DCMI namespace URI's
- how many namespaces we need
- what we do about versioning

1. Domain name

I think the desire for symmetry (all URIs should follow
purl.org or dublincore.org) should be followed if possible. So I would
support the purl.org naming convention throughout, given implementors are
understandably reluctant to change current data.

2. Namespaces

I fully concur that different people are using idea of 'namespace'
in all sorts of different ways which makes it difficult to agree criteria
on deciding on DCMI namespaces. In particular I think there is confusion
between namespaces and schemas and element sets.

My view is we need to take the data structure within DC metadata, and most
significantly the way DC is being used in practice, and reflect this in
the namespaces. I agree with Ralph Swick's comment at the last DC Workshop
in ottawa, that deciding on how many namespaces one uses is an
architectural decision. I think we should focus on what will be most
effective for users of metadata, and for managing evolution of the
metadata.

I believe we need to distinguish:

DC elements
DC qualifiers
DC domain specific element extensions (e.g. DC Education elements)
DC domain specific qualifier extensions (e.g. DC Education Qualifiers)
DC controlled term lists (ie DC 'owned' schemes)

It seems to me that each of these groupings can be distinguished in
relation to each other (picking up Carl's point that 'audience' needs to
be seen in relation to other DC metadata vocabulary). I would argue that
each of these groupings is used by metadata end-users (creators/searchers)
in a different way, and that each needs to be distinguished in the way
that its evolution is managed.

If I understand Tom's proposal he is arguing for one 'dictionary' of all
DC vocabulary.... I would suggest that what Tom is proposing is a
particular 'user interface' to DC semantics. We can still present one
dictionary to the end-user while behind it lies different namespaces to
enable more effective manipulation of metadata. By having different
namespaces we can distinguish, manage and manipulate different sorts of
metadata in different ways.

I would see it as the role of a regsitry to present appropriate 'user
interfaces' to the concepts identified by various DC namespaces. So a user
interface to a registry might allow the user to view all various
namespaces as one 'space'.

If we do not include in the namespace URI differentials between elements
and qualifiers, between core elements and and domain specific elements,
then where do we signal this? I am unclear from Tom's proposal as tom
whether he thinks we should do away with this structure or whether the
intention is that it is the role of the registry to impose the
structures.

In summary I would support distinguishing namespaces as in Andy's original
mail with addition of domain specific namespaces. This is the route we are
currently taking in the SCHEMAS registry.

 3. Versioning

I think there is some confusion in this debate as to whether we are
discussing where versioning info needs to be located.... or whether we are
saying we do not need versioning info at all.  I would suggest there has
to be clear record of versioning, I would have thought that the namespace
URI was a good enough way to do this.

I believe there is a need to keep track of namespace versions for each
semantic unit. Why? to make communication easier, to enable identification
of metadata created to a partic version, to enable clear id of tools that
are compatible with latest standard etc

If we do not put this info in the URI where does it go??

Seems to me putting in a place-holder in the URI (whether a date or v1 or
...) is good failsafe approach. Then if nothing ever changes much you are
ok, if it does you have mechanism to version...??



Sorry for length of this... I will forward precise proposal to list giving
suggested namespaces, later

Rachel

---------------------------------------------------------------------------
Rachel Heery
UKOLN (UK Office for Library and Information Networking)
University of Bath                              tel: +44 (0)1225 826724
Bath, BA2 7AY, UK                               fax: +44 (0)1225 826838
http://www.ukoln.ac.uk/