From October 13 - 16, 2014, I had the opportunity to go to (and the priviledge to present at) Islandora Camp Colorado (http://islandora.ca/camps/co2014). These were four?fairly intensive days, including?a last day workshop looking to the future with Fedora Commons 4.x. We had a one day introduction to Islandora, a?day of workshops, and?a final day of community presentations on how Libraries (and companies that work with Libraries such as ours) are using Islandora. The future?looks?quite interesting for the relationship between Fedora Commons and Drupal.
- The new version of Islandora allows you to regenerate derivatives on the fly. You can specify which datastreams are derivatives of (what I am calling) parent datastreams. As a result, the new feature allows you to regenerate a derivative through the UI or possibly via Drush, which?something the Colorado Alliance is working to have working with the?Derivative Generation module.
- A number of libraries are setting up Islandora as multisite installations. The Colorado Alliance has its own stack on github set up for deploying additional libraries using a combination of drush aliases, capistrano, and jenkins to allow for site-specific customizations. Others support all modules but have separate Fedora Commons repositories for each site.
- Of the new modules that have been worked on in the last 10 months,?Islandora Scholar is probably the most interesting. It?acts like a true information repository allowing for ingests, workflows, and data consumption, which?in many ways?makes?Islandora much more refined.
- Data Preservation was also a hot topic at the camp.?As a developer, I've not generally cared for the data that a user adds. This has come from my thinking that the data will not degrade over time. While I may not fully understand everything around PREMIS, I left the session?having a better understanding of how important systems like Fedora Commons and tools like PREMIS are to?ensure?data is not corrupted or even lost over time.
- Also at the camp Nick Ruest, the?current Islandora release manager?spoke about how he keeps his codebase at the very edge of the work going on in the Islandora ecosystem. While it might not be recommended for libraries where custom modules are developed, it was certainly interesting to see how well testing has been integrated into the Islandora suite of modules.
One of my absolute highlights from the camp was a presentation by Jeremy Nelson on how he and his team developed a very lean stack using a combination of Fedora Commons 4.x, Flask (a micro Python web framework), and Node.js. Completely deviating away from Islandora, this certainly gives me inspiration that if we do things right with the Drupal 8 version of Islandora, we could separate some of the underlying functionality into components that can be reused in other PHP frameworks like Symfony2, Laravel, etc. I believe that we would?see?some really amazing work come out of that.
The last day included a Fedora Commons 4 workshop which examined?some of the major changes that are coming (datastreams are out, 'resources' are in). There was a discussion on how data will be migrated into Fedora 4, and?another about how?data could be mapped from Fedora 3 to Fedora 4 and the new Fedora 4 repository would simply act as the main endpoint to access the data in Fedora 3. This concept and functionality is very intriguing to me.
While I find Islandora to be great in many way, there are a few?considerations I?recommend?taking?into account.?First is the level of knowledge required to work with Islandora. As a developer, a clear understanding of Drupal is needed to?grasp?how to develop custom functionality for Islandora,?such as understanding theming, understanding entities, the hook system...and drush. A few of the libraries that I spoke with?didn't understand before getting into Islandora just how large a part Drupal plays in the project which I found quite shocking. As part of both the Islandora community and the Drupal community, the tools used in Islandora (the suite of modules and the solution packs) definitely need to be re-examined to figure out how?we can utilize more Drupal modules and more members of the Drupal community (either as Drupal projects or even being able to find Drupal developers to help on a project). We also need to make sure we are not repeating ourselves in both communities by having modules that offer the exact same functionality (like Flag vs. Islandora Bookmark, or?Views Bulk Operations vs. Simple Workflow). While we do have one module that partially helps in this realm with the amazing Islandora Sync module, we need to also explore possibilities where the datastreams are not being stored twice; once in Fedora Commons, once in Drupal. This becomes increasingly important with binary datastreams such as PDFs, images, and videos which can take up large amounts of storage, and?end up prohibitively expensive. These are areas where Islandora is still improving and I look forward to utilizing new technology.
I used the camp as an opportunity to introduce the Islandora Entity Bridge?module, a module we developed for the Detroit Public Library Digital Collections which internally maps a namespaced Fedora ID to a internal Drupal integer ID. With this basic integration, we actually opened up the entirety of a fedora object to the entity ecosystem which includes:
- Entity References
- Flag
- Views
We added additional?Views integration for displaying datastreams and XPATH data from XML datastreams. Based off some clever views, blocks, and flags, we were able to add flagging capabilities to a Fedora Object within 30 minutes. We were also then able to create a showcase carousel based off the flagged user content (along with a favorites section) on the site with relatively minimal effort and a bit of understanding of XPATH. We also replaced the functionality offered by the Islandora Simple Workflow module by creating a view and adding views bulk operations to publish/unpublish records. In fact, we actually gained functionality by being able to search and filter through content to drill down to the exact set of records.
I think we can stretch this idea further by being able to use a mix of fields?that are created solely for display purposes?and?get synced into Drupal. These fields?have content that can get indexed directly through Drupal by using tools like Search API (and negating the need for applications like GSearch) while still being able to have content stored in Fedora Commons. Thus, the barrier for entry for a Drupal developer/themer can be lowered and help make it more accessible to create Institutional Repositories that really utilize Drupal and maybe do very interesting things to draw users into the site.