CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-001 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-1 PARAGRAPH NUMBER: Sec 1.1 PID SHORT TITLE: Strange use of "organization" and "system" to describe an "archive" ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: An OAIS is an Archive, consisting of an organization, which may be part of a larger organization, of people and systems, that has accepted the responsibility to preserve information and make it available for a Designated Community. To: An OAIS is an Archive System, owned and operated by some organization, composed of systems elements (hardware, software, people, and procedures), that has accepted the responsibility to preserve information and make it available for a Designated Community. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: A widely accepted definition of "system" is that it is composed of hardware, software, people, and procedures. To say that "an archive (system) consists of an organization" is a very peculiar use of common terminology. ------------------------------------------------------------------ DISPOSITION: ALTERNATIVE CHANGES MADE The book uses the term "Archive", rather than "Archive System" because the latter has the implication to many that it is a specific implementation. The view in OAIS is clearly that the implementation may change, indeed will change, over relatively short time intervals and the book clearly states that the reference model "does not specify a design or an implementation". Because of this the suggested text would actually be confusing to the current readership, while on the other hand we do not believe that the existing text would confuse systems engineers. The suggested phrase "owned and operated by some organization" seems to exclude the possibility that the archive is stand-alone. However we do want to include such stand-alone archives, for example those that are independent and obtain funding from many sources. However to clarify the way "organization" is used we suggest making the following change: FROM: An OAIS is an Archive, consisting of an organization, which may be part of a larger organization, of people and systems, that has accepted the responsibility to preserve information and make it available for a Designated Community. TO: An OAIS is an Archive consisting of an organization of people and systems, which has accepted the responsibility to preserve information and make it available for a Designated Community. The organization may be part of a larger organization. Also change the Glossary. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-002 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-2 PARAGRAPH NUMBER: 1.2 PID SHORT TITLE: OAIS is a recommended practice ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: It is specifically applicable to organizations, which may themselves be part of larger organizations, with the responsibility of making information available for the Long Term. To: As a recommended practice it is specifically applicable to organizations with the responsibility for making information available for the Long Term. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: This is a recommended practice and is largely about concepts and procedures. As such it is much more about systems than it is organizations. Also, I find the repetition of "organizations, which may themselves be part of larger organizations" to provide no added value, largely because a) it is repeated here and above, and b) because it is almost tautological. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE See previous RID SEA-650x0-001 (DAI reference http://review.oais.info/show_bug.cgi?id=281) For the 2012 version of OAIS we had RIDS asking us to clarify that an organization could be part of a larger organization. To clarify the way "organization" is used we suggest making the following change: FROM: An OAIS is an Archive, consisting of an organization, which may be part of a larger organization, of people and systems, that has accepted the responsibility to preserve information and make it available for a Designated Community. TO: An OAIS is an Archive consisting of an organization of people and systems, which has accepted the responsibility to preserve information and make it available for a Designated Community. The organization may be part of a larger organization. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-003 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-4 PARAGRAPH NUMBER: 1.5.2 PID SHORT TITLE: Model views are abstractions ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Section 4 provides model views needed for a detailed understanding of an OAIS Archive. It breaks down the OAIS into a number of functional entities and it identifies some high-level services at the interfaces. It also provides information models using Unified Modeling Language (UML) diagrams. To: Section 4 provides model views needed for a detailed understanding of an OAIS Archive. It breaks down the OAIS into a number of abstract functional entities and it describes some abstract high-level services provided at the interfaces of these entities. It also provides abstract information models using Unified Modeling Language (UML) diagrams. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: I think it is useful to be clear that these are abstractions and there is no expectation that they can be directly implemented. This is stated, in different terms, in Sec 1.4. Even with the specific use of abstract, but formal, language for these systems elements there can be no assumption that this is a specification for how to build a system. At best it might become a specification for how to think about designing and building a system. Or evaluating existing systems. ------------------------------------------------------------------ DISPOSITION: AGREED, CHANGE MADE except adding the word "abstract" to "information models" was thought unnecessary. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-004 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-5 PARAGRAPH NUMBER: 1.5.3 PID SHORT TITLE: Strange diagram conventions ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Except where indicated otherwise, diagrams show entities such as people or organizations as round cornered long rectangles, functions as rectangles with round corners and functional entities as rectangles with cut corners, with information between them as arrows, and special information objects as ellipses as illustrated in figure 1-1. To: Except where indicated otherwise, diagrams show entities such as people or organizations as round cornered long rectangles, functions as ovals (ellipses, functional entities as 3-D rectangles, with information flows between them shown as arrows, and special information objects as cut corner rectangles as illustrated in ASL figure 3-1. Organizational domains and data stores may also be represented. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: The ASL is being contemporaneously processed and it covers the OAIS as well as the rest of MOIMS and SOIS. Instead of using a separate, and non-standard, set of representations, which are in some cases hard to understand, I recommend that OAIS adopt the ASL/RASDS representations. It will make understanding all of this much easier. See attached screenshot of ASL Fig 3-1. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE. D AI agreed thatwe should NOT make this change because it will cause confusion for the vast number of people and institutions who have been using the current OAIS diagrams in their own work for the past 20+ years (see https://www.flickr.com/photos/wlef70/8508056502 or https://www.agid.gov.it/sites/default/files/repository_files/documentazione/m-manuale_della_conservazione_-_rev_2.0.2-firmatorg.pdf (page 5) or search for "OAIS Functional Model" in Google). This will particularly apply if we change the use of ovals (ellipses) which currently designate information objects. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-005 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-15 PARAGRAPH NUMBER: 1.6.2 PID SHORT TITLE: Weak definition of semantic information ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Semantic Information: The Representation Information that further describes the meaning of the Data Object beyond that provided by the Structure Information. Structure Information: The Representation Information that imparts meaning about how the Data Object is organized To: Semantic Information: The Representation Information that describes Data Objects using relationships between signifiers—like words, phrases, signs, and symbols—and what they stand for in reality. NOTE: This is distinct from that provided by the Syntax, the Structure Information. Structure information: The set of rules, principles, and processes that govern the syntax of Information. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: The definitions of semantics and syntax, as stated, are weakly specified and somewhat intertwined. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE Rejected because we do not wish to force the definition of Semantic/Structure Information to be too formal. We want to allow Semantic/Structure Information to include a wide variety of possibilities, including a narrative description. Of course having a formal description is advantageous but may not be possible at the early stages of preservation. So when the justification for the changes states that the definitions are "weakly specified" -it should be realized that that is what we need, for very practical reasons - it should be regarded as "broad" rather than weak. The proposed text, puts quite specific constraints on the representation of Semantic Information and restricts its application to specific objects. E.g. semantics could be as well described in an informal way and if we think about archiving music, we will not have any signifiers—like words, phrases, signs, and symbols =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-006 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-12 PARAGRAPH NUMBER: 1.6.2 PID SHORT TITLE: Use of term "metadata" ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Metadata: Data about other data. Representation Information: The information that maps a Data Object into more meaningful concepts so that the Data Object may be understood in ways exemplified by Preservation Objectives. It is a type of Information Object. To: Consistent use of "metadata", or "representation information", i.e. "The information that maps a Data Object into more meaningful concepts", but not both. The definition for Representation information seems to convolve two separate thoughts, 1) "data about data" or some variant of that, and 2) "some exemplification of Preservation Objectives". ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: The term "metadata" is widely used and understood, but it only appears in a couple of places in this document(pg 4-15, 4-33). The two separate thoughts embodied in the current "Representation information" description should probably be sorted out and clarified. They are distinct. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE Rejected. It illustrates the fundamental confusion which is the reason why we severely limit the use of the word "metadata". The point is that "metadata" covers far too many possibilities, not just Representation Information but also Provenance, Fixity, and also MARC records, claims of Authenticity etc etc etc. Before we decided to limit the use of the word "metadata" the confusion wasted years of pointless discussions e.g. Archivists meant things like integrity while Librarians meant things like MARC records, yet they all simply used the word "metadata", and thought they were talking about the same thing. Hence the confusion. One of the aims of OAIS was to define, and use, terms with a much finer granularity than "metadata". =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-007 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 2-5 PARAGRAPH NUMBER: 2.3.1 PID SHORT TITLE: Support for "digital preservation" ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: As digital technology develops, multimedia technology and the dependency on complex interplay between the data and presentation technologies will lead some organizations to require that the look and feel of the original presentation of the information be preserved. This type of preservation requirement may necessitate that the software programs and interfaces used to access the data be preserved. This problem may be further complicated by the proprietary nature of some of the software. Various techniques for preserving the look and feel of information access are currently the subject of research and prototyping. These techniques, which include hardware level emulation, emulation of various common service APIs, and the development of virtual machines, are being investigated for the preservation of the original bit stream and software across technology. To: Some more focused discussion of the nature of digital preservation. This seems to wander off into some techno-weeds. Is it really that case that people want to preserve old IBM 1620 printer data and software? Do we need to create emulators for old Cobol programs and dot matrix printers in order to preserve "information", or will a nice clean, modern print-out do as well (or better)? I can understand the desire to want to preserve and represent all of the subtlety in a painting by one of the old masters (van Gogh, Rembrandt, Michelangelo), or even a new(er) master like Picasso or Pollack. There is subtlety of information in the colors, brush strokes, layers and thickness of paint that even an excellent flat photo cannot capture. But this discussion of hardware emulation seems way off base. NOTE: I did just take my grandson to an excellent museum. These flights of fancy are are derived from that and my own computing experiences from 50+ years ago. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: Re-think whether this paragraph really adds anything or if it misses the mark entirely. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADERejected. It comment seems to be wandering into the area of trying to say what should be preserved. Instead OAIS aims to be useful no matter what is being preserved for whatever reason. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-008 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 2-9 PARAGRAPH NUMBER: 2.4 PID SHORT TITLE: Is "re-perform" really an aspect of digital preservation? ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: – The ability to re-perform an artistic performance. This could be compared with a recording of a previous performance. To: [NULL] ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: Is the ability to "re-perform an artistic piece", presumably with different musicians, actors, or dancers, really an instance of "digital preservation"? No argument with the value of preserving images, movies, and/or recordings of such artistic endeavors, but is "re-performance" really an aspect of preservation? ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE Rejected. The supporting analysis asks: 'is "re-performance" really an aspect of preservation?' Enabling re-performance is a valid aim of preservation, in arts as well as science. OAIS is not aimed at judging what should be preserved. The point here is that someone want to preserve the information encoded in digital objects which should allow the work to be performed. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-009 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 2-11 PARAGRAPH NUMBER: 2.5.3 PID SHORT TITLE: Submission Information Schema? ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: The Submission Agreement will normally specify its data model by creating a submission information schema. The submission information schema formally defines the digital information objects to be transferred by an information Producer to an Archive and how these objects are packed in the form of Submission Information Packages (SIPs). To: The Submission Agreement will normally specify its data model by creating a Submission Information Schema. The Submission Information Schema (defined in sec ???) formally defines the digital information objects to be transferred by an information Producer to an Archive and how these objects are packed in the form of Submission Information Packages (SIPs). ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: This section introduces the term Submission Information Schema, and states that it has a formal definition and is "normally" used in the SA, but it neither defines this SIS (even abstractly) nor makes further reference to it. if this is a formal definition that is normally part of an SA it should be defined somewhere. The same situation seems to obtain for "dissemination information schema" in the following sec 2.5.4. ------------------------------------------------------------------ DISPOSITION: ALTERNATIVE CHANGE MADE. The change removes the word "schema": From: The Submission Agreement will normally specify its data model by creating a submission information schema. The submission information schema formally defines the digital information objects to be transferred by an information Producer to an Archive and how these objects are packed in the form of Submission Information Packages (SIPs). To: The Submission Agreement will normally include a detailed description of the Submission Information Package(s) (SIP). The description formally defines the digital information objects to be transferred by an information Producer to an Archive and how these objects are packed in the form of Submission Information Packages. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-010 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 3-4 PARAGRAPH NUMBER: 3.3.4 PID SHORT TITLE: Designated Community terminology ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: For some scientific information, the Designated Community of Consumers might be described as those with a first-year graduate level education in a related scientific discipline. This is a more difficult case as it is less clear what degree of specialized scientific terminology might actually be acceptable. The Producers of such specialized information are often familiar with a narrowly recognized set of terminology, so it is especially critical to clearly define the Designated Community for that information and to make the effort to ensure that this community can understand the information. To: This section really seems to beg the question of just how the terminology in any given designated community is defined and managed. Isn't this terminology itself an archivable information object? Doesn't it need to be established, and curated? Isn't this every bit as important as the "specialized information" itself, since it is part of the semantics that support understanding. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: Consider if something further needs to be stated about "designated community" terminology in the basic sense and if it (the definitions of the semantics) needs to be archived along with the data itself. This comes up again on pg 3-5 in sec 3.3.5. But perhaps you think of this is another form of Representation Information? If so, that should be clarified. ------------------------------------------------------------------ DISPOSITION: CHANGE MADE as follows: It would be better to add this group of bullets as a new section 2.5. We believe that all the concepts have been mentioned before this, as follows: 2.5 Supplementary Information Held by the Archive The archive will need to preserve many pieces of information besides the AIPs. The following lists show items mentioned in this document, but the archive may preserve other items. As long as the objects are being preserved by the archive the following should also be preserved: • Definition of the Designated Communities • Preservation Objectives • Transformational Information Properties For as long as any specific AIP structure is in use: • Packaging Information for the AIPs. • Relationship between Editions and Versions of AIPs Other information may be useful while the various services are in use • Finding, Ordering, and Retrieval Aids • Packaging Information for SIPs, DIPs =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-011 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 4-1 PARAGRAPH NUMBER: 4.2.1, Figure 4-1 PID SHORT TITLE: Meanings of lines on Fig 4-1 ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Figure 4-1 shows a set of functional entities, information objects, and two organizational entities. It also has three separate kinds of "connecting lines", and it says "The lines connecting entities identify communication paths over which information flows. The lines to Administration and Preservation Planning are dashed only to reduce diagram clutter." But there is a third kind of line besides those with arrows and those dashed ones, and those are the thin lines from Producer and Consumer to Admin and Preservation Planning. Are these intended as flows of some sort or are they something else? To: Clean up this diagram, and others, as requested in SEA-650x0-004. Clarify if there are two, or three, kinds of flows and label them appropriately. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: The inclusion of extra, unlabelled, lines in this diagram that have no stated purpose nor type is confusing. ------------------------------------------------------------------ DISPOSITION: CHANGE MADE: Make the thin lines as double ended arrows. Add text saying these flows are shown in more detail in figures in section 4. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-012 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 4-3 PARAGRAPH NUMBER: 4.2.2.2 PID SHORT TITLE: Common "Services", or just functions, and what about more formal OAIS services? ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: This entire section describes what are called "Common Services". The term is used elsewhere in the document as well. In sec 1.6.2 you say "In other CCSDS documents the terms such as ‘service’ and ‘object’ have different definitions from those used here.", but then you do not define "service" except in context, as in, on pg 1-8, "Access Functional Entity: The OAIS functional entity that provides the services and functions that support Consumers". So all of the OAIS functional entities provide "services". This seems to align well enough with the definition of "service" from MOS (A software application that uses a being supplied by a being supplied by a service provider. An individual software application can act as the consumer of multiple services.. An individual software application can act as the consumer of multiple services.) or, more abstractly, from RASDS "A provision of an interface of an object to support actions of another object.". SLE & CSTS use similar definitions. To: Calling all of these Operating System, Network, and Security functions "services" seems to diminish the meaning of the word "service" as applied to the OAIS functional entity services. I would think that you would want to emphasize the role that these Functional Entity services play in the OAIS and to define clearly the nature of their service interfaces, even if only abstractly. This is just a Reference Model, so you are not going to define service interfaces formally, but even some abstract specification, such as those in the RASIM, CCSDS 312.0-G-1, Sec 3 & 4, could be useful in conveying what you have in mind for these OAIS service interfaces. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: Treating OS functions in the same way as OAIS services weakens their status. Failing to provide even some abstract formalism for these important, exposed, OAIS service interfaces does likewise. Note that this is not asking to define the internal service interfaces in a formal way, just the external ones exposed to the "users". ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE The supporting analysis says 'seems to diminish the meaning of the word "service"'. However that is like saying that using the word "building" for both the Taj Mahal as well as for my garden shed diminishes the Taj Mahal. What makes the difference is surely the additional description of the objects. The DAI agreed to reject this change. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-013 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 4-5 PARAGRAPH NUMBER: 4.2.2.3, fig 4-2 PID SHORT TITLE: Meaning of figures are not as clear as they could be ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Fig 1-1 defines diagram conventions. Figure 4-2 includes four primary kinds of objects: "entities" (Producer), "Functional Entities" (Data Management), "Functions" (Generate AIP, QA), and "special information", or data objects, (just named). I believe it is the case that the Functions on this diagram are "inside" the Ingest Functional Entity, and that the other Functional Entities, like Data Management" are "outside" the Ingest Functional Entity, but this is not evident from the diagram and it is easy to get confused. To: See earlier request, in SEA-650x0-004, to adopt a clearer diagramming convention. At the minimum redraw this diagram, and all of the others in this section, to show these "Functions" that are inside the Ingest Functional Entity, as actually being inside the "Ingest" box (a "white box" diagram) and that the other Functional Entities, and "entities" like "Producer", are actually outside this Entity. Consistent use of the color codes that are introduced here, both dealing with "what's inside the box", and throughout the document, would improve clarity. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: In this set of diagrams it is really easy to overlook the rather subtle distinctions between the clipped corners and rounded corners of different boxes. The use of different colors helps, but even there an opportunity for consistence was missed. For instance, the "Function" color codes (orange, yellow, green, ...)introduced here in these white box diagrams could also be applied to the Functional Entities themselves, on "black box" diagrams like Fig 4-1 (and others). It's a little thing, but that way the color codes would be consistent throughout and actually help to convey meaning. ------------------------------------------------------------------ DISPOSITION: Agreed that we update figures to have consistent colours and add short explanation in section 1.5.3, but the document does not rely on the colours. Append to section 1.5.3: Suggestions for text will be added as comments to get agreement. To serve as visual clues, consistent colors have been adopted for each Functional Entity and its component Functions, however the diagrams do not depend upon these colors. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-014 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 6-9 PARAGRAPH NUMBER: 6.2.6 PID SHORT TITLE: No viable definition of Registry ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: In Sec 6.2.6, "Archives with Shared Resources, the term "registry" is used, as in: "Additional potential shared services include registries of Representation Information and name resolvers such as the DNS. In the former case a registry of Representation Information should also be an OAIS and the Representation Information it holds should be part of the Content Information it holds. The Representation Information it holds might, for example, be part of the Representation Information Network for the Content Information within an AIP in another OAIS. In such a case the OAIS holding that AIP may cache copies of the Representation Information Network held in the registry. Whether it does so or instead relies on the registry to maintain the Representation Information Network, the ultimate responsibility for the understandability of the Content Information remains with the OAIS which holds the AIP." To: Define the term "registry" in a formal way. Provide an abstract model of what a "registry" object is and what sorts of abstract interfaces it provides. It is recommended to use the definitions that appear in the Reference Architecture for Space Information Management (RASIM), CCSDS 312.0-G-1. Furthermore, it is recommended that the interfaces throughout Sec 6 (and Sec 4), where they reference the kinds of functionality associated with a Registry adopt this terminology in a consistent way for clarity. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact _X_ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: In this section which addresses "Archive Interoperability" it would be ideal if a more formal set of definitions for registry, repository, query, and producer objects were used and if a set of clear, if abstract, interface definitions were provided. The RASIM provides a clear set of abstract definitions for such functional objects as well as recipes for combining them to build information management systems. These could be put into an annex and referenced here. The same situation occurs in re "repository" (see SEA-650x0-015). It is also the case that none of the other documents in this series, OAIS (650.0), PAIS (651.0), nor TDR (652.0)provide any sort of concrete definitions for these fundamental building blocks for information management systems and their interfaces. Note that use of such abstract service interfaces is not the same as providing anything like a concrete interface spec or technology binding. The treatment would still be abstract, and open to a separate transformation into interoperable designs, but it would be a whole lot clearer. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE Our position is that a formal definition is not needed for a word that is used minimally (only used 3 times in one paragraph) and in this case the common English usage is preferred. We want to wait until OAIS-IF defines it because we want to ensure that the definition we provide is correct for that future application. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-015 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 6-11 PARAGRAPH NUMBER: 6.2.7 PID SHORT TITLE: No viable definition of Repository ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: In Sec 6.2.7, "Archives with Distributed Functionality" the term "repository" is used, as in: It is possible that development of these agreements and oversight of the results might be accomplished more easily and more reliably with another OAIS. For example, oversight and monitoring of the OAIS providing the service could be simplified by requiring the OAIS be certified as a Trustworthy Digital Repository in accordance with the metrics specified by CCSDS 652.0 (also known as ISO 16363) and the procedures specified in CCSDS 652.1 (also known as ISO 16919). To: Define the term "repository" in a formal way. Provide an abstract model of what a "repository" object is and what sorts of abstract interfaces it provides. It is recommended to use the definitions that appear in the Reference Architecture for Space Information Management (RASIM), CCSDS 312.0-G-1. Furthermore, it is recommended that the interfaces throughout Sec 6 (and Sec 4), where they reference the kinds of functionality associated with a Repository adopt this terminology in a consistent way for clarity. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact _X_ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: In this section which addresses "Distributed Functionality" it would be ideal if a more formal set of definitions for registry, repository, query, and producer objects were used and if a set of clear if abstract, interface definitions were provided. The RASIM provides a clear set of abstract definitions for such functional objects as well as recipes for combining them to build information management systems. The same situation occurs in re "registry" (see SEA-650x0-014). It is also the case that none of the other documents in this series, OAIS (650.0), PAIS (651.0), nor TDR (652.0)provide any sort of concrete definitions for these fundamental, and essential, building blocks for information management systems and their interfaces. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE Our position is that a formal definition is not needed for words that are used minimally and in these cases the common English usage is preferred. We want to wait until OAIS-IF defines them because we want to ensure that the definition we provide is correct for that future application. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-016 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 4-1 PARAGRAPH NUMBER: 4.2.1, Fig 4-1 PID SHORT TITLE: All of these Functional Entities need better definitions and interfaces ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: The definitions throughout this section 4, for "functional entities", make continual references to "query", "storage", "submission", "provide", "database", but no even semi-formal definitions of any of these terms are provided. "The purpose of this section is to provide a more detailed model view of the functional entities of the OAIS and the information handled by the OAIS. This aids OAIS designers of future systems and provides a more precise set of terms and concepts for discussion of current systems." Furthermore, a "detailed model view" of these functional entities would be vastly improved by the use of the "registry", "repository", "query", and "product" service building blocks defined within the Reference Architecture for Space Information Management (RASIM), CCSDS 312.0-G-1. To: Define these "OAIS Functional Entities" in a more formal way. It is recommended to use the definitions that appear in the Reference Architecture for Space Information Management (RASIM), CCSDS 312.0-G-1. All of the functions in this section can be composed of these building blocks, and the associated abstract interfaces would vastly improve comprehensibility of what is really the intended functionality of these entities. Furthermore, it is recommended that the interfaces throughout Sec 4, where they reference the kinds of functionality associated with "registry", "repository", "query", and "product" service objects adopt this terminology in a consistent way for clarity. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact _X_ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: In this section which addresses OAIS Functional Entities would be vastly improved if a more formal set of definitions for registry, repository, query, and product service objects were used and if a set of clear if abstract, interface definitions were provided. The RASIM provides a clear set of abstract definitions for such functional objects as well as recipes for combining them to build information management systems. Even though this is a Magenta Book, and as such describes entities in the abstract, these can be described in much clearer and more explanatory ways by referencing the RASIM abstract building block definitions and service interfaces. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE Our position is that a formal definition is not needed for words that are used minimally and in these cases the common English usage is preferred. We want to wait until OAIS-IF to define them because we want to ensure that the definition we provide is correct for that future application. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-017 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 5-11 PARAGRAPH NUMBER: 5.3.1 PID SHORT TITLE: Representation Information Network or Semantic Information Network? ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: This section talks about "representation information network" and adding it to Content Data Objects. It also references semantic as well as structure information. I went looking for references for "representation information network" and came up pretty empty handed, but find lost of references for "semantic information network". I am wondering why this pretty well understood field of knowledge management was overlooked. To: Suggest that the team look at their use of the term "representation information network" and see if the body of work covered by "semantic information network" shouldn't be addressed or leveraged in some way. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: It feels as though a rather well known set of terms in knowledge management has been overlooked in favor of a locally defined term. It is not clear that this is the best possible approach. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE A "representation information network" is much more than "semantic information network". It can include, as part of the network, Semantic RepInfo, Structure RepInfo and Other RepInfo. For example it includes software and the libraries and operating system it depends on, also file formats etc, as well as semantic information such as ontologies, data dictionaries and relationships. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-018 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 4-37 PARAGRAPH NUMBER: 4.3.3.3 PID SHORT TITLE: Type of Information Packages ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: This section talks about "information Packages" and the different kinds that might exist. These are all discussed very much in the abstract, using somewhat vague terms: "There are several types of Information Packages that are used within the archival process. These Information Packages may be used to structure and store the OAIS holdings; to transport the required information from the Producer to the OAIS, or to transport requested information between the OAIS and Consumers. There are differing information requirements for each of these functions. It is necessary to distinguish between an Information Package that is preserved by an OAIS (an Archival Information Package) and the Information Packages that are used to transport requested information from the Producer to an OAIS (a Submission Information Package), and those that are used to transport requested information from an OAIS to the Consumers (a Dissemination Information Package). Although these are all Information Packages, they differ in mandatory content and the multiplicity of the associations among contained classes." To: Presumably any system that adopts this OAIS approach, and attempts to "conform" to it, will need to define the kinds, syntax and semantics of the information packages that it uses. Shouldn't there be reference made to the need to do this and to a registry of such packages and a repository where they are stored? Isn't this essentially one of the "meta" functions of an open archive system? ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: This is just one of the types of registries that seem to be appropriate as "meta" functional objects in an Open Archive System. A registry of package formats, for SIP, AIP, DIP, AIU, and PDI is another. A registry of Finding, Ordering, and Retrieval Aids is another. ------------------------------------------------------------------ DISPOSITION: CHANGE MADE ALREADY Resolved this in SC290 (SEA-650x0-010) so this item can be closed with no further change needed. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-019 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 5-1 PARAGRAPH NUMBER: 5.1 PID SHORT TITLE: Systems & software evolution and "bit rot" ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: This section talks about the issues of "irreversible loss of data", i.e. "bit rot" and it's relationship to storage media and software longevity. "Today’s digital data storage media can typically be kept at most a few decades before the probability of irreversible loss of data becomes too high to ignore. Further, the rapid pace of technology evolution makes many systems much less cost-effective after only a few years. Even more daunting, as operating systems evolve, is maintenance of operational software as a part of the Representation Information, which is essential for the preservation of Content Information." To: It is axiomatic that operating systems and software have to evolve or "die", i.e. lose their efficacy. And we all know that digital media and the devices that read them are among the most fragile, and fungible parts of any system. But from reading this it seems that the ability to provide formal descriptions of data formats that will allow data to be recovered from still viable media, even if the original software has rotted away, is missing or not emphasized at all. I suggest that this aspect of data preservation be explored in more depth. Much in the same way that the Nav WG data format standards allow different software, written in different languages, running on different operating systems, to be exchanged. Data preservation should consider such practices rather than archiving old software and hoping that this will continue to run in the future. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: This is just one of the types of data preservation that seems to be overlooked in this document. Or maybe it is in here, as some aspect of "migration" and I just do not recognize it. ------------------------------------------------------------------ DISPOSITION: ALTERNATIVE CHANGE MADE From: The fast-changing nature of the computer industry and the ephemeral nature of electronic data storage media are at odds with the key purpose of an OAIS: to preserve information over a long period of time. Today’s digital data storage media can typically be kept at most a few decades before the probability of irreversible loss of data becomes too high to ignore. Further, the rapid pace of technology evolution makes many systems much less cost-effective after only a few years. Even more daunting, as operating systems evolve, is maintenance of operational software as a part of the Representation Information, which is essential for the preservation of Content Information. In addition to the technology changes there will be changes to the Knowledge Base of the Designated Community which will affect the Representation Information needed. To: Despite the efforts (e.g. making use of standardized data formats that are expected to be used for a time) of an OAIS to make information it holds to be relevant for the long-term, it is inevitable that at some point, OAIS holdings will need to be addressed to ensure they are usable to future generations. Even more so the fast-changing nature of the computer industry and the ephemeral nature of electronic data storage media are at odds with the key purpose of an OAIS: to preserve information over a long period of time. Today’s digital data storage media can typically be kept at most a few decades before the probability of irreversible loss of data becomes too high to ignore. Further, the rapid pace of technology evolution makes many systems much less cost-effective after only a few years. Even more daunting, as operating systems evolve, is maintenance of operational software as a part of the Representation Information, which can be used by the Designated Community to use the Content Data Object. These additional preservation strategies are discussed below in section 5.3. In addition to the technology changes there will be changes to the Knowledge Base of the Designated Community which will affect the Representation Information needed. In section 5.3.1 we should append: "Structure Information, with the Semantic Information could allow one to create new software to access elements from a Digital Object, so that one does not have to rely on maintaining old software." =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-020 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 6-2 PARAGRAPH NUMBER: 6.2 PID SHORT TITLE: OAIS Interaction Requirements ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: This section talks about the issues of "OAIS archive interoperability", i.e. how might one archive interoperate with another. "Each time the OAIS exchanges data with another organization the agreements include: – the protocol(s) to be used in the transfer, for example, TCP/IP, HTTP, USB memory stick, etc.; – the interfaces to use; – the definition of the packages (SIP/DIP/AIP) transferred; – the processes which the sending and receiving organizations should follow. These agreements may include standards (current or future standards that will be developed which will specify these agreements and processes). The type and extent of these agreements and the level of formality of the agreements can be the basis of categorizing these interactions. " To: To a great extent this section seems to cast the discussion of archive interoperability in terms of "organizations" and "agreements". The list of technical concerns that would support interoperability, namely: protocols (mostly network & application layer are named), interfaces, definitions of packages, processes, but also processes is necessary, but not sufficient. And the "conformance" points that are used do not cover any topics related to interoperability. The document is truly silent on this subject and avoids even the abstract discussion of these key topics. What is also missing is any attention paid to how these archives might provide any sort of common means for discovering which variations of these systems features that have been employed, how to document the protocols, interfaces, data packages, query (and product, report, etc) interfaces that are available. A common way for documenting these interfaces and discovering them could be provided. Even without providing a way to migrate to common interface and protocols forms, where this is possible, such a "meta" framework might prove really valuable. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: An approach that covers the functional model, and information models, in Sec 6, and which is rather more comprehensive, even if it is still abstract and not directly implementable, would be a real improvement over what has been attempted so far. This could start to provide a real interoperability framework for disparate archives. ------------------------------------------------------------------ DISPOSITION: ALTERNATIVE CHANGE MADE The section aims to address overall organizational issues of interoperability rather than detailed technical ones. This approach gives guidance on the type of organizational issues which archives need to address before starting to look at the technical issues. We have emphasized throughout that OAIS is not meant as a design. However we can put in a reference to the Roadmap in ANNEX B, which leads on to Steve's documents by adding the following text after the bullet points: "Standards which address several of these issues are noted in the Roadmap in Annex B." =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-021 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 6-9 & 6-10 PARAGRAPH NUMBER: 6.2.6 & 6.2.7 PID SHORT TITLE: Shared and Distributed Resources ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: "Sec 6.2.6 Figure 6-4 illustrates the sharing of a common storage function, consisting of an Archival Storage Functional Entity and a Data Management Functional Entity, between two Archives, OAIS 1 and OAIS 2. The Access and Ingest facilities can be at any of the previously described levels of inter-operability. In fact, each Archive can serve totally independent communities as implied in this figure. However, for the common storage element to succeed, standards are needed at the internal Ingest-storage and Access-storage interfaces." "Sec 6.2.7 Such a distribution of functional areas or functional entities of an OAIS, as well as their composition into distributed OAIS, can be, for example, of a physical, organizational, or administrative nature. The motivation could be to distribute resources to achieve the complete set of functional entities or functional areas to establish a distributed OAIS in a complementary and collaborative way. Other motivation factors can be to mitigate risks or outsource parts of the OAIS in a way that enables the OAIS to remain an OAIS. " To: The discussion in these sections is philosophically accurate, but provides the reader with little in the way of leverage except conceptually. If, following some of the other recommendations in the set of RIDs, even a set of abstract services were identified, along with a clear discussion of the functions of query interfaces, and of a suitable set of registries and repositories, a much more compelling picture of how these shared and distributed resources could interoperate could be presented. This is viable even in the abstract as long as clear requirements are stated for compatible and interoperable service interfaces on these different types of Functional Entities. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: An approach like this, which is rather more challenging than what has been attempted so far, could start to provide a real interoperability framework for federated and distributed archives. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE The current OAIS document is not intended to be a design document (even for an abstract design). The DAI WG has begun work on the suite of standards that will form the OAIS-Interoperability Framework and we will be addressing this issue in those standards. Since the OAIS RM is not a design document and since the OAIS-IF is addressing these issues, we reject any update to the current document. However, we do agree that these issues should be addressed and we intend to address them in the OAIS-IF efforts as quickly as possible given our current resources. There is a Roadmap in ANNEX B which describes OAIS-IF. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-022 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: A-1 PARAGRAPH NUMBER: Figure A-1 PID SHORT TITLE: Use, features, and position of Fig A-1 ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: Figure A-1, which shows all of the major Functional Entities, their interfaces, their decomposition into Functions, and suitable color coding would be better placed much earlier in the document. Similarly, the color coding used here, and in Sec 4, would be better if introduced earlier and used consistently. Even a "lower resolution", "black box" version like this, with the same color coding and aggregated flows would be an improvement over what is there now. To: Move this figure into Sec 4, to replace / augment Fig 4-1 (maybe in a lower resolution form as a new 4-2). This would help to tie the entire discussion in Sec 4 together and lend greater coherence. Also, introduce the concept of these query, registry, repository, product interfaces early on in Sec 4 and show where there is commonality in interfaces and functions on this diagram. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: These recommended changes will require some amount of work, but they will also make the document much more informative and useful. As it is now it is more descriptive, using lots of words, than it is prescriptive. The document could be moved in a more prescriptive direction while still dealing in abstractions and not directly implementable formalisms. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE The supporting text says: "The document could be moved in a more prescriptive direction". We do not believe that it would be sensible to do this. We did not mention colors in the Functional Model diagram because of comments during the development of the 2012 version of OAIS. We do not think that A-1 diagram should be moved to section 4. That would make it look as if OAIS is a prescriptive design for an archive instantiation, which we state elsewhere in the document that it is NOT, and it would make the document more difficult to read. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-023 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: C-1 PARAGRAPH NUMBER: Figure C-1 PID SHORT TITLE: UML Diagram description ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: "A key to object relationships in the UML diagrams of 4.3 in this document is shown in figure C 1." and ... "A Class is indicated by a rectangle containing the Class name. The UML representation of a class is a three-compartment rectangle with name in the top compartment attributes in the second compartment and methods in the lowest compartment. In this document the attributes and operations compartments are always empty and UML states empty compartments can be suppressed." To: Other WGs use similar subsets of UML for various diagrams. The SM WG uses UML Class diagrams, but includes the attributes and operations compartments. Given some of the other discussions in this set of RIDs some more extensive use of such practices might be adopted to good purpose. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: I like the use of UML and the inclusion of this brief introduction in the document. But I think that the addition of more specificity in these diagrams, such as adding at least operations, if not attributes, would make the descriptions even clearer. ------------------------------------------------------------------ DISPOSITION: NO CHANGE MADE We do not think that the suggested change would be helpful. OAIS is not a detailed design document. The supporting analysis says "adding at least operations" would be helpful. We believe that (1) it would over complicate the diagrams (2) adding the various get/set/put/ etc for the objects that are shown in the UML diagrams are pretty obvious and do not need to be made explicit (3) we have not analyzed all the operations The forthcoming documents on OAIS Interoperability Framework is the appropriate document to include that level of detail. =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-024 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 1-3 PARAGRAPH NUMBER: Sec 1.4 PID SHORT TITLE: Notions of "Conformance" are weak ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: "A conforming OAIS Archive implementation shall support the model of information described in 2.3. The OAIS Reference Model does not define or require any particular method of implementation of these concepts. A conforming OAIS Archive shall fulfill the responsibilities listed in 3.2. Subsection 3.3 provides examples of the mechanisms that may be used to discharge the responsibilities identified in 3.2. These mechanisms are not required for conformance. A conformant OAIS Archive may provide additional services that are beyond those required of an OAIS." To: In this reference model the only aspects that are identified as being important for "conformance" are the sec 2.3 information model, which is so simple in its form (fig 2-2) that almost anything that talks about "information" would be compliant. The other conformance point is sec 3.2 which addresses organizational responsibilities having to do with accepting, controlling, preserving, and providing access to data. These both use "shall" language, so it is fair to say that they are requirements, but they appear to be of limited utility in terms of understanding anything about what an Open Archive Information System is, with emphasis on the "system" part, how one ought to operate, what one ought to do, or how one might be designed. There are very few other uses of "shall" in the document and none that directly relate to any of the elements in sec 4, which forms the Functional Model and Information Model heart of the document, 56 out of a total of 150 pages, many of which are "boiler plate". Recommend adding conformance with the key section (sec 4) of the document and also the other, related, edits identified elsewhere in this set of RIDs. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: The idea of "conformance with requirements" given the extremely vague language in sec 2.3 and 3.2 seems disjoint with the usual CCSDS notions of conformance, even with regard to reference models. There are materials in this document which could supply a much stronger framework for conformance, especially if the changes requested elsewhere in this set of RIDs are adopted. Even in their absence, requiring conformance also with Sec 4 would provide a much stronger "compliance" test than just sec 2.3 and 3.2. The weak nature of "conformance", as specified, is further called into suspicion when there is language like this in Sec 6.2.7, pg 6-12: "It should be noted that in the example and elsewhere whenever something is named as an OAIS, it is expected that anything that is spoken about as an OAIS conforms to the full suite of OAIS criteria specified in the conformance subsection (1.4)." That phrase "conforms to the full suite of OAIS criteria" sounds really strong, but in reality it is not. ------------------------------------------------------------------ DISPOSITION: ALTERNATIVE CHANGE MADE Reject the recommendation of adding conformance with the key section (sec 4) of the document and also the other, related, edits identified elsewhere in this set of RIDs. The Functional Model has always been excluded from the conformance statement because OAIS is not a design document. We think the use of the conformance section has been very useful in the reference model as it stands. The "To:" text in this RID is obviously not seriously being proposed. However this comment suggests to me that it might be useful to change From: "A conforming OAIS Archive implementation shall support the model of information described in 2.3. The OAIS Reference Model does not define or require any particular method of implementation of these concepts." To: "A conforming OAIS Archive implementation shall support, and be able to map to the components of, the model of information described in 2.3. The OAIS Reference Model does not define or require any particular method of implementation of these concepts." =================================================================================== AREA PID NUMBER:SEA-650x0-025 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: 3-1 PARAGRAPH NUMBER: Sec 3.2 PID SHORT TITLE: Inadequate coverage of security topics ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: This subsection establishes mandatory responsibilities that an organization must discharge in order to operate an OAIS Archive. To: This subsection establishes mandatory responsibilities that an organization must discharge in order to operate an OAIS Archive. Augment this section to cover this topic: The document has some cursory attribution to security requirements: access control, authentication, confidentiality, integrity, and non-repudiation. This was in section 4.2.2.2 - Common Services and appeared in the Network Services and the Security Services sections. That being said, there was no in-depth discussion of any of the security services or specification of their application in the model. But the requirements are listed in Section 3.2 and there are no security requirements. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: Coverage of security topics, for all archives in general, and for federated archives in particular, should be identified as required practices. See also SEA-650x0-026. ------------------------------------------------------------------ DISPOSITION: We recognize the importance of security in archival applications, but we do not wish to put in a great deal about it in the body of the document beyond that which is already there. We will cover this topic in more detail in the OAIS-IF documents mentioned in the Roadmap in Annex B, which will take detailed advice from security experts. However we realize that it would be helpful to put a reference to the security Annex in the relevant overview sections in order to remind readers of its importance. Append to section 3.1: "Annex F discusses security considerations which may apply to section 3.3." Note that Annex F states: "Communications between the Archive and Producer may require additional safeguards such as electronic signatures and/or digests.", which covers the point made about transfers. Note also that ANNEX F has a typo in the last bullet - it should be moved up a level and then the sub-bullet should begin "Implementations of Dissemination Information Packages" Insert after para 3 in 6.2.1 "Annex F discusses security considerations which may apply to interacting OAISes, which are described below." =================================================================================== CESG POLL ITEM DISPOSITION (PID) INITIATION FORM AREA PID NUMBER:SEA-650x0-026 SUBMITTING AREA: SEA ------------------------------------------------------------------ REVIEWER'S NAME: Peter Shames E-MAIL ADDRESS: peter.m.shames@jpl.nasa.gov ------------------------------------------------------------------ DOCUMENT NUMBER: CCSDS 650.0-P-2.0 DOCUMENT NAME: OAIS Reference Model DATE ISSUED: December 2019 PAGE NUMBER: F-1 PARAGRAPH NUMBER: Annex F PID SHORT TITLE: Inadequate coverage of security topics, redux ------------------------------------------------------------------ DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) From: To be conformant to this Reference Model an implementation should use the Information Model and follow the mandatory requirements in 3.2; therefore, the following annotations on those mandatory requirements provide some guidance on security concerns. To: The security section was quite well done, but did not cover certain topics. Of particular concern is the there is no mention of security concerns related to logical access control at the interfaces, but physical access is addressed. And there is little mention anywhere of providing adequate measures to ensure the integrity of the data, either at ingest, at rest, or in transit to the users (or other archives). There is also no mention of any specific security concerns needed for the kinds of cooperating or federated archives conceived of in Sec 6.2. Moreover, my suggestion is that they need to include the information contained in the security section back in the "meat" of the document and not just leave it as an "orphan" in the security section. The security section should be a synopsis of the security services/mechanisms contained in the document and not be the first time they are exposed. The security section does follow the requirements listed in Section 3.2, but in 3.2 there is are no security requirements other than authenticity of the data received for archiving. ------------------------------------------------------------------ CATEGORY OF REQUESTED CHANGE: Technical Fact ___ Recommended _X_ Editorial ___ NOTES: TECHNICAL FACT: Major technical change of sufficient magnitude as to render the Recommendation inaccurate and unacceptable if not corrected. (Supporting analysis/rationale is essential.) RECOMMENDED: Change of a nature that would, if incorporated, produce a marked improvement in document quality and acceptance. EDITORIAL: Typographical or other factual error needing correction. (This type of change will be made without feedback to submitter.) ------------------------------------------------------------------ SUPPORTING ANALYSIS: Coverage of security topics, for all archives in general, and for cooperating and federated archives in particular, should be identified as required practices. See also SEA-650x0-025. ------------------------------------------------------------------ DISPOSITION: CHANGE MADE in SEA-650x0-025 ===================================================================================