A Little Sweat Goes A Long Way - Museums and The Web 2016
•Download as PPTX, PDF•
1 like•358 views
This document summarizes the Art Institute of Chicago's experience building a digital asset management system using Fedora and related open source frameworks. It discusses two approaches they initially considered: [1] heavily customizing Fedora which proved too complex, and [2] using vanilla Fedora with specialized technologies like Hydra to handle additional functionality outside of Fedora. The second approach worked better by leveraging existing work. Key benefits of the Fedora ecosystem noted are its community-driven development, integration capabilities, and transparency from being open source. The document encourages other museums to consider reusing code and collaborating within these communities to more efficiently develop digital asset systems.
Recommended
More Related Content
Similar to A Little Sweat Goes A Long Way - Museums and The Web 2016
Similar to A Little Sweat Goes A Long Way - Museums and The Web 2016 (20)
More from Stefano Cossu
More from Stefano Cossu (12)
Recently uploaded
Recently uploaded (20)
A Little Sweat Goes A Long Way - Museums and The Web 2016
- 1. A Little Sweat Goes a Long Way Or: Building a Community-Driven Digital Asset Management System for Museums Stefano Cossu, Director of Application Services – The Art Institute of Chicago David Wilcox, Fedora Product Manager – Duraspace
- 3. Initial Status (2013) CITI: Custom-built Collection Management System (est. 1990) Several other applications relying on CITI CITI handles images and other files for collection items Our requirements: A dedicated system to preserve, manage and publish digital assets A place for all collection-related documents Seamless UX and integration with live CITI data
- 4. No precedent for museums Not a “turnkey” solution Completely new concepts and technologies New version in alpha stage All bad selling points A Little Sweat? Not Really.
- 5. Approach #1 (And Why It Did Not Work) Fedora does nearly everything Fedora 4 focuses on a minimal feature set to serve a specific role in a larger architecture Fork off code base, contribute back later if relevant Creates bloatware and one-off implementations hard to work collaboratively with Develop custom service layer, API and front end Have you ever tried that? It is a lot of work!
- 6. Approach #2 (A Year Later) Fedora is only a part of the architecture Clear role separation, aligned with other implementers Use vanilla Fedora code Build additional functionality outside of Fedora using specialized technologies maintained by someone else Use a shared project for business layer and front end (Hydra) and customize that to fit our workflows This takes a great deal of work off of our plate
- 7. The Plan Design and Research: 1 year Final Design: December 2014 Basic Framework: 1 year Beta1: December 2015 Production, limited adoption: 6 months 1.0: June 2016 Full-scale adoption: 6 months 1.1: December 2016 Total: 3 years
- 8. Fedora Beyond The Code
- 9. Fedora Facts Managed by DuraSpace (not-for-profit) Funded by the community Collaboratively developed by the community Supported by 2 full-time staff members (not developers)
- 11. Fedora Committers Ben Armintor, Columbia University Chris Beer, Stanford University Aaron Coburn, Amherst College Esmé Cowles, Princeton University Osman Din, Yale University Mike Durbin, University of Virginia Nick Ruest, York University Adam Soroka, University of Virginia Jared Whiklo, University of Manitoba Andrew Woods, DuraSpace
- 12. Fedora Leadership Group Julie Allinson, University of York Chris Awre, University of Hull Rob Cartolano, Columbia University Aaron Choate, University of Texas Tom Cramer, Stanford University Stefano Cossu, Art Institute of Chicago Dan Coughlin, Penn State University Jon Dunn, Indiana University Sarah Fredline, University of NSW Robin Ruggaber, University of Virginia Glen Robson, National Library of Wales Dan Santamaria, Tufts University Kelcy Shepherd, Amherst College Steve Marks, University of Toronto Sandy Payette, Cornell University Jim Tuttle, Duke University Keith Webster, Carnegie Mellon Evviva Weinraub, Northwestern University
- 13. Community-Driven Feature Development Use cases are gathered from the community People with common interests form groups Groups gather requirements, implement, and test new features
- 14. Hydra + Islandora Popular frameworks based on Fedora Provide search, discovery, theming, workflows, and more Collaboration between members of all three communities Hydra-in-a-Box provides a turn-key solution
- 15. Working Together Toward Interoperability Adopting common, open standards Integrating specialized components using common patterns Leveraging linked data best practices
- 17. Lessons Learned While Building LAKE Maybe we are not that special Some needs can be adapted to the existing framework, not the other way around Don't write code if we don't have to And when we have to, ask around if somebody is doing the same thing Others don't need to go through this Share experience and code; create communities; Hydra In A Box as a potential low-barrier approach to a museum-focused ecosystem
- 18. Added Values Learned Underway (Meta-Features) Community The backbone of healthy software Ease of integration Your DAMS is not the Almighty Transparency Open Source, Open Agenda, Open Pockets
- 19. An Alternative Way to Produce Software Community Source is different than just Open Source And sometimes a very different approach Open Source ≠ free But open governance means that you know where your money is going Shift resources' focus Less coding hours, more community engagement and coordination
- 20. Thank You More info: http://fedorarepository.org http://hydrainabox.projecthydra.org Ping us: dwilcox@duraspace.org scossu@artic.edu