Notes from MegaMeeting 11th May 2009


BruceAmbacher UM
DavidGiaretta STFC
JohnGarrett GSFC
KatiaThomaz INPE
MarieWaltz CRL
RobertDowns CIESIN, Columbia University
SimonLambert STFC

Actions (see transcript for details):

  • DavidGiaretta to produce cleaned up version of the current working document.
  • All to amend the metrics in the sections for which they are responsible, using Word documents, so that supporting text is informative, and that all the normative material from the supporting text is in the metrics.

Transcript of chat

BruceAmbacher >> (All): Where is the document on the wiki?  I want to open the 
correct text. but do not see what I think it should be
SimonLambert >> (All): Is it DraftMetricsMB-20090430.doc? 
SimonLambert >> (All): at the bottom of the page MetricsWorkingDocumentFollowingFaceToFace
BruceAmbacher >> (All): OK.  I expected to see a link on the main page rather 
than inside the face-to-face
JohnGarrett >> (All): Hello, everyone.
Marie Waltz >> (All): Hi JOhn
SimonLambert >> (All): It would make sense to have it more prominent
BruceAmbacher >> (All): Marie, have you absorbed and reacted to Mark's comments? 
Any suggested responses?
Marie Waltz >> (All): I have been thinking about them and i have a few questions 
for Mark. Most important is what he says regarding how the Preservation 
Strategic Plan does not include the ppropriate, formal succession plan, 
contingency plans, and/or escrow arrangements, does everyone agree with this?
BruceAmbacher >> (All): We have always had a problem of wanting to conflate 
everyting into a single metric when , as the metrics show, there is a need to 
develop multiple Plans, strategies.  There should be a comprehensive plan but it 
should be comprised of separate plans and approaches for accessioning, storage, 
preservation, access, delivery.  They should link but necessarily contain pieces 
of the linked elements.
Marie Waltz >> (All): So the way it is now the strategic plan is at the top of 
the hierarchy with the succession plan, etc as submetrics, should these all be 
at the same level as Mark suggests?
BruceAmbacher >> (All): Your acquisition strategy may change but that would not 
need to change your preservation strategy, or it may have significant impact on 
preservation and none on access/dissemination
BruceAmbacher >> (All): Marie I support a more equal coupling, retaining the 
distinctions between the major activities/concepts
KatiaThomaz >> (All): hi all
BruceAmbacher >> (All): Katia, hi
Marie Waltz >> (All): OK, so I'll move the two up that were submetrics. Hi Katia
Marie Waltz >> (All): Mark found several problems with this metric: This section 
seems to be solely concerned with understandability and not the other topics 
encompassed by the metric. It is also very difficult to understand.   3.3.2   
must have Preservation Policies in place that define its technical 
infrastructure, its services, and the expected level of understandability for 
its Designated Community for each Archival Information Product. This is 
necessary in order to ensure that each designated community knows the 
operational definition of understandability for its community and the knowledge 
base each user must possess in order to understand the preserved content. This 
allows the repository to provide appropriate levels of service to each 
designated community while keeping the necessary resource commitment to a 
minimum.Examples of Ways the Repository can Demonstrate it is Meeting this 
Requirement: Mission statement; written definitions of the Designated Community; 
documented policies; protocols, rules, manuals, handbooks, and workflows; 
service-level agreements.Discussion: The repository's level of service can vary 
from one submission to another, just as the definition of understandability that 
establishes the repository’s responsibility in this area may vary. This may 
range from no responsibility, if bits are only to be preserved, to the 
maintenance of a particular level of use, if understanding by the members of the 
Designated Community is determined outside the repository, to a responsibility 
for ensuring a given level of Designated Community human understanding, 
requiring appropriate Representation Information. The documentation of 
understandability will typically include a definition of the applications the 
Designated Community will use with the information, possibly after 
transformation by repository services. For example, if a designated community is 
defined as readers of English with access to widely available document rendering 
tools, and if this definition is clearly associated with a given set of Content 
Information and Preservation Description Information, then the requirement is 
met. Examples of designated community definitions include: General English-
reading public educated to high school and above, with access to a Web Browser 
(HTML 4.0 capable). For GIS data: GIS researchers -undergraduates and above - 
having an understanding of the concepts of Geographic data and having access to 
current (2005, USA) GIS tools/computer software, e.g., ArcInfo (2005). 
Astronomer (undergraduate and above) with access to FITS software such as 
FITSIO, familiar with astronomical spectrographic instruments. Student of Middle 
English with an understanding of TEI encoding and access to an XML rendering 
environment. Variant 1: Cannot understand TEI Variant 2: Cannot understand TEI 
and no access to XML rendering environment Variant 3: No understanding of Middle 
English but does understand TEI and XML The repository has defined the external 
parties (see ISO27001 A.6.2), and  its assets, owners and uses (see ISO27001 
A.7).  Two groups: the publishers of scholarly journals and their readers, each 
of whom have different rights to access material and different services offered 
to them.
Marie Waltz >> (All): Any suggestions on how to make it clearer?
BruceAmbacher >> (All): Is this a legacy of David's exercise to put 
"preservation" in everything?  I don't see the clear connections
BruceAmbacher >> (All): In TRAC this read: 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.
RobertDowns >> (All): In response to the comments that the document covers more 
than just preservation, we might consider adding "and stewardship".
BruceAmbacher >> (All): That kind of metric shows multiple statements are 
necessary, they are interrelated but each may be changeable independent of the 
JohnGarrett >> (All): Or we could say it "primarily" deals with preservance (and 
BruceAmbacher >> (All): All phases are equal here.  If you don't have a good 
accessioning policy you don't have anything to preserve.  If you don't have a 
good access/dissemination policy, you preserve for nothing.
BruceAmbacher >> (All): Each type of policy is developed fully later in the 
metrics so we need here to say all aspects must have documented policies and 
procedures.  The heart is a good, strong preservation policy but that does not 
stand alone as the all encompassing principle/practice.
JohnGarrett >> (All): Right, but at the face-to-face, the majority of the group 
wanted to focus strictly on preservation.  But I agree with Bruce.
BruceAmbacher >> (All): I understand that our success ultimately comes down to 
the degree of success we have preserving the bits in an understandable form but 
the other policies need to be articulated.  We need well formed, understandable 
SIPs.  We need procedures to turn the SIPs into AIPs, etc.
Marie Waltz >> (All): So looking at the metric, does it capture what people 
JohnGarrett >> (All): So could a reference in the Discussion to other metrics 
address the concern?
Marie Waltz >> (All): John can you explain what sort of wording you would use?
BruceAmbacher >> (All): Section A is still Organizational Infrastructure.  Each 
section within A deals with a different aspect of organization - governance, 
structure, procedure, finances, contracts.  Does placing all within a 
"Preservation" overstructure change that?
BruceAmbacher >> (All): I don't see Mark's comments in the version I am looking 
at.  Are they only in the text attached to his email?
Marie Waltz >> (All): Yes they are
BruceAmbacher >> (All): Yes they are - what? incorporated into a text or only in 
the attachment?
Marie Waltz >> (All): marks comments on this one was: This section seems to be 
solely concerned with understandability and not the other topics encompassed by 
the metric. It is also very difficult to understand
Marie Waltz >> (All): Mark's comments are in comment boxes, he is mc2.
JohnGarrett >> (All): I didn't have any specific words in mind, just seemed to 
be that others were suggesting that it was covered elsewhere.
BruceAmbacher >> (All): Is everyone comfortable with the change from: 3.3   
uncomfortable with David's mass insertion of "preservation" into every possible 
David Giaretta >> (All): Hi folks - sorry I'm late
Marie Waltz >> (All): Hi David
David Giaretta >> (All): Hi Bruce - it wasn;t just me - other comments suggested 
preservation instead of archiving
KatiaThomaz >> (All): hi david
JohnGarrett >> (All): I don't think Mark's comments are in the full version that 
is on the wiki.  I think there are only in the partial document that Mark sent 
in his email.
David Giaretta >> (All): Yes, my fault - I was including then and was  to upload 
but I got sidetracked before I finished
BruceAmbacher >> (All): David, we are discussing Mark's comment on A3.1
RobertDowns >> (All): To address the comments about the Discussion section of 
3.3.2, perhaps the examples of the designated community definitions can be 
formatted differently to identify as examples, if that is allowed.
Marie Waltz >> (All): It is comment mc62
David Giaretta >> (All): Robert - looks like a format failure on my part in some 
cutting and pasting
David Giaretta >> (All): But the text does seem exclusively focussed on 
understandability - looks as if it could do with some extra text
Marie Waltz >> (All): yes I think it needs more examples, any ideas?
BruceAmbacher >> (All): The discussion is all about usability and access.  It 
does not touch on preservation policy directly.
David Giaretta >> (All): I guess we need an example of an item in a Strategic 
plan and a policy to support it
BruceAmbacher >> (All): What is stated is as applicable to a short term data 
center with no preservation mission as it is to a long term repository with 
preservation as a core part of its mission
RobertDowns >> (All): To address mc63, would it hellp to replace the phrase 
'level of use' with 'level of preservation service'.
David Giaretta >> (All): The understandability could be - Strat Plan - keep data 
understandable >> Policy: maintain RepInfo
BruceAmbacher >> (All): David, would this review process be speeded up if we had 
a version that accepted all minor edits and strikethroughs and just left the 
outstanding comments?
KatiaThomaz >> (All): i think the text vefore face-to-face meeting was: 
Repository has preservation policies in place to dictate how its preservation 
service requirements will be met
BruceAmbacher >> (All): Robert, preservation service does not have to include 
use at all.
David Giaretta >> (All): Bruce - I'll try to accept everything I believe is 
settled but there is a danger I get carried away.
David Giaretta >> (All): Otherwise one can just select the reviewer whose 
comments one wants to see
David Giaretta >> (All): I'll take an action to produce a cleaned up version but 
people should make sure I don't go too far
David Giaretta >> (All): Katia - I was looking at the Glossary - I think we are 
being consistent with that
David Giaretta >> (All): .... in which case we need some examples of items in a 
Pres. Strat.Plan
David Giaretta >> (All): .... and then think of Pres Policies which support them
David Giaretta >> (All): By the way - any discussion on the mandatory 
"Supporting Text"?
David Giaretta >> (All): ...because that could be a big edit
JohnGarrett >> (All): There has been no discussion yet, but I would like to see 
Supporting Text be mandatory.  I think we often include mandatory material 
David Giaretta >> (All): But not all the text there is mandatory
JohnGarrett >> (All): The metric itself is often very terse and a bit more 
detail has been included in the "The repository must ..." statements.
BruceAmbacher >> (All): Should we consider NOT creating an appendix with just 
the metrics or the metrics and supporting text?  Make everyone read the metrics 
in context.
David Giaretta >> (All): ...and we were supposed to encapsulated the point which 
was mandatory in the metric
JohnGarrett >> (All): But that would probably mean we should change the "musts" 
into "shalls" for ISO
BruceAmbacher >> (All): John, what would?
David Giaretta >> (All): Bruce/John - I think "must" is OK but I was thinking 
about editing all the metrics - we agreed with Tom that we could simply say 
"Supporting Text is informative" - otherwise we need to offset it with "NOTE"
David Giaretta >> (All): ...and moving the 1st sentence up into the metric may 
lead to duplication
David Giaretta >> (All): Bruce - I agreee that we need not put in an appendix 
with only the metrics
David Giaretta >> (All): ....but we need to be clear what is mandatory
David Giaretta >> (All): My suggestion was to integrate the 1st sentence of the 
Supporting Text into the metric and leave the rest as informative text
BruceAmbacher >> (All): We are now moving to a style that we did not write the 
document to reflect.  That could require some serious rewriting. with some very 
long metrics.
JohnGarrett >> (All): Bruce, I meant if we made the Supporting Text a mandatory 
section, then we should probably change "The repository must ..." statements to 
"The repository shall ..." statements to ensure that ISO is happier with the 
David Giaretta >> (All): ....that would be consistent and but we would have to 
remove duplications in metrics/1st sentence Supporting Text
BruceAmbacher >> (All): John, I did not realize there was a serious difference 
betwqeen shall and must in ISO parlance
David Giaretta >> (All): John - the CCSDS Pub Manual says "words ‘shall’ and 
‘must’ imply a binding and verifiable specification"
David Giaretta >> (All): ...also in the Nomenclature section
JohnGarrett >> (All): My thought was that we could say the Metric and the 
Supporting Text are mandatory.  The Evidence and Discussion are informative.   I 
thought that would be acceptable to CCSDS/Tom.
David Giaretta >> (All): But most supporting text is explanatory
David Giaretta >> (All): .....only the 1st sentence has "must"
BruceAmbacher >> (All): Do we then have to mark each example and discussion as 
"informative" or can a blanket statement at the beginning cover it?
JohnGarrett >> (All): Yes, the CCSDS Pub Manual says that, but the ISO Pub 
manual says you should use "shall" and should not use "must".  But since it is 
first a CCSDS document, ISO would accept it.
David Giaretta >> (All): Bruce - that was our discussion with the CCSDS editor. 
So we included in "Conventions" a blanket statement
JohnGarrett >> (All): We just need a blanket statement that says what is 
normative and what is informative.  I think only question is if Supporting Text 
is normative or informative.
David Giaretta >> (All): ...that Supporting TExt" "Examples..." and "Discussion" 
are informative
BruceAmbacher >> (All): For ISO what is the difference between shall and must?  
We probably could accept a global replace.
David Giaretta >> (All): John - yes and my only problem is whether what is 
clearly explanatory text can be normative
David Giaretta >> (All): Bruce - sure we could do taht ...carefully!
KatiaThomaz >> (All): I must quit now. Bye and have a nice week.
David Giaretta >> (All): Bye katia
BruceAmbacher >> (All): Mark strongly wanted supporting text incorporated as 
David Giaretta >> (All): Bruce - we can do taht by changing the "Conventions" 
blanket text.
David Giaretta >> (All): ,,,,but what about the explanatory text?
JohnGarrett >> (All): OK, let's have Supporting Text as informative, but then 
make sure all the normative material from supporting text is in the metrics.
David Giaretta >> (All): John - yes I'd go with that
BruceAmbacher >> (All): I still think anyone who only reads the mandatory parts 
is foolish and will have a difficult time implementing the metrics.
JohnGarrett >> (All): I agree.
David Giaretta >> (All): Bruce - absolutely right
JohnGarrett >> (All): But the auditor can point out the error of their ways ;^)
BruceAmbacher >> (All): John your suggestion will increase the verbage in the 
metrics and may mean significant recasting to keep the broader meaning of the 
metric and supporting statements. right?
BruceAmbacher >> (All): Can we send that action back to the section writers to 
do by next week?
David Giaretta >> (All): Bruce - I thought we captured most if not all of the 
1st sentence in the metrics in any case
David Giaretta >> (All): Bruce - - good plan
JohnGarrett >> (All): Possibly, but if there is material we consider mandatory 
in the supporting text (which is informative) it will need to be added as a 
metric or sub-metric.
BruceAmbacher >> (All): David, but is there anything in the rest that should be 
brought into the metric?
BruceAmbacher >> (All): John and I have the same approach/issue/question.
David Giaretta >> (All): Bruce - I guess the guidance is something like "terse 
BruceAmbacher >> (All): I will try to rewrite B2 for next week.
David Giaretta >> (All): ...I guess it's a judgement call but I thought that in 
most cases we are OK
BruceAmbacher >> (All): we very well may be.
BruceAmbacher >> (All): I must leave now - final exams and case studies don't 
grade themselves.
David Giaretta >> (All): So an ACTION on all to update the metrics on the WIki - 
or is WOrd easier?
Marie Waltz >> (All): Word is faster for us, is it a lot more work for you?
BruceAmbacher >> (All): I think a word document is easier for me.
David Giaretta >> (All): Word fine by me
David Giaretta >> (All): ...otherwise I'd only sleep!
David Giaretta >> (All): Great - Bye all
SimonLambert >> (All): bye

-- SimonLambert - 11 May 2009

Topic revision: r1 - 2009-05-11 - 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