RID resolution for Metrics draft

Type of comment

  • T - TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.)
  • R - RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance.
  • E - EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.)

Number Area Type Contact ID Comment Rationale Proposed disposition Disposition rationale
1 P1-4 R banon @dpi .inpe.br INPE-1 From: “TDR” To: “Trusted Digital Repository (TDR)”   Put (TDR) in 2nd para page 1-2 to explain the abbreviation Seems sensible to add a reference.
Note the CCSDS editor removed the footnote which made it clear what TDR meant.
2 P1-4 R banon @dpi .inpe.br INPE-2 Add the definition of “Information Properties” in the glossary. The expression “Information Properties” is used 4.1.1 without definition. Does “Information Properties” means “the properties of the Content Information?” Yes add from OAIS
Information Property : That part of the Content Information as described by the Information Property Description. The detailed expression, or value, of that part of the information content is conveyed by the appropriate parts of the Content Data Object and its Representation Information.

Information Property Description : The description of the Information Property. It is a description of a part of the information content of a Content Information object that is highlighted for a particular purpose.
Seems sensible to add something. But would not like to get into "significant properties" arguments.
3 P3-2 R banon @dpi .inpe.br INPE-3 From: “explicit agreements with successor organizations documenting the measures” To: “explicit agreements with successor trustworthy repository documenting the measures”   Note this is just in the EXAMPLES section
At first sight OK but we need to work on the wording e.g. "one or more successor repositories which are sufficiently trustworthy".
Makes sense - although until lots of repositories are certified then it is difficult to verify the successor is Trustworthy
4 P3-8 E banon @dpi .inpe.br INPE-4 From: “retirement of critical repository software and hardware file retention and” To: “retirement of critical repository software and hardware, file retention and”   OK Seems good English
5 P1-4 R Claude Huc CNES-1 From “The relationship between these terms” to “the repository must carry out.”
It should be added that this is an abstract documentary model that, in reality, can result in different documentary structures, a different distribution of subjects between documents, different document names etc.
The names of the documentary components (Mission statement, Preservation strategic plan, Preservation policy, Preservation implementation plan are not standards for all organizations. The true need is:
1. That the Archive has a structured and hierarchical set of documents,
2. That these documents contain the expected information as defined in the metrics
This is text in a NOTE Not sure exactly what is meant as the change. Ok with the abstract model
6 P1-5 R Claude Huc CNES-2 From “A metric may have one or more sub-metrics”
to “own sub-sub-metrics.” It should be added:
* That the sub-metrics are not supposed to handle all the requirements of the parent metrics,
* That the sub-metrics may introduce some duplication with the parent metrics.
More over, it is suggested to delete the phrase “In some cases these sub-metrics also have their own sub-sub-metrics’ and to use only one hierarchy level.
A metrics hierarchy is relevant because it can be used to define global metrics and identify the crucial issues to be addressed as sub-metrics. However, we think that one hierarchical level should be sufficient.
Using two or even three hierarchical levels is perhaps more satisfactory from a purely logical viewpoint, but this does not facilitate the auditor’s task or the determination of suitable weighted marking.
Agree that we should change "sub-sub-metrics" to "sub-metrics" Not sure exactly what change in text is meant
7   T Claude Huc CNES-3 Add a metric in order to specify that the Repository shall have an ingest process which verify that all the SIPs planned in the submission agreement/contract have been transferred by the Producer. The Repository should also be able to verify that the Producer adheres to the commitments specified in the agreements/deposit contracts. The PAIS draft standard allows for the production of a plan of objects to be transferred. This plan can, for instance, specify that the transfer of this or the other SIP is mandatory. It can also define the number of SIPs that will be transferred, etc. In such a case, the Repository must not only ensure that each SIP transferred is complete and correct, but it must also ensure that all the SIPs expected have been transferred. Accomodate this point by adding clarification to other metrics It is not the fault of the repository if the Producer does not send all the SIPs in a timely manner. What we check is that the repository knows what it has received and can preserve it.
It should know that it has an incomplete set of SIP if that is the case but I think there is a metric that covers that - 4.2.9 and 4.1.7 plus discussion of
Add PAIMAS as abbreviation to words in and add words about possibility of Producer failing to fulfil its submission agreement in 4.1.7 - and add explanation as above i.e.
"It is not the fault of the repository if the Producer does not send all the SIPs in a timely agreed manner. The repository can decide taht an agreement had become moribund in this case"
8 P4-24 R Claude Huc CNES-4` The sub-metric “ The repository shall maintain the associations between its AIPs and their descriptive information over time. » should be removed. The sub-metric is superfluous because identical to 4.5.3 (The repository shall maintain bi-directional linkage between each AIP and its descriptive information) Change 4.5.2 to remove "associate".

Change 4.5.3 "Rep. shall create bi-directional.." then renumber to be 4.5.4 - "maintain bi-direction"
This does look like duplication so we need need to clarify
9 P4-9 and 4-10 R Claude Huc CNES-5 The sub-metrics of 4.2.4 (The repository shall have and use a convention that generates persistent, unique identifiers for all AIPs.)should be re-organized:
- To reduce the number of levels of metrics
- To resolve the following inconsistencies: a sub-metric is supposed to pick out particularly important aspects of the broader parent metric. However, we can observe that :
The sub-metric (The repository shall uniquely identify each AIP within the repository) is related to the fact that the identifiers must be unique.
The sub-sub-metric (The repository shall assign and maintain persistent identifiers of the AIP and its components so as to be unique within the context of the repository.) is related o the fact the identifiers must also be persistent.
The multiplication of levels is here a source of inconsistencies and useless complexity. Maybe? This does look like a good point. I cannot remember why we did this.
10 P4-24 and 4-25 T matt.schultz @meta archive .org META-1 For, From "The repository shall have tools or methods" To "The repository shall have or encourage the use of tools or methods..."
For From "The repository shall have access to..." To "The repository shall have or encourage access to..."
For Supporting Text
From "This is necessary in order to ensure that the repository's digital objects are understandable to the Designated Community"
To "This is necessary in order to ensure that the repository's digital objects are understandable to the Designated Community should they deem it of importance"
In some cases, "dark" archive solutions may choose to be format agnostic, enabling contributing/preserving institutions to make determinations locally about what files and file types they wish to preserve at the bit level. In such cases, the preserving institutions may serve as the Designated Community. They deposit digital objects of multiple formats, some of which may already be obsolete, but for which they have assigned a preservation value for their own designated communities.
A repository such as the MetaArchive Cooperative recognizes that format registries can be valuable but these are a secondary precaution in its bit-level, format agnostic preservation. First and foremost is its mission to preserve any and all collections, regardless of their degree of obsolescence. For that reason it takes a more neutral and encouraging role on behalf of its contributing institutions in respect to such format registry subscriptions. We believe that a format registry should serve as a tool for preservation, not as a barrier to preservation.
The MetaArchive Cooperative supports the practice of identifying the Representation Information of digital objects through validation tools, particularly as a means of verifying submissions with a contributor, but this is something separate from subscribing to format registries. This criteria element conflates the two practices as it moves from onward.

Change "The repository shall have access to the rep info it consiers necessary to make each digital object understandable to the Designated Community"
This appears to be a misreading of the metrics or a misunderstanding of the Designated Community as defined in the OAIS reference model.-- MarkConrad - 01 Feb 2010 For the repository to encourage itself to have access to tools does not make much sense. Nor do these metrics require the use of a format registry.-- MarkConrad - 01 Feb 2010

More importantly it is not up to the Designated Community to decide on whether it is of interest to them to understand the digital objects. It is a committment made by the repository. Also later generations of the DC may decide they do have an interest and if one has not kept up the chain of preservation there would be trouble.
Note we can point out that the repository can provide services in addition to preservation e.g. keep other digital objects for which it does not do full preservation but instead only bit preservation.

The proposed change makes the metric clearer.

Note if bit-level preservation is all that is required then this implies a particular Designated Community and that can be made clear.
11 P5-14, section 5.2.4 R H Kent Hills NASA-1 The offsite information backup and the offsite copy of the recovery plan will be of no use in a catastrophic loss if none of the surviving personnel or successors to the personnel of a repository know where these backup and recovery items are.

This seems to imply the need for registry of such information with: (a) The parent or sponsoring organization; (b) an organization of data repositories; or (c) local and/or national disaster recovery bodies.
Append the comment text to the discussion of 5.2.4
This is a useful additional piece of information for repositories to consider.

-- DavidGiaretta - 29 Jan 2010

Topic attachments
I Attachment History Action Size Date Who Comment
Microsoft Word filedoc 652x0r1candidate-update-typoscorrected.doc r1 manage 318.0 K 2010-05-04 - 18:36 DavidGiaretta Version for ISO review - with correct typos
Microsoft Word filedoc 652x0r1candidate-update.doc r1 manage 317.5 K 2010-02-02 - 16:57 DavidGiaretta Candidate update of the Metrics doc
Microsoft Word filedoc 652x0r1final.doc r1 manage 310.5 K 2010-02-01 - 17:26 DavidGiaretta CCSDS editor's version in Word
Microsoft Word filedoc AuditCertificationTDR-MB-20100201.doc r1 manage 303.0 K 2010-02-01 - 12:36 DavidGiaretta Metrics document with proposed updates based on RIDS
Microsoft Word filedoc RID-disposition-merged.doc r1 manage 70.5 K 2010-02-05 - 19:09 DavidGiaretta RID responses - merged into one file
Microsoft Excel Spreadsheetxls RIDResponses-20100202.xls r1 manage 55.0 K 2010-02-02 - 16:56 DavidGiaretta Spreadsheet of responses ready for mail-merge
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2010-05-04 - 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