Page History

...

1. Roll call of attendees (~16 persons were on the call).
2. Goals of this meeting: 
   1. Shared understanding of what we would like to achieve (specifically in 2 week sprint) – probably it is going to be a subset of what falls into the scope of import/export;
   2. Look at the calendar to plan when the feature sprint might be scheduled.
3. Andrew Woods commented on the two flavors of import/export:
   1. Raw RDF serialized in some way to on disk, plus the binaries or files associated with the those objects;
   2. Bagit bags that could be imported/exported and (round tripped into ) in/out of a Fedora repository.
4. Andrew Woods is hosting this initial call; Nick Ruest will lead the effort/sprint going forward
5. Nick Ruest led a walk through of the use cases and requirements on the design page:
   1. Use Case #1: Transfer between Fedora and external preservation systems:
      1. there was general agreement that round-tripping was implied in 'transfer between'; 
      2. discussion of whether content should be assumed to be in Bagit bags (often yes, but not universally so, as for example in LOCKSS);
      3. after some discussion, suggestion was made (and there was general agreement) to leave the use case as is and let the particulars be refined later.
   2. Use Case #2: Export the content of a single Fedora container and all of its descendants:
      1. the basic idea is to have the ability to define a subset of resources (by default it seems logical that this be via LDP:contains relationships);
      2. hypothetically one might wish to be able to configure the property that determines containment (for example according to PCDM relationships).
   3. Use Case #3: Transfer between fedora instances or (more generally) from Fedora to another LDP instance (e.g. Apache Marmotta):
      1. this use case was intended to help flesh out whether the transfer was always going to be in/out of the same repository, or whether it could be more generally conceived as a means of transferring between LDP repositories (i.e. g. in not only for backup/restore or deposit to a dark archive, but also useful in the context of a transfer of stewardship from one institution to another).
   4. Use Case #4: Import into a specified, existing container:
      1. the one problem here could be is that there could be very different ideas about what to do if there are conflicts during the import;
      2. lossless round-tripping is not currently possible (creation date, for example, not least because creation dates cannot be set), though it was noted that the barriers to lossless round-tripping are rooted in policy decisions, and those policies could be changed (making dates alterable);
      3. the issue of versioning was raised: the versioning in Fedora 3 would allow a new version to be created even if a resource already exists – it would become a new datastream version of the resource; it was noted that while versioning exists in F4, it is not the same as the datastream-based versioning of F3;
      4. the issue of adding resources to an existing export was raised; an additional use case will be created that captures this scenario.
   5. Use Case #5: Round-tripping resources in Fedora in support of backup/restore.
   6. Use Case #6: Round-tripping resources in Fedora in support of Fedora repository version upgrades.
6. Due to a lack of time, use cases 5-6 and the list of specific requirements were not discussed in detail. 
7. It was agreed that a second planning meeting would be held in one week at the same time. 
8. Andrew Woods raised one final consideration going forward for the planning of this work: namely, that a development sprint around Bagit is planned for September 19-23 at Penn State, and one of the items on the agenda for this sprint is import/export.  This sprint would thus be a good opportunity to fix bugs or add additional features to an initial implementation, if assuming it is possible to carry forward the planning, scheduling, and completion of an initial development sprint in the interim.
9. The question of the language used for the implementation was discussed.  It was agreed that that is 's an implementation decision that should be driven by the developers who are available to work on the sprint, as well as considering the long-term maintainability of the resulting code.