Global navigation options:	Home	Metadata Basics	DCMI Specifications	Community and Events	Join/Support	About Us

Search:

Overview of May Meeting

Dublin, Ohio

2001-05-21-2001-05-22

(Note: From a Usage Board email message. Archived copy is available at:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0106&L=dc-usage&F=&S=&P=2538 )

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 Thomas.Baker@gmd.de
GMD Library
Schloss Birlinghoven +49-2241-14-2352
53754 Sankt Augustin, Germany fax +49-2241-14-2619