innovation in metadata design, implementation & best practices

Title: Changes to terms in the DCMES namespace 
Identifier: /usage/meetings/2006/04/seattle/dcmes-changes/
Created: 2006-03-30

Shepherd: Andrew

Texts:
[1] /usageboard/2006/2006-01.definitions/term-changes/
[2] /usage/meetings/2006/04/seattle/dcmes-changes/comment-announcement-text.txt
[3] /usage/meetings/2006/04/seattle/dcmes-changes/2005-03-23.dc-language.html

Background 
[4] /usageboard/2006/2006-01.definitions/2005-09-10.meeting-notes-excerpts.html

The background for this issue is that documentation of any
(and all) changes to the original fifteen elements needs to be
done on a priority basis in order to prepare for a potential
NISO review later this year.

Andrew has compared the draft against what was decided last
year in Madrid [3].

Aside from polishing the text explaining the changes in the
above, an announcement giving overall context for the comment
period on dc-general needs to be finalized, see first draft at
[2] (maybe move this draft into the Wiki).

As of 2006-03-30, the proposed changes need to be justified.
Each individual term needs to have a justification for the
change proposed, even if this is just cut-and-paste from
another term. Several sections marked (@@@@TODO) need to be
filled in. An announcement giving overall context for the
comment period and justification for the changes (especially
regarding "content of the resource") needs to be finalized.

ACTION 2006-03-16 Andrew: Wordsmith justifications for the
proposed changes, also on a per-element basis (sections
marked "@@@TODO"), with particular attention to "content of
the resource".

ACTION 2006-03-16 Andrew: Suggest a comment for dc:language
along these lines ("Use an encoding scheme...") and post to
dc-usage for discussion. (This was done on 2006-03-28 and the 
proposed comment text has been integrated into [1]).

In February 2006, discussion on the DC-Government and
DC-Corporate lists suggested that DCMI re-think its approach
to 2- and 3-letter language codes.

In effect, the change in wording proposed in [1] (recommending
that one follow RFC 3066 in using 2-letter codes when
available) is at odds with the preference of many implementers
for 3-letter codes. While this issue may require special
attention on the list, the consensus was to try to keep this
as part of the current batch of changes.

Diane suggested that the crux of the issue is what
"recommendation" means. Why does DCMI need to recommend
one or the other? One way to handle this problem is to
generalize the comment. From an interoperability point of
view, the crucial point is that whichever way an implementer
does it, an encoding scheme should be used. For example, in
the comment to dc:coverage, we say simply: "Recommended best
practice is to select a value from a controlled vocabulary..."

ACTION 2006-03-16 Andrew: Suggest a comment for dc:language
along these lines ("Use an encoding scheme...") and post to
dc-usage for discussion.