This document from May 2010 outlines the scope and development plan for Hydrangea Beta1. Feature numbers reference tickets in the MediaShelf instance of RedMine; as of August 2010, all future tickets for Hydra Plugin and Hydrangea are being tracked and managed in DuraSpace's JIRA instance.
Hydrangea is a Ruby on Rails application that incorporate the full functionality of the Hydra technical framework, all in a single demo application / reference installation. Running on top of Fedora 3.x and with solr 1.3 or greater, Hydrangea includes:
o with ActiveFedora gems
Hydrangea will be distributed with Hydra-Jetty copy of Jetty server that also runs solr and Fedora (for demonstration and testing purposes). It will have also have sample models and views that enable and demonstrate the deposit, editing and permissions management of Hydra-compatible objects and use cases.
For summer 2010, Stanford and MediaShelf will collaborate to
enhance ActiveFedora to support Nokogiri-based metadata editing, MODS editing in Ruby, MODS datastream support in AF, and optimistic locking (this is covered under a separate SOW)
create the Hydra plugin by combining existing code from SALT, ETD et al. with new development
bundle a full stack of Hydra components together into Hydrangea, as a reference implementation, demo application of Hydra's capabilities, and portable (locally installable) starter app.
Hydrangea's initial target is to provide beta-level code that can be picked up and run at other institutions and serve as a starting point for their own Hydra development efforts. Hydrangea will not initially provide a turnkey IR service; some development effort will be required to install and customize it at local institutions.
Hydrangea Functionality for Summer 2010 will demonstrate the following Hydra Stack capabilities:
Deposit of simple & complex objects (akin to the Stanford ETD solution);
Metadata editing (akin to the Stanford SALT solution), including support for MODS metadata
Searching & browsing (largely powered by Blacklight, in a SALT-like interface)
Object viewing (with customized object views, depending on object type)
A primitive Permissions management interface which will enable on a per object pasis the assignment of permissions to individuals or groups.
Permissions-aware deposit, editing, searching, and viewing
as powered by the Hydra rightsMetadata datastream
Application styling, to present Hydrangea in a polished, coherent visual design, based on the Blacklight demo application
Bundling components into a single, or small set of, distributable and installable packages (with documentation)
Sample models and views for creating, editing, managing and displaying Hydra-compliant Fedora objects
Unit tests, and excellent coverage via automated, continuous integration testing of the Hydra stack components
Out of Scope for Summer 2010
bulk loading of content into Hydrangea (ie through scripts/fedora utitilites)
complex sorting & grouping of search results (SALT implementation is specific to SALT metadata, minimal 'bang for buck' in demos)
bulk editing/management of content (ie sophisticated group & tag) – (out of scope for Hydrangea, but in scope for AIMS)
full MODS metadata editing support. The initial deployment will only support where MODS overlaps with ...
robust permissions management interface, integration with institutional authn/z infrastructure
externally managed content files
integration with institutional workflow systems and/or demonstration of complex workflows
djatoka distribution and integration
solrizer as JMS listener (solrizer) - possibly desirable as a future enhancement
integration of X-forms into Hydrangea as an advanced metadata editor
support for objects in externally managed storage
integration with FESL for authorization
Integration with Utilities
e.g., checksumming, transformations,
may be important based on identified use case
may not be feasible based on timeframe
Deposit functionality includes a singleton submission page that exemplifies complex submission/object creation (like ETD app). Core functionality should include a two-step submission process (Step 1 = upload, edit. Step 2 = review & publish by another party), along with the ETD-like progress panel (and green checkboxes). The "publish" function might be realized by coding a publish-button visible only to members of a designated group, which when activated would set discoverablity = world, visibility = world.
Note: is there an object/file first upload paradigm (akin to flickr, or Hull's private repository), in addition to the guided submission w/ checkboxes? If so, should Hydrangea's default functionality support this use case?
create new object by uploading file
upload file into an object
add file as child object
view & manage files within an object
view & manage datastreams within an object
Feature #733, Feature #727
permissions-aware editing of content
Access Control or Hydra Plugin
object submission / editing page with in-page workflow
support for two-stage, two party workflow ?
MODS Metadata editing will support the highest priority overlaps with Dublin Core: titleInfo, name, originInfo, identifier, typeOfResource, genre, language, abstract, tableOfContents, note, accessCondition, subject...
Lynn has done an analysis crosswalking MODS and DC, and rank sorting the fields of greatest interest and priority.
July 2010 target fields need to be guided by use cases. Regardless of the number of MODS fields supported, once baseline MODS mapping functionality is created, local development & contributions should enable the expansion of functionality to cover full MODS support over time.
upload file to create DC or MODS object
Feature #697, Feature #695
Feature #698, Feature #700
View DC Metadata
Edit DC Metadata
Create DC Objects through UI
View MODS MD
Create MODS object through UI
Permissions-aware, controlled access to metadata edit view
Access Control or Hydra Plugin
Search & Browse
MODS indexing into Solr (via Indexer)
Index rightsMetadata DS
Access Control or solrizer/Indexer
Permissions-aware discovery of objects
Content-aware behaviors may include label and order switching, icon / image toggling, links to delivery options. Is submission a separate interaction than editing?
content-aware and -specific deposit forms
content-aware and -specific editing forms
content-aware displays of objects
implied in other tasks
permissions-aware delivery of content
Access Control or Hydra Plugin
User Management (704 and 705): ability to create user accounts, login, and update user account (change password, email, etc.). Set user group memberships in a config file (with no interface). Set read, discover and edit permissions for users or for whole groups per object.
User management & permission editing with user & group permissions
AuthLogic in Hydrangea
Feature #704, Feature #705
UI for managing permissions for uses and groups
Hydra plugin ?
Hydrangea Styling & Bundling
Bundle Hydra rake tasks w/ Hydra Plugin
Define settings range and default config for AF, BL and solrizer
Hydrangea Styling & Brand
Remove SALT-specific code from Hydra
Hydra Plugin or Hydrangea?
Clean up and finish off Hydra helpers
editable MD, downloads, etc.
Hydra/Hydrangea production deployment instructions
Rake tasks for hydra jetty
Rake tasks for loading all hydra fixtures
specific use cases for
content-specific deposit forms
accounts, account management, authorization
how do AuthLogic, rightsMetadata, solr and FESL interoperate for a cohesive authz strategy?
specific use cases for permissions management, and UI development
Hydra Plugin (or core)
Shelver v. solrizer v. Indexer
UI Mocks ? (When, What interactions?)
what are the use cases and object types for OR10?
schema-validation for MODS work? When does this happen? Nokogiri supports syntactic schema validation natively. Semantic schema validation will happen later in development, and possibly as an autonomous process.
specific version of MODS needs to be selected for support = MODS 3.2