Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. Islandora/F4 status
    1. Fedora 4 IG meeting January 30, 2015 at 1pm EST
    2. Proof of concept full Drupal integration - Islandora 7.x-2.0
    3. Chef recipe will be updated to reflect the proof of concept
    4. Danny and Nick with both be at Code4Lib
  2. Audit feature sprint
  3. Indexing federated resources
  4. Fedora 3 to 4 data upgrade strategies
  5. Fedora 4.1.0 release next week?
  6. Brief comment about Triplestore index named graphs
  7. ...
  8. Recent mailing list threads

Minutes

  1. Islandora/F4 updates will be added to agenda regularly
    1. Started Jan. 19th 
    2. Danny has an implementation plan
    3. Tomorrow first F4 interest group to figure out sprint schedule
    4. Kevin is attending interest group meetings
  2. Audit feature has been added in Jan-June sprint schedule
    1. Will identify one or more feature sprints focused on implementing audit in 4.1 – likely two sprints
    2. Some design discussion with stakeholders is still needed
    3. March 23 is a good candidate for first sprint, second one following immediately
    4. Esme + Islandora community are interested in contributing; Stefano can provide testing/discussion
  3. Indexing and federation
    1. Two main limitations:
      1. Cannot easily mark federated resources as indexable
      2. Cannot detect changes in ext filesystem
    2. Stefano: for first issue, two solutions are proposed: 
      1. Adding mixin definitions in CND that target federated resources specifically
        1. Andrew: Need to figure out implementation details
      2. Modeshape config option that allows to add arbitrary mixins to each projection
        1. This is the most flexible option but might require more effort
    3. For second issue, Camel (not fcrepo-camel) can be used to scan external FS and detect changes
    4. Aaron: Camel has a mechanism for polling external FS
    5. Andrew: this could be a viable option 
    6. Stefano: still to verify how usable it is with large and deeply nested FSs
    7. Andrew: According to documentation, Modeshape connector should be able to detect changes
    8. Stefano: well worth testing
    9. Aaron: this is only valid for local fs. The MS connector uses inotify and may tax the Fedora server
    10. Andrew: What is the priority?
      1. Stefano: high - might spend some time to figure out solutions outside of sprint schedule
      2. Mike: medium - Feb. 
      3. Aaron: We have a similar use case at Amherst – actively researching
    11. Andrew: Seems like we have a critical mass. 
    12. Will send out an e-mail trying to fit this topic into the schedule
  4. Mike has been working on F3->F4 migration 
    1. Federation was initially considered a good solution but
      1. configurability and mapping need to be more flexible 
      2. effort to set up that federation is too large
    2. FOXML is a good interchange format for migration - mapping can be done using that format
    3. Mike will update "upgration" pages
    4. Doron: This is a good approach. Which FOXML version would you use? Store version seems more reasonable
    5. Mike: Started with archive context export but store FOXML can be used
    6. Mike: Need feedback from community about processing FOXML best practices
    7. Andrew: There are a few pilot projects available
    8. Andrew: we need coordination within community to avoid duplicating efforts
    9. Mike: will send e-mail updates on progress to help keeping people in sync
    10. Mike: Can spend some time each week for the next couple of months and try to have a strawman by next meeting
    11. A. Wead has developed some tools, not sure if there is some documentation about migration issues. His tools require Hydra content model
  5. Next release
    1. Will be next week
    2. Coordinate timing with devs
    3. It will 4.1.0, not 4.0.1 as planned previously
    4. Some major user-facing changes prompted the version number change
    5. Nick: need to make clear to the community that 4.1.0 is not related to the F3 migration as it has been advertised so far
  6. Named graphs in triplestore index
    1. Stefano: We have worked on this with Aaron in order to store non-Fedora triples (e.g. schema information) in triplestore and be able to easily clear index without affecting external data
    2. Andrew: Will benefit from more discussion
    3. Stefano: Will post a Wiki use case page for information's sake when enough testing is done