Notes from Megameeting 19th November 2007

Attendees:

BruceAmbacher UM
CandidaFenton HATII, Univ Glasgow
HelenTibbo UNC
JohnGarrett NASA/GSFC
KatiaThomaz INPE, Brazil
NancyMcGovern ICPSR
SimonLambert STFC
RobertDowns Center for International Earth Science Information Network (CIESIN), U Columbia

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

Summary: discussion of B1.6 based on matrix for identification of madatory requirements, and suggestion for amended wording (to be circulated). Also discussion of the significance of "mandatory" requirements.

cclrc >> (All): I think we've got a quorum - shall we begin?
cclrc >> (All): Did you see my email about the current issues?  I thought it might help to structure the discussions.
cclrc >> (All): It was just to summarise the state of the matrix of mandatory reqts, and summarise what the open issues are in section B1.*.
BruceAmbacher >> (All): Let's start with B1.6 - why would it not be mandatory?  The answer could be no prior response by agreement between producer and repository.
JohnGarrett >> (All): Yes, I think that is the main reason
BruceAmbacher >> (All): But that is a predefined  point.  With the possible exception of web harvest, there should be communication between repository and producer, right?
NancyMcGovern >> (All): That sounds right.  
JohnGarrett >> (All): But as you say, there is web harvest
KatiaThomaz >> (All): I think it is an issue for section A5
JohnGarrett >> (All): I think it is at least highly desirable that there be some handshaking, but is it required for preservation/
BruceAmbacher >> (All): Even with web harvest it is best accomplished with discussion/agreement between producer and repository/harvester.
BruceAmbacher >> (All): Whay would a repository assume preservation responsibility for objects that the producer does not want them to have?
NancyMcGovern >> (All): The focus of the requirement is on appropriate responses - the evidence would document when and how the archive provides responses during ingest.  Notification is required so it seems like documentation should be required.  This is a technological rather than organizational step - yes?  The need for notification is speficifed in section 1 - this item says when and how.  correct?
Helen Tibbo >> (All): We would definitely want good communication between the producer and the archive, but is this a recommendation or requirement?
KatiaThomaz >> (All): web archiving project, for example
JohnGarrett >> (All): I think most web archiving projects happen without agreements
Helen Tibbo >> (All): If there is no agreement would the archive tell the producer anything?
JohnGarrett >> (All): With the exception of web archiving type of projects, do others require interaction to ensure preservation?
NancyMcGovern >> (All): Aren't the largest web archiving projects national and they occur with a legislative mandate or equivalent statement - we are going to archive all of the web content in this national domain, for example.  Isn't this a case when the repository response during an audit would be N/A and here's why.
cclrc >> (All): Perhaps the key question is what is "appropriate" for a particular situation.
NancyMcGovern >> (All): exactly.
cclrc >> (All): Appropriate for what?  To reassure the producer/depositor? Or something more concrete?
JohnGarrett >> (All): I think the biggest web archiving project is Internet Archives (the Way Back Machine).  I think that is a private effort without agreements with anyone.
RobertDowns >> (All): Perhaps the repository should just just state their procedures and then follow their procedures
Helen Tibbo >> (All): Weren't we separating out the variable response points from the more generally required ones? 
BruceAmbacher >> (All): As B1.6 begins: "Based on the initial processing plan and agreement between the repository and the producer"  So there is a sense in the bullet that there is agreement/prior notice
JohnGarrett >> (All): What would be the required response points?
BruceAmbacher >> (All): Is that the "evidence" statements?
Helen Tibbo >> (All): Wouldn't the evidence statements be what is communicated and not the response points, although the eveidence might trigger response points, i.e., the repository has something to report.
NancyMcGovern >> (All): I think the intent was that the repository defines a procedure for when it will notify depositors/producers and it follows that procedure.  The evidence is the procedure and documentation of the notifications - for example.
BruceAmbacher >> (All): So, are we back to Simon's original question of whether B1.6 should be mandatory?  I say yes, meaning that the producer and the repository should work out their desired schedule of notification (which can be none).
Helen Tibbo >> (All): So, all this sounds great and desirable, but is it mandatory?
JohnGarrett >> (All): I'd be fine with saying that for each Producer-Archive Project, the Producer and Archive are required to have an agreement on when responses are made and then need to follow that agreement.
NancyMcGovern >> (All): What's a producer Archive Project? 
JohnGarrett >> (All): In most cases the Archives would have a standard proceedure and it would be followed by most PA Projects.
KatiaThomaz >> (All): A3.5 Repository has policies and procedures to ensure that feedback from producers andusers is sought and addressed over time.
BruceAmbacher >> (All): John, So what do you think must change in the text?
cclrc >> (All): Katia - that is feedback from producers, not to them.
cclrc >> (All): "B1.6 Repository defines and follows a plan for responses to the producer ..."
cclrc >> (All): Something like that?
NancyMcGovern >> (All): Every trusted repository should determine and document its interactions with producers - including a statement that we don't do that and here's why.  It does raise a question about the various ways of viewing mandatory.  
BruceAmbacher >> (All): As written both "appropriate responses" and "at predefined points" are vague and flexible.  The supporting text bases it on a processing plan and agreement with producer.  Any support for leaving it as is?
JohnGarrett >> (All): A Producer-Archive Project may have been defined in a follow-on standard to the OAIS Reference Model - the Producer Archive Ingest Methodology Abstract Standard.  A PA Project is basically an agreement between a Producer and an Archive to ingest some particular set of data
Helen Tibbo >> (All): I think the question here is between best practice (herein that would engender trust, auditability, etc.) and a requirement for preservation. So, if the intent of the standard and this run through the points is to foster both preservation and good practice we should consider this a requirement
JohnGarrett >> (All): Bruce, if we replaced 'predefined' with 'agreed' in the checklist item, I would like it better.  And then update text somewhat also.
JohnGarrett >> (All): I thought we were trying to determine which items were actual requirements and which were best practices, but not required.
NancyMcGovern >> (All): Producer-Archive interface standard does formalize the interaction between producers and archives.  I thought you might be using project in a differnt way.  A producer-archive agreement is a known term.
NancyMcGovern >> (All): I think changing pre-defined to agreed sounds good.
JohnGarrett >> (All): In my view, probably everything in current TRAC would be at least a best practice.
Helen Tibbo >> (All): John, Yes, I agree with that! 
RobertDowns >> (All): I also agree that changing pre-defined to agreed seems reasonable.
BruceAmbacher >> (All): Do we then change the beginning text to producer-archive agreement?
Helen Tibbo >> (All): Yes, agreed is a good term here and one that denotes more of a partnership than some authoritative schedule imposed from one side or the other.
candida fenton >> (All): 'Agreed' is a good term to use
BruceAmbacher >> (All): I'm ok with the proposed change but I do not see the existing text as imposed.
NancyMcGovern >> (All): About good practice - TRAC identifies a complete set of good of practice, a repository indicates how it responds to each requirements including not, the audit results document gaps and ways in which the repository is not doing well enough.  I've been comfortable with that approach.
Helen Tibbo >> (All): Agreed seems more collaborative, as in the producer and the archive actually had to talk with one another
BruceAmbacher >> (All): I have always seen the proposed audit process as both quantitative and qualitative with narrative from the auditors accompanying some raw score.
RobertDowns >> (All): If there are scores, would each item carry the same weight?
BruceAmbacher >> (All): I don't think that has been determined.
Helen Tibbo >> (All): This is a fundamental question. If some are scored more heavily does that mean they are more "mandatory"?
JohnGarrett >> (All): I also see some leeway in the audit process, but I was getting the feeling that we wanted to say at least some of the items were required.  If anyone didn't follow those items, then we would not consider them a trusted Archives.
RobertDowns >> (All): If everything has the same score and a repository receives 90%,  then might that archive be considered trusted?
BruceAmbacher >> (All): Who makes that decision?  this group? A group like this set up to do that?  The auditors based on some test audits or based on a absolute scale?
BruceAmbacher >> (All): Do we have one scale for all repositories or multiple scales based on size, type, etc.?  The TRAC group certainly could not answer that.
NancyMcGovern >> (All): We talked about menu options because things like A5.1 are not always relevant, for example. I imagined that the auditors would define an audit plan that was informed by the mandate and context for the repository.
Helen Tibbo >> (All): I think whoever makes the pronouncement on trustworthiness, the term has to be defined for the consumer. Trustworthiness is not a promise of everlasting life in the repository (well, we coul dbe on to something if we could figure that out!)
BruceAmbacher >> (All): Nancy, I agree but the more qualitative elements introduced into the process, the less alike the results and thus less confidence in the "seal of approval"
NancyMcGovern >> (All): I think deposits represent a compact with producers and with current and future users - but I see your point, Heloen.  
Helen Tibbo >> (All): Yes, I would think the audit plan would be customized within a framework for a given repository and depositor community and user community.
Helen Tibbo >> (All): Nancy, yes, in that compact the producers/users (esp. producers) would have to know just what was being 'Promised."
BruceAmbacher >> (All): So, is my gold medal equal to your gold medal?
NancyMcGovern >> (All): I think there might be a set of requirements or showstoppers within different contexts and sectors to guide the audit. aAre we trying to determine: Is a repository or is a repository more trustwoirthy than that one?
Helen Tibbo >> (All): Good question - if I tell my producers we will keep the stuff for 10 years and 3 migrations and you say 20 years and 6 migrations are you at a higher level of trust?
JohnGarrett >> (All): When we get to the point of actually creating the standard, we will need to include a Conformance section.  In that section we will need to say what is needed to conform tom the standard.  If there are mandatory items we would list them there.
NancyMcGovern >> (All): I agree, Helen - about the producer/consumer promise
JohnGarrett >> (All): If there are not mandatory items, then our conformance section would probably be something the explains how we score things consistently across different audits/auditors, etc.
Helen Tibbo >> (All): I actually think the false promise is worse than a shorter term of performance.
BruceAmbacher >> (All): Thanks John for trying get us back on track.  We have leaped ahead.  We need to finish our text review/revision first
NancyMcGovern >> (All): If 10 years meets the one context's needs and 20 the other - both trustworthy.  I agree about the conformance section.  And I agree about finishing the revision.  I think mandatory relates to logisitics and the how of things.
Helen Tibbo >> (All): Well, it sounds like most folks here want B1.6 back in with slightly different wording. Is this correct?
BruceAmbacher >> (All): I sensed that "agreed" was replacing "predetermined" in the bullet and probably in the supporting text.
NancyMcGovern >> (All): Does back in mean on the mandatory list or in the requirements set?  The latter is not a question - correct?  Changing to agreed seems agreed.
JohnGarrett >> (All): Yes, with the change, it could go back in as mandatory requirement in my view.
Helen Tibbo >> (All): I meant on the mandatory required list.
KatiaThomaz >> (All): sorry i must leave you now. bye and have a good week.
NancyMcGovern >> (All): Gotta run.  I think I'm set to attend next week.  Hope you ahve a nice week, whether you're calebrating Thanksgiving or not.  
JohnGarrett >> (All): Yes, I need to leave also.  For US folks, have a Happy Thanksgiving.
Helen Tibbo >> (All): Yes, I need to be off - much to do. Happy Thanksgiving and safe travels if you are going about to family.
RobertDowns >> (All): I need to go too. Have a Happy Thanksgiving
candida fenton >> (All): Bye
BruceAmbacher >> (All): We also should change the beginning of the last sentence from "Depositors" to Producer/depositors to be consistent.
BruceAmbacher >> (All): bye
cclrc >> (All): Bye everyone - I will  put notes.

-- SimonLambert - 19 Nov 2007

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