Introductions

Real Folks

Tom Cramer - dislocated knee in 8th Grade
Bill Parod
Gary - Something with puppets ?
Nicole - likes to fly tail draggers
Mike - talked to Oprah on the phone
Bess - drove to arctic ocean (Ice Road Trucker!)
Steve - severed tendon
Matt - teaches meditation
Robin (UVA) - designed stain glass windows
Karen - quit tech (?) job to become lib.
Brad - prof. lightening designer who dialed 9 for Dionne Warwick
Johnathan - plays jazz piano
Rick - boxed
Claire - herniated disk
Stu - been to all 50 states
Adam - musician
Eddie - moved to singapore
Dan - rocket enthusiast
Ragesh -
Jessie - plays bass guitar
Richard (Hull) - clematis flowers
Naomi - played in NWU orchestra

Julie (UVA) - in airportland

Skype Folks

Partner Updates

Tom says, try to build a tech and com. roadmap as we go. Take good notes about who is going what and what they want to do next.

Notre Dame

Rick:
Deploy at end of the month. http://seasideprod.library.nd.edu

Blacklight, rails3, feeding off of data from Fedora. HH dev not finished, so pub portal is just blacklight. HH is comming that will enter data. Needs final touches on static pages.

Dan: BL instance with pluggins to extend it. Each serach result pulls in data from solr... solr data populated from previous libra/hydrangea app. wants to o back/forth from google maps and BL app

R: materials are all about arch. of the town. drawings of buildings. mixing metadata types. vracore and archival holdings in ead. mixing them. linking them with rdf via fedora.

Fedora model? linked by relationships. each entity has its own object. structure and architect are their own with their own vracore datastream. they're linked to a parent ead record. based on the component level – components and nested components are their own F. objects. map to google maps using lat on long. coordinates and toggle back and forth.

digital exhibit code is the example of this: Atrium. Atrium provides a browse view. Different collections needed different browse functions. Created hier. facets in a rails2 HH.

create an exhibit and edit settings so that different parts of it are displayed using different facets (awead: need more explanation)
requires entering a corret solr search string. allows you to define custom facets and hierarchical facets for a specific exhibit.

In progress: have multiple browse sets, such as browsing by architect or ???

Collection level display? That's TBD. Along with creating narratives and "landing pages" for each collection.

Compared to Omeka? Not feature for feature.

Mirrors how HH is built, put on top of rails3 code with similar generators.

Hydrangea code used for data entry and linking the objects to one another.

Should it just be a blacklight plugin or a Hydra plugin?

Submitting EAD? Yes and No. Some managed within Hydra, others are fed in and F. objects are generated.

F objects? Unique ID at each level of the EAD to created F. objects

EAD and VRA? Each is its own object with an rdf relationship that links them

Linking? Hydrangea manages Fedora data then solrizer puts it all into the solr index that's running BL.

What's next? Fully functional site by March...

NU

Nicole: PSDS - Prod. Suupprt Delivery System. unifies digital collection workflow for images. Currently in Drupal. Also DIL: vracore editor using Xforms... looking to combine the two and use Hydra to replace the DIL functions.

Mike: Jobs and items. Jobs contain several items, or just items can be alone

http://psds-stg.library.northwestern.edu

Jobs have statuses with tasks that can be flagged off or on. Flag settings determine status. Workflow is "fluid" so you can go back at any point and do things.

batch processing: folder on external server with images. batch process uses JMS, apache Camel and shell scripts. creates drupal items and F. objects for each image and image processing: conv. to JP2, tech metadata extraction, push source image to archival s erver, and jp2 image to access server, convert tech data from XFtool to MIX.

VRA editing tool allows you to edit metadata.

can upload images from local machine. Hooks into LDAP for looking up submitters and requestors.

STOMP protocol with JMS and RPC calls facilitates communication between Drupal and VRA editing

Steve:

Why Drupal?? Was too far along when Hydra cam along. So, finish up Drupal and use Hydra for DIL front-end system Drupal runs more of the back-end stuff. Hydra can do authentication... long-term, move everything to Hydra.

Drupal features needed later? No, because workflow system is separate.

Claire: workflow jobs will be put into Fedora as well.

Ingesting? Bill: when image is uploaded through Hydra, message sent to backend... image is copied, processed and action is invoked to create object and Hydra would be notified.

Mike:

Delivery... faculty gets email that image is complete and approved, along with link to image in catalog.

Roadmap? Steve: finish up PSDS (Drupal) next month, then DIL (Hydra) starts, work for a few months until Feb/March, then potentially switch to VoV (Variations on Video). using scrum.

Claire: EAD is done with Archon. Watching ArchivesSpace and interested in Hyptia. Long term to bring EAD and digital content together.

Bill: Fedora is preservation archive. EAD managed in Archon. EAD is put into Fedora and indexed in Solr. item level is a dissemination of the ead:

http://findingaids.library.northwestern.edu/

Rock Hall

Status

Blacklight app with EAD support: 2,500 MARC records and 114 finding aids
Hydrangea app with PBCore metadata support, SIP definitions and ingest methods
Virtual environment for Solr, Fedora, MySQL and Rails
10 TB of disk for access-level content
Up to 600 TB of LTO5 storage for preservation-level content, duplicated at 2 offsite locations

Timeline

One Month: Begin ingesting/cataloging 1400 hours of induction ceremony video with Hydrangea
Within 3 months: Move to Hydra with Rails3 and refactor user interface
Within 4 mos: Release finalized Blacklight application with MARC data, finding aids and content from Hydra
January 2012: Library soft opening in January
Before April 2012: Refactor/tweak/fine-tune
April 2012: Library grand opening in April 2012 to coincide with induction ceremonies in Cleveland

PBCore

version 2
full document stored in one Fedora object
additional pbcoreInstantiation nodes stored in child objects
not technically “valid” due to node order requirement
OM's behavior with attributes as variables require some additional nodes to be inserted first – there are Jira tickets that address these issues

Fedora model

atomistic
parent object contains metadata and instantiation metadata about physical video tape
additional child objects contain instantiation metadata for one or more multiple access and preservation file types
data content are externally referenced files stored outside of Fedora and accessed via HTTP

Short-term Goals

video cataloging, streaming and preservation
integration with “traditional” finding aids (via Blacklight w/ EAD plugin) – right now, plan to just export Hydra content to Blacklight
move to image and document collections: modeling, dissemination, preservation

Long-Term Goals

integrating digitized materials from archival collections
combine our Hydra and Blacklight applications into one
content models, metadata and ingestion procedures that work easily with different types of collections
institutional repository for Rockhall staff
workflow management (Ruote gem?)
born-digital content (Hypatia?)

Partners Meeting Plenary Topics

Hydra-Head - What do we need to do with the software right now

What will it take to finish the release
What will it take to refactor to rails3
How to flesh out the content types? / What content-types (data models?) should be in the hydra-head plugin?

Proposal: Rails3 and rest of UI refactored.
Status:
- 20 cucumber tests failing.
- Controller review discussion needs to complete.
- Estimate is "two days" work to be completed for tests and merge for 9/19/2011 call.
- Need to have J-Team review (starting immediately after merge completes) to ensure nothing is missing by 9/23/2011.
- Fixes to follow.
Timing:
- RC: Happy Path is 9/23/2011
- Release: 9/30/2011 or 10/3/2011 if no negative feedback.

Proposal: currently have MODS asset; propose a second fixture that works with just simple underlying Fedora objects using the DC datastreams.
Discussion:
- Nice to have ability to drop hydra on any existing Fedora and have it work? Maybe not because it perpetuates a misuse of DC in Fedora.
- Would like two different exemplars of MODS, ...
- Hydrangea did exactly that; articles using MODS and not using MODS - hypothetical use case that lead to kludges and then UI on top - killed Hydrangea.
- How about grabbing fixture objects from Hypatia that are using MODS and pull them into Hydra-Head? Want to beef up the supported types in the generic Hydra-Head - some beyond just MODS. What do you do if you have objects that don't match models - no tests available.
- Generic DC object would be useful as LCD in library space. Better candidate than data sets or ETD.
- Is this a pure example, or actually useful? Purely example; we can't predict what is genuinely useful.
- Even if we release with all irrelevant models removed, we will still have the generic code that doesn't use the same structure as MODS; so either we keep it and generate tests for it, or we have to have different exemplars.
- Should use the exemplars from Hull that range from generic to specific. We should pull this in as the fixtures that exercise the code and provide reference materials.
- Agreed, but we should also grab some fixtures now (from Xanadu?).
- Conclusion: Excise the legacy code, add a second content type that is Xanadu. Bring back the code from Hull as it becomes available. Desirable to have for 3.0 release, but not a must-have.

Proposal: Only have Phase2 UI; Phase 3 won't be ready for 10/3/2011 release; so add it afterwards in a 3.1 release.

Hydra-Head - Code collaboration and management

Move to Quarterly releases w/ release manager?
relative merits of time-based releases to feature-based releases
is Hydra mature enough to move this structure
release manager: responsibilities & rotation of roles
Hydra vs. distributed component-based approaches (hydra_head, OM, AF, solrizer, heads)

Discussion

Using semantic versioning today
- Major number bumps for incompatible changes
- Minor number bumps for new features
- Point number bumps for bugfixes
Should we just announce when the next release will be (approximately)
Should we just aspire to quarterly releases?
Not enough cycles to devote to the release process.
Should we just release as we are comfortable?
Should we have a rotating release manager? Responsibilities are:
- Tracking the dependencies and schedules of subprojects for sync.
- Driving weekly committer's calls.
- Preparing and cleaning Jira tickets before and after the meetings.
- Wiki gardening / doc management.
- Keeping an eye on the release (clean installs, etc). Coordinating.
- Note that these responsibilities can be split amongst multiple people, but need to be backstopped by a single responsible party.
Proposals:
- Start with aspiration goal of quarterly releases
- Stewardship role: Release manager for each release
  - Ensures that the goals are discussed at each meeting and report to the partners
- Quarterly rotation of release manager. UVA for Dec?
- Matt will help to coach initial RMs.

Community

Enrollment Updates - Talks, Queries and Responses
Communication - How to most effectively use our tools and our time