Notes from Megameeting 7th January 2008

Attendees:

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

cclrc >> (All): Hi Helen & Bruce - "cclrc" is Simon this week.
cclrc >> (All): David hoped to take part but some travel problems means he won't be able to make it this time.
BruceAmbacher >> (All): We seem to be a small group so far
cclrc >> (All): Yes, let's wait a few more minutes.
Mark Conrad >> (All): Hello! Just saw an e-mail from Don Sawyer saying he would be unable to attend today.
KatiaThomaz >> (All): hello!
Helen Tibbo >> (All): I am having problems, no matter what I do to stay connected! Wish we could use Skype for this. That always works. 
Helen Tibbo >> (All): I've been trying various things all AM
Helen Tibbo >> (All): I have now lowered the entire firewall to see if that's where the problem is. I can get connected from my docking station at work but either wireless or wired at home seems to drop out.
Helen Tibbo >> (All): Well, perhaps it is the firewall and I just don't know how to open the right port. Let's see how this goes.
cclrc >> (All): OK, last time the discussion was on B1.7, with a proposal to split it in two, but I'm not sure that was agreed by everyone.
BruceAmbacher >> (All): Remind me of the proposed split and the major arguments for it.
cclrc >> (All): John G said "Should this be broken into two parts - one the agreement with producer when handoff is made and the second recording that it happened for each SIP"
KatiaThomaz >> (All): B1.7?
BruceAmbacher >> (All): I see John's proposed split as already being accomplished in B1.6 and B1.7.
JohnGarrett >> (All): Yes, I thought that's what the group was migrating to.  We left B1.7 to be that we had a policy about when responsibility was accepted.
JohnGarrett >> (All): Then B1.8 handled the recording that responsibility was actually accepted.
Mark Conrad >> (All): I believe this is what we agreed to at the last meeting.
BruceAmbacher >> (All): Is any minor editing required to clarify this?
JohnGarrett >> (All): Looks like some editing was done in the main document already.  Does this look acceptable to all?
KatiaThomaz >> (All): ok for me.
Mark Conrad >> (All): I am confused by th ephrase "when it first receives the SIP transformation,"
Mark Conrad >> (All): Should the word transformation be removed?
BruceAmbacher >> (All): I see that as a notification (automated or manual) back to producer that you received the SIP
BruceAmbacher >> (All): Agree to change/eliminate transformation.  That is when the SIP becomes some kind of AIP right?
JohnGarrett >> (All): I agree we could eliminate "transformation" there.
KatiaThomaz >> (All): agree to eliminate "transformation".
Mark Conrad >> (All): Bruce, Right. See the following phrase.
BruceAmbacher >> (All): Strike "transformation"  A SIP is a SIP.
Mark Conrad >> (All): Should the second paragraph be eliminated? moved to B. 1.8?
Mark Conrad >> (All): After we make all these changes we will have to revisit our votes on the mandatory requirements page.
BruceAmbacher >> (All): Printed, I don't see a second par.  Does it start "Repositories . . ?  If so, ok
JohnGarrett >> (All): I thought about that, but it is only one aspect of B1.8 and if we moved it there, I think we would need to really expand discussion in B1.8 to cover other aspects.
JohnGarrett >> (All): Bruce, yes second paragraph online start "Repositories that report..."
Mark Conrad >> (All): Then I would propose eliminating the paragraph that starts, Repositories that report back.  Nothing in the paragraph is mandatory and it only adds to the confusion of what is covered by B 1.7
BruceAmbacher >> (All): Ah, the logic and the sequence of 6, 7, 8 s coming back to me.  The 2nd par, is more appropriate in 7  I do think it illuminates what 7 says but if others see confusion as Mark does I can agree to drop it.
JohnGarrett >> (All): I liked the detail that it had, but agree that it is somewhat out of place.  I don't find it too confusing, but could see how others would.
BruceAmbacher >> (All): It was put there to try & explain different sequences of events in the ingest process.
JohnGarrett >> (All): I think I would like to keep it, unless it is too confusing to others.
KatiaThomaz >> (All): I liked too. It contains a some examples on how to write the policies.
BruceAmbacher >> (All): So, lets keep it and see what is said in broader document review.
JohnGarrett >> (All): OK
Helen Tibbo >> (All): Well, I left home and am now at a coffee shop!
Mark Conrad >> (All): Bruce, We moved reporting back to the depositor to B.1.8. I don't think this explanation fits here. B.1.7 is now focused on what types of policies are in place. These are not examples of policies for when the repository formally accepts responsibility for preservation.
JohnGarrett >> (All): Welcome back, Helen
BruceAmbacher >> (All): Mark, I don't see that in the online text of 8.
Mark Conrad >> (All): See the updated evidence section of 8
JohnGarrett >> (All): Perhaps we could reword the second paragraph a bit to indicate that the policy may also dictate that a report is generated at the point responsibility is accepted.
BruceAmbacher >> (All): That one slipped past me.  I have no problem adding it to 8 but do have a problem with eliminating it from 7.  It can be in both items.
JohnGarrett >> (All): I think we can't just move it to B1.8 without then having to describe every action that should be recorded.
KatiaThomaz >> (All): I agree with John.
Mark Conrad >> (All): If we are to develop an international statndard I think for clarity's sake we need to minimize the amount of text that addresses non-mandatory requirements.
BruceAmbacher >> (All): 7 is the submission/ingest process; 8 is internal preservation actions. which are rarely reported back to producer.
Mark Conrad >> (All): I would propose moving as much of the non-mandatory text in this document as possible to an appendix of suggested issues to consider. Otherwise it just clutters up the standard.
BruceAmbacher >> (All): Mark, perhaps we need a few application annexes as are in OAIS that show how the concepts are applied.
Mark Conrad >> (All): That would be fine, but I think the text of the standard itself should be concise.
BruceAmbacher >> (All): would you agree to keeping first 2 sentences of second paragraph?
JohnGarrett >> (All): In general I agree with Mark, but there is also a balance of including enough text to make it understandable with most users of the document.  It's often hard to find the right balance.
Mark Conrad >> (All): That is one of the reasons I suggested identifying what is mandatory and what is not. in the TRAC document.
Mark Conrad >> (All): Bruce, no. I don't think the first two sentences illuminate the requirement for B 1.7 as revised.
Helen Tibbo >> (All): To keep the main document uncluttered, should their be an annex of examples to help people understand what could be rather abstract text in the main section? We would have to be careful to make the point that these did not cover all situation but were examples only.
Mark Conrad >> (All): B.1.7. as I understand it is about establishing policy about when the repository accepts responsibilty - not what to do once it has accepted responsibility.
BruceAmbacher >> (All): With the refocus, B1.7 should come earlier in the sequence - before any actions are taken, perhaps as a new 2 or 3
JohnGarrett >> (All): How about starting the paragraph with something like "For repositories that report back to their depositories, the point where preservation responsibility is accepted is marked by a report."
Mark Conrad >> (All): Helen, Maybe in terms of organizing the material an annex is not the best approach. Perhaps have the text of the requirement and the evidence followed immediately by a section for examples/issues to consider.
JohnGarrett >> (All): This will set a context for the paragraph, or shortened version of it, to help ID the point of accepting responsibility.
BruceAmbacher >> (All): John, "report" minimizes what the document might be - it could be a formal "deed of gift" or formal transfer of legal responsibility.
BruceAmbacher >> (All): Mark, the original thinking was that some repositories know exactly how they will/must execute each point and added examples will clutter and expand the actual document, hence thoughts to create annexes.
KatiaThomaz >> (All): I accept the idea of creating annexes.
Mark Conrad >> (All): I am not opposed to either creating an examples section or moving the non-mandatory material to an annex. I am opposed to having a bunch of text that deos not apply to all repositories cluttering up the text of the standard.
Helen Tibbo >> (All): How about "reporting instrument" rather than report? Then give examples somewhere of what such a instrument might be such as a deed of gift?
BruceAmbacher >> (All): The evidence section gives different kinds of "reports"  Should it be expanded?
Mark Conrad >> (All): Are we requiing all repositories to issue a report to the depositor when they accept responsibility for the preservation of a submission? If no, I suggest eliminating the discussion of reporting here. If yes, I believe that should be a separate requirement from B.1.7.
BruceAmbacher >> (All): We know many ingest activities (web harvest) do not trigger "reports".  We can't require it..  So it should be separate.
RobertDowns >> (All): Sorry, I lost connectivity and arrived late. Would the report for B1.7 be a record of the date when responsibility was accepted?
Helen Tibbo >> (All): Right we can't require it but perhaps we can require that the repository has a specific policy/process statement that indicates even when they do not have such an agreement/report. This would provide evidence that they had considered it and why there is no report.
BruceAmbacher >> (All): Robert, It could be but it does not have to be reported back to producer; it could be maintained internally
Mark Conrad >> (All): Bob, Presumably the report would include the date. However, I would argue that report addresses the requirement in  B.1.8 not 1.7.
Helen Tibbo >> (All): That wasn't very clear. Sorry. But the repository would have to say something like "we don't generate this report because we web harvest."
RobertDowns >> (All): I am interpreting the requirement for B1.7 to mean that the repository has to know when it took responsibility. The evidence of knowing when is the date
Mark Conrad >> (All): I believe that B.1.7 as revised requires all repositories to have policies in place for DETERMINING WHEN they take responsibility - not WHAT ACTIONS TO TAKE after accepting that responsibility.
Helen Tibbo >> (All): I gree with Mark.
JohnGarrett >> (All): B1.7 is currently only having a policy.  B1.8 is maintaining a record of important actions.
KatiaThomaz >> (All): Right, John.
BruceAmbacher >> (All): Are we near consensus to eliminate 2nd par. from B1.7, making it a policy only (no action) statement?
Mark Conrad >> (All): John, Yes. And I would say that the report could be on of those records.
JohnGarrett >> (All): Report is not really part of either one directly.  Policy may include a requirement to send a reporting instrument back to deposit and to make an entry in archives records to show this responsibility was accepted and the report was sent.
Mark Conrad >> (All): Bruce, I think so.
JohnGarrett >> (All): I interest of moving on, let's eliminate the paragraph.
Helen Tibbo >> (All): It seems that the evidence in B.1.7 should really be in B.1.8
KatiaThomaz >> (All): Ok of eiliminating.
BruceAmbacher >> (All): Helen, What evidence would you propose - the policy itself?
Mark Conrad >> (All): Helen, The documents listed in the evidence section for B 1.7 may be the written policies required by B 1.7.
KatiaThomaz >> (All): Not moving to B1.8.
JohnGarrett >> (All): No the evidence in B1.7 is evidence that there is a policy about when responsibility is accepted.  I think that would be in a submission agreement/deposit agreement
Helen Tibbo >> (All): To me, that would be from the repository's policy manual that would say something like, when we take in a collection we create a deed of gift, etc. and it is signed by all parties and when we web harvest we don't, etc. 
RobertDowns >> (All): I agree that we should add policy to the evidence for B1.7 
BruceAmbacher >> (All): The current B1.7 evidence should stay - it can be supplemented with policy document if desired.
Mark Conrad >> (All): I agree.
Helen Tibbo >> (All): The policy would be that we use agreements or not or when. Then that second paragraph could be its own number that illustrates the reporting of that which seems to be separate from what is discussed in b.1.8
RobertDowns >> (All): I agree that we should simply add "or policy" to the evidence for B1.7
Helen Tibbo >> (All): deeds of gift, etc. are manifestations of policy, not the actually policy itself nor the rules of application
Mark Conrad >> (All): Do we need a statement in the text for B.1.7 that states WHY all repositories should have such a policy?
JohnGarrett >> (All): But it might not be the same policy across all collections.  Policy about when preservation responsibility is accepted could change from depositor to depositor or even from Producer-Archive Project to the next project.
BruceAmbacher >> (All): Helen, does your suggestion run against Mark's premise that only "applicable to all" elements should be in document?
RobertDowns >> (All): Mark - A little explanation in B1.7 might help clear up the confusion
JohnGarrett >> (All): No, we're presenting the requirements not the reasoning behind them.
BruceAmbacher >> (All): I must go.  I will be travelling next week and will not have internet.
Helen Tibbo >> (All): I don't think so - a policy is general. It might say the repository negotiates with the depositor, etc. 
Helen Tibbo >> (All): Bye Bruce!
JohnGarrett >> (All): Evidence has to be physical evidence that indicates policies are actually in place.
Mark Conrad >> (All): John, requirements without  reason for the requirement may result in some very unexpected (and possibly unacceptable) policies.
KatiaThomaz >> (All): I answer, what to do with "A3.2 Repository has procedures and policies in place, and mechanisms for their review, update, and development as the repository grows and as technology and community practice evolve." and others requirements in A3.?
JohnGarrett >> (All): But if you can't show that you negotiated with the depositor and reached a policy for this project, you don't have a policy for this project.  The evidence that you reached agreement is the Submission Agreement.
Helen Tibbo >> (All): I think a "why" would be very useful for much of this for repositories.
Helen Tibbo >> (All): John, I think we are talking about two levels of "policy." You could have notes from the negotiation to prove you had it or internal reasoning such as we are web harvesting so we don't have an agreement. Then the deed, etc. in the first place is the evidence of the report.
Mark Conrad >> (All): I believe the evidence section for most requirements list examples of possible ways of verifying the requirement has been met. I do not think the list is exhaustive or mandatory.
JohnGarrett >> (All): I agree with Mark.  They are only examples. 
Helen Tibbo >> (All): Yes, they are examplesof evidence
RobertDowns >> (All): Yes, but it should be made clear to the auditors that the stated evidence items are just examples.
Mark Conrad >> (All): So I would say that the discussion about including or not including deposit agreements etc is moot.
Mark Conrad >> (All): Bob, I agree. It should be made explicit at the beginning of the document.
JohnGarrett >> (All): Yes there should be introductory section that includes "How to read this document" that explains that up front.
Mark Conrad >> (All): Yes.
KatiaThomaz >> (All): Yes.
Helen Tibbo >> (All): wasn't the discussion about deposit agreements predicated on the question of whether some sort of report was mandatory? 
RobertDowns >> (All): Yes, I also agree. An introductory section on how to read the document will help reduce confusion. 
JohnGarrett >> (All): OK, I'm signing off now.  Everyone have a good new year.
Mark Conrad >> (All): Helen, No. The discussion between you and John was about whether or not deposit agreements were evidence of a policy or not.
KatiaThomaz >> (All): I must sign off too. Have a HAPPY NEW YEAR!!!
KatiaThomaz >> (All): Bye.
Mark Conrad >> (All): Bye!
Mark Conrad >> (All): Simon will you capture the chat?
cclrc >> (All): Yes, I will do that.
Mark Conrad >> (All): Thank you. Happy New Year everyone!
cclrc >> (All): Bye all

-- SimonLambert - 07 Jan 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