Notes from Megameeting 11th February 2008

Attendees:

BarbaraSierman Koninklijke Bibliotheek, Netherlands
BruceAmbacher UM
CandidaFenton HATII, Univ Glasgow
HelenTibbo UNC
JohnGarrett NASA/GSFC
KatiaThomaz INPE, Brazil
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.

Simon Lambert >> (All): I'm just looking at the templates filled in ...
RobertDowns >> (All): Hi
BruceAmbacher >> (All): Simon, just to be clear that is "re-expression of Requirements'?  If so, what section are we discussing today?
Simon Lambert >> (All): Bruce - that's right.  It seems that A1.1 to A2.2, B1.*, B3.*, most of B4.*, B6.* are done.
Simon Lambert >> (All): Maybe we could focus on the difficult cases.  Mark identified B4.2 for example as unclear.
MarkConrad >> (All): B.4.2, definitely! I also had questions about several others in B3. and B4. as to whether or not I had captured the original intent for the "why".
Marie Waltz >> (All): I thought b6.9 might be redundant
Helen Tibbo >> (All): I worked on mine without looking at others and found I was unclear as to how much we should be adding vs. just moving the TRAC text around.
MarkConrad >> (All): Those of you that were involved in the development of TRAC, can you tell me what the intent of B.4.2. was?
Simon Lambert >> (All): Helen - I think the idea was to keep additions to a minimum, but to look out for insufficiencies in the TRAC text, especially in motivation for reqts.
candida fenton >> (All): Simon, I thought I had completed B5
Simon Lambert >> (All): Candida - yes, I see that is done - I accidentally missed it from my list above.
Helen Tibbo >> (All): Simon, good. I think I did that but it felt like I wasn't doing enough...
Simon Lambert >> (All): I think only B2.* is missing but I'm sure David is working on it :-)
BruceAmbacher >> (All): Mark, the memory fades these days but I think we were focusing on both current and future preservation actions as demonstrated in both current preservation actions and the use of preservation planning/technology watch to plan for future preservation actions that require a different approach/different technology than currently employed.  Can the repository demonstrate both its current actions and its awareness of future requirements.
MarkConrad >> (All): Bruce, Isn't that covered in B.3.3?
BruceAmbacher >> (All): To the extent that I remember correctly, it may be possible to expand B4.1 to fully address the first part and reshape B4.2?  Relation to B3.3 may be the difference between planning (B3.3) and actual demonstration of actions (B4.2)
MarkConrad >> (All): B.3.3. specifically mentions "demonstrate" how it reacts to information from monitoring.
JohnGarrett >> (All): I think that in the old version each subsection covered a OAIS subsection, so B3.3 was addressing things to do under Preservation Planning and B4.2 would be addressing actions under Archival Storage.
JohnGarrett >> (All): So section B3 would be focused on the planning and B4 on the implementation and record keeping when actions were taken
BruceAmbacher >> (All): That is the way B3 Preservation Planning and B4 Archival Storage & Preservation/maintenance are labeled.
BruceAmbacher >> (All): We want to demonstrate both that the repository is looking at possible future technology impacts and that it has plans and capability to introduce new echnology as needed.  Whether two sections are required can be debated.
MarkConrad >> (All): I am still confused as to the intent of B.4.2. B.4.1 says that Repository employs documented preservation strategies. The supporting text for B.4.2. says at least two aspects of the strategy must be acted upon. Isn't the repository to employ (i.e. implement) the entire preservation strategy?
BarbaraSierman >> (All): Is a preservation strategy only an action you do with objects in the archive, or is emulation on the moment the consumer requests a AIP also a preservation strategy?
BruceAmbacher >> (All): Would this work better if B4.2, 3, 4 and 5 were subsections of B4.1?  That is what actually happens - the broad strategy is laid out in B4.1, then each subpart is developed in 2 through 5.
BruceAmbacher >> (All): I would say that action on an access request is not preservation.  It may entail the same strategies or it may not and the repository may not employ access actions in their preservation strategy due to transformations of the AIP that are not acceptable for a stored AIP.
MarkConrad >> (All): That might make more sense in terms of organization, but I still am not sure I understand what B.4.2. is requiring a repository to do.
BarbaraSierman >> (All): Bruce, but emulation in itself might be seen as a preservation strategy, as might migration on the fly.
BruceAmbacher >> (All): Barbara, Agreed but, based on OAIS, the AIP and the DIP can be very different in their contents and in what the consumer wants to do with the DIP may shape how the repository presents it to the consumer.
KatiaThomaz >> (All): yes. we shouldn´t indicate strategies....
MarkConrad >> (All): Barbara, Emulation might be seen as a preservation strategy in some instances, but using emulation to meet a users request for a particular record is a dissemination strategy.
RobertDowns >> (All): Is the intent of B4.2 to identify and mitigate risks that coud affect objects in the repository?
JohnGarrett >> (All): I think one thing B4.2 is requiring is that the Archives maintain the archival packages in archival storage is the manner they said they would.  Another is that the archive have a technology watch to ensure that they can continue to access and use that information.  We may need to separate some of what it was looking for.
MarkConrad >> (All): John, Is the technology watch covered by B.3.2 and B.3.3?
BarbaraSierman >> (All): Mark, agreed, Bruce agreed in the aspect of the DIP. I only want to draw attenttion to the fact that not all preservation strategies are action IN the archive, like with migration
MarkConrad >> (All): Barbara, I am not sure what you mean by IN the repository.
BruceAmbacher >> (All): Does anyone see and negatives to eliminating B4.2?  Implementation of B4.1 is covered in B4.3 (current preservation), B4.4 (technology watch) and B4.5 (transparency through records).
MarkConrad >> (All): I would certainly vote for eliminating B. 4.2
Helen Tibbo >> (All): I would agree to eliminate B4.2
KatiaThomaz >> (All): ok for me.
RobertDowns >> (All): Me too
BarbaraSierman >> (All): Mark I mean that you take an object from the archive, migrate it to a newer version/object. With emulation you leave the object untouched. 
BarbaraSierman >> (All): And I agree with elimination of B4.2
BruceAmbacher >> (All): Is there anything in B4.2 that is not conveyed in B4.1, 3, 4 and 5?
MarkConrad >> (All): Barbara, With emulation for dissemination you would still make a copy of the AIP and use emulation on the copy.
JohnGarrett >> (All): I think B4.2 is partially covered in 3.2 and B3.3.  Again in B3 the question is whether mechanism are set up and B4 is a question of actually implementing them I think.
BruceAmbacher >> (All): B3.2 also addresses Representation Information and B3.3 represents technology watch/preservation planning.
Helen Tibbo >> (All): I think there is a difference between technology watching, setting up mechanisms/plans, etc. and actually carrying out the mechanisms and plans. I think we need to cover all these aspects as a repository may accomplish some of these without actual implementation.
MarkConrad >> (All): John, Several of the B.3 requirements talk about the "demonstrating" the plans. How do you demonstrate plans in action without implementing them?
BruceAmbacher >> (All): Agreed.  That is in B3.4 and in part of B4.2
Marie Waltz >> (All): B3 only covers the preservation plan, not the specific requirements fro the AIP, if we don't specifically say we want to know about the storage and migration architecture, then will the repository provide them?
BruceAmbacher >> (All): Mark, Isn't the "proof" in the establishment of the function and periodic reports from the function?
Helen Tibbo >> (All): You can demonstrate a plan by having drawn it up; demonstrating a plan in action is something else and indicates implementation.
MarkConrad >> (All): Bruce, Yes. Wouldn't that be what you would demonstrate in the B.3. requirements?
BruceAmbacher >> (All): Marie, Does B4.5 cover it from your perspective?
BarbaraSierman >> (All): sorry need to go
JohnGarrett >> (All): For example, I think it happens all the time that plans are made to migrate something, but that the migration doesn't actually happen.  
BruceAmbacher >> (All): Mark, yes but it is a function required in B4.2, 2nd paragraph.
MarkConrad >> (All): The fact that we are having this much trouble deciding what is and isn't covered by these requirements does not bode well for folks trying to implement the standard.
KatiaThomaz >> (All): The repository must show it plans, it does, it controls and it acts
Helen Tibbo >> (All): There seems to be a need of evidence for a plan; evidence for monitoring and updating the plan as necessary; and evidence of implementing the plan and any subsequent changes to the plan.
BruceAmbacher >> (All): I think the clarity is in the section headings.  The blurring came in B4.2 by going back to a planning function already covered in B3.
Helen Tibbo >> (All): We need all these elements as the repository may plan years in advance of implementing.
Marie Waltz >> (All): Bruce, from an evidence point of view B4.5 almost covers it but the "demonstration of objects on which a preservation strategy has been performed" is important too. 
MarkConrad >> (All): B3.3 and B 3.4 seem to blur the line bbetween planning and implementation .
JohnGarrett >> (All): A question I have is about how this standard will be used.  In general will a single person be completing the audit for the whole archive?  Or is it more likely that each section will be given to different people to complete?  If it is the latter, then I don't mind the overlap as much.  It will mean that each function wil look at their function and make sure what is needed is getting done from their perspective.
Helen Tibbo >> (All): Mark,
BruceAmbacher >> (All): Marie, the "evidence for B4.5  covers that - written documentation of decisions and/or action taken
Helen Tibbo >> (All): Mark, we changed the wording in the title of that one from planning to activities but I think this is a mistake. B.3 is all about planning, not implementing activities
MarkConrad >> (All): John, Presumably one person will read the entire standard to decide whether or not to implement it. I believe that person will be very confused by the overlap.
BruceAmbacher >> (All): Helen, the new requirements template still calls it Preservation Planning.
RobertDowns >> (All): However, if there is redundancy, we need to be specific within each redundant requirement to avoid confusion and misinterpretation.
MarkConrad >> (All): Bob, Agreed.
Marie Waltz >> (All): Bruce it doesn't cover examining an actual AIP. You can have the logs you want but without a look at an actual AIP you might miss something.
MarkConrad >> (All): Marie, See B4.4
BruceAmbacher >> (All): Wouldn't logs be part of written documentation of actions taken?
BruceAmbacher >> (All): Has anyone looked at Annex 5 - Preservation Planning and Strategies?  It may be useful to cross reference it in B4.
MarkConrad >> (All): Bruce, I raised the question of Appendix 5 as a comment in B.3.1.
JohnGarrett >> (All): OK, I didn't think most people would be bothered by the overlap.  Based on our experience of trying to use TRAC document with our basically domain area archives.  Their questions were more just what do I need to show that I met this checklist item.  
MarkConrad >> (All): Appendix 5 lists many sub-requirements that are not made explicit in the main document. Should these be included?
MarkConrad >> (All): If so, they probably belong under B.3.
MarkConrad >> (All): and B.4 Appendix 5 goes back and forth between planning and implementation.
BruceAmbacher >> (All): Yes, and gets to some of the documentation questions that have been raised.  It does further demonstrate there is a fuzzy line between planning and implementation
Marie Waltz >> (All): Sorry still stuck on the B4.2=B4.4, B4.5 thing. I think we need to state we want a look at an actual AIP after migration, tests and logs and all are great but seeing an actual AIP after it has been migrated needs to be a requirement. 
MarkConrad >> (All): Bruce this raises the question of whether or not we should be trying to make the distinction between planning and implementation.
JohnGarrett >> (All): And there are questions of different levels of implementation when you are discussing planning.  If you have a requirement that you do planning, you need to actually do and prove that you did the planning.  And then you also have to do and prove that you followed the plan.
MarkConrad >> (All): Marie, See. B.4.3.
BruceAmbacher >> (All): I think keeping an eye on the "future" as it relates to what you are doing is very important.  We do not want to be led down a box canyon with no path out.
Marie Waltz >> (All): So B4.2=B4.3-B4.5.
MarkConrad >> (All): John, The planning is also an ongoing (recursive) activity reacting to technology changes.
BruceAmbacher >> (All): I must sign off.til next week.
Helen Tibbo >> (All): Well, the proof is in the pudding as they say so in the end I guess implementation is all that counts, but without good planning it is doubtful there will be good implementation. Also, some repositories will only have planned at the time of audit and this needs to be examined separately from what they might do for implementaiton.
KatiaThomaz >> (All): what about rethinking the document structure? are OAIS functions ok? will they help the work of the auditor?
RobertDowns >> (All): I have to sign off now, too. Bye
Marie Waltz >> (All): I agree with Helen, written planning is often the last thing to be addressed.
Helen Tibbo >> (All): I think there is another dimension on top of the OAIS functions - technology, etc. watching; planning; doing; evaluating.
Helen Tibbo >> (All): And, to make it a bit more compliated, these actions are iterative.
MarkConrad >> (All): I think we need to be explicit about what each requirement covers and have good explanations of all overlap across requirements.
candida fenton >> (All): I have to go now - bye
JohnGarrett >> (All): I think the document was supposed to be a certification that an organization was conforming to OAIS defiinition of an archive.  So I think following OAIS is essential.
MarkConrad >> (All): John, I agree.
Marie Waltz >> (All): Do we want to eliminate overlap, like John mentioned earlier, if the sections can be used stand alone it might be useful. The OAIS is essential.
Helen Tibbo >> (All): Yes, I think OAIS functions are the foundation for all the planning, doing, and evaluating
MarkConrad >> (All): I also think we need to make the requirements as easy to understand as possible for folks that weren't involved in developing the OAIS.
Helen Tibbo >> (All): I need to run. I will continue on with section A for next week.
JohnGarrett >> (All): OK,  Thanks.  Good discussions today, but I think we need some kind of strategy for how to make progress and get a document published.
Marie Waltz >> (All): I totally agree with this. 
KatiaThomaz >> (All): of course. but a new structture can serve this too. you can see the document as a matrix OAIS x PDCA, for example...
MarkConrad >> (All): John, Agreed.
Marie Waltz >> (All): Maybe we can do strategy talk in the next meeting?
Marie Waltz >> (All): I have to go, good-bye
KatiaThomaz >> (All): bye and have a good week.
MarkConrad >> (All): I will not be here next week. It is a Federal holiday her in the U.S.
MarkConrad >> (All): here
JohnGarrett >> (All): OK,bye.  Actually next week is US holiday.  Don't know which people will show then.
MarkConrad >> (All): Bye for now.
Simon Lambert >> (All): Bye everyone

-- SimonLambert - 11 Feb 2008

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2008-02-13 - KatiaThomaz
 
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