This presentation is a case study of the Art Institute of Chicago’s DAMS project.
LAKE, the AIC DAMS, is entirely based on modern Web standards and open-source software built in collaboration with several cultural heritage institutions. Its first beta release was launched in September 2016 and a full release is planned for early 2017.
In this session we will describe: 1) the scenario pre-dating LAKE; 2) the thought process and design phase that led to choosing the technology we are using; 3) the implementation steps and challenges; and 4) the current status and plans for expansion and long-term sustainability.
1. The LAKE Experience
Stefano Cossu, Director of Application Services, the Art Institute of Chicago
Kevin Ford, Senior Software Architect, the Art Institute of Chicago
Museums and The Web 2017—Cleveland OH, April 22nd 2017
A Voyage Into Unknown Museum DAM Waters
(And Back)
2. Rise & Decline of City–States
● Home-grown software
● Home-grown cataloging practices
● Proprietary vocabularies and authority lists
● Department-specific file & metadata stores
Not So Long Ago:
https://commons.wikimedia.org/wiki/File:Cinta_muraria_di_Palmanova.jpg
Perfect for a self-contained system
3. Rise & Decline of City–States
Suddenly:
https://commons.wikimedia.org/wiki/File:16th_century_Portuguese_Spanish_trade_routes.png
https://commons.wikimedia.org/wiki/File:Ralamb_Sipahi.jpg
4. Rise & Decline of City–States
● Data fragmentation
● Changing cataloging practices
● Integration is a challenge (if
ever possible)
● Data preserwhat?
● Spreadsheet infestation
Hence:
https://commons.wikimedia.org/wiki/File:MS_Ghent_-_Battle_of_Tewkesbury.jpg
5. Here We Go
● Clear separation of purposes
● Emphasis on communication channels
● As little custom code as possible
Alright then:
https://commons.wikimedia.org/wiki/File:Ship%27s_limited_channel_effects_(Blockage_Effects)_NT.PNG
6. Here We Go
● Collection Management
● Digital Asset Management
● Preservation
● Image ordering, production and delivery
● Publishing to Web, trusted parties and other channels
We Will Integrate:
7. Here We Go
● Images (pretty and ugly)
● Interpretive media
● Curatorial and Registration paperwork
● Conservation documents
● Institutional archives
● And much more...
We Will Store:
● Works (Objects)
● Agents
● Places
● Exhibitions
● Transactions
● Shipments
Related To:
10. Here We Go
● LAKEshore → DAMS (Hydra)
● Combine → ETL (custom Python code)
● LAKE repo → Institutional repository (Fedora)
● Geneva → Event framework (Apache Camel)
● Indices → Solr, triplestore (Blazegraph)
● LPM → LAKE Public Mirror (Fedora + Solr
+ IIIF server)
Resulting in:
11. Whither LAKE?
● Research & Design learning curve
Completely new concepts
Completely new technologies
For Starters:
● Implementation issues
Alpha software
Upstream development timeline
Legacy systems grumbling
Followed By:
12. Whither LAKE?
● Data Mapping (empathy please)
Decades of changing conventions
● Data migration
285K images, 50Tb
Scaling: tiny issues become huge
Performance & monitoring
On the Side:
● After full-institutional release
Long-term sustainability
Adoption management
Scheduling digitization projects
For Dessert:
16. Whither LAKE?
● Necessary with complex workflows
● Beautiful when it works
● Use tools to monitor the path of messages
● Users too must understand UX implications
Asynchronous Architecture: Lessons Learned
18. Was It Worth It?
Yes:
● Deeper understanding of our data & systems
● It's working! (>600K resources in production)
● Achieved better data quality and access
● It is expandable
19. Was It Worth It?
But:
● (Significant) specialized skills required
● Still a lot of work to do
● Long-term payoff → Hard to sell
20. Was It Worth It?
But, Yes?
● Long-term advantages are just beginning to show
● LAKE is open source
● Container technology can simplify adoption
● Anyone interested?
21. Thank You
Stefano Cossu scossu@artic.edu @industrievisive
Kevin Ford kford1@artic.edu @3windmills
https://github.com/aic-collections/aicdams-lakeshore/