<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:753865840;
mso-list-type:hybrid;
mso-list-template-ids:-1083905852 281173484 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1392848598;
mso-list-template-ids:-304840348;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Dear all,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Sorry, I won’t be on the webex tomorrow.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I expect you’ll continue on with discussions from last week, so I’ll try to get some of my comments sent.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>My view is that an OAIS repository needs to preserve a lot of things. However, we also should remain cognizant that all the information that is being preserved is being preserved to support the preservation of the Content Data Object that was identified as the target of the preservation effort.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>If we are not preserving a particular Content Data Object, then there is no need to preserve any of the supporting information. If no CDO, then you don’t need RepInfo Network to understand it. If there is no CDO, you don’t need any fixity information to ensure it isn’t changing. OK maybe if you discard a CDO you may be useful for the archive to keep some provenance info for its deletion, but that is an edge case and you wouldn’t have Provenance Info if you never tried to preserve the CDO.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I also agree that you can use the same OAIS Information Package model to preserve any type of data object whether it be a CDO that is an actual target of preservation (in terms of the mission of the archive and what the Designated Community is expecting the OAIS to preserve. A Science Data Archive probably has a mission to preserve science data. It doesn’t have a direct mission to preserve file format data. The archive probably has a real need to ensure that file format data is preserved, but that is not the direct intent of its mission.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>An OAIS is allowed to preserve other things than AIPs. It certainly can use the same information model and procedures to do so, but I would probably prefer that we reserve the AIP term for Info Packages that contain CDOs that form the basis of their preservation mission. What exactly is the set of AIPs for the OAIS is open to discussion, but I don’t think that and AIP is needed everything that the OAIS is preserving. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>For any of the RepInfo, Fixity Info, Reference Info, … there could be a network of data/information, but in all cases at some point the OAIS will need to cut the Network off at a leaf node. At the top (or the bottom if you prefer) of the network, you may have a full-fledged Info Object that includes a data object with a RepInfo like object and with all the PDI like objects. At the end of the network, you will likely only have the data/information and will not have another layer of fixity and reference IDs and access rights …<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I think those are the major viewpoints I would suggest for this discussion.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Good luck. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Hope you can close all the outstanding SCs without me there. ;^)<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Peace and joy,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>-JOhn<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'> <o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> MOIMS-DAI [mailto:moims-dai-bounces@mailman.ccsds.org] <b>On Behalf Of </b>David Giaretta<br><b>Sent:</b> Sunday, June 3, 2018 4:11 PM<br><b>To:</b> 'MOIMS-Data Archive Interoperability' <moims-dai@mailman.ccsds.org><br><b>Subject:</b> Re: [Moims-dai] Tuesday's marathon DAI telecon<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoPlainText><span lang=EN-GB>Dear all<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>I think Don has fairly expressed my views - up to a point.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>Don's alternative view (1) in a sense misses the major point and (2) makes things unnecessarily complicated by talking about AIPs within AIPs to describe my views.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>For point (1) the issue is that in order to know that ANY piece of information is being preserved, following OAIS concepts, one needs to know what the Data Object is and what the associated Representation Information is as a start, and also one needs to know, if one wants to have evidence to support claims of Authenticity:<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo3'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>How one can be sure the object has not been altered in an undocumented manner – otherwise how can we know what we are preserving – in other words we need Fixity Information<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo3'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>How was the object created etc – in other words its Provenance<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo3'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>How to locate the object i.e. Reference<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo3'><![if !supportLists]><span lang=EN-GB><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span lang=EN-GB>And so on for the other PDI elements<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>I hope this is generally agreed.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>We would all agree that the NASA image should be in an AIP, which of course is a logical construct. Our divergence is only that they do not want to say that, for example, a piece of Provenance Information is preserved “in” an AIP. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>However if, to preserve the Provenance one has the data object, its RepInfo, its Fixity Info etc etc – then I would say that just as, <i>if something walks like a duck and quacks like a duck then it is a duck</i> – in a similar way if we can, as we <u>must be able to</u>, point to the Provenance’s Data Object, RepInfo, Fixity, Reference, etc then we can, if we want to, say we have an AIP. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>I prefer to use the term AIP, others might want to invent a new term and write a whole lot of extra text – but why bother?<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>There is no need for Don’s complicated view of AIPs in AIPs etc. All one need to do is to ask, for any particular piece of information, do we have all the things required for its preservation? If one does not, then we are missing something vital. If one does have everything needed then one is preserving that piece of information and, if we want to do so, we can say we have an AIP. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB>One does not have to draw more and more complex diagrams – for the same reason that we do not draw out Representation Information as a Data Object with its own RepInfo, instead we just talk about a Representation Information Network and leave it at that.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>Just to repeat, one does not need to talk about AIPs in AIPs to draw my view. All one has to do is to ask how we know we have everything needed to preserve any particular thing. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>This view has the added benefit that it will not require any changes, other than perhaps some explanatory text, to ISO 16363 and it allows audits to be conducted without needing new concepts. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>While it is true, as Don says, that “Nowhere in the OAIS RM do we say that PDI should be treated as Content Information which would have its own PDI and its own Descriptive Information” – well sure, there are lots of things that OAIS does not explicitly say, otherwise it would be 10,000 pages long. The point is that we called it Preservation Description <u>Information</u> and its components are also pieces of <u>Information</u>. Thus, all the concepts of Information to apply, including Information Packages etc.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>One error I would like to point out, since this was mentioned in an earlier email and I let it pass then, is that he writes “associate Representation Information (assuming the Data Object is digital)”. This is an incorrect view of the Information Model – just look at Fig 4-10 – the diagram shows that both the Physical Object as well as the Digital Objects are sub-types of Data Objects, and anything that is a Data Object has Representation Information. As a specific example, imagine that I write “</span><span lang=EN-GB style='mso-fareast-language:EN-GB'>01001110 01001101 01010001 01001101 01010000 01001010 00100000 00100000</span><span lang=EN-GB>” on a piece of paper. This is a physical object which is a Data Object which encodes some information. It needs Representation Information which is that what I have written is encoded as eight 7-bit ASCII characters etc. This view also, by the way, allows a consistent view of information encoded on other physical media such as tapes, labels on tapes, disks, kanji characters etched on Silicon Carbide plates or images of “1”s and “0” on photographic film, if needed.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>In terms of Don’s conclusions, I have no disagreement except to add the recommendation that we make the change agreed in SC222 and add a small amount of explanatory text after Fig 4-12 about the appropriate Designated Community(ies) and perhaps a few examples. This may then require that a small amount of additional explanation be inserted into ISO 16 363.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Regards<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Images of <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>..David<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span style='mso-fareast-language:EN-GB'>-----Original Message-----<br>From: MOIMS-DAI <<a href="mailto:moims-dai-bounces@mailman.ccsds.org">moims-dai-bounces@mailman.ccsds.org</a>> On Behalf Of D or C Sawyer<br>Sent: 30 May 2018 14:24<br>To: MOIMS DAI List <<a href="mailto:moims-dai@mailman.ccsds.org">moims-dai@mailman.ccsds.org</a>><br>Subject: [Moims-dai] Tuesday's marathon DAI telecon</span><span lang=EN-GB><o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>All,<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>I found Tuesday's marathon DAI telecon (over 2 hours) to be very interesting on at least 2 levels. The first is the recognition that despite working on the OAIS RM from its inception, David and I had developed a significant difference in how we interpreted certain inferences which could be implied from the written word. We made different projections about things that were not explicitly stated. That this is possible, despite long histories of communication and working on past revisions of OAIS, should serve to remind us how difficult clear communication can be.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>I’m going to try to fairly characterize both points of view as the issue was not resolved during the telecon. The participants were Terry, Mark, John, David, myself (Don). Terry had to depart after about 1.5 hours. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>The issue under discussion was triggered by my objections to dropping Reference Information from having PDI directly associated as shown in OAIS RM section 2.2, figure 2-3. Responding to a point about PDI that David made, I pointed out that PDI doesn’t have its own PDI as is shown in Figure 2-3. However David responded that yes, PDI does have PDI, because by the process of recursion PDI is information that clearly the Archive wants to preserve and thus it should be viewed as information that conceptually should be taken as the Content Information of an Archival Information Package. The Information Package (IP) model is given in Figure 2-3 and is fundamental to being a conforming OAIS. When all its components are present, it is called an AIP and is the preservable entity focused on in the OAIS RM. It turned out that John and Mark viewed it as I did. I’m not sure about Terry as he left before I was clear on how he felt. We discussed some pros and cons of these conflicting views with no resolution.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>I believe David’s approach is to recognize that PDI associated with, say an image from NASA, will be put together by the Archive and the Archive needs to preserve it. Since the Archive is required to associate Representation Information (assuming the Data Object is digital), and to associate PDI with the Content Information (current OAIS), in order to preserve the NASA image information, therefore it should do the same with the PDI that it has prepared. After all, if this is required for preservation of the Image information, it is logical to argue it should also be required for preservation of the PDI information that has been created or prepared. Further, unless this is done in some way, the PDI that the Archive is preserving may not be reliable (for any number of reasons) and this will impact the Authenticity view of the Image information as the Archive will not be in a position to validate that the original PDI came, for example, from a good source and/or that it has not been corrupted in some way. Therefore he argues that it makes sense to treat the image PDI as Content Information in its own Information Package (actually an AIP for preservation) and thus one see that this PDI/Content Information must have its own PDI. He did note that one issue with this approach is how to define the Designated Community. In response to the objection that PDI having PDI starts a potentially endless recursion, he believes that in practice it will be cut off by some very simple or perhaps general Archive policy that can be readily applied. He feels that it is important for OAIS implementers to be aware and concerned about what I might call this second level (beyond the NASA Image information) information preservation. Presumably how many levels this is taken will be Archive dependent. There is logic to this view, of course, or David wouldn’t hold it. If I’ve mischaracterized David’s view I apologize and I’m sure he will correct this.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>Neither Mark, John, nor I have the view that PDI should be considered to be Content Information despite clearly needing to be preserved within the OAIS. I’m going to give my views which may differ in some details from those of Mark or John, or they may not. I have long recognized, or course, that PDI needs to be preserved within the OAIS. I’ve also recognized that there can be some interest in the origin and history of PDI, but I’ve not wanted to enter into the recursion explicitly because I’ve felt this is getting too complicated. It has seemed sufficiently difficult to get OAIS readers to understand and adopt the Information Package as an AIP without entering into an explicit recursion discussion. In this sense, my personal view has been that the Archive will address this with some best practices to ensure that PDI is properly preserved and can be relied upon for Authenticity concerns. For example, the Context Information and Provenance Information can address themselves as well as the NASA image, when the Archive thinks their own Context and Provenance is important. The Archive can maintain this in a controlled data base to guard against corruption. In my view it has not been necessary to formerly view preserving PDI in a recursive manner and to do so brings up a number of issues. Many of these were discussed during the telecon.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>David stated that his view is supported by, or at least not inconsistent with, the wording in OAIS. That may or may not be fully true, but I think the bigger issue is what should we be communicating that will assist readers and implementers of an OAIS? Clearly what we say needs to create a whole view that is logical and understandable. We can not take out some parts for examination without considering the overall context that is the OAIS RM. Another way of saying this is that most readers, ‘reading between the lines’, should come to nearly the same view of what is meant as best we can arrange this. It seems clear to me that we need to reach a consensus on this issue as it is having an impact on assumptions and leading to disagreements in other areas of discussion. At the very least, I believe we need to address this explicitly in OAIS to remove this ambiguity. For me, the question is what should we say.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>David’s approach raises some issue for me, as follows:<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>1. As the OAIS RM now stands, the overall view of OAIS is that SIPs are ingested, AIPs are formulated from the SIPs for preservation, Descriptive Information is associated with the AIPs to facilitate Consumer searches for the information (see Figure 2-3) of interest, and DIPs are created from the AIPs and provided to Consumers. This is the high level view of OAIS given in Section 2. Nowhere in the OAIS RM do we say that PDI should be treated as Content Information which would have its own PDI and its own Descriptive Information. When PDI is digital, we acknowledge that it will have explicit Representation Information. However I doubt very few, if any, readers of the OAIS RM come to the view that PDI should become a new Content Information in its own AIP. Of course we could change this, but should we?<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>2. If we want to promote the view that PDI, and for consistency all other information (e.g. Representation Information components) that OAIS may be preserving should be treated as its own conceptual AIP, then to be consistent we need to show that the top level AIP contains a Content Data Object, any number of Representation data objects, and any number of PDI data objects. Each of these data objects would need to be shown as its own AIP. The top level AIP containing multiple internal AIPs would be the minimum to be shown but at least one more level of breakdown would be needed or there would be no point in going to the trouble of showing the internals as AIPs in their own right. Consistency is not achieved unless each data object is a Content Data Object in an AIP. Perhaps all this nesting of AIPs in the original AIP could be shown in a reasonable way, but I think it would look quite complex. I think it would make the Representation Network look simple by comparison, if only because it would also contain such networks. In any event, I think the Descriptive Information aspect of the internal AIPs would need to be foregone, at least in most cases, as I don’t see the utility in promoting Consumer search information for second and third levels of PDI. However it could be useful internally depending on implementation. In any event, if only for clarity, I think lower level AIPs would probably need to be identified as a special type of IP, much as the SIP and DIP are specialized. I think Representation data object IPs would need a special name as would a PDI data object IP. However the fixity part of PDI would probably need to have its own IP as it is quite different than the other components which might be seen as a single data object. Actual usage seems very much case specific. I’ve tried to be as accommodating to my understanding of David’s view as I can. It would have to be fleshed out with appropriate figures and text to convince me it was workable, and I believe it would have to start in Section 2 and expanded upon in Section 4. <o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>David brought up the issue of how a Designated Community would be assigned to address who would need to understand the original PDI, and then the PDI of the PDI, possibly etc. I believe the original PDI needs to be understood by the Designated Community for the original Content Information (e.g., NASA Image) as, for example, the Context and Provenance can have a significant impact on the understanding that is conveyed by the Content Information - at least in some cases like experimental observation data. The PDI (on this PDI) Designated Community would probably be Archive staff with a certain natural language ability. This does not seem like a big issue to me.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>3. I find that nested AIPs (or nested specialized IPs) raises the abstraction level of the information modeling and may work against continuing wide adoption. It would certainly cause a significant revision of many figures and much text. At this point I do not see that it would be a net benefit to the clarity of the OAIS RM or its adoption.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>Conclusion:<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>Barring a clear demonstration that my concerns above are not valid, I think the best approach is to continue with the use of Figure 2-3 in its current OAIS form, together with a discussion in Section 4 addressing how an OAIS might go about preserving PDI while maintaining reasonable Authenticity. There is, of course, nothing to prevent an OAIS from implementing a somewhat recursive approach to data object preservation as long as it can be conceptualized as shown in Figure 2-3. After all, it is data objects that are being preserved but there are mandatory special types with mandatory relationships along with no required implementation mechanisms. For me, it comes down to what is the best way to continue communicating preservation perspectives recognizing a very broad base of current OAIS RM adopters as well as supporting future adopters with increased clarity.<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>= = = =<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoPlainText><span lang=EN-GB>_______________________________________________<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB>MOIMS-DAI mailing list<o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><a href="mailto:MOIMS-DAI@mailman.ccsds.org"><span style='color:windowtext;text-decoration:none'>MOIMS-DAI@mailman.ccsds.org</span></a><o:p></o:p></span></p><p class=MsoPlainText><span lang=EN-GB><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai"><span style='color:windowtext;text-decoration:none'>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/moims-dai</span></a><o:p></o:p></span></p></div></body></html>