Attendees:

Discussion was completed of sections B5.2 (concentrating particularly on the appropriate place for Packaging Information to be treated) and B5.3.

Actions:

• MarkConrad to make agreed changes to the working document.
• All to think about where Packaging Information should be treated in other sections.

Mark Conrad >> (All): I guess we left off with B.5.2.
BruceAmbacher >> (All): Are we still dealing with the last two comments (conrad 
and Thomaz) in B5.2?
Mark Conrad >> (All): What happened to the link to the OAIS document?
Mark Conrad >> (All): Bruce, yes.
Mark Conrad >> (All): I agree with Katia that packaging information needs to be 
discussed somewhere in this document. I am not sure where it should be placed.
BruceAmbacher >> (All): Isn't the appropriate place B6 Access Management?
Mark Conrad >> (All): From the OAIS: "The Information Package has associated 
Packaging Information used to delimit and identify the Content Information and 
Preservation Description Information." I think it needs to be somewhere under 
information management. You can't manage what you can't parse.
KatiaThomaz >> (All): i decided the better place should be b4 archival storage & 
preservation/management of AIPs. i think packaging information has more to be 
with archival storage. what do you think?
JOhnGarrett >> (All): I could see it being several different places, but we 
should pick one place to discuss it.
BruceAmbacher >> (All): Packaging information is related to both AIP and DIP.
With an AIP it would be information about how the AIP is stored and with the DIP 
how the DIP is packaged to meet the consumer's specifications.
JOhnGarrett >> (All): One place could be early during Ingest when we define the 
AIP. Or as Katia says in Archival Storage or even as Bruce proposes in Access 
Management
Mark Conrad >> (All): Bruce, a SIP also has to have packaging information.
JOhnGarrett >> (All): Bruce's point is right, it applies to both AIPs and DIPs 
so maybe it will need to be discussed more than 1 place.
KatiaThomaz >> (All): SIPs has packaging information too and sometimes you need 
to archive this, as OAIS RM recommends.
BruceAmbacher >> (All): Mark, correct but the SIP packaging may not be visible 
to the consumer since it is used to bring in the SIP and may play a role in 
creating the AIP for storage.
KatiaThomaz >> (All): and packaging information is clearly involved in 
transformation process
Mark Conrad >> (All): Bruce, Visible or not the repository has to deal with it.
BruceAmbacher >> (All): Mark, yes, deal with it but poissibly not retain it 
after the AIP is stored.
KatiaThomaz >> (All): i am searching the specific place where OAIS RM says 
sometimes you should archive SIP´s packaging information
Mark Conrad >> (All): Bruce, We do not specifically discuss packaging 
information anywhere in the current text of Section B. I think that we need to 
deal with the packaging information associated with ALL information packages. If 
nothing else we need to talk about the role it plays in moving from the SIP to 
the AIP and from the AIP to the DIP. These may be three separate sets of 
packaging information.
JOhnGarrett >> (All): But if you need to save the SIP Packaging Information, it 
becomes part of the AIP Content Information
Mark Conrad >> (All): Let's try nailing some of this jello to the wall. Katia, 
if you put a requirement in B.4 for packaging information what would it say?
KatiaThomaz >> (All): wait a minute...
Mark Conrad >> (All): ok
Mark Conrad >> (All): Bruce, Do you have a suggestion for what the requirement 
would look like in B.6.?
KatiaThomaz >> (All): for example: Repository captures or creates packaging 
information and ensures that it is associated with the AIP.
JOhnGarrett >> (All): Can I suggest that maybe we add a bit to supporting text 
of B2.1.  I think if we add ", including Packaging Information." to the end of 
the first paragraph of Supporting Text in B2.1.
KatiaThomaz >> (All): sorry, only creates...
BruceAmbacher >> (All): I sugggest adding packaging information as an evidence 
requirement for SIPs in B1.2, B1.5 and B1.8 and as an evidence requirement in 
B2.2, B2.8 and B2.12.  A detailed definition of packaging information could be 
included in the first place used in each section.
KatiaThomaz >> (All): as John said if you need to save the SIP Packaging 
Information, it becomes part of the AIP Content Information
Mark Conrad >> (All): Bruce, Evidence sections are non-mandatory. Is that 
sufficient?
BruceAmbacher >> (All): Katia, I can't accept that as a universal statement.  
Not all SIPs are transformed exactly into an AIP.
BruceAmbacher >> (All): Mark, Is packaging information mandatory?  
Mark Conrad >> (All): Yes.
KatiaThomaz >> (All): From OAIS RM: The Packaging Information does not 
necessarily need to be preserved by an OAIS since it does not contribute to the 
Content Information or the PDI. However, there are cases where the OAIS may be 
required to reproduce the original submission exactly. In this case the Content 
Information is defined to include all the bits submitted.
KatiaThomaz >> (All): page 4-29
BruceAmbacher >> (All): That would appear to me to make it not mandatory
Mark Conrad >> (All): Packaging Information: The information that is used to 
bind and identify the componentsof an Information Package. For example, it may 
be the ISO 9660 volume and directoryinformation used on a CD-ROM to provide the 
content of several files containing ContentInformation and Preservation 
Description Information.
JOhnGarrett >> (All): Right, not all SIPs are transformed in an AIP.  But 
normally the packaging of the SIP is not considered something that needs to be 
preserved long-term.  If it is identified as something that needs to be 
preserved, then that Packaging becomes part of the Content Information that 
needs to be preserved in the AIP.
KatiaThomaz >> (All): for AIP is mandatory
Mark Conrad >> (All): Bruce, If you can't parse an information package what can 
you do with it?
Mark Conrad >> (All): "An Information Package is a conceptual container of two 
types of information called Content Information and Preservation Description 
Information (PDI). The Content Information and PDI are viewed as being 
encapsulated and identifiable by the Packaging Information. The resulting package 
is viewed as being discoverable by virtue of the Descriptive Information." page 
2-5
JOhnGarrett >> (All): I think it is mandatory that Archive specifies and 
understands the Packaging Information for the AIPs under its control.  But it is 
inherently so ingrained in the process that it is considered common knowledge 
and practice.
BruceAmbacher >> (All): I am just trying to avoid absolutes where they do not 
exist.  I fully support preserving it and making it available when it is a 
factor in understanding/using an object
JOhnGarrett >> (All): For AIPs, I still support adding it as part of the 
definition of the AIP in B2.1.  I think we will need to make a similiar point 
for DIPs somewhere.
Mark Conrad >> (All): Despite the statement that Katia quotes most of the OAIS 
sure makes it sound like it is mandatory.
Mark Conrad >> (All): "Producer. Its form and detailed content are typically 
negotiated between the Producer andthe OAIS. Most SIPs will have some Content 
Information and some PDI, but it may requireseveral SIPs to provide a complete 
set of Content Information and associated PDI to form an AIP. A single SIP may 
contain information that is to be included in several AIPs. The Packaging 
Information will always be present in some form." pg 2-9
BruceAmbacher >> (All): Mark, what Katia quoted does not sound mandatory to me: 
The Packaging Information does not necessarily need to be preserved by an OAIS 
since it does not contribute to the Content Information or the PDI. 
JOhnGarrett >> (All): Packaging Information for AIP is required by definition 
that it is part of how AIP is constructed.  Capturing the Packaging Information 
from SIPs however is matter of agreement between Archives and 
Producers/Consumers.
Mark Conrad >> (All): Bruce, I understand. Its just that the rest of the 
document seems to contradict that statement.
BruceAmbacher >> (All): John, Agreed but the trend in this discussion is to make 
all packaging information mandatory
Mark Conrad >> (All): See the definition of an information package above. It 
covers SIPs, AIPs, and DIPs.
KatiaThomaz >> (All): Bruce i reproduced OAIS RM. At this point, it refers to 
SIP´s packaging information
BruceAmbacher >> (All): Mark, Where is "above" for the information package?
JOhnGarrett >> (All): Packaging Information exists.  It is a fact.  The 
information is physically saved somehow.  Discussion needs to focus on how much 
definition of the Packaging Information is needed.
Mark Conrad >> (All): Bruce, "An Information Package is a conceptual container 
of two types of information calledContent Information and Preservation 
Description Information (PDI). The ContentInformation and PDI are viewed as 
being encapsulated and identifiable by the PackagingInformation. The resulting 
package is viewed as being discoverable by virtue of theDescriptive 
Information." page 2-5
BruceAmbacher >> (All): My point is that packaging information for SIP and DIP 
are transient and apply only to that specific ingest/dissemination.  They must 
be present for the ingest/dissemination so the archives /user can verify what 
they are getting.  But the information may be transient and discarded once the 
SIP/DIP is received and verified.  The presence of packaging information is 
mandatory but the PI may be transient.
Mark Conrad >> (All): So then the only madatory PI would be for the AIP?
JOhnGarrett >> (All): I think when we look at B6.1, we could add text indicating 
that the various packaging options are available for DIPs.  I think that along 
with the B2.1 change I suggested would take care of this issue.
BruceAmbacher >> (All): NO, all are mandatory but all are not necessarily 
preserved.
Mark Conrad >> (All): Does anyone feel that there should be something in B.5. 
about packaging information?
JOhnGarrett >> (All): I agree with Bruce, that SIP and DIP PI is transient, but 
must be at least ad hoc agreement between Archvives and Consumer on what that 
is.  AIP PI is how AIPs are held in Archvives and it needs to be understood and 
perhaps documented.
JOhnGarrett >> (All): I think it is better put in other places than B5
Ricc ferrante >> (All): Agreed
RobertDowns >> (All): Agreed
BruceAmbacher >> (All): agreed
Mark Conrad >> (All): Katia?
Marie >> (All): agreed
KatiaThomaz >> (All): i think b4
Mark Conrad >> (All): So can we table this comment in B.5.2.?
KatiaThomaz >> (All): i explained before
JOhnGarrett >> (All): Yes, I think we table this issue for B5 and people take as 
homework proposing where and how it is added to other sections.
RobertDowns >> (All): Mark - Have we addressed all of your comments in B.5.2?
KatiaThomaz >> (All): yes
Mark Conrad >> (All): I still think we have a separate requirement in the 
supporting text. I will propose a change in two weeks time. I will not be here 
next week.
BruceAmbacher >> (All): I though we had agreement on your making a new separate 
requirement.
Mark Conrad >> (All): Ok. I withdraw my other comment on the discussion. On to 
B.5.3.?
JOhnGarrett >> (All): I agree with Mark that showing how the information is 
acquired is a separate requirement.  I believe we already show how SIP info is 
transformed into AIP info in earlier sections.  So I think it is only necessary 
to show that we have it here.
JOhnGarrett >> (All): OK, onward.
Mark Conrad >> (All): any problems with my first comment? We have been doing 
this for the other requirements.
KatiaThomaz >> (All): agreed
Marie >> (All): agreed
Ricc ferrante >> (All): agreed
JOhnGarrett >> (All): Agreed, I thought we agreed to do this as a global edit.
Mark Conrad >> (All): I agree with David's comment. My suggested replacement 
text actually covers this requirement and the next one. Do we need separate 
requirements here?
RobertDowns >> (All): Agreed with Mark's first, which I also thought we were 
doing globally.
BruceAmbacher >> (All): Mark, where are you B5.2 or B5.3?
Mark Conrad >> (All): B.5.3.
BruceAmbacher >> (All): B5.3, Mark, would you accept "exists" in place of "is 
enforced"?
BruceAmbacher >> (All): B5.3 I accept Mark's first comment and third comment.
Mark Conrad >> (All): Bruce, If we are going to keep B.5.3. and B.5.4. as 
separate requirements then. yes.
JOhnGarrett >> (All): At face to face, a number of people objected to use of 
term "referential integrity" since it is so overloaded in for example Database 
circles.  They preferred that the current supporting text that really explains 
what is needed be used as the requirement statement.
BruceAmbacher >> (All): John, were any comments from the face-to-face 
incorporated into the working document?  If not, who will do that and when?
Mark Conrad >> (All): John the current supporting text is not talking about the 
same thing that is talked about in the requirement.
Mark Conrad >> (All): We are talking about referential integrity here - not the 
integrity of the AIP itself.
JOhnGarrett >> (All): Bruce, in general David tried to add them as comments to 
the requirements.  I think David's comment here was supposed to do that, but I 
don't think it really caught the discussion in this case.
BruceAmbacher >> (All): If referential integrity is viewed as loaded, should we 
define what we are requiring here - that the relationship between an AIP and its 
decriptive information is clearly established.
Mark Conrad >> (All): David's comment was added before the meeting.
RobertDowns >> (All): Would "associated with" be an acceptable alternative to 
the term "referential integrity"?
JOhnGarrett >> (All): Bruce, Yes, I think that is what was desired.
JOhnGarrett >> (All): Mark, Sorry I thought David had captured our comments 
while we were at the meeting.
JOhnGarrett >> (All): Since we didn't come to any conclusion maybe he didn't 
enter a comment.
Mark Conrad >> (All): From the OAIS, "Data Management: This entity provides the 
services and functions for populating,maintaining, and accessing both 
Descriptive Information which identifies and documentsarchive holdings and 
administrative data used to manage the archive. Data Managementfunctions include 
administering the archive database functions (maintaining schema andview 
definitions, and referential integrity), performing database updates (loading 
newdescriptive information or archive administrative data), performing queries 
on the datamanagement data to generate result sets, and producing reports from 
these result sets."
Mark Conrad >> (All): From the OAIS: "The Administer Database function is 
responsible for maintaining the integrity of the DataManagement database, which 
contains both Descriptive Information and system information.Descriptive 
Information identifies and describes the archive holdings, and systeminformation 
is used to support archive operations. The Administer Database function 
isresponsible for creating any schema or table definitions required to support 
DataManagement functions; for providing the capability to create, maintain and 
accesscustomized user views of the contents of this storage; and for providing 
internal validation(e.g., referential integrity) of the contents of the 
database. The Administer Database function is carried out in accordance with 
policies received from Administration."
BruceAmbacher >> (All): Robert, would this be acceptable: Repository can 
demonstrate that  all archived objects (i.e., AIPs) are associated with their 
descriptive information
RobertDowns >> (All): Bruce - that looks good to me.
JOhnGarrett >> (All): I would also add "and there is descriptive information for 
each AIP."
KatiaThomaz >> (All): i must quit know. thanks. have a nice week. bye
BruceAmbacher >> (All): Thanks John
JOhnGarrett >> (All): Bye, Katia.
RobertDowns >> (All): John's amendment to Bruce's suggestion adds clarity.
JOhnGarrett >> (All): I'm also in another meeting next week, so I won't make it 
until very late if at all.
BruceAmbacher >> (All): Do we have an acceptable resolution for B5.3? with the 
two rewording suggestions?
JOhnGarrett >> (All): Works for me.
Mark Conrad >> (All): How about, "Repository can demonstrate that  all AIPs are 
associated with their descriptive information and there is descriptive 
information for each AIP."
BruceAmbacher >> (All): ok
JOhnGarrett >> (All): OK
RobertDowns >> (All): ok
Marie >> (All): OK
BruceAmbacher >> (All): Lets declare victory and call it a day.
Ricc ferrante >> (All): Alright
Marie >> (All): Bye all
Mark Conrad >> (All): Will you accept my second comment? Then we can finish 
B.5.3.
JOhnGarrett >> (All): Yes, I think we should accept your comment.
JOhnGarrett >> (All): Bye
RobertDowns >> (All): ok
Mark Conrad >> (All): Simon, If you will capture the chat, I will make the 
changes to the document.
Simon Lambert >> (All): OK Mark
Mark Conrad >> (All): Thanks, bye.
RobertDowns >> (All): Bye

-- SimonLambert - 01 Dec 2008