Notes from Megameeting 28th January 2008

Attendees:

BarbaraSierman Koninklijke Bibliotheek, Netherlands
BruceAmbacher UM
CandidaFenton HATII, Univ Glasgow
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: MarkConrad to send a Word version of the proposed template for requirements; SimonLambert to put it on the wiki; all to try using the template to adapt the requirements. More specific division of responsibilities can be assigned next week.

Simon Lambert >> (All): I think there were two main strands of discussion from the last meetings: one was about justification of requirements and the other about significant properties.
Simon Lambert >> (All): Mark sent an example of reqritten reqts using a template including justification for the reqt.
Mark Conrad >> (All): Simon, I believe the discussion was about more than just the justification for the requirements. It was also about making them more concise and moving the material that did not apply to all repositories out of the main text of the requirements.
Simon Lambert >> (All): Yes, that's right
BruceAmbacher >> (All): We currently have 3 parts - requirement, "supporting" text/discussion and evidence.  Mark, which part are you referring to when you say moving the materials?
Mark Conrad >> (All): Bruce, Did you see my examples? I proposed moving information that is currently in the supporting text and evidence section that does not apply to all repositories to a footnote, annex, or separate document.
BruceAmbacher >> (All): I am concerned about adding another place to look for information.  The test audits and the TRAC committee were concerned that  people were not looking beyond the requirement annex.  What would the reaction be to having a "mandatory" or "applicable to all" supporting paragraph and, where applicable,  a non-mandatory or "in some circumstances" paragraph?
Mark Conrad >> (All): I don't care where it is put as long as the applicable to all information is easily read without having to wade through information that may not apply to the repository in question.
Barbara Sierman >> (All): I agree with Bruce that it is best to have it all in one place, but the Premis document can help us there: the relevant info is all in one page most time
Barbara Sierman >> (All): I think we will find a practical solution for it, we now need to think about the remarks and the rationales
Mark Conrad >> (All): The reason for each requirement also needs to be clearly visible. As we discussed on the 14th if people don't understand the rationale for a requirement they are very unlikely to implement it. A number of requirements as currently written do not make the rationale explicit.
JohnGarrett >> (All): I could go either way.  I like Mark's concise version.  I would also add samples of the evidence needed.  On the other hand I think the longer text can help users understand the requirement.
Barbara Sierman >> (All): We could use some more headings to separate the different aspects
Simon Lambert >> (All): Something that struck me about Mark's two examples is that the shortened version is really contained within the heading of the requirement.
Candida Fenton >> (All): If we can, I think it is best to keep all the information on each requirement together. The more concise things are the better. 
Mark Conrad >> (All): Simon, Not in all cases. Several of the requirements list a number of mandatory sub-requirements in the supporting text.
JohnGarrett >> (All): We obviously don't want to do it with footnotes since the footnotes would end up much larger than the text.
RobertDowns >> (All): Subheadings for each requirement should help to organize the information
Mark Conrad >> (All): In terms of the organization of the information why not have two "views" of the document - one with and one without the non-mandatory text?
JohnGarrett >> (All): Clearly identified subsections might work, but it would partially defeat Mark's desire for conciseness.
BruceAmbacher >> (All): Mark, That was the purpose of the annex that contains just the requirement beginning on p.52
Mark Conrad >> (All): As an outside reader of this document, I lose the big picture and the relationships between the various requirements in wading through all of the material that may or may not apply to my repository.
JohnGarrett >> (All): We have have tutorial documents that accompany standards in CCSDS.  This could work, but then they might not get used.
Mark Conrad >> (All): Bruce, Page 52 of wht document?
JohnGarrett >> (All): There is also just the list of the checklist items for a very concise view. 
BruceAmbacher >> (All): The TRAC document as released by CRL.
BruceAmbacher >> (All): The checklist lists each requirement and has spaces to fill in what evidence shows compliance, the auditor's assessment and the results
Mark Conrad >> (All): Bruce, The checklist does not list all of the mandatory sub-requirements in the supporting text. Nor does it provide a rationale for each of the requirements.
HelenTibbo >> (All): Hello. Sorry to be late - new computer with no bookmarks, etc. but it works!! 
HelenTibbo >> (All): We could take the same text and make 2 versions and test with real users to see which one they like better.
BruceAmbacher >> (All): Agreed regarding the rationale.  It was intended to include all auditable requirements.
HelenTibbo >> (All): We could also just make various versions and let people use whichever they find the most clear and useful for they way they think and the information they need.
Barbara Sierman >> (All): Mark would it help if there is a list of requirements with a reference to the detailed info and rationale
BruceAmbacher >> (All): Helen, then we run a risk of critical elements being left out and having multiple flavors of certification.
Mark Conrad >> (All): Barbara, I would think that an outside reader would want all three elements together.
HelenTibbo >> (All): Bruce, well yes, we would have to make sure all the same content was some place in all documents if we did multiple docs but I am not sure we can predict which arrangement would be better for users without some testing of that even if we end up with one "winning" design.
Barbara Sierman >> (All): Yes, that is on the page where all the information is (as I said before, like Premis), but this list helps the outside reader to the relevant places for him
JohnGarrett >> (All): We need to have a single document that will become the standard and will be voted on to be approved as the standard.
Barbara Sierman >> (All): Would not it help if we just start to work on the rationale and then later organize the text according to different views?
Mark Conrad >> (All): Barbara, I misunderstood what you meant by detailed information. I meant that the reader would want to have the requirement, all of the supporting text that applied to all repositories, and the rationale for the requirement in one place.
BruceAmbacher >> (All): Folks, the current version of TRAC has each requiremnent with explanation and evidence, followed by the checklist, followed by annexes to expand on certain points and issues.  What do you want that is different?
Barbara Sierman >> (All): Yes Mark, exactly 
Barbara Sierman >> (All): Bruce, I would like the rationale added 
Mark Conrad >> (All): Bruce, The current version of TRAc contains too much information that does not apply to all repositories and some of the requirements do not have a rationale.
Marie W >> (All): Is the rationale necessary for standardization?
Barbara Sierman >> (All): Can we make a list of different kinds of repositories?
Mark Conrad >> (All): It is if you want people to implement the standard.
RobertDowns >> (All): Adding rationale will reduce ambiguity when interpreting each requirement.
Mark Conrad >> (All): Barbara, we probably could, but what would we use the list for?
JohnGarrett >> (All): The rationale is not required for the standards document, but it is useful and may make the standard easier to use and to "sell" to others that it should be used.
BruceAmbacher >> (All): I would have to see examples.  I am not sure the same rationale will work for the variety of repositories.
Barbara Sierman >> (All): Hi Mark, I understood that you would make a distinction between requirements for different repositories, or did I misunderstand you? 
Mark Conrad >> (All): Bruce, I provided two examples.
JohnGarrett >> (All): I don't think we want to try to make different requirements for different repositories.  I think it will dilute the effectiveness of creating the standard.
Mark Conrad >> (All): Barbara, I would distinquish between text that applies to all repositories and text that applies to only some repositories.
Barbara Sierman >> (All): Ok, so I misunderstood you, sorry
Barbara Sierman >> (All): I heard some speech?!
BruceAmbacher >> (All): Are we moving toward a structural reorganization that puts the checklist (or another requirements only list) first followed by a separate "page" for each requirement with text, rationale, and evidence?
Mark Conrad >> (All): Sorry. I was just using the microphone to make sure Bruce had received the document with the examples.
Barbara Sierman >> (All): Bruce, I think it would be nice to have that as a template and then add the missing info
HelenTibbo >> (All): I rather like what Bruce just proposed. 
HelenTibbo >> (All): We had talked about a template a few weeks ago - it is useful for the writing and for reading.
Mark Conrad >> (All): My examples are based on the template we discussed on the 14th.
HelenTibbo >> (All): I think right now we should agree on the elements, i.e., rationale, etc. are important , moving foreard with the content and then worry about the design of the overall document, perhaps with input from users. Also CRL is "testing" TRAC. Surely this will involve ease of use as well as content and we can benefit from those findings.
BruceAmbacher >> (All): What would be in the standard - just the stripped requirements?  with everything else as nobinding supporting text
Mark Conrad >> (All): Bruce, No. It would include the requirements, all supporting text that applies to all repositories, and the rationale for each requirement.
Barbara Sierman >> (All): I don't know what are the rules with standards?
BruceAmbacher >> (All): John, You have experience sheparding OAIS, what do you think works best?
Mark Conrad >> (All): All information that did not apply to all repositories would be segregated and presented in a footnote, annex, or appendix.
JohnGarrett >> (All): The are no strict rules for what is included in standards, but you need to be able to clearly identify in the standard what you need to do to conform to the standard.
JohnGarrett >> (All): So it is useful to separate the mandatory stuff from just the informational stuff so you can point to the mandatory stuff and say that is what you need to do to meet the standard.
BruceAmbacher >> (All): Mark, Separating such information out land moving it elsewhere eaves some types of repositories wondering if this applies to them.  I favor showing both mandatory and nonmandatory/applicable to some in the same place to achieve greater buy-in.
JohnGarrett >> (All): I think at this point we need to decide what format we are going to use and make it through the entire document and publish it to our communities for comment.  We've been having these megameetings for over a year now and we haven't ever reviewed the whole document.  
BruceAmbacher >> (All): I have to go to a meeting on the hour.  I also will not be able to participate next week.
JohnGarrett >> (All): Yes, I have to go also.  Talk to you again next couple weeks.
HelenTibbo >> (All): I agree with John - we need to focus on the parts we want and the content and get a draft out and get comments. Oh, and I imagine not everyone will agree with us no matter how long we agonize over the format...
HelenTibbo >> (All): Bye Bruce
Mark Conrad >> (All): Bruce, The way the document is written now it is very difficult to see what applioes to the reader's repository. If the mandatory information is listed in one place the reader knows it applies to them. If they are not sure how it applies that read the non-mandatory material to see if that helps them.
Mark Conrad >> (All): I would propose that folks re-read the chat from the January 14th meeting and the examples I provided after that meeting and decide if the proposed format is worth pursuing. John, I think one reason we have not made it all the way through the document is that there is too much non-mandatory text to wade through and we forget what has already been covered in other requirements.
RobertDowns >> (All): It seems that multiple interpretations of each requirement have made it difficult to review each requirement in an efficient manner.
HelenTibbo >> (All): I think if we are strict with ourselves and follow a template it will be easier.
Candida Fenton >> (All): I agree that a template could help move things along.
Marie W >> (All): I have to go, thanks everyone.
Mark Conrad >> (All): We proposed such a template at the meeting on the 14th. Is that template suitable or do we need a different one?
HelenTibbo >> (All): I thought it was fine and expected that we were moving forward with it. Again, when we get comments back we may want to change something but we need to move forward.
Simon Lambert >> (All): I think we should run with the template that was suggested.
Barbara Sierman >> (All): Helen I agree
RobertDowns >> (All): I agree, too
Candida Fenton >> (All): Me too
HelenTibbo >> (All): Would it be helpful to have a standard word document with the template and then each of us be assigned parts to templatize?
Mark Conrad >> (All): There were a few comments posted on the web thety were all positive.
HelenTibbo >> (All): I work best with specific assignments and deadlines...
Simon Lambert >> (All): Helen, that sounds a good approach.  We might want to have a wiki version though.
Barbara Sierman >> (All): Yes I think so, I'm afrais to repeat it again, but in the Premis dict. there are clear blocks of info
Simon Lambert >> (All): Though that would mean another reworking of the TRAC doc on the wiki!
HelenTibbo >> (All): Yes, like PREMIS
Mark Conrad >> (All): I will be glad to prepare the template in Word form. Simon can you turn it into a wiki document?
Simon Lambert >> (All): Yes certainly.
HelenTibbo >> (All): Fabulous! Now, how do we want to break up the work?
HelenTibbo >> (All): I know, assign it all to Bruce now that he has left!
Barbara Sierman >> (All): Sorry I need to go, we made some progress at last I think! (Helen, this is not because I don't want to do some work!)
Simon Lambert >> (All): Perhaps we can let people try it out for themselves this week, and assign responsibilities next time.
Mark Conrad >> (All): Barbara gets all of the difficult requirements! :)
HelenTibbo >> (All): Simon, that sounds like a good plan
Mark Conrad >> (All): I will try to get the template to Simon this afternoon.
HelenTibbo >> (All): I need to sign off! Everyone have a great week.  -Helen
Mark Conrad >> (All): See you next week!
Simon Lambert >> (All): Bye everyone.

-- SimonLambert - 28 Jan 2008

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