Notes from Megameeting 7th April 2008


BruceAmbacher UM
CandidaFenton HATII, Univ Glasgow
HelenTibbo UNC
JohnGarrett GSFC
MarkConrad NARA
RiccardoFerrante Smithsonian Institution Archives
RobertDowns Center for International Earth Science Information Network (CIESIN), U Columbia
SimonLambert STFC

The discussion was a combination of audio and typed chat; however the chat transcript captures most of the points.

Progress made: Section B1.5 had been finalised in advance. Amendments to B1.6 were agreed. Discussion of B1.7 started. Changes are being made to the working document on the wiki at the page with the new template for requirements.

Next meeting: Continue with B1.7.


  • No specific actions this week.

candida fenton >> (All): I have been asked to do some work on possible
scoring systems for TRAC. So I'd just like to clarify something
concerning the term 'mandatory' which has been used. I understand the
term to mean compulsory and wonder if we agree on that?So in the case of
TRAC a mandatory requirement would be one that a repository has to
fulfil to become certified, and if a repository does not fulfil all the
specified requirements they will not be certified.
BruceAmbacher >> (All): Bob, All I heard was static.
Mark Conrad >> (All): Candida and Riccardo, Can you hear the audio?
candida fenton >> (All): No
Riccardo Ferrante >> (All): no
Mark Conrad >> (All): I guess we will have to use the chat then.
BruceAmbacher >> (All): candida, I would generally agree with your views
on mandatory and consequences but we have to allow some flexibility
where an item does not apply or where the repository has taken an
alternate approach and that works in their environment
Mark Conrad >> (All): Should we get started with B.1.6?
candida fenton >> (All): Can anyone else comment on the use of the term
Mark Conrad >> (All): Under the new template, the Supporting text
section of each requirement is supposed to list the mandatory elements
of that requirement.
Mark Conrad >> (All): As I said in my comments, this is problematic for
candida fenton >> (All): So does that make all  requirements mandatory?
BruceAmbacher >> (All): Agreed.  I am just trying to have some latitude
for the auditors in interpreting what is required to signify compliance.
Mark Conrad >> (All): Atleast the elements in the supporting text
section should be mandatory.
BruceAmbacher >> (All): How does B1.6 (and others) apply to a web
harvest or similar action?
Mark Conrad >> (All): Whoever is doing the web harvest is the producer.
RobertDowns >> (All): I believe that we need to put in appropriate
statements in the supporting text to facilitate web harvest and informal
relationships with producers
BruceAmbacher >> (All): So they inform themselves via a memo of action
taken with specifications of what was harvested and what metadata apply
to that harvest?
Mark Conrad >> (All): I believe that B.1.6. should be removed unless we
remove the phrase about nothing at all.
Mark Conrad >> (All): See the comments for B.1.6.
RobertDowns >> (All): Mark, are you referring to the comments in B1.5?
BruceAmbacher >> (All): If memory serves me, that phrase was to cover
web harvests where the producer does not know about the harvest.
Mark Conrad >> (All): Bob, no B.1.6.
Mark Conrad >> (All): Bruce, if it isn't mandatory in all cases, why
should it be part of the standard?
BruceAmbacher >> (All): Because we are dealing with both "traditional"
repositories with such chains of custody and direct contact between
producers and archives and with the web harvest and other unknowing
captures of SIPs.
Mark Conrad >> (All): There is always a producer - even in a web
harvest. Either the requirement has mandatory elements for all
repositories or it doesn't
RobertDowns >> (All): Another case would be if a submission inteface
provides an automatic response to the producer stating that the object
has been submitted and you will be notified if there are any questions
BruceAmbacher >> (All): We grappled with this issue in developing TRAC -
not fully successfully.
BruceAmbacher >> (All): Nothing at all can mean successful ingest
JohnGarrett >> (All): Hi, I think a piece of the mandatory part of this
is that if no reports are generated, then you have a mandatory agreement
that you are not providing other reports.
BruceAmbacher >> (All): You still have some agreement (that should be
memorialized) as to what your course of action will be, e.g. the data
will be available for harvest on the first day of each quarter.
BruceAmbacher >> (All): Text may not need modifying if the agreed points
are all pre-ingest/harvest
Riccardo Ferrante >> (All): Remove nothing at all, add standing
agreements, and initial annoucements to SIP providers. This would cover
NARA's major harvest of .gov websites, yes?
RobertDowns >> (All): I agree that it makes sense to add a statement
about standing agreements and initial announcements
Riccardo Ferrante >> (All): So that removes the option for standing
agreements that therein define no further contact. If we keep the
'during the ingest process', then I agree we this mandatory.
Riccardo Ferrante >> (All): Sorry, not mandatory
BruceAmbacher >> (All): "at agreed points" can mean never or by prior
arrangement before initial ingest.  It also can mean a memo for record
from each ingest.
Mark Conrad >> (All): Riccardo, Under the current template the
Supporting text is supposed to be mandatory for all repositories.
Mark Conrad >> (All): Bruce, how does that prevent lapses in
Mark Conrad >> (All): What do we lose if we delete B. 1.6?
JohnGarrett >> (All): How about "Repository provides producer/depositors
with appropriate responses at any points as agreed to within the
submission agreement. "
Mark Conrad >> (All): John, How does that prevent lapses in
communication and inadvertent loss of SIPs?
Riccardo Ferrante >> (All): why not 'all' instead of 'any'. That would
avoid undocumented lapses, yes
BruceAmbacher >> (All): I think we do lose the usual need to document
the ingest..  The action John suggests may occur outside a formal SIP.
We would look for evidence that the repository does have a tickler
system to harvest and does check its standing ingest agreements for
JohnGarrett >> (All): Presumably a determination was made during
creation of the submission agreement that there was so little chance of
a loss that it was not worth spending resources checking it or that
checking would be done by producer taking action to check the holdings
to make sure they made it in.
JohnGarrett >> (All): All instead of any is OK with me.
BruceAmbacher >> (All): John, In my experience producers are not as
motivated as you suggest.
Mark Conrad >> (All): Bruce, documenting the ingest is covered under
other requirements.
JohnGarrett >> (All): I agree, but if that is what the submission
agreement says, I don't think we should force the archives to do more
than is in the agreement.
Simon Lambert >> (All): The proposed change is pushing responsibility on
to the submission agreement - is that ok?
Mark Conrad >> (All): Then this is not a mandatory requirement and why
is it in here?
BruceAmbacher >> (All): Where are we replacing any with all?
Simon Lambert >> (All): Bruce - that's within John's proposed amendment
further up the chat log.
Riccardo Ferrante >> (All): I was referring to John's line 11 lines
lines back
Simon Lambert >> (All): "Repository provides producer/depositors with
appropriate responses at *all* points as agreed to within the submission
agreement. "
Mark Conrad >> (All): Simon, I think the any they are referring to is in
the Discussion section. Is that correct, Riccardo or John?
JohnGarrett >> (All): I think I have a philosophical problem that I
think we could go through all these criteria and find an edge case where
we wouldn't do 50% or more of the criteria.  However I think throwing
all those out will result in many 'archives' passing by meeting all the
criteria, but not really being able to maintain data long-term.  I think
it is more valuable to keep in these criteria that apply in most cases.
And if they don't apply, then you need to document that you are leaving
them out.
JohnGarrett >> (All): I think the "any" being referred to was my rewrite
of the criteria.
BruceAmbacher >> (All): They have met the requirement by aSIP or other
agreement/announcement and it conforms with their documented practice
which should include their processing requirements and check.
Helen Tibbo >> (All): Isn't this like the IRS telling us they have
received out e-tax submission?
BruceAmbacher >> (All): Watch your screen you are talking over each
Riccardo Ferrante >> (All): I'm hearing 2 of you at the same time,
missed what John said at first
Riccardo Ferrante >> (All): Not , my mistake. It was you Bob
Helen Tibbo >> (All): Isn't this also about timeliness - i.e., the
repository tells the depositor that they have received XYZ and then the
depositor can check and see if that was what was sent.
BruceAmbacher >> (All): This is all deja vu all over again.  We had
similar impasses in developing TRAC
Helen Tibbo >> (All): Is this a double check on b1.4?
BruceAmbacher >> (All): John, Do you have actual examples where the
producer is never told of ingest actions?  No annual report, for
JohnGarrett >> (All): This is necessary in order to ensure that the
producer is able to check as they expect to be able to check that there
is no inadvertent lapses in communications which might otherwise allow
loss of SIPs.
Riccardo Ferrante >> (All): With this change in the supporting text, I
think it can stand as mandatory.
Helen Tibbo >> (All): Yes, I like that wording.
Mark Conrad >> (All): Does anyone have any objections to the revised
candida fenton >> (All): No
BruceAmbacher >> (All): I agree to text.
RobertDowns >> (All): I agree to the revised text, too
Simon Lambert >> (All): Looks good to me.
Mark Conrad >> (All): Shall we move to B.1.7?
RobertDowns >> (All): I agree with Mark's suggestion to remove the
statement, beginning with "otherwise" out of the supporting text area
Mark Conrad >> (All): Does anyone object to the proposed change in my
first comment in B.1.7?
BruceAmbacher >> (All): accept
Riccardo Ferrante >> (All): accept
Helen Tibbo >> (All): Accept
candida fenton >> (All): accept
RobertDowns >> (All): accept
Simon Lambert >> (All): accept
JohnGarrett >> (All): No
JohnGarrett >> (All): Sorry no I don't object, ie. agree
JohnGarrett >> (All): Without the understanding that the archive has
already taken custody of the data, the producer/depositor may make
changes to the data and these would not be properly archived since they
had already been ingested by the archive.
BruceAmbacher >> (All): John, Wouldn't your scenario require a periodic
re-ingest or snapshot of changes since x?
BruceAmbacher >> (All): Let me raise my question here: Why were
"confirmation receipts" eliminated? They seem to be a most pertinent
type of notification.|
Mark Conrad >> (All): Without the understanding that the repository has
already taken preservation responsibility for the SIP, the
producer/depositor may make changes to the data and these would not be
properly archived since they had already been ingested by the
Helen Tibbo >> (All): Might there not be some repositories that take on
custody but not long-term preservation? Do we want to make a distinction
between these two or is it our assumption that the repository will
always take custody to preserve the content?
JohnGarrett >> (All): Yes it would require reingest if changes were
made.  But if there is sufficient tracking and few changes then reingest
of the data bits would not be necessary.
Helen Tibbo >> (All): OK
BruceAmbacher >> (All): "since that data had already been ingested . .
JohnGarrett >> (All): I agree
Helen Tibbo >> (All): Yes
Riccardo Ferrante >> (All): yes
BruceAmbacher >> (All): yes
candida fenton >> (All): yes
BruceAmbacher >> (All): I have to sign off.  I have a site visit inone
hour and a half.
Mark Conrad >> (All): I have to sign off as well. Shall we pick up with
the rest of the comments for B.1.7. next week?
Riccardo Ferrante >> (All): That works for me.
JohnGarrett >> (All): Sure
candida fenton >> (All): Sure
Helen Tibbo >> (All): OK
Mark Conrad >> (All): Bye for now!

-- SimonLambert - 08 Apr 2008

Topic revision: r1 - 2008-04-08 - SimonLambert
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