Open Repositories 2015 has always been bright line on our project calendar. It's been a deadline for most of our project goals because that's when we wanted to show the community what their funding, use cases, discussions, and development has wrought. Well, OR2015 has come and gone and there is plenty of good news. First, the official goals of the Islandora 7.x-2.x project that have been completed:
- Update Tuque
Tuque is the repository agnostic API that allows Islandora to interact with Fedora repositories. Tuque will need to be updated to connect to and work with the Fedora 4 APIs.
- Islandora (core)
Islandora (core) is the Drupal module that allows for browsing and managing assets in a Fedora repository. Islandora (core) provides core hook and API functionality for all Islandora solution pack and utility modules
- Islandora Solution Pack Collection
Islandora Solution Pack Collection allows Islandora to view to view and manipulate objects as a collection. It also allows collections to be created, viewable, and manageable. Along with Tuque and Islandora (core), it is a requirement for all other solution packs.
- Replace FedoraGSearch
Fedora 4 provides a pluggable framework for an external triplestore and search index. The same JMS indexer can be used to communicate with both the triplestore and search index (e.g. Solr). Any triplestore that supports SPARQL updates can be used with Fedora 4. Fuseki and Sesame have been tested.
- Community driven and lead - With some guidance and funding from the Islandora Foundation, Islandora7.x-2.x has been designed, built, tested, and documented by the Islandora Community as a whole. In particular, the efforts of the Fedora 4 Interest Group (an open group welcome to anyone who wants to participate) have been integral to shaping the project and continue to drive the work forward.
- Documentation from the onset - Rather than writing up documentation as a last step when Islandora 7.x-2.x is up and running, it has been a part of the process right from the design phase, making it easier for contributors to step in and make their own modifications to the heavily-commented code while its still being developed.
- Encouraging contributions - Hand in hand with the previous improvement, encouragement to contribute to the project has been a goal at all levels, from developers helping with the code to end-users providing use cases and requesting features. By drawing on the opinions of the community as a whole, and not just the developers among us, Islandora 7.x-2.x is made to reflect the needs of a broad group of users. Our call: “All contributions are welcome: use-cases, documentation, code, patches, bug reports, feature requests, etc. You do not need to be a programmer to speak up!”
- DevOps - A vagrant build was created to fire up a working copy of Islandora 7.x-2.x quickly and easily. Every update is reflected in the vagrant build. Anybody can run the environment and work with the stack, whether that be testing or developing.
- Everything is in a single Git repository!
- Portland Common Data Model - At long last, a common data model between Hydra and Islandora. Lots of collaboration between the Islandora, Hydra, and Fedora communities for the betterment of all our projects. Our Project Director, Nick Ruest, is a committer for PCDM and an active member of the Hydra Metadata Working Group, working with the Hydra community on base recommendations for technical metadata (Nick and Aaron Coburn co-lead that sub-group), structural metadata, rights metadata, and descriptive metadata.
- Working with the Fedora team - Contributing to Fedora development, attending Fedora Tech meetings, being a stakeholder for the audit service integration.
- migration-utils - The community is going to need a way to get content from Fedora 3 into Fedora 4. Our team collaborated with Mike Durbin (University of Virginia) on creating a migration utility, and with just a handful of minor changes, it will be ready for use very soon. Testing is even underway to adapt this tool to bring content out of legacy Fedora 2 repositories.
- Scalable, Distributed, Service Oriented Architecture - no assumptions on the location of any component of the stack.
- Apache Camel - adopted as a routing and mediation engine for integrating Drupal and Fedora. The fcrepo-camel component provided by the Fedora community has been utilized to replace Tuque as our primary means of interaction.
- True Drupal integration - Fedora content is modelled as nodes. Due to this, many modules in the codebase have been replaced with third party drupal.org modules. We can finally use that 'Add Content' button in Drupal!
- Asynchronous communication Between Drupal and Fedora.
- Bi-directional synchronization Between Drupal Fields and Fedora RDF.
- Drupal Field to RDF mappings - A handy user interface allowing end users to control field -> RDF mappings.
- Map XML with XPath - User interface controlling extraction of xml metadata using XPath, allowing fragments to get mapped to RDF. Similar to Hydra “Terminologies” except with a user interface.
- RDFa Enriched HTML Output - Google will love your site!
- Solr Solr Solr - The entire Solr suite of modules from drupal.org is available, giving the end user control over how and when content is indexed in Solr.
The next steps and goals for the project include:
- Refactoring the current Apache Camel processing implementation to utilize command-line PHP. This should be more comfortable for the Islandora community. The goal is to lower the barrier to contribution.
- Starting serious work to make the project easier to share. Tickets are coming, some marked for "newbies" to take on as an entry point to the project. The Basic Image Solution Pack will be the first target. Contributors are very welcome!
- WebAccessControl integration - The Fedora community has begun planning WebAccessControl integration. If you'd love to see XACML go away, we'd love to have you as part of the stakeholder team!
Islandora 7.x-2.x community sprints coordinated with Fedora community sprints.