Goals

1. resolve tension between solution bundles and flexibility
2. make our Hydra-based IRs more shareable (define a development process that facilities easier sharing)

Curate (ND/NU/DCE)

• uses Sufia for file-level functionality, does not incorporate all of Sufia's higher-layer functionality (views, etc.)
• adds functionality for intellectual works (e.g., to accommodate works w/o files)
• first two models added are article and dataset
• supports user collections and administrative collections, and the roles and workflows to support them
• supports project-level aggregation (pulls in project team members)
• provides user profiles
• supports embargoes

Feature backlog

• mediated deposit 
• metrics
• ORCID integration
• batch ingest (by manifest or another trigger)
• network location ingest
• proxy deposit & "delegates"

Governance

• how can/should Curate's governance (e.g., deciding on the feature backlog) evolve to accommodate stakeholders, specifically from other institutions if we're working more closely on shared solutions
  
  • look at Fedora 4 model for gathering input and gauging consensus

Sufia (PSU/ND/WGBH/DCE/etc.)

I was blabbing. TODO: add this later

Component architecture

A component architecture for solution bundles allows adopters to decide how they should reuse work other Hydra institutions have done. (Talking around the question of "how can, e.g., Stanford leverage Sufia or Curate?")

Levels

1. "Core" IR functionality (like Sufia or Curate) & plugin IR functionality
2. Bundle gem
3. App (solution bundle)

Next Steps

See IR vertical - how to work together

See graphic.