F EDORA 4 – R UMORS & T HOUGHTS Mark Bussey Chief Information Leafblower

Fedora ≠ preservation solution Preservation is the result of a well-thought set of systems and practices A single application on a single server cannot provide a complete preservation solution Fedora is a repository application Fedora is designed from the ground up to be integrated into a preservation ecosystem

No more data-streams?! Fedora 4 no longer has the concept of a datasteam Instead, Fedora 4 supports RDF resources Binary attachments XML is treated just like any other bit-stream Hydra 9 parses XML ‘attachments’ using OM identically to how Hydra 6/7/8 parsed XML ‘datastreams’

You have to use RDF?! You don’t have to use RDF for your metadata Hydra 9 parses XML ‘attachments’ using OM identically to how Hydra 6/7/8 parsed XML ‘datastreams’ System attributes are stored as RDF, but your descriptive metadata can be stored however you like: XML, JSON, Narrative text, emoticons – Fedora 4 is (mostly) agnostic You can mix and match RDF and XML objects in your repository You can even mix and match RDF and XML for individual terms on your objects

Versioning Versioning is an expensive (processing intensive) activity Fedora 4 does not automatically create versions on update Fedora 4 provides an API to mint snapshots of an object The application is responsible for determining when to make a snapshot Reference:

Fedora is not a Triple-Store Fedora is built on ModeShape – a standards compliant, open source, noSQL data storeModeShape ModeShape uses it’s own internal storage format to store RDF containers Fedora 4 / ModeShape stores binary attachments in a directory tree similar to Fedora 3 Preservation systems will need to implement a serializer to product human and/or machine readable metadata Fedora has hooks to integrate external triple-stores to support LOD activitiesexternal triple-stores

Code Migration Hydra hides much of the complexity and most of the changes from Fedora 3  Fedora 4 Many upgrade challenges come from other issues – like bootstrap upgrades in older versions of blacklight Good test coverage is your best ally The ScholarSphere team has done much work to prepare the way OM (Opinionated Metadata) – the gem that handles XML in Hydra is incredibly stable and has not changed significantly since June 2013incredibly stable

Hydra hides most of the changes Hydra provides a ruby object interface for repository objects Hydra is designed to provides simple, ActiveRecord-like methods to manipulate repository objects Those methods are largely unchanged across Hydra and Active Fedora versions since 6.x

Content Migration You don’t have to migrate your metadata to RDF You do have to migrate your data-streams to attachments Fedora tools are forthcoming, but not here yet AND This still might be a good time to think about cleaning up your metadata & data

Thank You