On Thu, 21 Jun 2001, Thomas Baker wrote:

> On Thu, 21 Jun 2001, Rachel Heery wrote:
> > ( I have cc'd to those who I think are on DC Usage + Dan. I can't seem to
> > find a pointer to the usage committee on the web site nor a list of who
> > is on it)
>
> In the meantime, Rachel would like feedback from the Usage Board on
> "Purpose and scope of DCMI Registry".  This came in shortly before the
> May meeting, so it was not on the agenda.  I guess I hadn't realized
> she was asking for a coordinated response from UB as a whole.
> Certainly, though, it makes sense to frame our recent discussion of
> Application Profiles in terms of that strawman (see
> http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0105&L=dc-registry&F=&S=&P=52,
> which points to
> http://www.dublincore.org/groups/registry/purpose-20010511.shtml).

(Note: I'm responding to dc-usage, otherwise there is no log of the
discussion).

My comments on the registry scope document follow:

> Purpose and Scope of DCMI Registry
>
> 2001-05-11
>
> This document represents consensus reached by the Registry Working group
> on the requirements for a DCMI Registry. It is a brief outline which may
> be filled out in future after discussion with developers of the registry
> software, and after feedback from the Architecture WG and the Usage WG.
>
> The purpose and scope of the DCMI Registry is:
>
>   To assist DCMI to manage the evolution of DC vocabularies (to gather
> proposals for additional qualifiers, to manage process of approving
> qualifiers etc.)

My understanding of the view of the Usage Board (UB) was that only
recommendations should appear in the registry - therefore it can't help
manage the approval process can it - because nothing can go into the
registry until it has become recommended? (This is really a question for
people at the UB meeting).

>   To provide authoritative definitions of recommended DC elements and
> qualifiers

I'm not totally convinced by this.  Perhaps I don't understand what it
means.  I think this means that the authoritative definition of the DC
elements resides in a namespace schema hosted within the DCMI registry
rather than in a namespace schema hosted at the namespace URI (I'm
assuming, for example, that http://purl.org/dc/elements/1.1/ will never be
a URI within the DCMI registry).

My personal view is to see the registry as a handy repository of copies
of schemas and other material.  The actual schemas (both namespace schemas
and application profile schemas) and associated text documents can live
anywhere (and in the case of namespace schemas, the most appropriate place
is at the namespace URI).  In most cases, the schemas will not live within
the registry, rather the registry will hold copies of them.  Such an
approach does not make the registry any less useful (IMHO), nor does it
prevent it from holding annotations about externally-held schemas.

So I'd prefer to see this reading something like, 'To provide access to
authoritative definitions of recommended DC elements and qualifiers'.

>   To identify DC recommended schemes

Does this mean 'to enumerate DCMI-maintained controlled vocabularies' or
something else - I'm not clear what 'identify' means here?

>   To express these 'controlled metadata sets' and the relationships
> between them in machine readable schema language (see constraints) and in
> human readable mode.

Fine

>   To provide a user friendly interface to the registered metadata ( search
> and browse facility, browseable element set lists, links to annotations
> and guidance on use of DC elements and qualifiers)

Fine

>   To manage multilingual aspects of DC.

Fine - though not quite sure what 'manage' means here?  To provide 'access
to authoritative multilingual versions of DC elements and qualifiers'
perhaps?

> Essential Requirements:
>
> The following requirements are recommended for implementation in Phase One:
>
>   To enable DC elements and qualifiers to be annotated with a status such
> as 'proposed', 'recommended', 'deprecated' (these 'status' terms to be
> provided by the usage committee)

Fine, but need to either remove explicit list of statuses or align with
current UB view.

>   Interfaces to enable search by element name, free text, and element set
> (DC elements, DC qualifiers etc.); and browse through lists of element
> sets by namespace (DC, DC qualifier, DC approved schemes etc.)

browse by object 'type' as well as by namespace - e.g. browse all
'elements', browse all 'qualifiers', browse all 'application profiles',
etc.

> Other requirements:
>
> Other requirements to be phased in, priority as indicated:
>
>   High priority:
>
>     To link to authoritative translations of DC element and qualifier
> names and definitions.

'names and definitions' should read 'labels, definitions and comments'
I think... the names aren't translated.

>     To register DC recommended domain specific 'application profiles' e.g.
> the DCMI Education group application profile

Fine.  Again, I'd prefer to see 'To provide access to DC recommended
domain specific 'application profiles''.

>   Priority to be established:
>
>     To register authoritative mappings and crosswalks between DC and other
> metadata sets (e.g. ONIX, MARC etc.)

Fine.

>     To provide information on deployment (e.g. which services are using
> particular domain specific extensions)

Fine

>     To provide links to best practice, guidelines for use (perhaps link
> into the user guide?)

Fine.

>     To enable implementors to submit proposed extensions and application
> profiles.

(see above) I think this happens outside of the registry.

> Constraints/Assumptions:
>
>   We will use RDF schema language in the first instance as this is
> supported in the prototype software.

RDF schema language 'plus additional properties as necessary'?  We won't
be able to do everything just using RDFS ??

>   We do not expect to solve the versioning problem within the early phases
> of the registry, otherwise we will never get started.

I'm not sure why this is here.  What is the 'versioning problem'?

> Dependencies:
>
> In order to express DC elements and qualifiers in RDF there needs to be a
> decision on the namespace model for DC, in particular we will need to use
> a URL for each element and qualifier and scheme registered. For various
> reasons DC elements and qualifiers are now declared as separate
> namespaces, as are DC schemes and controlled lists. We need clarification
> on agreed practice regarding DC namespaces from the DC Architecture WG

a new namespace draft is forthcoming...

> In order to clarify process of assigning 'status' to DC qualifiers,
> recommended schemes, domain specific extensions we need advice from the
> Usage Committee

yes.

> Development work on the DCMI Registry software is currently undertaken at
> OCLC.  Work on multilingual aspects is being taken forward at ULIS, Tokyo.

Andy
--
Distributed Systems and Services
UKOLN, University of Bath, Bath, BA2 7AY, UK       [log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/a.powell      Voice: +44 1225 323933
Resource Discovery Network http://www.rdn.ac.uk/   Fax: +44 1225 826838