Notes from Megameeting 14th January 2008


BarbaraSierman Koninklijke Bibliotheek, Netherlands
DavidGiaretta STFC
HelenTibbo UNC
JohnGarrett NASA/GSFC
MarieWaltz Center for Research Libraries
MarkConrad NARA
RobertDowns Center for International Earth Science Information Network (CIESIN), U Columbia
SimonLambert STFC

All the discussion at this meeting was conducted by chat, so the following transcript of the meeting (with a few typos corrected) is complete.

Actions: All to complete marking of Section B for mandatory requirements; MarkConrad to provide examples of justification of requirements (the "why").

barbara sierman >> (All): hello all
MarieW >> (All): Hello
Helen Tibbo >> (All): Hi!
SimonLambert >> (All): Hello everyone.
SimonLambert >> (All): Earlier I added Section A to the mandatory requirements matrix - for the really enthusiastic!
JohnGarrett >> (All): Hello
Mark Conrad >> (All): I am in the middle of a little experiment. I hoped to have it done before the meeting today. I am producing a version of Section B. with only text that appears to be mandatory across all instances. I will share it with the group once it is complete.
SimonLambert >> (All): Was my summary of last week OK?  Or did we reach more definite conclusions than I indicated in the email?
Mark Conrad >> (All): I think your summary was good, Simon.
MarieW >> (All): I think this was important to discuss: There is a methodological issue about revisions to the text.  If these cause changes to the statement of the items on the "mandatory requirements" pages, then presumably people should have a chance to revise their ratings.  But how to keep track of what has been changed and whether people have looked again at the requirements?
JohnGarrett >> (All): Thanks, Mark.  I'd be interested in seeing what that looks like.  I talked outside our mega-meeting with Don Sawyer last week.  He said they tried something similar when creating the TRAC document.  But the participants then decided more text was need to make it understandable.  So I'm interested in seeing what it looks like.
SimonLambert >> (All): Marie - Yes, that's tricky.  The "correct" thing might be to reset everyone's marks after an edit, but that might get frustrating.
Helen Tibbo >> (All): I left confused last week so I cannnot cite anything more definite
MarieW >> (All): I think resetting might be frustrating, but I agree it is good to know when people change what they vote, particularly if it tips the scales in a different direction, we might want to revisit why someone didn't like a change, etc.
Mark Conrad >> (All): One of the things that I have found so far in my experiment is that for many of the items, the accompanying text does not explain WHY a repository should meet the particular requirement.
Helen Tibbo >> (All): Should we have a template for each entry with categories such as "what must be done," "why," and "what other items this one links to"?
SimonLambert >> (All): It has come up several times that there is a logic to the succession of requirements that is not always apparent.  Maybe the flow needs to be made more explicit.
MarieW >> (All): I agree I like tracing things back and forth, it makes a lot of sense.
barbara sierman >> (All): Mark, do you mean that the text is not explicit enough about the why?
Mark Conrad >> (All): Barbara, yes. In many cases there is no text that explains why a repository should meet the requirement in question.
Mark Conrad >> (All): I personally believe that having an explanantion of WHY a repository should meet a requirement is much more useful to a reader of the standard than examples of  how a particular repository might meet the requirement.
MarieW >> (All): Anything to help understand the requirement is good.
barbara sierman >> (All): Yes, we had that problem here too. You can often debate about a requirement, so it is important to understand what is the idea behind that requirement. I think this is illustrated best with the evidence documents, but I agree, you should first see the need of the requirement
JohnGarrett >> (All): I don't think I agree that the why is more important within a standards document. 
RobertDowns >> (All): Seeing the reason for the requirement should help repositories to put the examples into context and consider additional ways to meet a particular requirement
JohnGarrett >> (All): Often we have a tutorial document that goes along with a standard or annexes that will provide the why, but as a user of a standard I am usually more interested in "How" rather than "Why".
Helen Tibbo >> (All): I would say both the  "why" and the "evdience" are important. There's going to be a good deal of "selling" involved in getting repositories to take the time to go through at this so the "why" is very important. It is also important for those using the standard to build a new repository.
JohnGarrett >> (All): I no longer have the option of debating "Why" once something is a standard.  It is already set and if I want to meet the standard I need to meet it.
Mark Conrad >> (All): As someone who was not involved in the development of the TRAC document (i.e., and outside reader) it is not always abundantly clear why a repository should meet a specific requirement. If I can't understand WHY I will probably not implement the standard.
Helen Tibbo >> (All): Exactly.
MarieW >> (All): But in the audit method the auditor can provide this context.
barbara sierman >> (All): in the preservation area a lot of requirements are still under debate
Helen Tibbo >> (All): There's a long way between now and actual audits. Whys will help people go toward better practice.
Mark Conrad >> (All): The examples could be listed in an annexx or as footnotes,  but having all of the examples in the text of the standard makes it difficult to see the forest for the trees.
barbara sierman >> (All): Mark, did you see special paragraphs that needed more explanation about the why?
JohnGarrett >> (All): I think the examples are going to be much, much shorter than the why would be. 
Mark Conrad >> (All): Most of the requirements do not have adequate supporting text to explain the WHY.
barbara sierman >> (All): Yes, that might be a good idea: to put the examples/evidence in a special paragraph
MarieW >> (All): I like the seperate document/tutorial idea John brought up earlier.
Mark Conrad >> (All): John, In my experiment almost all of the text accompanying the requirement has been examples with very little text about the WHY.
Helen Tibbo >> (All): I think we should devise some standard format, whether it be in the text in marked sections or as appendices, and follow this for each item.
David Giaretta >> (All): ISO 27001 for example has very little explanatory text. We did say that we might need to split the docuemnt into two parts. Perhaps we should collect the text as we go along and then review whether tpo split into two documents, one a standard with rather little text and the second a rather wordy document which has examples and the "why"s
David Giaretta >> (All): ...on that basis Helen's suggestion would allow us to collect text quite nicely.
Mark Conrad >> (All): David, I think the why's need to be in the standard.
Mark Conrad >> (All): I believe Helen's suggestion called for the why's to be included in the standard.
David Giaretta >> (All): Mark, - I guess it depends on the depth of explanation. AT the moment we have a static structure of headings and some introductory text in each section. However it looks as if that is too generic and some brief "why" needs to be addeded for each metric
Mark Conrad >> (All): David, My suggestion would be to REPLACE the EXAMPLES with the WHY's.
David Giaretta >> (All): Mark - Oh - I missed that
JohnGarrett >> (All): I like the idea of having a standard template to follow to follow for each checklist item.  Template could include what is listed with the item and what was in the annex or accompanying document.
Mark Conrad >> (All): I would move the examples to the footnotes, an annex or a separate document.
SimonLambert >> (All): I like the template idea.  We could decide afterwards how much belongs in the standard doc itself and how much in annexes/supplementary docs.
Helen Tibbo >> (All): As long as they are consistently in one place and consistently present I think this would be great.
David Giaretta >> (All): Mark - OK, but I was just thinking that we might initially write a very long "why" for a metric, which we may later feel we should abstract into a second docuemnt (with the examples)
barbara sierman >> (All): I agree with Simon
MarieW >> (All): Me too, let's see what we get
RobertDowns >> (All): If the examples are put in a separate appendix or annex, each requirement should reference that part of the example section 
David Giaretta >> (All): Simon - I agree
Mark Conrad >> (All): David, I would hope that the whys would be concise.
Helen Tibbo >> (All): I don't know if you consider an appendix/annex to be a separate document or not, but we need to have all this tightly linked or people may only look at one part.
Mark Conrad >> (All): Bob, I agree.
MarieW >> (All): Can you do an example of what you're thinking?
barbara sierman >> (All): Could not we use a template similar to the Premis dictionary and have all the info in one page?
barbara sierman >> (All): for the working document I mean
JohnGarrett >> (All): I think the why is very important to understand.  I just haven't seen many standards documents with the why included with each item.
David Giaretta >> (All): As Mark said, we would hope that the whys are concise. That will be a challenge!
RobertDowns >> (All): The rationale could reference the relevant part of the OAIS, if appropriate
Mark Conrad >> (All): For the text accompanying each requirement you could have pairs of sentences beginning with the phrases, "The repository must..." and This is necessary  in order to...".
barbara sierman >> (All): If we agree on this, how could we make a start with it?
David Giaretta >> (All): I recollect from the TRAC development that one could place a metric against several OAIS/TDR aspects.
David Giaretta >> (All): To start we could agree on a template (Helen??) and then split the work up between us.
JohnGarrett >> (All): I would be happy with short sentence or two rationales like in PREMIS data dictionary.  I think that would be valuable.   I guess I misunderstood and that we were talking about much longer explanations of why. 
David Giaretta >> (All): But first - have we all put in our votes about mandatory or not for all the metrics?
barbara sierman >> (All): Sorry, I did not finish the C part
MarieW >> (All): I haven't started the C part.
Mark Conrad >> (All): I have not done parts A or C.
Helen Tibbo >> (All): Oh, neither have I!
Mark Conrad >> (All): Has everyone done Part B? Maybe we could just start there.
RobertDowns >> (All):  I only completed B so far
barbara sierman >> (All): Need to catch the train! Bye
MarieW >> (All): NO, I have a few sections left to complete.
SimonLambert >> (All): Maybe we should allow one more week for Part B as an action on all, and then take it as finished.
MarieW >> (All): That would be very kind.
Helen Tibbo >> (All): This sounds good. Should we do C before A after B?
JohnGarrett >> (All): I need to complete the items.  I've just been working ahead of the discussion, but I could get more done.
Mark Conrad >> (All): OK. I will try to prepare some example requirements from Section B using a template similar to what Helen proposed today.
JohnGarrett >> (All): Thanks Mark.
David Giaretta >> (All): Helen - I have not checked but I would guess that C will be completed before A in terms of mandatory comments.
JohnGarrett >> (All): What is our plan for making progress the next month or two?  Are we trying to get anything done for the CCSDS meeting in Silver Spring in March?
David Giaretta >> (All): John - I think we will have to. At the moment we are on track to have some revisions of the metrics and text,  mandatory (yes/no) and at least some "whys". We will just need to  put that in the appropriate format.
David Giaretta >> (All): It would be useful if we can submit something as a Committee Draft
RobertDowns >> (All): Do we need to propose the committee or create a charter ?
David Giaretta >> (All): Sorry I meant an ISO Committee Draft - this would go into via  CCSDS which is TC20/SC13
Mark Conrad >> (All): So for next week we should have done our mandatory marking for Section B. and I will provide some examples for further discussion? Are those the only action items or are there others?
Mark Conrad >> (All): I just realized something. Next Monday is a Federal Holiday here in the U.S. I will not be here to participate.
Helen Tibbo >> (All): It's a holiday here as well I'll be around. 
Mark Conrad >> (All): I will try to get my examples to David and/or Simon by next Friday at the latest.
David Giaretta >> (All): I may be stuck in a meeting next week. Should those who can do so meet and check progress?
MarieW >> (All): Yes
David Giaretta >> (All): OK - I may see some of you next week. Must go now. Bye
Helen Tibbo >> (All): Yes, if we are going to get something done by the meeting we need to keep our noses to the grindstone!
JohnGarrett >> (All): OK.  Bye till next week or maybe two.
MarieW >> (All): Good bye
Mark Conrad >> (All): Later!
SimonLambert >> (All): Bye everyone.  I will put the transcript on the wiki as usual.
RobertDowns >> (All): Bye
Mark Conrad >> (All): Thanks, Simon!

-- SimonLambert - 14 Jan 2008

Topic revision: r1 - 2008-01-14 - SimonLambert
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback