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