At 09:41 PM 6/24/2001 -0400, Andy(? Tom? I've lost track) wrote:

>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).

I'm a bit concerned by this as well.  I think we need to track some of
these proposals through the formal recommendation process, perhaps via a
registry, perhaps not.  From the point of view of someone who is trying to
implement, and may be at the planning stage, having all this in the same
place makes sense.  Even having those things that were NOT recommended
makes sense with this scenario.

I guess, if we don't include any of the "other" stuff one registry, we have
to come up with some way to make the process and result more "public," and
I'm not sure a standard DCMI-style webpage really does that for those who
aren't familiar with DCMI and how it works.


>>    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?

Me neither.


>>    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?

I read it as "being the central place where all such version are
registered," which is a different thing, perhaps?  In any case, I think
both "manage" and "provide access to" are a bit ambiguous.

>>  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.

I'd say remove the statuses, but we still may need to clarify how people
will figure out what might be either "proposed but not yet recommended" or
"reviewed and not recommended."

>>  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.

Again, is this as a "central place" for those links, whereby the link
implies authority, or just a public service? (And does that matter?)

>>      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.

Yes, this is really necessary. But who determined whether they're
authoritative? The DC-UB perhaps?

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

Yes, definitely, and related to the "proposed" and "not recommended"
questions, in my view.

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

Absolutely ... ;-)


>>      To enable implementors to submit proposed extensions and application
>>  profiles.
>
>(see above) I think this happens outside of the registry.

Submission certainly belongs outside the registry, but tracking?  A
different problem.


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

Are we perhaps talking about more than one level of registration?  I know
we found that messy when discussing it in Dublin, but perhaps that was
because we mixed it up with the namespace discussion? I, for one, think
that maybe we should disentangle those issues, if possible.


*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Diane I. Hillmann
Metadata Specialist
National Science Digital Library Project at Cornell
Department of Computer Science          Voice: 607/255-5691
419 Rhodes Hall                                 Fax: 607/255-4428
Ithaca, NY 14853                                Email: [log in to unmask]
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*