SULAIR Home

Fedoraless Hydra

Fedora-less Hydra

Revisiting of topic from last year. Good to revisit the idea of
repository agnostic hydra use-cases from time to time. Keeps
discussions & development grounded.

Fedora Futures & Fedora 4 may reduce need for alternate persistence layers.

Looking at UCSD DAMS approach of setting up their homegrown repository
to speak a subset of the Fedora API, putting Hydra on that. A good
starting point is to review & identify the subset of the API that
Active Fedora uses.

Concern about this approach being a shim, having a system spoof the
API so that AF can speak with it, which is already a shim that's
spoofing (or at least an abstraction of) Active Record.

Corey's current use-case doesn't require repository functionality.
Metadata only repository. Examples of metadata only using Fedora &
Hydra? (Yes: WGBH, Stanford, many others.)

Concerns about scalability, speed, for large quantities of metadata
only content -- lots of transactions. Fedora is shardable, so should
scale, plus queuing with something like Resque
(https://github.com/defunkt/resque) can help with transaction heavy
applications. Sufia (https://github.com/curationexperts/sufia) is
using this.

3-4 options (For Triple-only MD-only use-case)
* Use Hydra over Fedora API w/ whatever persistence layer you want
(UCSD Approach)
* Use Fedora outright -- experiment with Resque & sharding
* Further abstraction: re-write Active Fedora to become "Active
Datastream", which then could have adapters for Mongo, DAMS, Fedora,
Triplestores, etc. (Some at Data Curation Experts were advising
against this approach -- AF is pretty baked-in to Hydra, and the
refactor may not provide much)
* Don't use Hydra at all -- without the access control component for
the non-MD datastreams, Hydra may not be much of a value add here.


« Back