You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Time/Place

Attendees

Related

Agenda

  1. Introduction and topic summary
    1. Establish common understanding of function of Import/Export
  2. Use case discussion
  3. Review initial requirements
    1. Two flavours of import/export effort; RDF and binaries vs BagIt Bags
  4. Confirm commitments
    1. Stakeholders
      1. Uses cases
      2. Requirements
    2. Developers
    3. Testing and validation
    4. Documentation
  5. Workplan and timelines
    1. Sprint scheduling

Minutes

  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 disk, plus the binaries or files associated with the objects;
    2. Bagit bags that could be imported/exported and round tripped into 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. 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 (e.g. in a transfer of stewardship).
    4. Use Case #4: Import into a specified container:
      1. the problem here could be 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, cannot be set), though it was noted that the barriers are rooted in policy decisions, and those policies could be changed (making dates alterable);
      3. issue of versioning: the versioning in Fedora 3 would allow a new version to be created if a resource already exists; 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 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: a development sprint around Bagit is planned for September at Penn State.  This sprint would be a good opportunity to fix bugs or add additional features to an initial implementation, if 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 an implementation decision that should be driven by the developers available to work on the sprint, as well as long-term maintainability.

 

  • No labels