Notes from Megameeting 12th November 2007

Attendees:

BruceAmbacher UM
CandidaFenton HATII, Univ Glasgow
SimonLambert STFC
JohnGarrett NASA/GSFC
RobertDowns Center for International Earth Science Information Network (CIESIN), U Columbia

All the discussion at this meeting was conducted by chat, so the following transcript of the meeting (with a few typos corrected) is complete.

Summary: discussion of B1.3 based on matrix for identification of madatory requirements, and suggestion for amended wording (to be circulated).

cclrc >> (All): There are a good number of entries in the matrix down to B1.4.
cclrc >> (All): The first one that seems to cause uncertainty is B1.3 which is the dreaded authenticity.
BruceAmbacher >> (All): B1.3  focuses more on authentication than authenticity - materials are from expected source, provenance has been maintained, objects are whay you expected byt nothing on the actual content validity
cclrc >> (All): Yes, you are right
RobertDowns >> (All): B1.3 appears to be a combination of requirements.
BruceAmbacher >> (All): The title focuses on the source and the text is some metrics for how to do that.  What if we replace "authenticate" with "validate"?
cclrc >> (All): Looks good to me.
BruceAmbacher >> (All): "Authenticate" and "authenticity" are NOT used in the text at all.
cclrc >> (All): I think that what the text describes could better be called validation than authentication - except for "the appropriate provenance has been maintained" which refers to a repository internal operation (or does it?).
JohnGarrett >> (All): I think B1.3 might be better broken into a couple pieces
BruceAmbacher >> (All): I read it as checking that the source is what it should be, they have controlled the object, and sent what they said they would send/transfer.
cclrc >> (All): Bruce - so the provenance here is prior to submission.
BruceAmbacher >> (All): Yes
JohnGarrett >> (All): Since this is in section B1 which is about obtaining content, I think provenance piece of this is not the internal tracking.
candida fenton >> (All): I think there is a case to be made for dividing  provenance into different types
BruceAmbacher >> (All): Such as?
candida fenton >> (All): Different types of provenance which have been suggested before are 'pre-submission provenance', 'ingest provenance', 'storage provenance', and possibly 'dissemination provenance'
BruceAmbacher >> (All): The producer guarantees the first, the repository the other three and that is our focus.
JohnGarrett >> (All): I like that breakout.  Then pre-submission would be desired, but not required.  Others would be required.
RobertDowns >> (All): That makes sense, but the others should be described in other sections, such as B.4
BruceAmbacher >> (All): My meaning for the first is that it is the responsibility of the Producer.  The repository seeks full guarantees but has no no role in it.
JohnGarrett >> (All): I agree with both Robert and Bruce
candida fenton >> (All): So it is useful to differentiate between different types of provenance, which can be dealt with in appropriate sections?
JohnGarrett >> (All): Yes
BruceAmbacher >> (All): So, do we have consensus to change "authenicate" to "validate" in B1.3?  Are any other text changes desired?
BruceAmbacher >> (All): I am not sure we need to make distinctions about types of provenance in the repository.  Can we hold that until we get there?  I think it is covered by references to audit trails, documenting changes due to preservation requirements such as migration, and creating different data objects for the user based on his/her requirements.
candida fenton >> (All): Could we differentiate between provenance prior to and post ingest?
JohnGarrett >> (All): I think B1.3 now covers a couple different things that could be broken into different checklist items.  One from whom we got the objects and another that we got the objects we expected.
candida fenton >> (All): I agree
BruceAmbacher >> (All): John, Isn't the reference here to HOW we can validate what we got as meeting the 3 criteria rather than discussing how to validate the object which comes in a later criteria?
JohnGarrett >> (All): If that is the intent, that is OK with me.  I wasn't getting that from the text, but it is probably what the intent was.
BruceAmbacher >> (All): I see B1.4 as doing the content verification. (completeness and correctness)
JohnGarrett >> (All): I agree that B1.4 covers that.  So can we drop "and that the objects are the expected objects." from B1.3?  Earlier text there already says objects are coming from source expected.
RobertDowns >> (All): Removing the part covered by B1.4 would reduce some of the complexity of B1.3.  
BruceAmbacher >> (All): Would you then also drop object validation from the text? (I would)
JohnGarrett >> (All): Yes, I think you are right.
BruceAmbacher >> (All): also drop it from the evidence?
BruceAmbacher >> (All): Simon, do we have a large enough group to declare victory on B1.3?
cclrc >> (All): I think we do - I can make those changes to the text.
BruceAmbacher >> (All): or at a minimum send out a proposed rewrite for larger group confirmation/acceptance
cclrc >> (All): OK, that might be easier for change control.
JohnGarrett >> (All): Great.  I'm going to sign off now.  Type at you all next week.
BruceAmbacher >> (All): I also must go.
cclrc >> (All): OK, see you next week. 
cclrc >> (All): Transcript will go on wiki as usual.

-- SimonLambert - 12 Nov 2007

Topic revision: r1 - 2007-11-12 - SimonLambert
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback