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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: =================================================================================== 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: ===================================================================================