Do we have some sort of form to fill out to submit a proposal? That might
be good to standardize this.
Rebecca
On Thu, 21 Jun 2001, Thomas Baker wrote:
> 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.
>
|