On Thu, 21 Jun 2001, Marsh,Beth wrote:
> However, I don't think I'm the one to track what documents are required and
> when they are due, so I would prefer that task be w/ you or someone else.
Of course. I had pictured there would be a Web page of meeting
deliverables and, for starters, it would have slots for the files
described in points 1 through 10 below. Everyone would then send their
latest draft into Beth, who would post it (or update it) at the
corresponding slot. It looks to me like we have:
Near-finished: 2, 3, 7 (Tom), 6 (Diane), 8 (Stuart)
Expected: Update to 1 (Harry and Andy), 4 (Traugott), 9 (Rebecca)
After everything there is done, Beth would combine 8 and 9 into 10,
using DCMI house-style templates.
Is this a good way to proceed?
I wish we had some good way to track those "loose ends" and "actions"
identified below -- anyone have a suggestion?
Tom
On 12 June, Tom wrote:
>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.
|
