Charged!
By the Technology Services Council to:
Review and provide an analysis of our current DAMS
(CONTENTdm), and other content management systems
Receive input/feedback from users of current and other
DAMS
Compare features, issues, and functionalities of other DAMS
to ours
Proposal:
◦
The potential of segmenting DAMS on the basis of needs of
different types of content
◦
Proposing a single solution that addresses most needs
•
Capacity for timely accommodation of
feature requests or fixing known problems
(OAI)
•
Local customizations get broken/have to be
ported for upgrades
•
Features appear and disappear (my favorites)
•
Does not support all our content types at the
same level (EAD)
Showcases a wide variety of materials:
◦
Subject matter/media
Digital photographs, newspapers, maps, books, audio
and video recordings, and various other formats items.
◦
Over 450 Digital Collections
◦
Over 2.5 million Digital Objects, and growing…
UDN = 1.5 million pages
CDMbuntu = 1 million objects
Highest no. of objects in CDM, anywhere
◦
Formats
jpegs, jpeg 2000s (zoomable files), pdfs, epub files,
UU-Marriott Library- Information Technology
Services
UU-Marriott Library –Scholarly Resources &
Collections
UU-Marriott Library – Special Collections
UU-Marriott Library - Research and Information
Services
UU-Eccles Health Sciences Library
UU-Quinney Law Library
First meeting in: January of 2013
Initial deadline by TSC: May 2013
Deadline extended twice
(To accommodate for) Open source
DAM REVIEW
SOFTWARESELECTION Working Group Scope: look at other peer institutions and PAC12 Institutions ANALYZE USER SURVEY Takeaways- Considerations for Stakeholder Analysis- patron needs pertaining to DAMS Criteria STAKEHOLDER ANALYSIS (IR, SPC, FA, UDN, Eccles, Quinney) Identifying stakeholders for
types of content and keeping their needs in mind in relation to building
out the Requirements Criteria TESTING • Sandbox setup • Hardware/Softwar e requirements • Other FINALYZING S/W LIST FOR REVIEW Scope: limit list to
10
Ensuring that final list of platforms gauge well against
Requirements Criteria
REQUIREMENTS CRITERIA (9 Dimensions) Ensuring the criteria
meets needs of all different formats in Digital Library EVALUATION CRITERIA • Scoring • Baseline • Cost-benefit analysis • Resources DEVELOPING BASELINE Scoring current DAMS INFORMATION GATHERING • Contacting Vendors • Contacting Institutions/Clie nts/Users of platforms • Conference Calls • Presentations (in-house and online) • Webinars VENDOR/CLIENT PRESENTATIONS • Online • In-person • Recordings SCORING SESSIONS (of Platforms) Criteria: • Vendor/Client presentations • Baseline DERTERMINING BASELINE Scoring of currents DAMS (CONTENTdm) DETERMINING DELTA • What other significant improvements are required to justify the change? • Costs?
Stakeholder Analysis
Software Selection
Requirements Criteria
Vendor Questions List
Scoring Model
UDN
First time visitors
26%
At least monthly
55%
Genealogists
63%
Accuracy good/excellent
64%
Will return soon
77%
More knowledge of fam hist 62%
Found new sources
66%
From outside Utah
43%
Overall good/excellent
80%
Most frequent suggested
improvement:
ADD MORE CONTENT
CDMbuntu
•
Overall good/excellent
72%
•
Navigation good/excellent
72%
•
Site layout good/excellent
64%
•
Positive feedback on UI
62%
•
Relevant, accurate searches
62%
•
Most frequent suggested
improvement:
CONTENTdm
Rosetta
Equella
Omeka
Cumulus
ChromAm
Bepress
XTF
Hydra
MDID
NWDA
CONTENTdm
◦
Online presentation by OCLC
◦
Gave it a score
◦
Established that score as our
baseline
Rosetta
◦
In-house presentation by
Exlibris
◦
Rosetta currently not able to
meet the needs of a true
DAM- does not sufficiently
meet our Requirements
Equella
◦
Teaching and Leaning
Technologies (TLT) on
campus, heavy users
◦
Scored low
◦
Group decided it did not
meet basic criteria
Omeka
◦
Main strengths lie in the
presentation and exhibits
display
◦
Omeka team did not
respond enthusiastically to
Questions list
◦
It did not meet the main
Requirements Criteria
Canto Cumulus
◦
Large scale deployments of
Cumulus
◦
Customers include Intel,
Bank of America, NASA, etc.
◦
Limited OAI support
◦
No support for Dublin Core
◦
Not suited for Digital
Libraries
◦
Did not meet basic criteria
ChronAm
◦
Demonstration of content in
ChronAm versus content in
UDN
◦
Scored on 2 dimensions
(technical Infrastructure, and
Patron ease-of-use)
◦
Required provision for
support of article level
metadata missing
◦
Potential for becoming
Hydra head for newspapers
◦
Decision to table ChronAm
until further development
along the process
Bepress
◦
Scored only as an IR
platform
◦
Cadillac solution for IR only
content
◦
Expensive
◦
Decision to table Bepress
until further developments
on the Open Source front
NWDA (North West
Digital Archive)
◦
Scored only as a solution
for EADs
◦
One workflow for adding
and editing items
◦
Works great from the
user’s perspective
◦
SPC using NWDA until
further developments on
the Open Source front
MDID
XTF
9 Dimensions
◦
Patron ease-of-use
◦
Types of content
◦
Ingestion/conversion/barriers to exit
◦
Collection administration
◦
Metadata administration
◦
Integration with other library platforms
◦
Technical infrastructure/administration
◦
Support
◦
Future/strategic directions
Full requirements criteria available on webinar page,
http://mwdl.org/events/DAMS_options.php
End-user experience
◦
Intuitive, easy navigation
User display settings
◦
Zoom, rotate, download, print, sort, no. items per page, other user
customizations
Search accuracy
◦
discoverability of the content
Handle all formats in similar fashion across all browser types,
operating systems, and mobile devices
Size of the patron base
Advanced search options
◦
Selecting collections/content to search
◦
Multiple fields
◦
Boolean operators
◦
Searching within results
◦
UDN: Date searching (by date range, before/after specific date)
Major content categories
◦
IR
◦
EAD
◦
UDN
◦
Everything else
File types and datasets
◦
ead files, xml, csv, tab-delimited, zip, epub, ppt, url, kmz,
tiff, jpg, jp2, mp3, mp4, pdf, ppt, etc.
Tiers of content (both object and item level)
◦
UDN: 3-tiered data structure - issue, page, article
Streaming
◦
Streaming capability, based on media types, file types, user
connection, device type (including mobile)
◦
Adjustable feature to determine bandwidth, device, etc. for
best possible
New content
◦
Ability to load batches of data
◦
UDN: Ingest batches in NDNP METS/ALTO format
plus article.xml files
◦
Create derivative images
◦
Run OCR
Convert existing collection data from CDM
Barrier(s) to Exit
Content access, security
Metadata options
◦
Configure for each collection
◦
Import/export
◦
Support for common metadata standards (Dublin Core, MODS, EAD, METS,
etc.)
Faceting
Editing capability
◦
Batch editing
◦
Find-and-replace
◦
Thumbnail editing
◦
Movement of objects between collections
No character limit on metadata fields
◦
*CDM’s current limit is 132K
Copyright
◦
Ensuring authenticity and integrity of objects
◦
Flexibility with metadata templates to be able to add appropriate
copyright statements
◦
Control over download file size
Full text search capability (OCR)
◦
*UDN: full-text within article-level metadata.
SEO
Design of interface
User permissions
Ability of collection mgr’s to do appropriate levels of
maintenance
Website configuration
◦
Display template customizations
◦
Client logos, sort options, fields displayed, etc.
Statistics / Reporting / Logs
◦
Reporting capability by collection and item level.
◦
Item level urls should include collection alias and item #s
to allow for filters
◦
Ability to attach Google Analytics into the reporting
structure
◦
Human read-ability of url
Primo
◦
OAI harvesting
Rosetta
◦
Link display object with archival object using ARK
Scale-ability of collections/content
Hardware/Server(s) specs - operating system, RAM, data
storage
Virtualization of the server(s)
Multi-threading of processor(s)
Automated/scheduled data repairs
Scheduling "Cron" jobs
API support
Single Signon - interfacing with CAS
Open standardness / non-proprietary
Language and Framework
Backups
Design of interface
System and server installation, configuration, and upgrades
Userid Admin / Permissions
Training
◦
Training manual
Help Desk
◦
Online, chat, phone
◦
Expected response time
Web 2.0 / Social
◦
Publishing ability/permissions/ rights management
◦
Comments/tags
◦
Social sharing, tagging, etc.
Meet evolving technologies
◦
Linked data
◦
Crowd sourcing
◦
Capability to transcribe an audio file or and audio
track of a video file
Tier 1 Scoring
◦
Based on user experience, knowledge, and research
Tier 2 Scoring
◦
Based on in-house and online demos
Process of elimination
◦
Using CDM as baseline
◦
Systems scoring lower than CDM, eliminated from review
process
◦
Scoring model available on webinar page:
http://mwdl.org/events/DAMS_options.php
Vendor based solutions not scaling to the
needs of our growing digital library
Need to possibly explore a different option?
Open source?
Two systems under review for Open Source
category:
◦
XTF
◦
Hydra
Looked at the possible implementations of
Requires a shift in approach for our digital
library
Cultural shift in libraries
Requires dedicated staff in place of vendor
support
Opportunity to develop our own code and
features
Opportunity to engage with community of
Code managed on Github:
https://github.com/projecthydra
Lead Institutions:
◦
Stanford, University of Virginia, Hull, Notre Dame,
Northwestern, Penn State, and more.
•
Open Source Repository System
oDAM Support
o
Preservation Support
•
Supported by active community and
Duraspace foundation,
Case studies, screencasts, and
documentation available at:
http://projecthydra.org/apps-demos-2-2/
•
Fedora - Open Source Repository System
oDAM Support
o
Preservation Support
o
Supported by active community and Duraspace
foundation,
http://www.fedora-commons.org/
Blacklight – discovery interface
Apache Solr – search and indexing
Ruby on Rails – Development language for
•
From call with Stanford, "General pattern is an engineer and
analyst/UI developer bringing an institution online in 6-8
months while working on Hydra and other responsibilities"
-Note this reflects a single Hydra project (eg only an institutional
repository)
•
At Duke University they started with 2 part-time developers who
now both work on Hydra full-time.
•
At Tufts, they had an existing Fedora repository. For their
environment, switching to Hydra took 1.5 FTE with an additional
1 FTE from an archivist. Maintenance takes less than the 2.5 FTE
allocated for development.
•
Northwestern development of Hydra-based MDID replacement
took 2 years of .75 FTE programming with additional project
management, user management, and UI support on project
team.
•
Marriott Library has formed a Hydra Development
group.
•
Attended HydraConnect at UCSD recently.
•
Have begun initial development.
•
Needs of University of Utah require multiple Hydra
heads displaying multiple types of content.
•
We estimate 1-2 year
minimum
development time
depending on staff time and resources, and
feature requests/requirements.
Situation being analysed:
Marriott Library’s
current DAM System (CONTENTdm) and
Strengths:
For current, locally hosted solution
• Familiarity of system and features (users already
trained on system; 10+ years of technical and administrative experience)
• Ability to customize display layer
• Able to update meta-data in bulk
• Able to integrate with other library/university
applications
For OCLC’s future (hosted) cloud-based solution
• Reduction in technical staff (e.g. server
administrator and DAMS)
• Upgrades will be seamless and automatically
implemented
• Vendor-client relationship gets simpler (roles are
better defined)
• Reduction in effort required to maintain local
customizations
Weaknesses:
For current, locally hosted solution
• Slow and sometimes unable to accommodate
feature requests or fix to problems
• Local customizations break when system is
upgraded
• Features appear/disappear without warning
• Not scaling to our size and according to our
requirements
• Does not support multiple content types equally
(IR, UDN, CDMbuntu)
• EADs remain to be a problem (currently not
supported)
For OCLC’s future (hosted) cloud-based solution
• Local customizations go away completely
• Does not support multiple content types equally
(IR, UDN, CDMbuntu)
• EADs not supported in hosted environment
• Loss of managing meta-data in bulk
Opportunities:
For current, locally hosted solution
• No significant time investment required in new
training
For OCLC’s future, hosted, cloud-based solution
• Possible redeployment of technical expertise
(System Administrator and Programmer roles (we may still be required to develop functionality using the CDM API) somewhere else, where better needed
• Crowd-sourced metadata editing capability via
World Cat
Threats:
For current, locally hosted solution
• System features/functionalities malfunctioning
due to scalability issues
• Current implementations eventually become
obsolete
• Continuous efforts in system customizations and
upgrades may become a sunk effort/cost
• Will eventually lose OCLC’s product support if
stay on current locally hosted system
• Forced to migrate to vendor’s future cloud based
solution (without clarification or the availability of new technical and other specifications) For OCLC’s future, hosted, cloud-based solution
• Current implementation eventually becomes
obsolete
• Current efforts on local system, customizations
and upgrades will become a sunk effort/cost
• When forced to migrate to OCLC’s new cloud
based solution, it will lead to added dissatisfaction (based on score of hosted solution on the basis of current knowledge of features)
• Lose control and customizations
• Large client needs won’t be readily addressed in
new solution (CDM’s future, cloud-based solution is geared towards small to middle tier Digital Libraries).
• Future directions of vendor not aligned with ML’s
