Throughout the Fedora Future build-out, we've maintained a Sufia-based Hydra head that consumes the Fedora APIs. At the June Hydra partners' meeting, we were able to cut over from the "legacy" Fedora 3-like APIs to the new, RDF based APIs.
A large amount of the effort was devoted to consuming the RDF and reproducing objects that appear to downstream API consumers like Fedora 3 objects, by providing analogues to Fedora 3 concepts (e.g. object properties like labels, owners, etc). In addition, converting multivalued fields to single valued fields to support Fedora 3-like objects.
There was some amount of tedious effort patching ActiveFedora to:
- use Rubydora exclusively for interacting with Fedora
- remove assumptions about the behavior of Fedora 3 (default DC datastreams, RELS-EXT, etc) and features not-yet-present in Fedora 4 (e.g. external datastreams)
- stop using FOXML to store fixture objects, and instead build them up programmatically.
Hydra is taking advantage of some of the new Fedora 4 features, including:
- Using RDF responses that contain full profile information for the object and datastreams to minimize HTTP round-trips
- Allowing (and exposing) arbitrary properties on objects, and pushing that through the stack, in order to let Hydra heads "tag" objects with arbitrary, non-datastream information
Running a Hydra head over fcrepo4
Our Sufia-based hydra head is maintained at https://github.com/futures/fcrepo4-demo-hydra-app. It uses a forked version of Rubydora:
gem 'rubydora', :git => 'http://github.com/projecthydra/rubydora.git', :branch => 'fcrepo4'
and ActiveFedora >= 6.4.
All of the Fedora 4-specific changes are constrained to the Rubydora fork. Everything else should just work. Some unit and integration tests that expect Fedora 3-like behaviors (DC, RELS-EXT, etc) may fail, but most end-user facing features should work unchanged.
Fedora 4 does not have some Fedora 3 concepts, like external and redirect datastreams. The sufia-based head does not use these features, but we expect they could be mimicked at either the Rubydora level, or created as an optional service at the Fedora level.
