Implementing a DAMS
•Als PPTX, PDF herunterladen•
0 gefällt mir•353 views
Power point for MARAC fall conference 2011 on digital asset management systems. Focused on the implementation of a DAMS at the Historical Society of Pennsylvania. Presentation by Matt Shoemaker, Director of Digital Collections and systems at HSP.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie Implementing a DAMS
Ähnlich wie Implementing a DAMS (20)
Mehr von MARAC Bethlehem PC
Mehr von MARAC Bethlehem PC (7)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Implementing a DAMS
- 1. Matt Shoemaker Historical Society of Pennsylvania mshoemaker@hsp.org October 22, 2011
- 2. Primary function: Manage your digital assets! It may or may not also provide: ◦ Access ◦ Distribution ◦ Discovery ◦ E-commerce ◦ Workflow management ◦ Digital Preservation Often these services are provided by other systems Commonly these systems are silos
- 10. Legacy data Working with an open source system ◦ Work closely with developer for testing, implementation and troubleshooting Smaller knowledgebase ◦ We get to be the guinea pig ◦ We get to help shape improvements …but they may not be as specific as we would like ◦ Timetables can be an issue Integrating with other Systems VuFind, Archivists’ Toolkit, Drupal
- 11. Matt Shoemaker ◦ mshoemaker@hsp.org HSP’s front end ◦ http://digitallibrary.hsp.org Collective Access ◦ www.collectiveaccess.org
Hinweis der Redaktion
- HSP originally used an MS access database for its DAMS-System utilized fields based on Dublin Core-Also used to track Rights and Reproduction orders and generate usage agreements-Managed file locations, names, and basic metadata-Did not handle any functions beyond asset management and basic R&R tracking and form generation
- With the Digital Center for Americana Project we sought a new DAMS-Collective Access chosen, primarily because we were also using it for Philaplace backend-Open source system-Developed by Whirl-i-gig-Allowed great flexibility-Able to work with developer to customize the software-We wanted our Philaplace instance to communicate with our main DAMS
- (go through system feature slides quickly, just an overview)The front end provides-several ways to search-customizable displays for audio, video, images and other digital documents
- For images it provides both a book viewer application for records with multiple imagesAs well as an image viewer with a more powerful zooming and panning features for scrutinizing images
- Back end allows easy management of metadata in a variety of catagories
- Backend also allows for easy management of files
- E-commerce module in the works will be implemented soon following testing-Will also manage R&R workflow and tasks
- All of these features are great, but how did we get there and was it everything we were hoping for?Garbage in, garbage out. Not all of the legacy data was good. Changing from digitization driven by R&R to digitization for access and building digital collections.Metadata quality between systems, and from getting used to the new one, is at times inconsistent (workflow and legacy issue more than system)Open source isn’t necessarily the easiest system to get up and running, though Whirl-i-gig does what they canto assist.The base program can change quickly and documentation may not be up to speed. Often you need to troubleshoot with the dev. team on issues,Especially after software updates.The system needs more staff knowledge to run effectively than many proprietary systems. Simply less options for external help.While we get to help shape improvements with the software, we also need to help do some of the testing on them. This results in a betterend product for us but can be frustrating for staff users (not necessarily system staff) as features come and go and are improved (or at least changed)and as we test features to make sure they work in a fashion.Improvements need to be useful to the community as a whole, as this means sometimes features you really want or need get pushed below others, and some features are implemented but in a way that they are more broadly useful than for your specific situation.The system is also somewhat siloed. There are two Drupalplugins we plan on implementing that will allow us to better integrate the system with HSP’s website. We also want to find ways to easily integrate assets into the finding aids we generate through AT, as well as make the assets more discoverable byintegrating them with VuFind, which we use as our discovery layer. These things are achievable with some creative scripting and other programmatic conventions,But are not native to any of these separate systems or tools.