Hydrangea Beta1 Scoping Notes and Development Plan

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:

• Hydra plugin
  o with ActiveFedora gems
• Blacklight plugin
• Solrizer

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

1. 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)
2. create the Hydra plugin by combining existing code from SALT, ETD et al. with new development
3. 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
• gallery view (should be re-done with book cover javascript, or use gallery views in BL core (ETA = summer?)
• 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

Work Breakdown

Deposit

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?

Metadata Editing

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.

Search & Browse

Object Viewing

Content-aware behaviors may include label and order switching, icon / image toggling, links to delivery options. Is submission a separate interaction than editing?

User Management

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.

Hydrangea Styling & Bundling

Open Issues

• specific use cases for
  • content-specific deposit forms
  • content-specific editing
  • content-specific display
• 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
• terminology
  • Hydra Plugin (or core)
  • Hydrangea
  • Shelver v. solrizer v. Indexer
• UI Mocks ? (When, What interactions?)
• what are the use cases and object types for OR10?

Notes

• 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