Dear all (Harry and Beth take note!),
I have finished the first pass through Beth's notes (see below) and am
looking for an efficient way to wrap up all of our work from the May
21-22 meeting. I find it easiest to think of this in terms of ten
deliverables, each with a designated drafter, and have structured the
discussion below accordingly. The filenames I assigned are not
binding.
Please print out this document (long!) and read it through carefully.
I would like to ask all drafters to send their documents (or URLs if
appropriate) to Beth for posting on a Web page; I have attached mine to
this message. Beth will let us know the URL of that page.
1. http://dublincore.org/documents/2001/03/09/dcmi-namespace/ (Harry)
-- the draft namespace policy for DCMI. Though this is not a Usage
Board document, we did discuss it at some length (see #2a-m, #9c,
#11, #19, #20). In particular, we suggested removing the words "in
the judgment of the DCMI directorate"; deleting references to the
registry for the sake of simplicity; and deleting comments about
what to do with the namespace if DCMI is dissolved.
That discussion has now been superseded by discussion on the
dc-architecture list. As of June 12, it would appear that a
consensus is forming around a counter-proposal, which will need to
be written up at some point. Could Harry perhaps use the current
proposal as a basis and put together a proposal using the URIs
suggested on the list? Tom and Andy could perhaps then help edit
this. We note that the DCMI Directorate said it was going to
recruit an ad-hoc committee of experts to review the draft of March
9 and assume they would do the same with a counter-proposal.
2. MISSION.TXT (Tom) - I have circulated the revised Mission and
Principles document to the list for comment and attach a copy here
for Beth.
3. CRITERIA.TXT (Tom) - As called for in points #3v-w, I cut the
"Criteria for Evaluating Element and Qualifier Proposals" from
MISSION.TXT and created a separate document, also attached.
4. GUIDELINES.TXT (Traugott) - Point #8 summarizes discussion of
Traugott's strawman. Traugott, could you please revise this, post
to dc-usage, and send it to Beth?
6. PROCESS.DOC (Diane) - Diane took extensive notes during the
discussion and posted a revised draft on May 30 at
http://128.253.121.110/DC-UB/DC-UBprocess3.html. Diane, does the
draft account for points #1a(ii-iii) below? Since this document is
undergoing revision, I'd suggest that Beth simply link to it for
now. Diane, with regard to 5.2.1 I believe we decided that only
members of the Usage Board (and the DCMI Directorate) can post to
the JISCMAIL list for the Usage Board, but that all of the traffic
is archived for and accessible to the public.
7. PROCESS-DIAGRAM.DOC (Tom) - I will have someone here turn
the process flow chart -- the one I drew on the flip-chart --
into a diagram for inclusion in #6.
8. EDUCATION.TXT (Stuart) - Stuart, I know you have posted this
but could you please submit the corrected to Beth as well?
9. LANGUAGE.TXT (Rebecca) - Rebecca, same as with Stuart's
document, could you please submit this to Beth?
10. DECISIONS.TXT (Beth) - In accordance with 5.3.3. of Diane's process
document, our decisions will need to be published as a Web document
on the Recommendations page. Beth has standard templates for this
and will combine the contents of EDUCATION.TXT and LANGUAGE.TXT
into one DECISIONS.TXT. This combined file should also include a
reference to our approval of "URI" for Source (point #21), which
does not need to be further documented because it already is part
of the August 2000 qualifier recommendation.
LOOSE ENDS
-- Point #3x(iii): it is not clear to me what action is required
with regard to links between the User Guide and recommended
terms.
-- Defining what is out of scope for UB: We decided that the UB should
not be concerned with application profiles or other namespaces
(point #15a-b). Is this articulated somewhere?
-- In point #15c, we suggested that the DCMI registry be responsible
for registering application profiles. What is the action?
-- Usage Board control of RDF/XML schemas in the DCMI registry:
In point #7a we established that nothing should go into the DCMI
namespace until it has been vetted by the UB. Is this
principle recorded somewhere in our documentation? Should it
be in the process document?
-- The Usage Board Web page will provide links to all relevant
documents, which includes
1) Human-readable Web documents such as Recommendations;
2) All machine-understandable (RDF/XML) schemas in the DCMI
registry.
It is not clear to me where this decision is documented. Perhaps
we need to elaborate section 5.3 of the Process document?
-- At some point, we decided that proposals might be submitted
via a standard form on the Web. Who would create such a form?
ACTIONS
-- Harry to use the current namespace strawman as the basis for a rough
draft for a namespace counter-proposal for discussion with Tom and
Andy (see point 1 above)?
-- #22b: Rebecca will shepherd a proposal to add RFC 3066 for
fast-track approval.
-- #14: All DCMI documentation should be consistent in the use of Name
and Label (these terms should switched in DCES 1.1 to bring it into
line with the Qualifier recommendation, and there would need to be
an "errata" note to this effect). Who can do this (perhaps Harry)?
-- #7b: The UB has decided that nothing will go into the DCMI namespace
until it has been vetted by the UB, so someone (not clear who) will
need to "clean house" in the registry directory tree, moving schemas
with unapproved elements into a separate "experimental" area and
reserving the persistent, "official" area for approved terms.
Harry?
-- I would suggest that the drafters of each document be responsible
for getting approval of their document. What should the process be
for doing this via the list? I suggest the following: the drafter
submits 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.
-- Once we have tried such a process, we should add it to the process
document.
-- We are tentatively scheduled to have a one-day (or two half-day)
meetings in Tokyo during October 22-24. I will write a separate note
to the group to set this in motion.
Tom
--------------------------------------------------------------------------
DCMI USAGE BOARD - notes (Beth Marsh)
--------------------------------------------------------------------------
21 - 22 May 2001
In Attendance:
Traugott Koch, member
Andy Powell, member
Stuart Sutton, member
Diane Hillmann, member
Makx Dekkers, ex officio
Tom Baker, chair
Stu Weibel, ex officio
Rebecca Guenther, member
Harry Wagner, web team
Beth Marsh, web team
1. Basic principles and documentation
a. Usage Board -
i. Usage board mailing list - closed subscription; public archive -
return to jiscmail list.
ii. Post proposals to dc-general for public comment
iii. Proposal shepards will be tasked w/ providing a digest of
discussions
iv. DC usage board web page will provide links to relevant documents
1. milestone changed to "under discussion" editor =>
Shepard; proposals endorsed by u.b.
2. members of group
3. mission statement
4. other issues, ongoing discussions
5. meeting agendas and minutes
6. background materials for proposals
7. archive view via meeting; proposal
8. archive past discussions/meeting notes
9. archives should be arranged around each meeting
10. Listing of documents that are under Usage Board control
(ownership)
a. Human readable documents (xref to docs on dcmi
web site)
b. Machine-understandable (RDF/XML) documents
(SCHEMAS)
2. Namespace Document
a. Posted to the DC-Architecture mailing list
b. Public comment is now over
c. Stu has asked Harry Wagner & Dan Brickley to incorporate public
comments into the document and prepare it for final publication
d. Need an "ad hoc" analysis board to review document (external reviewers)
e. Ad hoc committee will make a recommendation to the DCMI Directorate
f. Directorate will have final say - yea or nay
g. V-a - Minor editorial changes will be corrected w/o comment period but
will be posted to Usage board list
h. Web site needs to have a change notice for any changes to
recommendation documents
i. V-c - remove "in the judgment of the DCMI directorate"
j. Usage board has authority to add new elements & qualifiers
k. Usage board should see namespace document before finalized
l. Namespace doc shouldn't reference process or Registry - need to make it
as simple as possible.
m. VI - comments on what to do w/ namespace in the event DCMI is
expanded should be deleted.
3. Mission and scope of Usage Board
a. Mission: Remove references to specific status "recommending,
conforming, obsolete"
b. Publication policy: The Usage Board makes available its proceedings and
decisions in a publicly available space on the DCMI web site.
c. Publication policy: delete second sentence.
d. Process model: The UB process is defined in "Process Document"
e. Process model: Change title from process model to process
f. Scope: deleting second sentence
g. Scope: information resources should be changed to resources
h. Scope: The scope of the UB is the Dublin Core Metadata Element Set,
plus additional vocabulary terms (link to vocabulary terms section)
deemed useful for discovering resources across domains.
i. Grammar: delete "Dublin core statements.revised '2001-06-13'
j. Grammar: last sentence change to: "The grammar is described more fully
in "Grammar Document link".
k. Move dlib grammar doc to UB web site.
l. Can be ambiguous statement Vocabulary Terms in General: Vocabulary
terms in Dublin Core refer to elements, qualifiers or terms in controlled
vocabularies maintained by DCMI. Vocabulary terms are uniquely
defined in namespaces (link Namespace document).
m. Elements: First sentence: An element is a property of a resource.
n. Elements: Delete rest of paragraph
o. Qualifiers: First sentence: Qualifiers modify the properties of Dublin Core
... or relation.
p. Qualifiers statements (rest remains the same)
q. Dumb Down principle: Delete last sentence
r. Dumb Down principle: Change "be able to ignore any qualifier and use
the value as if it were unqualified"
s. Appropriate literals: delete paragraph
t. Appropriate literals: change name to "Appropriate Values"
u. Appropriate Values: Best practice for a particular element or qualifier may
vary by context. Definitions may provide some guidance, other
information may be found in the Users Guide (link to guide).
v. Criteria for Evaluating Element & Qualifier Proposals: change "it" to
"term"
w. Criteria for Evaluating Element & Qualifier Proposals: Delete entire
section and create a new document.
x. Questions for discussion
i. No
ii. Not at all.
iii. ACTION: Need to add "see also" reference from element set
linked to the Usage guide. - From working group: element
definition and further comments; From user guide wg - usage
recommendations - Usage Board is responsible for all 3 areas.
Make usage recommendations a part of element or qualifier
proposal.
iv. No decision - part of the process document
4. MARBI Process
a. Think about DCMI stakeholders; how to bring them into the process
5. Process Proposal
a. General discussion - Diane is keeping notes of changes on her copy.
6. Revisiting the Open Meeting Policy
a. Announcements of meetings will include an invitation to write to the
meeting chair or to Makx for an invitation to attend meeting.
7. Revisiting when URI's should be assigned to namespace proposal
a. Guideline: nothing will go into the DCMI namespace until it's been vetted
by the UB as recommended or conforming.
b. Need to clean up the registry area into experimental area and persistent
"official" area.
8. Guidelines for reviewing and acknowledging vocabulary and encoding scheme
qualifiers
a. For each scheme information
i. Add: Provide information on maintenance agency
ii. Add: Include spot for any additional information on the proposed
scheme
iii. Add: Information on what domains this is used in; how widely
used
iv. Add: Email address and contact person
v. Create web form for scheme submission
b. "Registered" encoding schemes, not recommended or conforming
c. DCMI maintained schemes are still recommended but registered for
tokens
d. Decision process is "fast-track" and different criteria; shepherd will be
assigned for a "group" of schemes (a flock).
e. Registered: just for vocabulary schemes, except for DCMI maintained
vocabularies
f. Recommended or Conforming is valid for encoding schemes
g. Delete "decently sized user base"
h. Token acronyms - if no official token exists but if there's an already
established tokens used in other applications, use it.
i. Tokens must be unique
j. Name of organization does not stand for particular vocabulary
k. Official translations - add "dash" and language code
l. Versions - if version is important, register each version, if it's not, than
only one version should be registered. Leave it up to users to decide
and/or register versions - For web form to registration: need to draft
explanation of versions and when it appropriate to register versions - also
to state that DCMI is just registering and not vetting versions. "If you use
a generic token, then be aware of x, y & z. If you use a versioned token,
then be aware of x, y, and z."
m. ACTION: Traugott will draft explanation for "l"
n. The UB acknowledges scheme by giving them the status of Registered.
Strike the rest of the last point.
9. Education Proposal
a. General comment: Need criteria for evaluating proposals
b. Audience element:
i. Need analysis of how audience has been used by other projects -
proposals should come w/ this information - shepherd could
provide analysis in larger context
ii. Agreement that it is conforming w/ modification to wording
iii. Comment: The category of user may be determined by the creator
or publisher of the resource or by a third party.
iv. Definition: A category of user for whom the resource intended or
useful.
v. Consensus is that it's conformant; UB looking at whether it should
become recommended. ACTION: Stuart Sutton will be the
shepherd to bring it to a recommended element before or by the
Tokyo meeting.
c. Any new element that is assigned a status of "recommended" should be
added to the DC Element Set. Recommended means more than just cross-
domain.
10. Terms revisited: Recommended, Conformant, Non-conformant, Obsolete.
11. Namespaces: A Recommended or Conformant element should go into the element
namespace; a recommended or conformant qualifier should go into the qualifier
namespace; non-conformant elements or qualifiers should find their own
namespace.
a. http://dublincore.org/qualifiers/dcq#
b. http://dublincore.org/elements/dces#
c. Recommendation: one namespace for elements; one for
qualifiers and one per DCMI controlled vocabulary;
furthermore we see no reason for a current DCMI
namespace to contain a version number or a date
stamp at this time.
12. Education: Qualifier: Mediator
a. Definition: A category of user that mediates access to the resource and for
whom the resource is intended and useful.
b. Comment: Delete reference to dc-ed: in the last sentence
c. Spelling: trainor should be trainer
d. Consensus is that it is a conformant qualifier.
13. Proposals #2 & #3
a. Consensus in favor of Proposal #3 (Conforms to)
b. Definition: Strike "education or training" - A reference to an established
standard to which the resource conforms.
c. Comment: This does not assume total conformance with the referenced
standard.
d. Name: conformsTo
e. Label: Conforms To
f. Consensus for conformant qualifier to the relation element.
14. Recommendation: All DCMI documentation should be consistent in the use of the
Name & the Label (changes should be made to DCES 1.1)
15. Education: Proposal #4
a. UB is not concerned w/ application profiles.
b. UB is not concerned w/ other namespaces.
c. Recommendation: UB shouldn't approve application profiles. DC-
Registry should be responsible for registering application profiles.
16. Makx - where to place information about domain specific information on the web
site?
17. Confusion w/ the term "Recommendation" - Need to have one document per
proposal. From web form comes a "proposed recommendation." Change status
terms from Recommended and Conformant to Recommended as Cross-domain x
and Recommended as a Domain-specific x. Changes will be written up and then
reviewed. (Ex. Audience has been recommended as a domain specific element)
18. UB Output: Gets incorporated into the RDF schema; announced on dc-general;
keep element recommendations separate from qualifier recommendations in
documents.
19. Tom - Keep the namespace for the first 15 elements as a core legacy and then add
additional elements as necessary into a new namespace.
20. Suggested namespaces:
a. dublincore.org/elements#
b. dublincore.org/qualifiers#
c. dublincore.org/vocabularies/type/
d. dublincore.org/vocabularies/???/
21. Consensus: URI is a qualifier for the Source element
22. Language Element definition:
a. Consensus: Accept Rebecca's recommendation.
b. Need to add RFC 3066 as an encoding scheme - ACTION: Rebecca will
shepherd the proposal to add RFC 3066 as a fast track proposal.
23. Go thru future work items via email
24. UB meeting will tenetively meet in Tokyo. Plan a full day meeting - or 2 half-
day meetings during the DC-2001 week.
_______________________________________________________________________________
Dr. Thomas Baker [log in to unmask]
GMD Library
Schloss Birlinghoven +49-2241-14-2352
53754 Sankt Augustin, Germany fax +49-2241-14-2619
CRITERIA FOR EVALUATING ELEMENT AND QUALIFIER PROPOSALS
Version: Tue Jun 12 15:22:06 MET DST 2001
1. Can the term be clearly described? Can the semantics of the proposed
element or element qualifier be expressed precisely, unambiguously,
and briefly?
2. Is there a clear requirement for the term in support of resource
discovery in the education domain? Is there a demonstrated need for
the proposed element, element qualifier, or value qualifier?
3. Does the term support interoperability? Does it, to the maximum extent
possible, support interoperability.
4. Is the term practical? How difficult would it be for people creating
metadata to comprehend the semantics of the proposed element or
element qualifier and to apply it reasonably in the description of
resources.
5. Does the term refine an existing element? If the proposed term is
an element, can it reasonably be handled as effectively as an
element or value qualifier for an existing element?
6. Are there alternative ways of implementing the term? Within the
conceptual framework of the Dublin Core Element Set (i.e.,
element/element qualifiers and value/value qualifiers), are there
alternative ways to achieve the ends sought?
7. Are there existing implementations or controlled vocabularies, etc.,
supporting the term? Somewhat akin to number 2 above, are there existing
implementations for which this solution (element or element
qualifier or value qualifier) is needed in support of resource
discovery. In similar fashion, are there existing value qualifiers
(i.e., controlled vocabularies, thesauri, etc.) that support the term.
DCMI USAGE BOARD: MISSION AND PRINCIPLES
Version: Tue Jun 12 11:37:23 MET DST 2001
MISSION
The mission of the DCMI Usage Board is to ensure an orderly evolution
of metadata vocabularies grounded in grammatical principle. The Usage
Board evaluates proposed vocabulary terms (or changes to existing
terms) in light of grammatical principle, semantic clarity, and overlap
with existing terms. To proposals that are accepted it assigns a
specific status. The Usage Committee strives for consensus, justifying
its decisions and interpretations in terms both of principle and of
empirical practice.
PUBLICATION POLICY
The Usage Board makes available its proceedings and decisions in a
publicly available space on the DCMI Web site.
PROCESS
The Usage Board process is described in a separate document [1].
SCOPE
The scope of the Usage Board is the Dublin Core Metadata Element Set
[2], plus additional vocabulary terms deemed useful for discovering
resources across domains.
GRAMMAR
Dublin Core may be seen as a small language for making a particular
class of statements about resources. Like natural languages, it has a
vocabulary of word-like terms, the two classes of which -- elements and
qualifiers -- function within statements like nouns and adjectives; and
it has a syntax for arranging elements and qualifiers into statements
according to a simple pattern. Optional qualifiers may make the
meaning of a property more definite, as in "Resource has dc:date
dcq:revised '2000-06-13'." This grammar is described more fully in
[3].
VOCABULARY TERMS IN GENERAL
Vocabulary terms in Dublin Core refer to elements, qualifiers, or terms
in controlled vocabularies maintained by DCMI. Vocabulary terms are
uniquely defined in namespaces [4].
Strictly speaking, a Dublin Core element or qualifier is a unique
identifier formed by a name (e.g., title) prefixed by the URI of the
namespace in which it is defined, as in
http://purl.org/dc/elements/1.1/title. In this context, a namespace is
a vocabulary that has been formally published, usually on the Web; it
describes elements and qualifiers with natural-language labels,
definitions, and other relevant documentation.
ELEMENTS
An element is a property of a resource.
QUALIFIERS
Qualifiers modify the properties of Dublin Core statements by
specifying, in the manner of natural-language adjectives, "what kind"
of subject, date, or relation. Qualifiers currently fall into two
classes:
-- Element Refinement. An element refinement is a qualifier that makes
the meaning of an element narrower or more specific. A refined
element shares the meaning of the unqualified element, but with a
more restricted scope. A client that does not understand a specific
element refinement term should be able to ignore the qualifier and
treat the metadata value as if it were an unqualified (broader)
element. The definitions of element refinement terms for qualifiers
must be publicly available.
-- Encoding Scheme. Encoding schemes are pointers to contextual
information or parsing rules that aid in the interpretation of
an element value. These schemes include controlled
vocabularies and formal notations or parsing rules. A value
expressed using an encoding scheme will thus be a token
selected from a controlled vocabulary (e.g., a term from a
classification system or set of subject headings) or a string
formatted in accordance with a formal notation (e.g.,
"2000-01-01" as the standard expression of a date). If an
encoding scheme is not understood by a client or agent, the
value may still be useful to a human reader. The definitive
description of an encoding scheme for qualifiers must be
clearly identified and available for public use.
DUMB-DOWN PRINCIPLE
The qualification of Dublin Core properties is guided by a rule known
colloquially as the Dumb-Down Principle. According to this rule, a
client should be able to ignore any qualifier and use the value as if
it were unqualified. While this may result in some loss of specificity,
the remaining element value (minus the qualifier) must continue to be
generally correct and useful for discovery. Qualification is therefore
supposed only to refine, not extend the semantic scope of a property.
APPROPRIATE VALUES
Best practice for a particular element or qualifier may vary by
context. Definitions may provide some guidance; other information may
be found in the User's Guide [5].
REFERENCES
[1] [Process document URL]
[2] http://dublincore.org/documents/dces/
[3] http://dublincore.org/groups/usage/meetings/dublin-20010521/grammar.shtml
[4] [Namespace policy URL, when available]
[5] [User Guide URL]
|
