...
- Andrew Woods
- Nick Ruest
- Unknown User (acoburn)
- David Wilcox
- Kevin S. Clarke
- Michael Durbin
- Osman Din
- Stefano Cossu
- Doron Shalvi
- A. Soroka
- Unknown User (daniel-dgi)
- Andy WagnerYinlin Chen
Agenda
- Islandora/F4 status
- Fedora 4 IG meeting January 30, 2015 at 1pm EST
- Proof of concept full Drupal integration - Islandora 7...x-2.0
- Chef recipe will be updated to reflect the proof of concept
- Danny and Nick with both be at Code4Lib
- Audit feature sprint
- Indexing federated resources
- Fedora 3 to 4 data upgrade strategies
- Fedora 4.1.0 release next week?
- Brief comment about Triplestore index named graphs
- ...
- Recent mailing list threads
Minutes
- Islandora/F4 updates will be added to agenda regularly
- Started Jan. 19th
- Danny has an implementation plan
- Tomorrow first F4 interest group to figure out sprint schedule
- Kevin is attending interest group meetings
- Audit feature has been added in Jan-June sprint schedule
- Will identify one or more feature sprints focused on implementing audit in 4.1 – likely two sprints
- Some design discussion with stakeholders is still needed
- March 23 is a good candidate for first sprint, second one following immediately
- Esme + Islandora community are interested in contributing; Stefano can provide testing/discussion
- Indexing and federation
- Two main limitations:
- Cannot easily mark federated resources as indexable
- Cannot detect changes in ext filesystem
- Stefano: for first issue, two solutions are proposed:
- Adding mixin definitions in CND that target federated resources specifically
- Andrew: Need to figure out implementation details
- Modeshape config option that allows to add arbitrary mixins to each projection
- This is the most flexible option but might require more effort
- Adding mixin definitions in CND that target federated resources specifically
- For second issue, Camel (not fcrepo-camel) can be used to scan external FS and detect changes
- Aaron: Camel has a mechanism for polling external FS
- Andrew: this could be a viable option
- Stefano: still to verify how usable it is with large and deeply nested FSs
- Andrew: According to documentation, Modeshape connector should be able to detect changes
- Stefano: well worth testing
- Aaron: this is only valid for local fs. The MS connector uses inotify and may tax the Fedora server
- Andrew: What is the priority?
- Stefano: high - might spend some time to figure out solutions outside of sprint schedule
- Mike: medium - Feb.
- Aaron: We have a similar use case at Amherst – actively researching
- Andrew: Seems like we have a critical mass.
- Will send out an e-mail trying to fit this topic into the schedule
- Two main limitations:
- Mike has been working on F3->F4 migration
- Federation was initially considered a good solution but
- configurability and mapping need to be more flexible
- effort to set up that federation is too large
- FOXML is a good interchange format for migration - mapping can be done using that format
- Mike will update "upgration" pages
- Doron: This is a good approach. Which FOXML version would you use? Store version seems more reasonable
- Mike: Started with archive context export but store FOXML can be used
- Mike: Need feedback from community about processing FOXML best practices
- Andrew: There are a few pilot projects available
- Andrew: we need coordination within community to avoid duplicating efforts
- Mike: will send e-mail updates on progress to help keeping people in sync
- Mike: Can spend some time each week for the next couple of months and try to have a strawman by next meeting
- A. Wead has developed some tools, not sure if there is some documentation about migration issues. His tools require Hydra content model
- Federation was initially considered a good solution but
- Next release
- Will be next week
- Coordinate timing with devs
- It will 4.1.0, not 4.0.1 as planned previously
- Some major user-facing changes prompted the version number change
- 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
- Named graphs in triplestore index
- 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
- Andrew: Will benefit from more discussion
- Stefano: Will post a Wiki use case page for information's sake when enough testing is done