Islandora 8 (formerly known as IslandoraCLAW) is the next generation of Islandora. This major upgrade is compatible with Drupal 8 and Fedora 5. For more details, please check out the following resources:
Latest Islandora 8 News
For years it has stirred in the depths of Github, just under the surface in the vast ocean of digital repositories. It has been growing, patiently collecting feature after feature. Now, as we speak, contributions flow from its powerful team of committers. Feeding it. Strengthening it. Integrating with ever more software, nothing is safe from its might. And now, the time of its release is nigh!
It's been a long time in the making. From humble beginnings back with Drupal 7 and Fedora 4, its development been a true community effort that has spanned major version changes in both underlying technologies. Now with Drupal 8 and Fedora 5, we're ready to shed the code name of CLAW and officially become Islandora 8. And we need your help to do it.
Releasing Islandora has always had three components to it:
As with most projects under heavy development, our feature set has outgrown our documentation. And if we want it to be testable, we need to have up to date and accurate documentation to give our end users. We've compiled a list of what we feel is required for documentation for a 1.0 release, and we're asking everybody out there to give this document a review. Feel free to comment, leave suggestions, or ask questions if you feel there's anything that we've missed.
The auditing/documentation sprint will be held for two weeks, from March 4th to the 15th, and we'll try to knock out everything on our wish list. If you or your organization are interested in helping us show the world all the things they can do with the new Islandora, please add your names to the sprint signup sheet. All you need to know is how to write in markdown and a Github account, so even if you don't have any experience with Islandora 8, it's a great chance to get some experience with the software and provide us with your thoughts and feedback while documenting. In fact, the more fresh eyes we can get on it, the better. Also, the committers are encouraged to join in and make themselves available to answer questions, lend a hand, and merge those documentation PRs.
After we're done, the committers will be given time to address any issues found that are deemed critical. And if all is well, we'll freeze the code, make our release branches, and slice a release candidate for our testing sprint, which will be held on April 8th to 19th. During this time, we'll try our best to do our worst to the software. We'll be entering garbage data, throwing funny characters into text fields, uploading horrendous tiffs, and much, much more. There will be more details to follow after our documentation/auditing sprint.
It's an exciting time for Islandora, and we hope that you'll take part in it. This is the culmination of several years of community effort, and we'd like to thank everyone that's had a role in the process. Every commit, code review, and bit of testing adds up to a world class repository software that can meet the needs of small and large institutions alike. It really proves how strong and sustainable the Islandora community is. It's been a long and exciting ride, and we sincerely hope you'll join us for the home stretch!
In recognition of their many contributions to the community and to the development of Islandora CLAW, the Islandora CLAW committers have asked Rosie Le Faive (UPEI) and Mark Jordan (SFU) to become a committers and we are pleased to announce that they have accepted!
Rosie has brought her dedication to user experience and documentation from the 7.x stack to Islandora CLAW, providing guidance on how to improve the front end and working as the convenor of the UI Interest Group (currently on hiatus) to develop a welcoming first experience for the Islandora CLAW sandbox environment. As co-convenor of the Metadata Interest Group, Rosie has also been integral to the process of plotting out our MODS to RDF mapping so that users of Islandora 7.x can make the move to Islandora CLAW with their MODS in tow.
Mark has joined the Islandora CLAW party more recently, but hit the ground running, developing tools such as RipRap, a fixity-auditing microservice that acts as a successor to Islandora Checksum Checker. Mark's focus on preservation tools fills an important gap in the CLAW ecosystem.
Both Rosie and Mark are also Committers on Islandora 7.x, and now join the short list of dual Committers.
Further details of the rights and responsibilities of being a Islandora committer can be found here:
Create a roadmap for the future of the Islandora platform, including tools and strategies for migration
The Technical Advisory Group (TAG for short) has been working on a prioritized list of upcoming features and improvements for Islandora CLAW to help guide its development. We're aiming to release Islandora CLAW (and drop the CLAW codename) after 7.x-1.12 is released. Once that happens, this roadmap will be used to set sprint goals and other development priorities. We're opening up the roadmap to review by the entire community, and are asking for your feedback. You can leave comments either in this google doc or in the individual Github issues. We've also ranked these issues using a Github project.
Priority was agreed upon following the general rule of providing "must-have" features before migration. In other words, features which, if missing, would prevent someone from adopting the software should receive higher priority. Documentation and examples involving migrations ranked first, with multi-site support following up second. Also on the list are features built around the Fedora API specification, UI/UX improvements, new derivatives, and a lot more.
If there's anything you think is missing that's high priority, feel free to leave a suggestion in the google doc, or create an issue on Github and give it the Roadmap label. This is your chance to help shape the development of the project, so if you really need something before migrating in, this is a good opportunity to have your voice heard. After this review, the finalized list of features will be presented to the Board of Directors for approval. Once approved, the roadmap will be prominently displayed on our web site to help give people a sense of the direction of the software.
- Migrate over objects based on content type
- Migrate ALL the datastreams (except AUDIT, which is a special case)
- Extract metadata from any XML datastream and make it a Drupal field
- Model authorities such as people, organizations, and subjects
- Convert MODS to CSV using Cara Key's (LSU) XML2CSV tool
- Migrating the AUDIT datastream
- Modeling more/different types of authorities
- Examples of extracting authorities from FOXML
- A workflow for those who want to use OpenRefine to reconcile linked data authorities during the migration process
- Benjamin Rosner - Barnard Collge, CU
- Pat Dunlavey - Born-Digital
- Andrija Sagic - Library "Milutin Bojic"
- Ann McShane - Library Company of Philadelphia
- Cara Key - Louisiana State University
- Jason Peak - Louisiana State University
- Jonathan Green - LYRASIS
- Rachel Leach - Mount Holyoke College
- Mark Jordan - Simon Fraser University
- Adam Soroka - Smithsonian Institution
- Rachel Tillay - Tulane University
- Pete Clarke - University College Dublin
- Jared Whiklo - University of Manitoba
- Mike Bolam - University of Pittsburgh
- Seth Shaw - University of Nevada Las Vegas
- Paul Pound - University of Prince Edward Island
- Rosie Le Faive - University of Prince Edward Island
- Nat Kanthan - University of Toronto Scarborough
- Marcus Barnes - University of Toronto Scarborough
- Carolyn Moritz - Vassar College
Late last year, a working group of the Confederation of Open Access Repositories (COAR) released a report with recommendations to adopt "new technologies, standards, and protocols that will help repositories become more integrated into the web environment and enable them to play a larger role in the scholarly communication ecosystem." Islandora's own Institutional Repository Interest Group took up the report and measured Islandora against it, looking at both the current functionality available in Islandora 7.x, and how we can best shape Islandora CLAW to meet these recommendations for the future (complete with issues in the CLAW GitHub so we can track our progress). They have shared their own results, written up by convenor Bryan Brown:
#1: Exposing Identifiers
The brunt of the recommendation here seems to be implementing best practices listed at http://signposting.org/ regarding typed HTTP links. I’m not sure what Islandora 7.x is doing in terms of typed HTTP links, but I’m assuming nothing beyond whatever Drupal 7 does by default. It could certainly be doing more, but there’s a lot to chew on in the best practices in terms of deciding what actually needs to be done, and how this should be done for different types of objects. CLAW, being a linked data application that operates primarily via HTTP, should definitely be doing these things. I’ve made a use case for this at https://github.com/Islandora-CLAW/CLAW/issues/860.
#2: Declaring Licenses at a Resource Level
Very similar to Behavior #1 (Exposing Identifiers), this recommends using best practices from http://signposting.org/ to use typed HTTP links to expose the URI for the license that best describes a resource. Good in theory, but not all licenses have machine-readable URIs, and would require either migrating existing free-text licenses to ones that have a URI, or in the case of special one-off licenses, creating URIs for local licenses (which wouldn’t be very interoperable). COAR recommends using Creative Commons licenses since they have readily available URIs, but CC licenses aren’t really a good fit for scholarly works since publishing introduces a lot of issues that CC licenses don’t cover. As for the human readable part, that’s just a matter of your metadata and your theming. 7.x and CLAW both should be able to display human-readable rights statements, but neither can do the HTTP link part currently. CLAW use case at https://github.com/Islandora-CLAW/CLAW/issues/860.
#3: Discovery through Navigation
Even more emphasis on using the best practices at http://signposting.org/. 7.x’s Islandora Google Scholar module adds a link to the PDF for citation/thesis objects as an HTML meta tag, but that’s it. Its easy to see how adding this as a typed HTTP link, especially for compound objects would be helpful to let a machine know about the different parts of a larger meta-object. This feature would be nice for 7.x, but as a Linked Data Application CLAW should definitely have it. Covered again by https://github.com/Islandora-CLAW/CLAW/issues/860.
#4: Interacting with Resources (Annotation, Commentary and Review)
Members of the IR IG are not sold on this one for use in university IRs. Perhaps there are very specific types of repo systems where peer review, comments and annotations are useful, perhaps for aggregators or publishing platforms. In a university IR, it seems like it could actually hinder adoption because faculty might not want folks interacting with their scholarship, and would request mediation for such things which would slow down already overworked IR staff. Drupal already has tons of modules for things like this, so you could probably modify one to work with Islandora objects in 7.x, and in CLAW you wouldn’t even have to write any code, just turn the module on and configure it. Turning those annotations into linked data on the object would be a bit more difficult, but that difficulty would be more in deciding how the metadata should look than how to implement.
#5: Resource Transfer
This seems to be suggesting a modern form of OAI-PMH, but in a way that includes assets in the transfer. Strong recommendation for ResourceSync, which we have no experience with, but looks like it would do the job. 7.x will probably never have this, but CLAW should focus on it. Use case at https://github.com/Islandora-CLAW/CLAW/issues/857.
#6: Batch Discovery
We aren’t really not sure how this differs from Behavior #5 (Resource Transfer) since this seems to be a use case where someone used “Resource Transfer” technology to put all of your repo’s stuff in an aggregator so that it could be found in multiple places. You take care of #5, you already take care of #6. Covered by use case https://github.com/Islandora-CLAW/CLAW/issues/857.
#7: Collecting and Exposing Activities
This seems to be a mash-up of #4 and #5: capture interactions, turn them into metadata that you expose, and then push that metadata along with the rest of your data with ResourceSync. There are a LOT of recommendations for possible ways to do this, which underscores the fact that there’s not a clear standard for this and probably not a lot of consumers for this kind of data either. This seems like a “nice to have”, not a “have to have”.
#8: Identification of Users
This seems like a good idea, and ORCID seems like the obvious best choice in a scholarly context. We don’t know much about the other two ID systems involved (Social Network Identities and WebID), perhaps they would be good for folks who don’t have an ORCID, but then again perhaps this could be a good way to get people to use/understand ORCID. Use of ORCID could potentially lock out non-academic users, which may be a bug or a feature depending on your goals. Whichever you pick, the problem is going to be getting something that people use across the web in order to deliver on the promises outlined in this section. In an age where people are wary about privacy and the web knowing too much about you, we don’t think this one would get as much broad adoption as COAR thinks.
#9: Authentication of Users
We don’t understand how this is different from #8, it seems like the two go together to such a degree that separating them is only confusing.
#10: Exposing Standardized Usage Metrics
This is a nice dream, but much harder than it sounds. Current generation repositories are pretty close to doing all they can in terms of capturing views/downloads on objects, although client-side triggers are better than server-side ones in order to avoid problems with caching, and Piwik seems to be a winner in the international community due to its focus on privacy and flexibility (although it does require setting up your own Piwik server). Standardizing the way usage stats are exposed from the same repo is a good idea as well, but none of us have experience with SUSHI or COUNTER.
All this can be done to perfect aggregation of usage stats on the same repo, but aggregating/summing stats from external sources is not going to be a practical option until there is a centralized source that does this with a solid API.
#11: Preserving Resources
While we agree with the sentiment here, we’re not sure they are saying anything new. Fedora should take care of the actual preservation bits, and Islandora has always requested least-common-denominator open format file types for archival master datastreams and used derivative processes to spin into other formats.