Notes from Megameeting 21st July 2008


Progress made:

Mark Conrad >> (All): Bruce,
Mark Conrad >> (All): I can't hear you.
Marie >> (All): hi all
RobertDowns >> (All): Hi Bruce and Mark
RobertDowns >> (All): and Marie
BruceAmbacher >> (All): Good day
Mark Conrad >> (All): Hello everyone
RobertDowns >> (All): Does anyone recall where we left off Mark Conrad >> (All): It looks like with 4.2. Is that right?
BruceAmbacher >> (All): I believe it is
Mark Conrad >> (All): Does the currrent markup of the document on the wiki reflect what took place on July 7?
KatiaThomaz >> (All): hi folks
Mark Conrad >> (All): Hello, Katia and Ricc BruceAmbacher >> (All): There were no markups/refreshment of the document during the meeting Riccardo Ferrante >> (All): I don't hear voices, but do I get the sound when text is submitted.
BruceAmbacher >> (All): Should we start with B4.3 and go back to B4.2 after it is marked up?
RobertDowns >> (All): It looks like changes were made after the meeting to B4.1 Mark Conrad >> (All): Are those changes complete? 
KatiaThomaz >> (All): i cant t see the wiki...
Mark Conrad >> (All): I think we need to take stock of where we are.
KatiaThomaz >> (All): do i need to install something?
Marie >> (All):  Katia, I can get in, here's a link to the last minutes, can you get in there?
Mark Conrad >> (All): Katia, I don't think you do need to install anything.
Mark Conrad >> (All): There were some issues with security when the folks at cclrc were working on the wiki.
RobertDowns >> (All): The changes to B4.1Supporting Text look complete, but it looks like there is nothing under Discussion, which also might reflect the meeting.
Mark Conrad >> (All): There were a number of action items from the June
30 meeting     *  DavidGiaretta : in B3.4 stop first sentence of
supporting text after "of its holdings" and then add text to discussion
to suggest some ways this may be done    * MarkConrad - revise
supporting text for B4.1 for 2 weeks time    * David - Review text to
check usage of policies/plans etc and suggest changes (unless there are too many!). Hierarchy should be Preservation Policies -> Preservation
Strategic Plans -> Preservation Implementation Plans    * David - In
B4.1 delete "- and allow them to validate - " and append "and allow them
to verify this"    * ALL - complete outstanding actions Outstanding
Action Items from previous meetings:    * All          o Read the
circulated B2. Rewritev2.doc document to ensure it accurately reflects
the discussion of 16 June 2008.          o Determine if the text in
Rewritev2.doc document should replace the text on the wiki in the
current working document.          o Reread the current working document
on the wiki at the 30,000 foot level.          o Consider whether other
sections of the document on the wiki should be rewritten in the style of
B2. Rewritev2.doc.          o Post comments for B.3.4 and all of B.4.   
 * Bruce Ambacher and MarkConrad          o Do a conceptual walk-through
of an AIP creation to see if B.2 contains all of the mandatory
requirements for AIP creation.     * David          o complete the
analysis of B.3. vs Appendix
Bruce Ambacher >> (All): If those changes are not made during the webchat who is responsible for doing that after the webchat?  It appears that was not done.
Bruce Ambacher >> (All): I was kicked out and I see voice capacity was terminated, then restored.
Bruce Ambacher >> (All): yes
Riccardo Ferrante >> (All): I can now
Marie >> (All): yes I
KatiaThomaz >> (All): yes
RobertDowns >> (All): I hear you Mark, but I do not have a microphone today.
Mark Conrad >> (All): Bruce, In answer to your question, normally whoever "chairs" the web meeting makes the changes to the wiki after the meeting.
Bruce Ambacher >> (All): I don't think we had a "formal" chair two weeks ago.  I suggest we move to a new item until the status of past changes can be sorted out.  I hate to waste this time.
RobertDowns >> (All): Good idea, Mark!
Riccardo Ferrante >> (All): if no, then how do we move forward?
Riccardo Ferrante >> (All): ok
KatiaThomaz >> (All): ok
Marie >> (All): OK
Bruce Ambacher >> (All): 4.3?
Mark Conrad >> (All): So is B.4.3. the next item ?
Marie >> (All): Yes
Mark Conrad >> (All): Ok.
Bruce Ambacher >> (All): If it is consistent with what we have done so fat, I accept.
KatiaThomaz >> (All): agreed
RobertDowns >> (All): I agree
Marie >> (All): I agree with that too
Riccardo Ferrante >> (All): agreed
RobertDowns >> (All): My guess is that he chain might refer to the "chain of custody"
Bruce Ambacher >> (All): I interpret this as wondering whether the relationships of SIP (one or more) must be maintained when AIP (one or
more) is created from all or part.
Riccardo Ferrante >> (All): Seems that he is looking for an explicit statement that content information is carried through as AIPs are "recut" when obsolescence requires another format migration.
Mark Conrad >> (All): Can someone explain to me what the text of the Examples section that John is commenting on means? I do not understand the text.
Mark Conrad >> (All): What is meant by a "chain of AIPS?
KatiaThomaz >> (All): all AIP versions?
RobertDowns >> (All): It looks like this is the sequence of conversions.
Mark Conrad >> (All): Katia, If that is what it means, I think the text should be revised to say that.
Bruce Ambacher >> (All): first part is whether repository has a disposal policy.  second is whether it documents what happens when multiple AIPs are joined into a new AIP or AIC KatiaThomaz >> (All): i don t like the word "chain" either...
RobertDowns >> (All): Yes. "chain" is confusing Mark Conrad >> (All): Bruce, How do you get the business about AICs?
They are not mentioned anywhere here.
Bruce Ambacher >> (All): Original TRAC mentions transformations here - that covers migrations and the creation of a new AIP from one or more SIP or AIP RobertDowns >> (All): Perhaps "chainof AIPs" should be changed to "sequence of conversions for an AIP"
Bruce Ambacher >> (All): I got AIC from OAIS.  I consider it one way to demonstrate that "chain" when you take 12 monthly files and create an annual file either by stacking the 12 or creating a summary file showing only the annual totals.
KatiaThomaz >> (All): only digital preservation conversions KatiaThomaz >> (All): first of all the repository must preserve the original AIP Bruce Ambacher >> (All): Possibly not if destruction is within their policy,  We should look at the discussion below John's comment Mark Conrad >> (All): The original TRAC document is contradictory on whether or not the original AIP must be preserved.
Marie >> (All): Yeah Mark's right, so what is the best course for preserving the content? 
RobertDowns >> (All): I could see cases where it could be prohibitive to keep the oriiginal, such as when it is contaminated or corrupted, to name the obvious ones.
Mark Conrad >> (All): I think B.4.3. should be explicit. Either you have to preserve the original AIP or you don't. If you don't what evidence to you have to keep that the current AIP accurately reflects the Content Information of the original AIP?
RobertDowns >> (All): A record of a review or a decision should be sufficient Mark Conrad >> (All): Robert, If the AIP is contaminated or corrupted the repository has bigger problems. Contamination should have been caught at the time the SIP was transformed to an AIP.
Bruce Ambacher >> (All): Both versions require the repository to state whether deletion is part of its policy.  If it is then a trail documents the changes and why, as Robert suggests.
Riccardo Ferrante >> (All): change "whether" to "under what conditions."
This also the repository to establish a policy that says never or something different. In response to the past couple of posts - all preservation actions conducted on the SIP and its AIPs must be maintained throughout the life of that record.
Riccardo Ferrante >> (All): also should be allows Bruce Ambacher >> (All): This section is only dealing with archival storage and how it is documented, hence the focus on AIP, chain of AIPs RobertDowns >> (All): I agree that contamination or corruption are bigger problems, but even if the repository has to migrate all its AIPs to resolve the problem, it should allowed to do so.
RobertDowns >> (All): it should be allowed to do so Bruce Ambacher >> (All): I still think the "Discussion" text  explains the intent.
Mark Conrad >> (All): Ok. Does someone have a suggestion for a revision to the text of the Examples section?
KatiaThomaz >> (All): robert, we have another requirements to do with this problem RobertDowns >> (All): Do we need to refer to these other requirements?
Bruce Ambacher >> (All): documentation of the persistent links between the ingested object and the current AIP Mark Conrad >> (All): Policy documents specifying treatment of AIPs and under what circumstances they may ever be deleted; ability to demonstrate the sequence of conversions for an AIP for any particular digital object or group of objects ingested; workflow procedure documentation; documentation of the persistent links between the ingested object and the current AIP.
Bruce Ambacher >> (All): ok
Marie >> (All): Yes that's it
RobertDowns >> (All): yes
Riccardo Ferrante >> (All): yes
Mark Conrad >> (All): Ok. I will make that change.
Bruce Ambacher >> (All): Is any change required to the "Discussion"
section in light of what we just adopted?
Riccardo Ferrante >> (All): no
Mark Conrad >> (All): I don't think any changes are necessary.
KatiaThomaz >> (All): ok for me
Marie >> (All): OK
RobertDowns >> (All): ok
Bruce Ambacher >> (All): Is it changed /improved if we delete the first sentence Mark Conrad >> (All): No. The second sentence does not make sense without the first.
RobertDowns >> (All): Since it says 'One approach", it is just one of many possibilities.
Bruce Ambacher >> (All): I am comfortable with it as is, just trying to address John's next comment.  I do not think ihis next concern is valid Mark Conrad >> (All): Is everyone happy with B.4.3. as revised?
Marie >> (All): Yes
Bruce Ambacher >> (All): yes
Riccardo Ferrante >> (All): yes
Mark Conrad >> (All): Shall we move on to B.4.4.?
RobertDowns >> (All): I agree with John's points, but I believe that our changes address them RobertDowns >> (All): Yes, le'ts move to B4.4 Marie >> (All): I too think John's point is addressed and let's move on.
Mark Conrad >> (All): I would suggest modifying the text of the Requirement to simply say, integrity of the AIPs.
Bruce Ambacher >> (All): ok
KatiaThomaz >> (All): ok
Marie >> (All): OK
RobertDowns >> (All): I agree, that would be consistent Riccardo Ferrante >> (All): ok Bruce Ambacher >> (All): In Supporting Text, I suggest starting with 2nd sentence Mark Conrad >> (All): I will make the change to the Requirement.
Bruce Ambacher >> (All): This = Repository actively monitors integrity of archival objects Riccardo Ferrante >> (All): seems redundant with the requirement. Why not put "over time" in the requirement?
Bruce Ambacher >> (All): I would say that "actively monitors" implies "over time"
Riccardo Ferrante >> (All): Then do we need that in the supporting text?
Bruce Ambacher >> (All): No. but it doesn't detract or confuse.
Riccardo Ferrante >> (All): agreed
Bruce Ambacher >> (All): suggestion withdrawn.  
RobertDowns >> (All): Should we remove "and must make some use of it"?
Bruce Ambacher >> (All): OK.  II don't see fixity as the only way to confirm integrity of AIPs.  That is part of my suggestion to delete. 
But I can support modification
Mark Conrad >> (All): In OAIS terminology, this means that the repository must have Fixity Information for AIPs and must periodically compare the Fixity Information with the AIP.
Bruce Ambacher >> (All): ok.  That conforms with the definition of fixity in the document.
RobertDowns >> (All): I agree
KatiaThomaz >> (All): You have all kinds of information in Fixity Information. OAIS RM only cites some of them...
Mark Conrad >> (All): I would support removing the first two sentences.
Riccardo Ferrante >> (All): if we keep it as an example, I am ok with removing it from the supporting text Marie >> (All):  I agree with Riccardo, let's keep it as an example Mark Conrad >> (All): Ricc I would suggest moving it to the discussion as one approach to meeting the requirement.
KatiaThomaz >> (All): no. we shouldn t remove them. we shoukld make clear that all akind of information about integrity must be inserted in Fixity Infomation...
Mark Conrad >> (All): Katia, How would you suggest that we do that?
KatiaThomaz >> (All): we must change the sentences, not remove Mark Conrad >> (All): How would you change them?
Bruce Ambacher >> (All): Different repositories employ different methods to determine ongoing integrity of their AIPs.  We want to mandate they do so but we don't mandate specifically how.  That can vary by type of file and by designated community as to what is acceptable.
RobertDowns >> (All): That might be good for the Supporting text.
KatiaThomaz >> (All): but those methods must be in the Fixity Information Bruce Ambacher >> (All): OAIS terminology for "Fixity Information"
refers to authentication, not integrity
Mark Conrad >> (All): I agree it could be useful for the supporting text.
KatiaThomaz >> (All): only examples...
KatiaThomaz >> (All): integrity: Integrity refers to the completeness of the digital objects and to the exclusion of unintended modifications as defined in the preservation rules. Integrity is measured in terms of the characteristics of the digital object being preserved.
Riccardo Ferrante >> (All): I need to go.
KatiaThomaz >> (All): in the glossay
KatiaThomaz >> (All): glossary
Marie >> (All): John louder
Mark Conrad >> (All): How about if we go with Bruce's original suggestion and delete the first sentence of the supporting text?
KatiaThomaz >> (All): ok for me. it s obvious if we follows OAIS RM KatiaThomaz >> (All): i need to go too.
Mark Conrad >> (All): I need to leave in a few minutes. Action items for next time - review and complete action items from the June 30th meeting.
KatiaThomaz >> (All): thanks and have a nice week.
Bruce Ambacher >> (All): My issue here is that text currently reads as if Fixity is the only aspect determining integrity Marie >> (All): Bye all KatiaThomaz >> (All): bye Mark Conrad >> (All): I agree with Bruce.
RobertDowns >> (All): I believe that the following suggested text, by Bruce is informative and that we should include, even if only under exampLes "Different repositories employ different methods to determine ongoing integrity of their AIPs.  We want to mandate they do so but we don't mandate specifically how.  That can vary by type of file and by designated community as to what is acceptable."
Mark Conrad >> (All): I will make the changes we discussed to B.4.3. and will forward the chat to Simon. Should we take up B.4.4. next week? Can someone ensure that B.4.1. and B.4.2. are marked up to accurately reflect the discussion on July 7?
RobertDowns >> (All): I am traveling this entire week.
Mark Conrad >> (All): Are we done for today?
RobertDowns >> (All): Next week, I think that we should consider the following sentence that you suggested, Mark, to replace the similar, ambiguous, sentence in 4.4: "In OAIS terminology, this means that the repository must have Fixity Information for AIPs and must periodically compare the Fixity Information with the AIP." 
RobertDowns >> (All): Is someone going to gather the chat from today?
RobertDowns >> (All): Bye
Topic revision: r1 - 2008-07-28 - DavidGiaretta
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