Attendees:

Discussion was completed of sections B5.4 (thus concluding B5), B6.1 and B6.2.

Actions:

• JohnGarrett to make agreed changes to the working document.

BruceAmbacher >> (All): Should we address the suggested changes for B5.4?
JohnGarrett >> (All): Yes, let's do it.
BruceAmbacher >> (All): Mark's rewrites reflect the consensus last week.
BruceAmbacher >> (All): His concerns about the discussion need discussion/clarification.
I favor the focus on data integrity.
BruceAmbacher >> (All): Sorry, I should have said examples, not discussion.
JohnGarrett >> (All): I think Mark's rewrites should be adopted.
BruceAmbacher >> (All): ok
Ricc Ferrante >> (All): ok
RobertDowns >> (All): ok
BruceAmbacher >> (All): Can we change referential integrity to the integrity of 
the data and its relationships to the associated decsriptive materials?
JohnGarrett >> (All): I think that data integrity should be covered in other 
sections.  I think this section should be focused more on the referential 
integrity.  So although I think data integrity is important, I don't think that 
is the focus here?
JohnGarrett >> (All): I'm agree with Bruce's suggestion.
JohnGarrett >> (All): Sort of covers both data and relational intergrity and I'm 
fine with that.
Ricc Ferrante >> (All): so would that be "the integrity of the data and its 
relationships to the associated decsriptive materials, especially..." ?
BruceAmbacher >> (All): Sorry, I lost my chat box
BruceAmbacher >> (All): That's my intention - delete all use of referential here 
and in discussion
JohnGarrett >> (All): Rather than "descriptive materials" I would use the OAIS 
term "Descriptive Information" to be a bit more specific
BruceAmbacher >> (All): For Discussion, how about: Repositories must implement 
procedures that let them know when the relationship between the data and the 
associated descriptive information is temporarily broken and ensure that it can 
be restored. 
BruceAmbacher >> (All): John, I'm ok with descriptive information
Ricc Ferrante >> (All): Same here, as well as your last suggestion for language 
under Discussion, Bruce
RobertDowns >> (All): I agree with the use of the term, "descriptive 
information", and also agree with Bruce's suggestion to be included under 
Discussion.
BruceAmbacher >> (All): Are we satisfied with B5.4 then?  Ready to move to B6?
JohnGarrett >> (All): OK, I think that's it.  On to B6?
RobertDowns >> (All): Yes
Ricc Ferrante >> (All): yes
BruceAmbacher >> (All): Under B6 Discussion, does anyone know what "See 27A11.4 
and 27A11.5" refers to?
Ricc Ferrante >> (All): NO
BruceAmbacher >> (All): I think the first set of comments under discussion 
cancel each other.  I think B6.1 addresses what Katia raises.
Ricc Ferrante >> (All): Under the B6 Discussion, there are numerous references 
to Katia's concerns being addressed in full or in part in subsection. I suggest 
we revisit these once we've gone through and modified the language in those 
subsections. 
BruceAmbacher >> (All): ok.  I sense the basic issue for Katia is that there be 
a "standard" DIP description.  I don't see this as possible since there may be 
both "stand" DIPs and custom DIPs, depending on the consumer's 
request/specifications.
Ricc Ferrante >> (All): I agree
BruceAmbacher >> (All): I am ok with David's changes to Requirement, Supporting 
Text and Examples.
JohnGarrett >> (All): I agree
RobertDowns >> (All): I also agree.
BruceAmbacher >> (All): I cannot accept Katia's comment under Discussion.  B6.1 
is about access, not the DIP information content..
JohnGarrett >> (All): Should we add something to the discussion to identify the 
issue of "secret" data and that access policy for it may not be published, but 
policy for other data should be.
Ricc Ferrante >> (All): Assuming we are on B6.1, I agree with David's changes. 
The "to" needs to be removed from "in order for users to know" under Supporting 
Text.
JohnGarrett >> (All): I think Katia has a valid point about needing some 
discussion of DIPs, but B6.1 is not the location for it.
Ricc Ferrante >> (All): regarding "secret" even "secret" records have access 
policies although those policies may be kept separate from access policies for 
other material.
BruceAmbacher >> (All): John, Under B6.1 the repository indicates its access 
policies.  I take that as plural.  A repository may/may not be able to indicate 
it has restricted data and must abide by that restriction.  I don't see a need 
to elaborate.  Various statutes will guide a repository on whatinformation it 
can/cannot provide 
JohnGarrett >> (All): I agree B6.1 covers it.  I just think that adding a 
sentence to the discussion will make it clear to other people and will save a 
bunch of questions down the line.
JohnGarrett >> (All): Something like "The repository may contain secret data.  
In that case, the repository will have an access policy for that data.  However 
the repository may not be able to make that policy  or even the existence of the 
policy known to parties without access to that data."
RobertDowns >> (All): The word "confidential" might be better than "secret".
BruceAmbacher >> (All): John, I would just say restricted information.  That can 
cover classified,time restrictions, community restrictions, etc.
RobertDowns >> (All): I am fine with the term, "restricted information".
Ricc Ferrante >> (All): ok
JohnGarrett >> (All): I'm fine with that.
BruceAmbacher >> (All): Are we addressing Katia's comment under Discussion or 
deferring it?
BruceAmbacher >> (All): I do not think it is a valid comment for this 
equirement.
Ricc Ferrante >> (All): I don't think it needs treatment under 6.1.
RobertDowns >> (All): I also do not that that it applies to 6.1.
Ricc Ferrante >> (All): It might be more appropriate under B6.7
JohnGarrett >> (All): I don't think it is appropriate for B6.1.  I think it is 
repeated in the Katia's comments above for B6 in general.
JohnGarrett >> (All): OK, Ready to move to B6.2?
BruceAmbacher >> (All): I agree.  That finishes B6.1
RobertDowns >> (All): yes
Ricc Ferrante >> (All): onward
BruceAmbacher >> (All): B6.2 I accept David's rewrite.  To answer his question, 
I do not think we need a requirement saying that the policy is actually 
implemented
JohnGarrett >> (All): I agree with David's point that we might not need to 
record all accesses.
BruceAmbacher >> (All): On to B6.3?
RobertDowns >> (All): I also agree that we might not need to record all 
accesses. 
Ricc Ferrante >> (All): ok
BruceAmbacher >> (All): B6.3 - Did David rethink his effort to relate all of 
this to preservation policy?  This is clearly access and does not impact 
directly on preservation.
JohnGarrett >> (All): I would like to suggest dropping a couple sentences from 
discussion.  First is "That is acceptable if the repository can prove it doesn't 
need to do more'
JohnGarrett >> (All): I dislike adding requirements for the repository to prove 
something where it didn't have a requirement before.  Also could be very hard or 
impracticle to 'prove' so would result in repository now needing to fulfill the 
requirement.
BruceAmbacher >> (All): John, What line of the B6.3 discussion are you referring 
to?
JohnGarrett >> (All): Second, I would suggest dropping or changing "If 
statistics are produced, they should be made available' 
JohnGarrett >> (All): I'm sorry, I'm still on B6.2
JohnGarrett >> (All): There may be privacy or security reasons to not make some 
statistics available.
RobertDowns >> (All): I agree with both of John's suggestions to remove 
sentences from the B6.2 Discussion.
Ricc Ferrante >> (All): no objection
BruceAmbacher >> (All): So we are eliminating the last two sentences of the B6.2 
Discussion.?
BruceAmbacher >> (All): ok
Ricc Ferrante >> (All): last three
Ricc Ferrante >> (All): "That is acceptable if the repository can demonstrate 
that it does not need to do more. The policy should include what figures are 
being monitored. If statistics are produced they should be made available. "
JohnGarrett >> (All): Actually, the last and the third last.  There is another 
sentence in there that remains.
Ricc Ferrante >> (All): I'm more comfortable with last and third last.
BruceAmbacher >> (All): John, please do a cut & paste rewrite for the record
JohnGarrett >> (All): Actually a lot of privacy policies identify what is being 
monitored and that should stay.  We may actually want to add web privacy policy 
as an evidence example.
RobertDowns >> (All): I am fine with adding the web privacy policy as an 
example.
JohnGarrett >> (All): I can't seem to cut and paste into megameeting, but I will 
make the edit on the wiki
BruceAmbacher >> (All): I don't think that is necessary to single out web access 
policies.  The Examples are access policies (plural but undefined)
Ricc Ferrante >> (All): The paragraph would end "This may mean that little or no 
information is recorded about access. The policy should include what figures are 
being monitored. "
BruceAmbacher >> (All): John, Is this what you want for B6.2 Discussion?  If 
necessary, a policy for recording actions (includes requests, orders etc) should 
be established and implemented. A repository need only record actions that meet 
the requirements of the repository and its information producers/depositors. 
This may mean that little or no information is recorded about access. The policy 
should include what figures are being monitored
JohnGarrett >> (All): Yes, that works for me.
Ricc Ferrante >> (All): ok
RobertDowns >> (All): ok
BruceAmbacher >> (All): Do we want to stop or address B6.3?
JohnGarrett >> (All): Sorry, it looks like I need to leave now.  Thanks all.  See you
next week.
Ricc Ferrante >> (All): I need to go. Suggest B6.3 be our next starting point.

-- SimonLambert - 08 Dec 2008