Time/Place

Attendees

Related

Agenda

  1. Finish: Initial Requirements
    1. Two flavours of import/export effort; RDF and binaries vs BagIt Bags
  2. Workplan and timelines
    1. Sprint scheduling
      1. August 8-19, 2016
    2. Developers
      1. Nick Ruest
      2. Esmé Cowles
      3. Michael Durbin (Maybe)
      4. A. Soroka (Maybe)
    3. Testing and validation
      1. Michael Durbin
      2. Youn Noh
      3. Bethany Seeger (Maybe)
      4. Nick Ruest
      5. Joshua Westgard
      6. Yinlin Chen
      7. Justin Simpson
    4. Documentation
      1. Youn Noh
      2. Nick Ruest
      3. Joshua Westgard

Minutes

Workplan and Timelines

  • Sprint 1 changed to start August 29 due to people being unavailable for the 8th
    • Developers
      • Nick
      • Esme - Nick will follow up
      • Mike
      • Ben
    • Testing/validation
      • Josh
      • Mike
      • Youn- Nick will follow up
      • Nick
      • Yinlin
      • Bethany
    • Documentation
      • Youn
      • Nick
      • Josh

Requirements

External systems

  1. Support import from and export to a TBD list of external systems.
    1. Already discussed
    2. Add Archivematica - Justin
    3. Add LOCKSS - Mark J

General

  1. Support transacting in Fedora-compliant RDF
    1. What do we mean by Fedora-compliant?
    2. Strike unless/until someone clarifies the meaning
  2. Support allowing the option to include Binaries
    1. No issues
  3. Support references from exported resources to other exported resources
    1. Important but challenging requirement
    2. Is this restricted to subtree resources?
      1. Need clarification on this point
  4. Support transacting in BagIt bags
    1. No issues
  5. Support import into a non-existing Fedora container
    1. Split into 2 requirements
      1. With same relative path
      2. With a different relative path
    2. Merge 5, 6, and 7?
  6. Support import into an existing, empty Fedora container
    1. Same issues as 5
  7. Support import into an existing, non-empty Fedora container with various policies: add, overwrite, delete, version, skip
    1. Same issues as 5
  8. Support export of resource versions
    1. No issues
  9. Support import of resource versions
    1. No issues
  10. Support export of resource and its "members" based on the ldp:contains predicate
    1. No issues
  11. Support export of resource and its "members" based on a user-provided membership predicate
    1. No issues
  12. Support recursive RDF insert/updates with LDP Indirect Container specified POST (and PUT / PATCH?) (ref: FCREPO-2042)
    1. Non-RESTful - impacting many resources by interacting with one
    2. Could be done client-side using transactions
    3. Makes more sense with PATCH than POST or PUT
    4. Can we put this aside for now pending further discussion?
    5. Not a priority for the first sprint
  13. Consider import/export performance as is possible under the assumption that this work is done via the REST interface
    1. This is not a requirement, just a recommendation
    2. We would need numbers to work against in order to turn this into a requirement
    3. Needs more discussion

Round-Tripping

  1. Support preservation of dates during round-tripping
    1.  No issues
  2. Support preservation of version snapshots during round-tripping 
    1. No issues
    2. Will be challenging to implement
  3. The URIs of the round-tripped resources must be the same as the original URIs
    1. No issues
    2. Note: within Fedora’s existing capabilities
  4. Support lossless round-tripping.  (ie, if you export a resource, delete that resource and import there is no difference from if you had never performed any of those operations).
    1. No issues
    2. No difference = no semantic difference
    3. There would still be an audit trail

Bag-It

  1. The structure and scope of accepted and produced BagIt bags must be configurable (resource)
    1. This is client-side - a script will pull the appropriate profile and assemble a bag
  2. Unambiguously support linking between resources within a bag, and from resources in the bag to resources outside the bag
    1. Is there already an assumed requirement that bags contain multiple resources?
      1. We should start with single resource bags as an initial goal
      2. This feature will not be very useful to some people if we cannot support multi-resource bags
    2. Needs more discussion at the beginning of the sprint (and during the sprint)
  • Nick will send out a Doodle poll to nail down a call on the 29th for the beginning of the sprint

 

  • No labels