------------------------------------------------------------------------ Date: Fri, 27 Aug 2004 05:04:54 -0700 From: Stuart Sutton Subject: Proposed revisions to the UB Process Document To: DC-USAGE@JISCMAIL.AC.UK ------------------------------------------------------------------------ All, below please find the URL for the current draft revisions of the UB Process document. The changes to the document are in red. The changes include a raft of revisions stemming from our last two face-to-face meetings as well as minor ongoing edits as we tinker our way to perfection. http://content.nsdl.org/dih1/UB_Process_(sas_dih).htm While we'll itemize below what Diane and I consider major changes, there was one point that came up as we prepared the revised draft that probably needs some discussion. These revisions (as well as some of the previous revisions) involve both substantive changes the renumbering of sections. The gist of Diane and my discussion has to do with problems in other documents that reference the process document without providing the URL to the "version". We think that all UB references to its process document should always include the appropriate version's URL. SECTION 1: Usage Board Membership and Participation There are two major changes to this section. The first is a revision to the potential terms of UB members. The revised text loosens the constraints on terms for both UB members and the chair by making the two-year terms simply renewable. The second change (1.5) adds text to handle participation of liaisons. SECTION 2: Meetings The changes in this section again result from accommodating the addition of liaisons. The changes make clear that DCMI direct financial support of UB members meeting attendance does not include funding for liaisons. SECTION 4: Proposals for Terms The language in section 4.1 has been "softened" through the addition of the phrase "may be" in order to suggest that the sources that follow need not be considered a closed list but that proposals may come from other appropriate sources. Similarly, some of the language in the 4.2.1 Proposal Requirements Table has also been "softened." First we have added the word "suggested" to term definitions since the UB has traditionally taken limited liberties where it has seen fit with the names of terms. We again add text regarding support for a proposal broadening the language to include demonstrated support by "others in the relevant community." There are substantial proposed revisions section 4.5.1.3. Responsibilities [of Shepherds] that we hope reflect the UB discussion about getting UB involvement in the proposal process going as early as possible in the life-cycle of a proposal. In a similar vein, the proposed revisions to section 4.5.2 Pre-Announcement Process we hope reflects our discussions regarding the UB providing as much assistance to proposers as early in the process as possible. This includes the addition of a table with "benchmark dates" ... our attempt to provide some additional structure to the proposal life-cycle. Section 4.5 [UB] Voting has been revised to reflect the Board of Trustees suggestions regarding voting majorities. SECTION 5: Proposals for Registration of Encoding Schemes Minor changes were made here to reflect (we hope) the current state of UB thinking with regard to the registration of encoding schemes. SECTION 6: Proposals for Registration of Application Profiles First, we added language to broaden the potential sources of application profile proposals beyond the DCMI working groups. (Note: There is a formatting problem with sections 6.1.2 and 6.1.3 that needs fixing!). We also included language under 6.2.4 referencing the CEN AP guidelines. Lastly, we added language regarding the time-stamping of APs that have "passed" UB review. Stuart & Diane ------------------------------------------------------------------------ Date: Mon, 30 Aug 2004 20:59:45 +0200 From: Thomas Baker Subject: Re: Proposed revisions to the UB Process Document ------------------------------------------------------------------------ Stuart, Diane, Many thanks for the thorough and careful revision of the Process. I will put this into the evolving agenda along with a brief summary of open questions (I have one or two in addition to the ones you list). May I suggest that references to the process document could be made a bit easier by adding a section, just under the header, listing the full URL references of the various anchors embedded in the text: 1. Usage Board Membership and Participation http://dublincore.org/usage/documents/process/#one 2. Meetings http://dublincore.org/usage/documents/process/#two 3. Categories of Usage Board Decisions http://dublincore.org/usage/documents/process/#three 4. Proposals for Terms http://dublincore.org/usage/documents/process/#four Types of status - http://dublincore.org/usage/documents/process/#recommended - http://dublincore.org/usage/documents/process/#conforming - http://dublincore.org/usage/documents/process/#obsolete - http://dublincore.org/usage/documents/process/#registered 4.3. Guidelines for developing a proposal http://dublincore.org/usage/documents/process/#four.3 4.5. Process for moving proposals http://dublincore.org/usage/documents/process/#moving-proposals 5. Proposals for Registration of Encoding Schemes http://dublincore.org/usage/documents/process/#five 6. Proposals for Registration of Application Profiles http://dublincore.org/usage/documents/process/#six On Fri, Aug 27, 2004 at 05:04:54AM -0700, Stuart Sutton wrote: > providing the URL to the "version". We think that all UB > references to its process document should always include the > appropriate version's URL. If you are suggesting that references to anchors should also cite the specific historical version, then all of the above could be given in the form: http://dublincore.org/usage/documents/2003/02/07/process/#six On Fri, Aug 27, 2004 at 05:04:54AM -0700, Stuart Sutton wrote: > http://content.nsdl.org/dih1/UB_Process_(sas_dih).htm I would like to request that you consider not using "(" and ")" in the URLs. I see from RFC 2396 that these are in fact legal characters for URIs; unfortunately, they break all of the simple tools I use to manage URLs :-( ------------------------------------------------------------------------ Date: Mon, 30 Aug 2004 12:04:11 -0700 From: Stuart Sutton Subject: Re: Proposed revisions to the UB Process Document To: DC-USAGE@JISCMAIL.AC.UK ------------------------------------------------------------------------ Tom, I believe we are saying that references to anchors contain version references. In your example below for referencing section 6, it might be that through other additions and changes, what used to be section 5 in the old version is section 6 in the new or that the substance of the section has changed (we have been know to change out minds :)). It is important that the references in other documents be absolutely clear and that seems to me to mean referencing the document version as well as the section. Stuart P.S. Sorry about the elipses in the URL ... just a way for us to keep our drafts straight. ------------------------------------------------------------------------ Date: Tue, 31 Aug 2004 09:43:03 +0200 From: Thomas Baker To: A mailing list for the Dublin Core Metadata Initiative's Usage Board Subject: Re: Proposed revisions to the UB Process Document ------------------------------------------------------------------------ On Mon, Aug 30, 2004 at 12:04:11PM -0700, Stuart Sutton wrote: > Tom, I believe we are saying that references to anchors contain version > references. In your example below for referencing section 6, it might > be that through other additions and changes, what used to be section 5 > in the old version is section 6 in the new or that the substance of the > section has changed (we have been know to change out minds :)). It is > important that the references in other documents be absolutely clear and > that seems to me to mean referencing the document version as well as the > section. Stuart, The issue here is that URLs with anchors to specific points in the document are being used for the purposes of citation. Currently, those anchors semantically reflect the section number, which can change between versions. For example: http://dublincore.org/usage/documents/process/#one http://dublincore.org/usage/documents/process/#two ... I understand you to be suggesting that we a) keep the anchors as is, but b) encourage people to cite the specific version (I am assuming that when you say "reference the document version" you actually mean "use the URL/URI of the specific historical version): http://dublincore.org/usage/documents/2003/10/03/process/#one ...because the content of what in October 2003 was "section one" may change from one historical version to the next. A few of the anchors, on the other hand, cite a specific section using a non-numbered handle, e.g.: http://dublincore.org/usage/documents/process/#recommended http://dublincore.org/usage/documents/process/#conforming I suggest we do the following: -- Clarify which points of the document need anchors (e.g., the ones already anchored), then: -- Decide whether we prefer the section-number naming style or the handle style (or a mix, as now), then: -- Decide whether we want to encourage people to cite the generic "latest version" or a specific "historical" version. When we have decided the above, then we should slightly expand the section at the start of the paper -- the half-page section currently called "Index" -- to include two things: -- Three or four sentences about citation style -- A list in clear text of the full URL for each citable anchor. ------------------------------------------------------------------------ Date: Wed, 1 Sep 2004 09:02:37 +0200 From: Thomas Baker To: DCMI Usage Board Subject: Changes to UB Process document ------------------------------------------------------------------------ Dear all, > http://content.nsdl.org/dih1/UB_Process_(sas_dih).htm What follows below is some comment, section by section, on the revised Process document (above). The executive summary: -- Suggest putting full URLs of document anchors into the section Index -- Suggest replacing Sections 1 and 2.1 with pointers and quotes from http://dublincore.org/about/bylaws/ -- Suggest some minor tweaks to wording in Section 4.5 -- Suggest re-structuring Section 4.5 as a chronological account of milestones leading up to a UB meeting summarizing, under each milestone, who is supposed to be doing what. This would arguably be easier for proposers to understand. -- Suggest that if Section 4.5 were restructured, table 4.5.2.10 might even be deleted. -- Point out several items from the Bath notes that may not yet be reflected in the revision. I note that Diane is still working on Section 5. If possible, it would be nice to clear up alot of these issues before Shanghai so that we can spend less face time on them at the meeting. Clearing these up would close out two of the topics pending from Bath. According to http://www.bi.fhg.de/People/Thomas.Baker/ISSUES/: > BATH TOPIC 15: Usage Board issues (Tom) > Agenda item: http://dublincore.org/usage/meetings/2004/03/ISSUES/usageboard/ > and related topic: > BATH TOPIC 9: Review of Application Profiles (Tom) > Agenda item: http://dublincore.org/usage/meetings/2004/03/ISSUES/docs-naming/ > Current: http://www.bi.fhg.de/People/Thomas.Baker/ISSUES/profiles/ > > ACTION (Stuart, Diane): Change process document to > reflect that approval refers to an archived ("time > stamped") version. > > ACTION (Diane, Stuart, Tom): To modify process > document with regard to comment period. (This was > originally in Topic 15.) > > ACTION (Diane, Stuart, Tom): To modify process document > to try to preclude WG expenditure of time and effort on > term proposals destined to meet with negative UB response: > > -- UB members may (or should) participate as > regular DCMI participants in WG and public discussion > period discussions of proposals, though without > "representing" the UB. > -- Shepherd assigned when "intent to submit" is announced. > -- One month before proposal deadline, draft distributed > and conference call held. > -- Proposals must be submitted 6 weeks before meeting. > -- Directorate/UB Chair have one week to post. > -- Four-week comment period starts. > -- At start of comment period, UB shepherd requests > feedback on DC-Usage list in order to flag major issues. > -- Relevant discussion cc'd to group chair/proposer. > -- Proposer could be made guest member of Usage Board list. > -- One week before meeting, comment period closes. > -- Shepherd brings to the UB meeting a written account of > discussion during the comment period. Looking at http://content.nsdl.org/dih1/UB_Process_(sas_dih).htm section by section: ------------------------------------------------------------------------ SECTION "Index" ------------------------------------------------------------------------ In two previous postings [1,2] I have suggested adding to this section full URLs of any "anchors" to specific sections of the Process document along with two sentences about best practice for their use in citation. [1] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0408&L=dc-usage&T=0&O=A&P=744 [2] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0408&L=dc-usage&T=0&O=A&P=1135 ------------------------------------------------------------------------ 1. Usage Board Membership and Participation ------------------------------------------------------------------------ This entire section (except for 1.6) is now covered almost verbatim, with few small differences, in http://dublincore.org/about/bylaws, Article II, Section D, "Selection and Appointment Process" and "Terms". The only things missing are wording about liaisons being encouraged to participate and that liaisons do not serve as shepherds. I would suggest we replace all of Section 1 with a pointer to the above, perhaps quoting the full text from the Bylaws with the disclaimer that the "most recent version" of the Bylaws will always be definitive. ------------------------------------------------------------------------ 2.1. Scheduling ------------------------------------------------------------------------ This section - along with 1.6 - is now covered by the Bylaws, Article II, Section D, "Communication and Documentation". The only difference is that the Bylaws are a bit vaguer about the requirement to hold two meetings per year. I would suggest doing the same for this section as for Section 1. ------------------------------------------------------------------------ 2.3.2. About archiving meeting materials ------------------------------------------------------------------------ I will write a half-page discussion paper about this issue for discussion in Shanghai. Basically, I am trying to streamline the work-flow and want to confirm that the PDF meeting packet could be sufficient as an archival record of those materials for the purposes of preservation (as opposed to making local copies of everything, then editing all of the URLs to point them, as I did for http://dublincore.org/usage/meetings/2004/03/ISSUES/). No suggestion for change now - it will be on the agenda in Shanghai. ------------------------------------------------------------------------ Point 4.5.1.3.2 ------------------------------------------------------------------------ This point still says that a shepherd should summarize comment-period discussion "either verbally or in writing", but the notes from Bath (above) show a stronger wording: > -- Shepherd brings to the UB meeting a written account of > discussion during the comment period. I suggest we tighten this ("written" could be just one paragraph, but at least we then have something for the records). ------------------------------------------------------------------------ Point 4.5.1.3.4 ------------------------------------------------------------------------ What is "registration information" - it is not defined anywhere (this is perhaps related to Diane's ongoing revision of Section 5?). Suggest we re-think this point... ------------------------------------------------------------------------ Point 4.5.2.3 ------------------------------------------------------------------------ I only vaguely recall discussing a _requirement_ that the UB Chair schedule a conference call for each proposal -- that is a significant requirement, and I wonder why email cannot suffice, at least in some cases. Also, I do not see that point captured in the Bath notes above. I suggest softening the language to a suggestion ("might consider" ... "in cases where"... or whatever). ------------------------------------------------------------------------ Point 4.5.2.6 ------------------------------------------------------------------------ The Bath notes (above) say: > -- Directorate/UB Chair have one week to post. But this point says: "A period of two weeks will be allowed...". More generally, I'm wondering if the presentation of the process in 4.5.2 could not be simplified a bit. For example, could one replace _all_ of the points under 4.5.2 (the table 4.5.2.10 included) with a chronological structure -- e.g., a simple sequence summarizing who needs to do what at each milestone, working back from the UB meeting -- e.g., at two months before the meeting, at six weeks, at one week, etc.? That would perhaps be easier for outsiders to digest and follow. ------------------------------------------------------------------------ Point 4.5.2.8 ------------------------------------------------------------------------ Suggest: s/Throught out/Throughout/ s/listserv/mailing-list/ ------------------------------------------------------------------------ Point 4.5.2.10 ------------------------------------------------------------------------ The table does not print out with borders, making it a bit hard to read. Also, I'm wondering if the column "Minimum Task Duration" is necessary -- I find it a bit confusing. ------------------------------------------------------------------------ Other points from Bath ------------------------------------------------------------------------ I wasn't sure whether these points are included somewhere: > -- At start of comment period, UB shepherd requests > feedback on DC-Usage list in order to flag major issues. > -- Relevant discussion cc'd to group chair/proposer. > -- Proposer could be made guest member of Usage Board list.