innovation in metadata design, implementation & best practices

DCMI Usage Board - Meeting Agenda

DCMI Usage Board

Previous version: Thu Oct 18 16:14:04 MEST 2001
This Version: Fri Oct 19 10:37:15 MEST 2001 - FINAL VERSION BEFORE MEETING

Please contact for the latest version.
The latest version will be posted on the mailing list
at and (ideally)
mirrored at
After the meeting, the agenda will be archived under


Convenor: Tom Baker, Chair
Members expected:
        Andy Powell Diane Hillmann Haruki Nagata
        Roland Schwaenzl Stuart Sutton Tom Baker
        Traugott Koch     
        Rebecca Guenther
Guests expected:
        Harry Wagner Stu Weibel Rachel Heery

See also (click on "Advance Program")

Meeting packet

1.0.1: This agenda
1.1.1: [Cached copy]
1.1.2: [Cached copy]
1.1.3: [Cached copy]
1.1.4: [Cached copy]
1.1.5: [Cached copy]
1.1.6: screen-shot [Cached copy]
1.2.1: [Cached copy]
2.1.4: [Cached copy]
2.1.6: [Cached copy]
2.1.7: [Cached copy]

1. Monday morning, 9:00-12:00 -- 3'00" with 15" break

1.1. Guidelines for encoding schemes and subject 
     vocabularies (Traugott, others?)

    We need to clarify the process, workflow, and guidelines for
    fast-track approval. Traugott has revised the guidelines we
    discussed in May and will present these. See
    [PACKET 1.1.1:],
    posted on 8 October.

    With regard to process, we should review Stu's recent addition
    to the FAQ, mirrored at:
    [PACKET 1.1.2:].

    Items under consideration for fast-track include:

        RFC 3066, Rebecca's proposal, see
            [PACKET 1.1.3:]
        Ethnologue language terms (Diane)
        Identifier encoding schemes: ISSN, DOI, SICI, OpenURL... (Andy)
            [PACKET 1.1.4:].
        [PACKET 1.1.5:]

    Harry has prototyped an encoding scheme Web page at
    [PACKET 1.1.6: screen-shot].
    We should try to agree on a standard Web form for submitting proposals.

1.2. DC-Government proposal (Stuart)

    This is the main agenda item, for which we might need two hours.
    I have mirrored the version we will discuss at
    [PACKET 1.2.1:]

    See also

2. Meeting some evening, to be planned, eg 19:00-22:00?

2.1. Update and wrapup of Namespace issue, implications for Usage Board (Andy)

    [PACKET 2.1.1:]

    What happened to the DCMI Persistence Policy which used to be at

2.2. Usage Board process (Diane)

    Diane will summarize UB process as described in the
    revised document and recap the process by which that
    document was approved by AC.

    Relevant documents are:
    -- "Procedure for approval of DCMI Metadata Terms and
       Recommendations", [PACKET 2.1.2:].
    -- "Usage Board administrative process",
       [PACKET 2.1.3:].

    Diane has also worked on a revised "Criteria for Evaluation
    of Proposals", posted to the list and mirrored at
    [PACKET 2.1.4:].
    This would replace the current "Criteria" draft at
    [PACKET 2.1.5:].

    One urgent set of process issues concerns the workflow for
    documenting decisions made at meetings.
    I would suggest that shepherds be responsible
    for getting approval of the final form of their documents.  

    I suggest that the drafter submit the document to the dc-usage
    list with Cc: to Beth for posting on the meeting follow-up
    page. The drafters should clearly indicate that they are
    submitting the document for close reading and final approval.
    During the course of a one-month comment period, every member
    of the Usage Board should sign off (if only with a one-on-one
    message to the drafter) on every such deliverable. The drafter
    should keep track of who has signed off. If we agree on this
    process, we should perhaps add it to our process document.

2.2. Agent issues: ways forward (Diane)

    We discussed this on the list back in June, and
    Diane has produced a summary mirrored at:
    [PACKET 2.1.6:]

    See also the Agent issues to be discussed in a Tokyo breakout
    session on 23 October:
    [PACKET 2.1.7:]

2.3. Documentation of Usage Board results (Tom, Stu/Harry, Rachel)

    A working paper was used as
    the basis for overhauling the Web pages at This document will be updated in
    response to discussion on the list and turned into a manual for
    maintaining the UB Web pages. Rachel Heery of the DCMI
    Registry Working Group will also participate in the
    discussions so that we can clarify the relationship between
    the Usage Board and Registry activities. The agenda of the
    DC-9 meeting of the Registry WG is at

    In particular see:
    -- Registry prototype:
    -- Functional requirements:

3. Longer-term issues for "bar BOFs"

3.1. Application profiles (Andy, Tom)

    On May 21 (at the Dublin meeting) we decided that:
    a. UB is not concerned with application profiles.
    b. UB is not concerned with other namespaces.
    c. Recommendation: UB shouldn't approve application profiles.
       DCMI Registry should be responsible for registering application 

    The issue here is by what process, and according to which
    criteria, DCMI should be in the business of reviewing,
    recognizing, or just plain registering application profiles.
    Andy and I have been planning to write up some strawman
    guidelines for application profiles and have not yet gotten to
    this. One issue is that of APs as human-readable Web pages, as
    which is discussed in:

    Ideally, however, we would have more detailed guidelines for
    expressing such profiles machine-understandably, eg along the
    lines described in a paper by Makx, Rachel, Manjula, Gauri, and
    myself to appear soon in JODI:

3.2. DC-Citation (Andy)

3.3. Naming policy, dct:alternative vs dct:alternativeTitle (Andy)

3.4. Are element refinements "elements" or "qualifiers"? (Tom, Andy)

    The broader issue is that of our grammar, and whether we need
    an updated grammar paper. A related issue from a DCMI
    registry perspective is the technical question of whether a
    metadata term's grammatical category (element, encoding
    scheme, etc) should be expressed in the base RDF schema
    encoding the DCMI namespace or expressed as an RDF annotation
    to that schema.

3.5. Reviewing or endorsing translations of DCMI Metadata Terms (Tom)
    We need to think, for the longer term, about whether, who,
    and how translations of DCMI metadata terms should be
    reviewed for quality and certified by DCMI.

3.6. Definition of the Title element (Roland)
    See Roland's comments, mirrored at

* * *

Version: Fri Oct 19 12:32:27 MEST 2001

Query from Alan Lillich, Adobe Systems Incorporated, 17 September 2001

Sent: Monday, September 17, 2001 8:14 PM
Subject: Re: Repeating DC elements

It has been very interesting to watch the recent discussion on repeating
elements. I think the focus on personal choices is missing some important
broader issues.

The use of DC metadata will become much more valuable if we can achieve a
high degree of commonality. Like the standardization of railroad gauges,
it is not so important that you have a semicolon separated list of keywords,
repeated simple keyword elements, or in the case of RDF one keyword element
containing a bag of individual words. It is more important that metadata
written by one piece of software be understood by another.

There are (at least) two established and one emerging class of participants
in the DC metadata game. The established players are the DCMI and
significant end users of DC metadata. The end users are largely
distinguished by defining their own databases and producing their own custom
implementations. They are often in a situation where the metadata is the

The emerging participants are the volume software vendors and their
customers who can benefit from reliable metadata for all of their electronic
documents. Adobe finds itself in this situation. We are in the process of
adding RDF and DC-based metadata support to all of our applications.
Acrobat 5 is the first to ship with some of this support. (For those who
have used Acrobat 5, it does not embody the final or definitive
implementation. It was first, and as usual for software it does not do
everything we want to do.)

Adobe needs to make choices about the UI we present and the metadata we
write. We can't afford to spend the time and money to provide ultimate
flexibility. Much as we might wish, we can't canvas all or even a
significant portion of our users ahead of time. We need to provide a common
approach in all our applications that is useful for our customers, and that
can be utilized by other software to provide additional value.

We think it would be tremendously helpful for the DCMI to provide guidance
and suggested good practice for the use of DC metadata in unclear areas like
repeating elements. These should not have the weight of standards, but
guidance to help choose a representation and to transform among
representations. Policy for logically equivalent representations so that
software recognizes all legitimate forms. Perhaps standard qualifiers to
denote encodings like semicolon separated keywords.

For those of us using RDF, localization through the xml:lang attribute is
another area where it is easy to construct ambiguous examples. Suppose you
have a book with two authors, one American and one Japanese. And the book
is published in both the U.S. and Japan.

For the title an rdf:Alt container makes the localization explicit, although
repeated title properties with xml:lang attributes should be clear at least
to a human (but only because of the semantic knowledge that books don't have
multiple titles).

Suppose the Japanese author wishes to have separate Romanji and Kanji names
for the US and Japan. Use of simple repeated properties would be ambiguous,
indistinguishable from a case of three authors. Again use of an rdf:Alt
container for the Japanese author makes things clear. And use of an rdf:Bag
or rdf:Seq container for both authors makes it clear whether there is any

Alan Lillich
Adobe Systems Incorporated.

Query from Eddie Byrne,
Irish Public Service Metadata Project Co-ordinator, 26 September 2001

Eddie Byrne sent a query to dc-general last May and got some responses,
attached below, but the responses were inconclusive. He is looking for
additional guidance:

Byrne> Issue: use of case for DC qualifiers in HTML
Byrne> Choice between: (example) DC.Relation.isFormatOf or
Byrne> DC.Relation.IsFormatOf (note the difference in case)
Byrne> Why am I confused? Because the explanation and examples given at both
Byrne> and
Byrne> are contradictory
Byrne> and do not explain the reasoning.
Byrne> I am currently recommending that which is indicated as the Name of the
Byrne> qualifier as that which is to be appended to the element (i.e.
Byrne> isFormatOf). The only rationale I can give is that in the event of
Byrne> migration to xhtml or xml the lower case convention is already
Byrne> practiced and minimum disruption occurs. Does that explanation make
Byrne> sense, or more precisely, is it correct?

[message from Eddie Byrne to DC General Discussion list in May 2001]

Forgive me, I know that this discussion was had in May 1999 (as per
archives search), but the outcome seemed inconclusive (at least re.
html). Rdf/xml lower case seems a foregone conclusion, but what about
HTML, or more specifically the case of qualifiers? For example.
DC.Relation.IsVersioOf or DC.Relation.isVersionOf ? DC site examples
indicate the first as the case to use, however I not that AGLS
specifies the second. What might be the now accepted case convention if
there is such a thing? Or might someone explain why AGLS differ? Is the
AGLS case determined in any way by issues of migration? Or does it

Eddie Byrne

Response 1:

Hi Eddie and other colleagues,

Funnily enough, we were looking at just this issue yesterday when I was
reviewing our metadata standards against AGLS and other Australioan
government recommendations. HealthInsite aims to be AGLS-compliant but
it was pointed out that we use the DC convention for case in element
refinements. When I was developing the HealthInstie standards there was
a lot of guess-work because DC and AGLS were developing at the same
time. My feeling is that the issue is trivial and that harvester
software can easily be adapted to ignore any case differences in the
metadata syntax.

Regards, Prue Prue Deacon
HealthInsite Editorial Team
Commonwealth Department of Health and Aged Care (Australia)

Response 2:


As Prue noted in her reply AGLS was a qualified metadata standard
before DC had agreed on its qualifier set. For that reason we had to
make a number of decisions about practical matters before DCMI had
finalised its position on such matters. The AGLS capitalisation
convention was based on earlier versions of the proposal set out in the
paper "Recording qualified Dublin Core metadata in HTML meta elements"
at: To date this
is the only example of a convention for writing element refinements and
it specifies the convention followed by AGLS (although not in so many
words - lok at the examples) i.e. for element refinements the first
letter of the refinement name is in lower case and the inital letter of
any and all subsequent words which make up the refinement name are in
upper case e.g. DC.Date.modified and DC.Relation.isVersionOf and

Cheers Andrew Wilson
Assistant Director
Recordkeeping Standards & Policy
National Archives of Australia