Purpose ( why did we decide to do this?) · UDN First time visitors 26% At least monthly •55%...
43
Transcript of Purpose ( why did we decide to do this?) · UDN First time visitors 26% At least monthly •55%...
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)
• Not scaling gracefully
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,
kmz files, A/V files, and many more
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
Utah State Historical Society
First meeting in: January of 2013
Initial deadline by TSC: May 2013
Deadline extended twice
(To accommodate for) Open source considerations)
DAM REVIEW
SOFTWARE SELECTION
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/Clients/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?
The Review Process
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:
ADD MORE CONTENT
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
Hydra
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)
ADA compliance
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 ◦ Converting away from this system later
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 ◦ Top 5 search engines: Google, Google Scholar, Bing, Baidu, Yahoo
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 ◦ Persistent urls required
Primo ◦ OAI harvesting
Rosetta ◦ Link display object with archival object using ARK
SIMP Tool
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
◦ Standard levels of support
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
Other major changes in direction
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 both systems, presented to larger group
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 developers from other institutions
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 o DAM Support
o Preservation Support
• Supported by active community and Duraspace foundation, http://www.fedora-commons.org/
Case studies, screencasts, and documentation available at:
http://projecthydra.org/apps-demos-2-2/
• Fedora - Open Source Repository System o DAM 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 Hydra Heads
• 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 OCLC’s future cloud-based solution (hosted)
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 long term growth and scalability needs
Strengths: • Demonstrated history of innovation
and collaboration. • Strong partnership model. • High profile institutions have
committed to becoming formal Hydra partners.
• Hydra is built on open source components.
• Articulated governance structure. • Technology framework for Hydra is
robust, provides a platform for continued innovation.
• Development is directed to future needs of digital library community.
• Sustainable cost structure, not at liberty of increasing licensing costs
• Can use recently developed SIMP tool as platform for Hydra ingestion.
Weaknesses: • Need to develop in house expertise
in Hydra technologies. • Staffing costs – start up and
ongoing. • Migration time to move digital
materials into new repository.
Hydra SWOT
Opportunities: • Can develop our digital library with
the features we need. • Ability to engage with dynamic
Hydra software development community.
• Can support data curation (regular data, not “big data”).
• Roadmap for linked data support. • Successful records of grant funding
to complement Hydra development efforts, provides a grant writing opportunity.
• Ability to provide consistent user experience to digital library users (no myfavorites disappearing or breaking).
• Can influence and contribute to future developments of Hydra code base.
• Offer our services to other UALC members or other state agencies.
Threats: • Loss of partners who don’t want to
move away from CONTENTdm. • Loss of relationship with OCLC. • Have to be our own technical
support.
Hydra SWOT
Based on in-depth analysis (including system scores), the committee has proposed: ◦ Embark on the Hydra Development Plan
◦ Table Bepress And ChronAm as IR and Newspaper solutions until further information from Hydra development is acquired
◦ Continue using NWDA for EADs until we have further information from Hydra Development
◦ A financial/business analysis currently underway
Starting Hydra development efforts.
Identifying resources needed, including infrastructure and staffing needs.
