Chat notes for 06 June Meeting

(NOTE: Action to review ALL of TRAC section B2, and provide comments, for next meeting)

MarkConrad >> (All): Is anyone speaking? If so, I am not hearing the audio.

MarkConrad >> (All): Did anyone ever hear back from David or Simon about capturing the chat transcript for the meeting of May 23rd?

BarbaraSierman >> (All): Daavid send an email that he would not attend

BarbaraSierman >> (All): Is anyone speaking?

MarkConrad >> (All): In the chat transcript for the May 30th meeting several folks raised the issue of what happened to the notes for the May 23rd meeting. They do not appear to have been posted.

BarbaraSierman >> (All): Is something happening? I see 5 people in the list, but no activity in the chatwindow?

BarbaraSierman >> (All): ok

Don Sawyer >> (All): Let's start then by addressing B2:

MarkConrad >> (All): What about Katia's comment?

BarbaraSierman >> (All): What was the reason to separate these two?

Don Sawyer >> (All): One needs to llook at the TRAC document for the distinction. Do you all have this handy?

MarkConrad >> (All): I do!

Robert Downs >> (All): I am opening it now

Don Sawyer >> (All): In summary, I think the distinction is first - is there a general defintion of the classes of AIP, and then whether these defintions are adequate for the long-term preservation.

BarbaraSierman >> (All): Yes I agree

MarkConrad >> (All): I agree

Don Sawyer >> (All): Seems we all agree - keep the distinction

Don Sawyer >> (All): Going to B 2.7

Don Sawyer >> (All): Sorry - make that B 2.6

MarkConrad >> (All): I agree with Barbara's comment.

Don Sawyer >> (All): However, I'm not sure it addresses Katia's comment. Seems she is asking 'why start with an 'IF''?

BarbaraSierman >> (All): You think she means that all SIPs have a unique identifier?

MarkConrad >> (All): I believe it is important to know when (and by whom) the id was assigned to the SIP.

Don Sawyer >> (All): Yes Barbara, I think that is what she means

BarbaraSierman >> (All): But it is not always the producer who adds the identifier to the SIP

BarbaraSierman >> (All): producer = original creator

MarkConrad >> (All): My point exactly

Don Sawyer >> (All): Perahaps the item title should be reworded slightly to empasize the need for uniqute IDs for SIP, regardless of who assigns them, and then the need to preserve them

MarkConrad >> (All): You also need to know who is assigning them and for what purpose.

Robert Downs >> (All): If the producer provides the unique identifying information for context, it seems that the archive should keep that information as part of the record for receiving it

MarkConrad >> (All): I agree Bob.

Don Sawyer >> (All): Yes, useful to know who did the assigning.

Don Sawyer >> (All): So, do we recommend rewording to remove the 'if'?

MarkConrad >> (All): This should be specified in the agreement for transfer between the producer and the repository.

BarbaraSierman >> (All): If the unique identifier is added during the proces of making the SIP, then it is only an administrative item

Don Sawyer >> (All): Mark, that is certainly one way to do it, but this is just addressing the general requirement

MarkConrad >> (All): It depends on what the id was created for. Isi it used for logging what was transferred?

MarkConrad >> (All): It would be useful to have Katia's input, instead of speculating on what she actually intended.

Don Sawyer >> (All): Barbara, even if the SIP did not have a unique ID coming in, it should need to be tracked in terms of other attributes and then the archive assignes a unique ID for internal tracking pruposes - most likely.

Don Sawyer >> (All): Mark -I'm quite sure she is addressing the 'IF'.

John Garrett >> (All): I'm not convinced that there is a need to idefinitely preserve the relation of a unique SIP identifier into the future.

BarbaraSierman >> (All): Yes ofcourse Don, but this is another notion than the persistent association with the AIP

Don Sawyer >> (All): John, - this ia the issue of replacements.

BarbaraSierman >> (All): Shall we ask Katia next time?

John Garrett >> (All): Only if replacements are dealt with at the SIP level and not at an AIP level

MarkConrad >> (All): If you don't preserve the producer assigned SIP ids, how do you audit the successful ingestion of the SIP?

Don Sawyer >> (All): John, there is no requirement on sending AIPs or even that Producer's know anything about resulting AIPs. Since we're using OAIS terminology, it is only the SIP that the producer knows about.

Don Sawyer >> (All): i agree with Mark - there is a chain here that needs to be followed from a certificaiton perspective (trust)

BarbaraSierman >> (All): Don, before an object becomes a SIP, there might be a procedure, the PRODUCER does not know about. That is one of the missing elements in OAIS, the produces does not send SIP, but pre-SIPs

John Garrett >> (All): Successful SIP ingestion could be tracked by something as simple as the Producer signing off that they agree that their material is adequately incorporated into the Archive.

MarkConrad >> (All): John, If the producer doesn't see the SIP how doe the producer do that?

MarkConrad >> (All): Sorry, I meant if the producer does not see the AIP.

Don Sawyer >> (All): Barbara - by definition, the Producer sends SIPs - not pre-SIPs. Otherwise, we have a different model and are not speaking the same concepts.

BarbaraSierman >> (All): In theory you are right, but practice is different

John Garrett >> (All): Producer may not see AIP, but there is nothing that precludes the Producer from seeing it. Especially if the Producer works closely with an Archive, they may know the details and many years down it may be easier to deal with what is actually recorded in an AIP than what was perhaps a fleeting choice for what went into a particular SIP many years ago.

MarkConrad >> (All): I fear we are entering a semantic tailspin here.

Don Sawyer >> (All): I think both threads are getting mixed up between a consistent model view and possible local implementations. We can't address all possible local implemetnations.

John Garrett >> (All): I think you should maintain the unique IDs if you need them to "prove" your process or if the submission agreement says that you will maintain them.

Don Sawyer >> (All): The purpose of the model is to faciliate communication. Then you, in specific cases, map to it to clarify. This has how the model has been used and quite successfully.

MarkConrad >> (All): At the time of transfer don't the producer and the repository have to have some agreement about the id of what is being transferred?

John Garrett >> (All): In practical terms, yes there will need to be some way for the Producer and the Archive to refer to a SIP

Don Sawyer >> (All): John, TRAC says you should be able to show that what you received has been properly received and there is a clear track into preservation.

John Garrett >> (All): But this is the discussion of what we agree with and don't agree with in TRAC.

Don Sawyer >> (All): Yes, which is why I raised it to a higher level. Do we agree with the thrust? Then, how to demonstrate it to the auditors.

MarkConrad >> (All): Take a look at the text of 2.6. It is referring to a specific instance of SIP ids when they are useful in providing consumers contextual information.

MarkConrad >> (All): I don't know of too many archivists who would discard this type of information.

MarkConrad >> (All): I also think that because this is referring to a particular kind of SIP ids the IF is appropriate.

MarkConrad >> (All): 2.6 however does not address the chain of custody issue that I raised earlier.

John Garrett >> (All): I guess something that I'm tripping up on is which unique IDs are we talking about? If it is just a unique ID of the SIP, which no one is required to keep around or even be able to recreate, it may not make sense to keep that unique ID around forever and put in all the work to maintain it's association with perhaps many AIPs. On the other hand if unique ID refers to the content and especially if it is used in other contexts, then it is useful to preserve it and keep it associated with the content.

MarkConrad >> (All): They should be required to keep the unique id of the SIP to ensure the chain of custody.

Don Sawyer >> (All): Mark, I understand TRAC to be addressing the chain of custory - at least from the SIP creation and submission to the dissemination by the archive. Note the third paragraph under 2.6.

BarbaraSierman >> (All): Sorry, need to catch the train. Bye

John Garrett >> (All): IF a unique ID of theSIP is needed to ensure chain of custody, then it should be maintained. But now I'm not sure that that is the unique ID that B2.6 is talking about. Text seems to be talking about unique IDs to content that are used in other contexts.

MarkConrad >> (All): The Evidence section seems to address my concern.

Robert Downs >> (All): Depending on the producer records, the unique ID could be the original title, which might be different than the current title, or it could be some other internal ID.

Don Sawyer >> (All): John - the SIP Ids may be at the SIP level, or at the level of data object inside the SIP, or both. And I agree with Robert's comment.

MarkConrad >> (All): 2.6 refers to 2.3. If I am reading 2.3. correctly it seems that logging SIP ingestions is optional. How do you audit the ingestion of SIPS if you are not logging this information?

Don Sawyer >> (All): As a participant in the generation of TRAC, I know the intent was to preserve a chain of custody. Perhaps some text up front in section 2.6 could clarify this, and then ways to do this with identifiers at different levels could be given.

MarkConrad >> (All): Somewhere in this document we need to establish requirements for an auditable chain of custody.

John Garrett >> (All): I agree

Robert Downs >> (All): I also agree

MarkConrad >> (All): I think we will need to take a closer look at 2.3 at some point.

MarkConrad >> (All): I will try to provide comments on 2.3 before the next meeting.

Robert Downs >> (All): The simplest way to show chain of custody is to show that some ID has been held since some period of time, regardless of the form that the ID takes.

Don Sawyer >> (All): I think one needs to read these in context - which may be why we're coming to different conclusions as to what they mean. Perhaps we should take an acton to review B2 in its entirety.

MarkConrad >> (All): I agree with Don. I disagree with Robert.

MarkConrad >> (All): If the ids are not unique and assigned according to a documented procedure you cannot audit the chain of custody.

Robert Downs >> (All): I should have clarified that the ID should be unique to the producer. Thanks for the clarification, Mark

MarkConrad >> (All): You also need a documented procedure for assigning the ids

Don Sawyer >> (All): Yes, the TRAC does not make clear over what sope IDs should be unique.

Robert Downs >> (All): I also agree with the need for a documented procedure for assigning IDs, as Mark has stated.

Don Sawyer >> (All): I'm going to have to leave. Shall we establish an action on our parts to review all of B2 and the comment?

MarkConrad >> (All): Yes.

Robert Downs >> (All): Yes

John Garrett >> (All): There are also issues of what is being uniquely identified, for example, is it a unique ID for a document or a particular issue of the document or a particular format of the document.

MarkConrad >> (All): for the SIP

John Garrett >> (All): I need to leave also, talk or type to you all next week.

Don Sawyer >> (All): Bye

MarkConrad >> (All): Bye!

-- RobertMcDonald - 06 Jun 2007 -- DonaldSawyer - 06 Jun 2007

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2007-06-06 - DonaldSawyer
 
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