|
|||||||
Global navigation options: |
|||||||
Participants in the meeting
Priscilla Caplan
Eliot Christian
Makx Dekkers
Pat Harris
Terry Kuny
John Kunze
Clifford Lynch
Sally MacCallum
Cecilia Preston
Ralph Swick
I. Why standardise Dublin Core?
1. To stabilise
There is a sense of instability in the current definition of
the Dublin Core among organisations that want to start
implementing. Organisations directly involved in the Dublin
Core activity have started implementing in the understanding
that the definitions were open to change as a result of their
experiences. Other organisations, however, are waiting for a
stable situation before they start investing substantial
amounts of effort and money in
creating Dublin Core metadata. Standardising the Dublin Core
would (a) clearly mark a stable version of the agreements and
(b) make the process of change verifiable.
2. To ratify
Some organisations are required to use (international) standards for their activities. Examples are government agencies who are bound by public procurement policies. Being able to refer to an international standard for metadata would give them a tool to implement and/or procure products that conform to this standard. In relation to this, it was mentioned that standardising DC could help in ISO 9000 compliance.
II. What should be standardised?
1. The current state of the consensus described in RFC 2413 (now referred to as version 1.0) is the clear candidate to act as the basis for international standardisation as this is the version that has currently been implemented by a large number of projects. This version will therefore be proposed as input for the standardisation process.
2. It is true that there are still discussions over the
semantics of some of the elements in version 1.0. In DC-6, a
short-term action was agreed to tidy up the definitions of
version 1.0. This will lead to DC version 1.1, with the same 15
elements as version 1.0, but with clarified descriptions. Given
the intended timescale for this (3 months?), it is likely that
version 1.1 can be injected in the standards process, together
with any other ballot
comments, before a standard is ratified.
3. The standardisation of version 2.0 that is under construction can be progressed as a new version of the DC standard probably at the end of 1999 at the earliest.
III. Where can DC 1.0 be standardised?
There are various options for standardisation of Dublin
Core. Candidate standardisation bodies that have been
identified are:
(a) ISO, the International Organisation for
Standardisation
(b) CEN/ISSS, the Information Society Standardization System
of the European Committee for Standardization
(c) NISO, the US National Information Standards
Organization
A parallel approach is proposed, submitting DC 1.0 as a work
item to the three bodies at the same time, addressing it
to:
1. ISO TC46/SC4/WG7
2. CEN/ISSS Workshop on Metadata for Multimedia Information
(MMI) for adoption as a CEN Workshop Agreement (CWA)
3. NISO Standards Development Committee
The timescale of the standardisation process depends on
the
established procedures of the three bodies. Of course,
the
proposal has to go through these procedures, although wherever
possible, a fast-track option will be pursued. Hopefully, the
ballot process for all three tracks can be well underway at the
time of DC-7 in Frankfurt.
In any case, there was a consensus in the break-out session that the DC community would retain "ownership" of DC, so that, for example, it would be the DC process and not any external standards organisation that would control changes.
IV. What could be problems in the process?
Three issues were identified:
1. Copyright issues
All of the standardisation bodies have certain policies
towards copyright on the standards they publish. A solution can
be proposed where the standards bodies have shared copyright,
which allows them to sell the standard document, whereas the
Dublin Core Metadata Initiative at the same time should retain
the rights on making the content freely available on the Web. A
similar solution has been found between ISO, NISO and the
Z39.50 maintenance agency
concerning the Z39.50 standard.
2. Document format
All of the standardisation bodies have certain rules
pertaining to the layout and format of published standards.
There should be a certain flexibility, provided that the core
body of the standard is identical. An example of this is again
the Z39.50 standard where the content of the ISO and NISO
standard documents is identical.
3. Maintenance agency
In any case, the responsible body for the maintenance of the
content of DC should be a more-or-less formalised maintenance
agency much like the Z39.50 Maintenance Agency supported by the
Z39.50 Implementers Group is responsible for the maintenance of
Z39.50. The proposals for the Organization and Process of the
Dublin Core Metadata Initiative (Directorate, Technical and
Policy Advisory Committees, and DC Workshops) should lead to a
similar
identifiable maintenance agency.