Notes from MM 13 June 2007

4pm UK time using MegaMeeting at RAC


BruceAmbacher NARA / U Maryland
DonaldSawyer NASA's Goddard Space Flight Center
JohnGarrett NASA GSFC
MarkConrad NARA
RobertMcDonald SDSC
DavidGiaretta STFC
KatiaThomaz INPE, Brazil


Discussion about the need for Unique Identifiers - rather than talking about unique identification, especially with respect to SIPs.

Discussion also of whether the metrics should be made more independently understandable - however this does not appear to be possible - the additional text is always needed. In fact somehow we must encourage people NOT to use ONLY the metrics.

ACTION by 27 June 2007 - MarkConrad will propose some changes for B2 to try to ensure that an audit trail - as a separate page lined to the Working docuemnt page for B2.

ACTION ALL - collect current practice so we can get a better idea of what might not be too proscriptive

ACTION those associated with TRAC to see if they can access some of the test audit material to obtain information which might make it clearer what is happening now

Note that Not all discussion was was via the chat

RobertDowns >> (All): I do not have a microphone, today, but can hear you on my speaker and communicate using the chat.
RobertDowns >> (All): Hi!
Donald Sawyer >> (All): Hi Katia,
Donald Sawyer >> (All): Katia,  would you prefer we mostly use the chat, or should we try the microphones?
Katia Thomaz >> (All): i prefer using the chat
Donald Sawyer >> (All): O'K, David asked me to 'chair', so let's go back to section 2.  
Katia Thomaz >> (All): sorry, i was trying to open the files
Donald Sawyer >> (All): Section B2, that is.
Katia Thomaz >> (All): i sent you a message few minutes ago.
Donald Sawyer >> (All): We assigned ourselves an action last time to read section B2 in its entirety so as to have a better context for addressing issues.
Katia Thomaz >> (All): don was right about my comment in B2.6
David Giaretta >> (All): I've been adding a few comments to comments already made
Katia Thomaz >> (All): i am addressing th IF clause. i believe that all SIPs should have a unique id
Donald Sawyer >> (All): Katia, the title of the requirement is ambigousu.  It is really referring to the IDs associated with the SIP componenets, or the data objects within the SIP.  They won't always have a unique ID as received.
David Giaretta >> (All): Is there point here that the producers need not be FORCED to provide unique Idebntifiers
Katia Thomaz >> (All): but it is completly necessary...
David Giaretta >> (All): Yes, some identifiers must be allocated but they could be allocated by the Repository
Katia Thomaz >> (All): you can replace any SIP not only those which has a unique id
Donald Sawyer >> (All): I can envision a case where a data object is wrapped in a zip file, and perhaps given a title, but that is not the same as a unique ID.
David Giaretta >> (All): The "IF" means that If the producer assignes a unique ID then it should be maintained somehow
MarkConrad >> (All): How do you verify the completeness of an SIP without an auditable manifest/inventory of its components?
Katia Thomaz >> (All): i think the most important point here is defining if all SIP must have a unique id
Donald Sawyer >> (All): This is about IDs that are unique OUTSIDE of the SIP, and that are then included in the SIP.  
Katia Thomaz >> (All): no matter
Katia Thomaz >> (All): if the producer provide an unique id is ok, but if the producer don´t provide one the repository will assign it
David Giaretta >> (All): Does this discussion indicate that we need a metric saying that each SIP IS assigned a unique ID
Katia Thomaz >> (All): i think we must read PAIMAS
Katia Thomaz >> (All): check not read
John Garrett >> (All): The checklist item says that all unique IDs must be maintained.  The descriptive text seems to be less strict. Is it only unique IDs that are widespread or all unique IDs or only unique IDs that archive policies state need to be maintained?
RobertDowns >> (All): The archive receiving the SIP needs to uniquely identify the SIP received. The archive should then assign its own unique ID.
Katia Thomaz >> (All): i agree with robert
David Giaretta >> (All): Yes - sounds sensible
Katia Thomaz >> (All): remember that the repository could have an agreement or not
John Garrett >> (All): Yes B2.5 indicates that a unique ID is assigned
Donald Sawyer >> (All): Folks- this is not about identifyin SIP, but identifying the CONTENTS of SIPs.
Katia Thomaz >> (All): don, i don't understand your point
Katia Thomaz >> (All): john, 2.5 refers to AIPs
MarkConrad >> (All): Does B.1. require each SIP to have a unique ID?
RobertDowns >> (All): I agree, we need to precisely define the requirement in the short title. Additional descriptive information should support the title.
David Giaretta >> (All): SHould we edit the metric itself?
Donald Sawyer >> (All): Mark, in a quick read, I don't think B 1 necessarily requires each SIP to have a unique ID.  However, unique over what context?  I'm not sure that a unique ID for the SIP is the only way to ensure proper association and tracking.
Donald Sawyer >> (All): DAvid, can we should the edit of a title, such as with a color?
MarkConrad >> (All): My concern is how do you produce an auditable chain of custody without unique ids for the SIPs.
Katia Thomaz >> (All): i think it is completly necessary
David Giaretta >> (All): I've added something to m etric 2.5
MarkConrad >> (All): As for ids for the components of an SIP, How do you verify the completeness of an SIP without an auditable manifest/inventory of its components?
Donald Sawyer >> (All): The repository can assign a unique ID to the SIP  - it  may not come in with one.
MarkConrad >> (All): How does the depositor certify what has been transferred without a unique id for the SIP?
BruceAmbacher >> (All): I thought we were after a persistent ID to identify the SIP in whatever repository and from producer to one archives to possibly another.
Donald Sawyer >> (All): Mark, for example, by the use of a protocol and place to deposit the SIP.
Donald Sawyer >> (All): Let's get back to B2.6.  This is not about a SIP ID.  Given what is there, do we still have issues?
David Giaretta >> (All): In B2.6 I've added "COmponents" in the metric - does that do it?
David Giaretta >> (All): If you refresh your browsers you will see it
Donald Sawyer >> (All): Yes, looking at David's new version, the title is consistent with the text now.
Donald Sawyer >> (All): The issues, are there problems with the text?
Katia Thomaz >> (All): but you must include DIPs
David Giaretta >> (All): The DIPs are more transient surely
Donald Sawyer >> (All): We should put 'components' after first use of SIP in the text.
Katia Thomaz >> (All): you will see in B6
RobertDowns >> (All): A SHA-1 signature of all of the files can be used to verify that all objects have been received. 
David Giaretta >> (All): It does sound as if there is  something missing
Katia Thomaz >> (All): i can´t follow you
Donald Sawyer >> (All): There is a clear requirement to identify the components.
Donald Sawyer >> (All): Katia,  Sorrry, the chat was too slow for folks.  We'll try to get some summary.
Donald Sawyer >> (All): The whole issue of receiving SIP is addressed in section B1
Katia Thomaz >> (All): B1?
Katia Thomaz >> (All): sorry, i must quit you now. bye.
David Giaretta >> (All): Bye
RobertDowns >> (All): The titles should state the general requirements, unambiguously, and the text should provide detail and additional context.
Donald Sawyer >> (All): Agreed!
Donald Sawyer >> (All): I'll take an action to see how NSSDC addresses B1 and B2 at this time.

-- DavidGiaretta - 13 Jun 2007

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2008-02-13 - KatiaThomaz
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback