Overview
In this document, I examine the use case of a small radio broadcaster who requires a software solution to manage their collections of audio files for the purposes of preservation and access to their archive as cultural heritage. I review open source content management systems to provide a short list of systems that the project board may consider.
The document is relevant to audiovisual archive collections even though the emphasis is on audio files. It may provide insight on systems for managing other forms of archive collections but the recommended short list may not be right for document or still image collections. The budgetary constraints of a small broadcaster limit the competitive analysis to open source solutions. My analysis may prove useful to larger broadcasters with bigger budgets but again, the short list may not be right for an organization with a larger budget.
The document
- examines the requirements and constraints of the project
- reviews the market for software solutions that may deliver on the data management and functionality requirements for preserving and providing access to a digital sound archive
- selects a long list of candidate products by eliminating the products on the market which cannot deliver within the project constraints or are not designed for the same concerns as the broadcaster’s target solution
- selects a short list of three candidate products which demonstrate a better fit to the requirements and constraints than their competing products may provide.
The short list of candidate products for evaluation are:
- Collective Access
- Omeka
- Resource Space.
I explain the reasoning behind filtering the range of products in the market to a long list of thirteen candidates, and then to a short list of three, based on performance quality attributes and on functional requirements.
1 About the project
1.1 Background
The broadcaster owns an archive of the programmes it has broadcast for just over twenty years There are 25,000 hours of content on VHS tapes and 15,000 hours of digital recordings on portable hard drives. There are also hand written and digital documents of programme information, and a collection of photographs related to the programmes. The broadcaster adds to the archive each day with new programmes. The project aims to preserve and provide access to this archive by digitizing and migrating all the content into one integrated solution and by cataloguing the content. The first stage of the project aims to set up the infrastructure and preserve and provide access to a sample of the collection before launching on the next stage to secure and make accessible the entire collection.
1.2 The strategic goals of the archive project
- To preserve the collection.
- To provide appropriate access to the collection.
- To establish a model of sustainable digital archiving for small broadcasters and other small organizations with archive holdings.
1.3 The scope of this document
This document supports the scoping exercise of the project. I provide details which the project board may need when they evaluate and select a software solution. The solution will support a workflow to accession, store, catalogue, and provide appropriate access to online and offline radio programmes and associated material.
1.3.1 The system
The solution will support a workflow to accession, store, catalogue, and provide appropriate access to online and offline radio programmes and associated material. The system will manage audio files and their associated metadata. Programme makers and member of the public may search, browse and listen to the audio files across the full archive from recent or early broadcasts according to access controls.
1.3.2 The data
The broadcaster has captured programmes digitally in one hour segments in the past ten years. Each year’s content amounts to about 2,000 files or one terabyte of data. In the first ten years of broadcasting, the broadcaster captured programme content on analogue VHS tapes and the archive holds 5,000 of these. The archive totals up to fifteen terabytes of data.
Data on other media formats:
- Several hundred photographs associated with radio programmes
- Daybooks 1995-2007 – handwritten pages which will be scanned
- Excel spreadsheets
1.4 The constraints of the project
1.4.1 The budget
The budget is €XXX,000 in total to include
- Project management and consultancy
- Infrastructure design, development and installation
- Storage costs over five years
- Support and maintenance over five years
- Digitization
- Cataloguing
This means that the products I evaluate should provide a solution during the digitization project life (12-18 months) and for a further 2.5-3 years. The costs may be upfront for development with low recurring costs or spread evenly over five years for a turnkey solution.
1.4.2 The schedule
The project board agreed the schedue as follows:
- evaluate and select a system in Q1 this year
- design, develop, install, and roll out the infrastructure in Q1-Q2 this year
- digitize and catalogue the collection from sampling in Q2 this year through to full operations in Q3-Q4 and continuing through to Q2 or Q4 next year (the duration will depend on the number of people working on the project).
- publish and provide access to the collection incrementally from Q3 this year
The project timeline allows four to sixteen weeks from selecting a software solution to rolling it out to the archiving staff.
1.4.2.1 Other constraints
The solution should
- Support several digital media formats
- Be scalable to digitizing and cataloguing the full collection
- Be applicable to other community radio stations.
1.4.3 The context
1.4.3.1 Current broadcaster resources related to the archive collection
- Station manager with a small team of part-time staff
- Logging infrastructure
- Network-attached storage box
- Digital files on hard drives
- Analogue tapes on shelves in the studio building
- Spreadsheets of programme content
- Day books of programme content
1.4.3.2 Archive resources related to the target software solution
1.4.3.2.1 Project oversight
- The project board consists of the station manager; two archivists with experience in digitizing large broadcast archive collections; an advocate for other small radio broadcasters; a technical engineer who will supply hardware for the technical infrastructure; and a programmer who will set up the software solution for use.
- The project manager, a broadcast archivist, has been hired on a consultancy contract for the duration of the project.
1.4.3.2.2 Digital transfer and cataloguing resources
- Project archivist
- Head cataloguer
- Cataloguing and digitizing team
1.4.3.2.3 Technical infrastructure
- Integration with network-attached storage
1.4.4 Guidelines for delivering quality
1.4.4.1 Standards
If we adhere to standards, we make it easier to conform to industry expectations of quality; we simplify decision making; and we ensure support and maintainability over time.
These are the standards relevant to this project:
1.4.4.1.1 Preservation
- OAIS preservation process standards
- ISO standard 16363 for a trusted digital repository
- Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) for metadata harvesting; and other protocols for data exchange relative to preservation
1.4.4.1.2 Digital media assets
- Metadata standards relevant to preserving and providing access to a radio broadcast archive:
- Dublin Core
- MARC, METS, MODS
- PBCore, EBUCore
- Other standards such as SKOS, FRBR, etc.
- File format standards for sound and other digital media files
- WAV, MP3; JPEG, TIFF, PDF; h264; etc.
1.4.4.1.3 Data exchange and systems interoperability
- Data exchange standards for exchanging data across systems
- XML (and the XML standards relevant to domain), EAD,EAC-CPF, CSV, etc.
1.4.4.1.4 Web publication
- W3C standards for web publication
- HTML 5 and responsive design
- JavaScript and JSon data format, etc.
1.4.4.1.5 System design and development principles
- Open source licensing
- Modular, open, services architecture
- RESTful API
- Security: access control, permissions; authentication, LDAP
- Data integrity – checksum validation
- Disaster recovery – export system content as AIP (Archival Information Packages)
- Data security standard – ISO27001
1.4.4.2 Project management and system design guidelines
- Microsoft provides a useful set of quality attributes which we may use to evaluate the potential solutions.
- Design Qualities
- Conceptual Integrity
- Maintainability
- Reusability
- Run-time Qualities
- Availability
- Interoperability
- Manageability
- Performance
- Reliability
- Scalability
- Security
- System Qualities
- Supportability
- Testability
- User Qualities
- Usability
- Design Qualities
- The Digital Repository of Ireland (DRI) has published guidelines for institutions in Ireland who want to set up their own repository and to deliver their collection, or extracts of their collection, to the DRI. All of the guideline documents are available here: http://dri.ie/publications.
1.4.4.3 Enterprise Information Management Capability Maturity Framework
- Resonance Content and Archive Management has a framework to consider the capabilities for managing information for value to the organization in a holistic manner. This framework informs the thinking behind the requirements below.
2 Requirements specification
2.1 The key requirement
The project board aims to select a software solution to manage collections of audio files for the purposes of preservation and access to a broadcast archive.
2.2 Industry standard solutions
This target solution combines three standard industry solutions:
- Digital asset management (master data management)
- Metadata management (catalogue management, collections management)
- Web content management (web publishing).
2.2.1 Digital asset management for broadcasters
The leading digital asset management solutions for broadcasters extend beyond our requirements into managing assets in a media production workflow and integrating with many systems across broadcast operations. Only the media library or media archive component is of interest to this project. If the focus is on broadcast production, the solution may not focus its attention on metadata and workflow principles relating to preservation for heritage and research purposes, although we might hope that the metadata standards for broadcasting, PBCore and EBUCore, are a given. The benefit of these solutions is their expertise in handling audio-visual formats with features relating to the time-based qualities of this media, for example, playing streamed media rather than accessing files for download and associating metadata with segments of a timed sequence in a file. The leading DAM providers for broadcasting target primarily large organizations with a consequent impact on the cost of the systems. Dalet and Avid are leaders of this form of solution.
2.2.2 Digital repositories for educational institutions
Digital repository solutions are designed for educational institutions and for the purposes of preserving and providing access to publications and digital resources for research. These repositories are driven by academic library administrator-users and will follow metadata and workflow standards for preservation and access to digital resources. They tend to be less focused on end-user experience and the aesthetics of presentation. They tend to be limited in their handling of audio-visual media compared to the broadcast DAMs. These repositories are addressing these limitations with plug-ins and new features in the coming years – specifically, including streaming players and archive exhibition publication tools in turnkey solutions. The two main repository solutions, DSpace and Fedora Comons are provided by Duraspace. Dspace provides a more complete out-of-the-box solution but the code is old (Dspace version 7 will be published in 2018). Fedora requires a technology stack delivered by Hydra, Islandora, or custom builds in order to deliver workflow, search, and web content management. Hydra-in-a-Box is a current project to deliver the most complete solution and was scheduled to begin pilot testing in Q2 2017. The research into requirements for this system gives a great insight to the current gap between user expectations and production specifications. Effectively, we would need to wait until 2018 to start using the new versions of the two main institutional repository solutions.
2.2.3 Collection management solutions for Galleries, Libraries, Archives, and Museums
There are collection management solutions for the Galleries, Libraries, Archives, Museums – what’s called the GLAM or LAM sector. The solutions tend to be more complete and ready for use compared to the digital repository solutions. They tend to suit small organizations regarding cost and maintainability. They also focus their attention on display in the form of online exhibitions. The solutions address the likelihood of a collection containing multiple media formats although their focus of attention is more likely to be still images and scanned documents rather than audio-visual or audio. They are less focused on preservation metadata and workflow standards compared with solutions for academic digital repositories.
2.2.4 Web content management
The market for web content management systems has matured and there are three main open source web content management systems: WordPress, Drupal, and Joomla. By far the most popular CMS is WordPress to the extent that it may be called the ‘dominant design’ just as the Apple iPod became for the MP3 player. It is possible and common to integrate the digital archive file store, the metadata database, and the workflow and search applications with a WordPress, Drupal, or Joomla CMS. None of the collection management solutions described above will provide the range of web content mangement features that WordPress can provide.
2.3 Limitations across all the solutions
All of the solutions presented below manage the metadata in a relational database with varying degrees of NoSQL methods of handling metadata and third party reference data (vocabularies). Metadata and content management is moving these days towards NoSQL storage, particularly storing data as XML, Json, and RDF file formats without transforming the data back and forth into and out of a SQL relational database. Several of the solutions listed here will support import and export of data in these file formats but still centralize the relational database as the primary storage.
Why bring this up? Because as long as the SQL relational database is the central repository for the metadata, it is necessary to pre-define a data schema and re-build the database with every change to the schema and there are limitations on the search range and performance.
Nuxeo is an example of a digital asset management service provider with NoSQL solutions using MongoDB or MarkLogic for NoSQL storage. BBC now maintain their programme information or metadata in a MarkLogic database (BBC’s Nitro programme information API). The benefits of NoSQL approaches to storing databases is the ability to maintain any number of schemas in the same database and avoid pre-defining a data model before setting up a database for use. This means that adhering to schemas and metadata standards relates solely to data quality and not to the technical limitations of the system. MongoDB is a an open source NoSQL database that may be worth considering in this project. The commercial licence for MarkLogic is outside the scope of the project due to budget constraints. Although we may not have the option to select a NoSQL solution for this project, we should at least be aware of the fundamental limitations to the products under evaluation in terms of flexibility and future-proofing.
Working within the selection of products we review here, we should pay attention to the quality of the search index outside the database because this is where the flexibility for search, workflow, and presentation will be determined.
2.4 Selecting a short list of candidate solutions by filtering
There are many content management systems available on the market so we need to filter our list of products to a short list of candidate products for our target solution: a system to manage collections of audio files for the purposes of preservation and access to a broadcast archive. Also, we should filter the long list based on the constraints of the project.
2.4.1 Filter by design qualities
2.4.1.1 Conceptual Integrity: Selection by market focus
Firstly, we should exclude products that do not have any key case studies related to
- Broadcast or film archives
- Galleries, Libraries, Archives, and Museums
- Digital repositories for education institutions.
These sectors will share common concerns with our project.
2.4.1.1.1 Solution readiness
We may choose a solution with a commercial licence or a general public licence, or we may commission a custom-build. It may be that we can select core components of our target solution under public licence and commission the configuration and integration of these components (with no application development). Considering our modest budget, it makes sense to select a turnkey solution under general public licence or a solution that requires configuration and integration of modules available under public licence. We should eliminate products or services under commercial licence or involving application development of core modules, on the assumption that these options are outside our budget. Also, we have scheduled just four-sixteen weeks between selecting and implementing the solution for cataloguing. This also puts a custom-build out of scope unless it were limited to configuring ready-built core components.
2.4.1.1.2 Deployment
We should choose solutions which may be deployed on premise, in the cloud, hybrid, or with mirrored solutions, and preferably with a cloud solution hosted by the service providers of the software solution. This will give us the flexibility to change the deployment options over the life-cycle of the project according to concerns such as the most economic pricing model, data security, network availability, and so on.
2.4.1.2 Maintainability
We should limit our short list to solutions which are likely to continue to be maintained and supported for the next five years. Indicators that a solution has currency and viability into the future include:
- A significant, reasonably large client base
- An active open source community
- At least one active and viable service provider
- A codebase that is reasonably up-to-date
- Clear evidence of contemporary principles of software design (e.g. responsive design on the website)
- Evidence of efforts to introduce emerging technologies and move away from declining technologies
- A clear strategy and product roadmap
- Continuous backing from a relevant organization.
2.4.1.3 Reusability
The short list of solutions must include products that can handle any media format with a common core of metadata standards (i.e. Dublin Core) and provide extended attributes appropriate to each individul media format.
The short list of solutions should include products that provide web content management for all the broadcaster’s requirements so that the station does not have to maintain two web content management systems – one for the archive and one for the website. At a minimum, the solution should provide the option to publish standard ‘brochure’ style web pages and blog/news posts. There must be the option to publish the archive collections at the broadcaster’s registered URL.
2.4.2 Runtime qualities
2.4.2.1 Interoperability
We need to consider only solutions that can import and export metadata in standard formats such as XML as a minimum, but also formats such as Json.
We also need to allow the option for plug-in features; Linked Open Data; and integration with useful modules such as a web content management system. This means that the short list should only include solutions which provide REST API.
2.4.3 Other performance quality attributes
I propose that the other attributes do not function as filters for creating a short list although they provide criteria for evaluating the short listed candidate solutions. These include:
- Performance
- Reliability
- Scalability
- Security
- Supportability
- Testability
- Usability
2.5 What the system can do and how it should perform
This a broad set of requirements for this type of target solution. The project board would need to identify which requirements they consider appropriate for the broadcaster and to what degree of priority.
2.5.1 What the user roles can do
| Functionality | |||
| The archivist-cataloguer can | 1. | ‘Ingest’ the digital media files. | |
| 2. | Read bar code of tape and other media assets. | ||
| 3. | Select and import available metadata directly associated with the media files from the following range of sources
– programme information files – scheduling system – editing suite – scripts, closed captioning, subtitling – online reports, blogs produced in-house – third party reports and online commentary, professional and social (e.g. Twitter) – online profiles and records (e.g. Wikipedia) |
||
| 4. | Automatically create a batch of catalogue records from the imported content and metadata. | ||
| 5. | Create a batch of catalogue records based on a known series (e.g. a season of programmes). | ||
| 6. | Create/edit/access and delete (according to user permissions) a template record for a collection, brand, series, programme, item/clip, and other digital assets based on recommended templates. | ||
| 7. | Create/edit/access and delete (according to user permissions) a catalogue record for a collection, brand, series, programme, item/clip, and other digital assets. | ||
| 8. | Create comprehensive metadata descriptions of each collection, brand, series, programme, item/clip, and other digital assets. | ||
| 9. | Associate each media file and other assets with keywords, themes, people, locations, and other references from ‘controlled vocabularies’. | ||
| 10. | Tag media assets with keywords that are not in the controlled vocabularies. | ||
| 11. | Input data with the assistance of predictive text from uncontrolled previously input data. | ||
| 12. | Input data with the assistance of predictive text and associated concepts from controlled vocabularies. | ||
| 13. | Mark which digital assets should be published for public access. | ||
| 14. | Ensure the media file can be viewed in the correct sequence according to a complete programme, a series, a chronology, a defined playlist. | ||
| 15. | Suggest additions to the controlled vocabularies. | ||
| 16. | Input editorial content for web pages. | ||
| 17. | Input versions of media content, records or fields in different languages (e.g. English and Irish). | ||
| 18. | Prepare a collection of media files for archive exhibition presentation. | ||
| 19. | Search and retrieve a media file by
– free text search – search using boolean operators – advanced search across all fields including administrative fields (e.g. ‘most recently updated’) – by date range – by location etc. |
||
| The archivist-administrator can | 20. | Set up a user and user’s permissions. | |
| 21. | Create/edit/access and delete catalogue records and does not require permissions. | ||
| 22. | Create and edit controlled vocabularies. | ||
| 23. | Upload, edit, and define the rules for a watermark and rights identifiers. | ||
| 24. | Globally edit records and web pages. | ||
| 25. | Define rules for metadata fields. | ||
| 26. | Define rules for rights management and access control based on the rights associated with a digital asset. | ||
| 27. | Review content, records, and media files or digital assets before web publishing. | ||
| 28. | Set up archive management and publishing workflows. | ||
| 29. | Review the logging history. | ||
| 30. | Review Website usage statistics. | ||
| 31. | Set the preferred order of search results (e.g. by relevance or by date). | ||
| The website/mobile app visitor can | 32. | View and interact with the media files from a mobile phone, touch-pad, laptop/PC, or exhibition touch-screen. | |
| 33. | Enjoy the experience of exploring and examining the media files in a variety of display modes (e.g. slideshow, map, timeline, icons, grid or list layout, etc.). | ||
| 34. | ‘Swipe’ and use other screen gestures to engage with the content. | ||
| 35. | Zoom in/out on each page. | ||
| 36. | Read associated metadata and editorial descriptions. | ||
| 37. | Navigate easily. | ||
| 38. | Search and retrieve a media file by
– free text search – search using boolean operators – advanced search across a range of fields. |
||
| 39. | Browse through digital media files by associated keywords, people, and other terms from controlled vocabularies. | ||
2.5.2 How the system can manage the collection
| Managing the collection | 40. | The system can manage a digital archive in excess of XX,000 hours of media files. It can manage several hundred thousand digital files and catalogue records. |
| 41. | The system can manage and display media files in multiple formats including XXX, XXX, and others (as defined by the broadcaster). | |
| 42. | The system can protect the rights associated with the digital assets through access control, setting resolution level, visible watermark, invisible ID ‘watermark’ or identifier, options on making available for Web publication. | |
| 43. | The system has editing tools to batch/individually edit page images to appear in playlist or archive exhibition format. | |
| 44. | The system can publish thumbnails of the media files. |
| Managing web publication | 45. | The administrator can create/review/preview/publish/edit/delete a web page or parts of a web page. |
| 46. | The administrator can create/review/preview/publish/edit/delete a media presentation and other digital archive presentations, such as tiled display, play lists or archive exhibitions. | |
| 47. | The administrator can control versions of a webpage or the website and return to earlier versions. | |
| 48. | The administrator can review usage statistics. |
2.5.3 How the system should perform to quality standards
| Performance attributes
(Based on Microsoft categories) |
49. | Design Qualities | Conceptual Integrity | The system is designed to manage a digital archive of time-based and other rich media and for web/mobile/exhibition publication. |
| 50. | Maintainability | They system is fully supported with a community of developers and a leading company or organization to back the open source community.
There is a clear indication of continual development of the system with recent and upcoming version releases. |
||
| 51. | Reusability | The system is developed for media archives preservation may be applied to several media genres (sports, music, drama, factual, news and current affairs) and media formats.
They system may be used for the broadcaster’s other modest web publication requirements without recourse to a second web content management system. |
||
| 52. | Run-time Qualities | Availability | Availability will depend on the choice of hosting service. | |
| 53. | Interoperability | The system provides an RESTful API. This enables
– interoperability with useful add-on applications such as WordPress if required (and the replacement of one module with a different application/technology if required). – internal systems integration, for example with an editing suite or playout system – data feeds to common digital repositories/catalogues such as Europeana and the Digital Repository of Ireland. |
||
| 54. | Manageability | The system provides a comprehensive range of administrative functions. | ||
| 55. | Performance | Traffic load of up to XX,000 concurrent users | ||
| 56. | Reliability | The system is reliable. | ||
| 57. | Scalability | The system manages volumes up to several hundred thousand files and catalogue records | ||
| 58. | Security | The system will comply with the security standard as per standard publicly funded contract terms and conditions. | ||
| 59. | System Qualities | Supportability | The selected support option provides a three-four year service level agreement. | |
| 60. | Testability | The system may be tested by following agreed workflow and website/mobile app visitor scenarios.
There is an online test version that the broadcaster may try before downloading and configuring a full application. |
||
| 61. | User Qualities | Usability | The system is designed, or maybe designed/configured with a responsive design approach and delivers an engaging user experience. |
3 Market analysis
3.1 Products reviewed
- Activae
- Archivematica and AtoM (Artefactual)
- Arkivum Perpetua (built on Archivematica and AtoM)
- Concerto Digital Asset Management Collection Space
- Collective Access
- ContentDM (OCLC)
- Dspace
- EnterMedia
- Eprints
- Fedora Commons
- Greenstone
- Hoppla archiving system for small institutions
- Hydra (Fedora Commons)
- Islandora (Fedora Commons)
- Notre DAM
- Omeka
- OpenStack
- Phraseanet (Alchemy)
- Razuna
- ResourceSpace
- Rosetta Ex-Libris (Proquest)
- Systems Simulation (SSL)
- Tactic Media Library from Southpaw
I eliminated products from this review list according to the filters discussed in Section Two and created the long list of candidate products below.
3.2 Candidate long list
- Archivematica and AtoM (Artefactual)
- Collection Space
- Collective Access
- ContentDM
- Dspace
- EnterMedia
- Fedora Commons
- Hydra (Fedora Commons)
- Islandora (Fedora Commons)
- Omeka
- OpenStack
- Phraseanet (Alchemy)
- ResourceSpace
I identified that there were three products which demonstrated a stronger fit than other candidates and created a final short list of just three products. All three of these products provide turnkey solutions with varying degrees of configuration and scalability.
3.3 Candidate short list
- Collective Access
- Omeka
- ResourceSpace
I have excluded the leading digital repositories for evaluation. DSpace is the digital repository in UCD, UCC, NUIG, and Trinity College. The Digital Repository of Ireland is built on Fedora Commons with the Hydra stack on top. It is important that the broadcaster’s digitized collections align with the primary digital repositories in Ireland, but the timing is not right for building a DSpace or Fedora solution for CRR.
DSpace is preparing its version 7, which will be published as a stable release in 2018 and the Hydra solution for Fedora Commons will be released as a turnkey solution, Hydra-in-a-Box, in 2018. Neither Dspace nor Hydra-Fedora provide a turnkey solution at present. If we were to build a full technology stack to address our requirements for preservation and access, we would be putting in effort which the new versions could render redundant next year. I recommend therefore that we select from the short list of Collective Access, Omeka, and ResourceSpace but ensure that we create a schema that enables us transfer into DSpace or Fedora Commons in the future, or that the data could be copied into the systems without a major migration project.
3.4 Recommended solution
The aim of this document is to present a competitive analysis of a short list of products so that the project board have sufficient but concise detail to consider over a single meeting to evaluate and select a solution. Personally, I recommend Collective Access primarily because it has successfully provided for the needs of NPR’s archive and because it provides the most comprehensive, relevant metadata support for a broadcast archive.
I welcome the reader’s feedback.
3.5 Competitive analysis
| Collective Access | Omeka | ResourceSpace | |
| Latest version | |||
| Version | Version 1.6.2 (Providence) | Version 2.5 | Version 8 |
| Date | 11/09/2016 | 31/01/2017 | 30/01/2017 |
| Organization backing | |||
| Organization backing | Whirl-i-gig, New York | George Mason University, Virginia | Montala Ltd., Oxfordshire |
| Client references | |||
| Key clients | NPR | George Mason University | Oxfam |
| Broadcast and film archives | NPR Smithsonian Channel Chicago Film Archives |
The Kitchen Sisters, independent radio producers, San Francisco | ESPN (provided by DPCI service providers) Kaboo Community Radio (test with report) |
| Galleries, Libraries, Archives, Museums | New York Sociey Library University of Michigan Museum of Art Hunter College, City University of New York Brooklyn Academy of Music Musée Rodin Association of Nova Scotia Museums, and others |
L’Arxiu de la Paraula, Barcelona Atheneum Biblioteca Digital del Centre de Lectura, Catalonia Battersea Arts Centre Making History: Transcribe, Library of Virginia Florida Memory, State Library and Archives of Florida The Story of the Beautiful, Smithsonian’s Freer Gallery of Art and others |
The Library of Congress logo is on the list of clients but I couldn’t find any further reference. |
| Irish client | City of Limerick Museum and Archive University of Ulster |
Trinity College, Gothic Past Unversity College Cork, The World-Tree Project William Corbett’s Bookshop, Belfast The Hurdy Gurdy Museum of Vintage Radio |
None listed. |
| Universities | University of Ulster and others | George Mason University Trinity College, Gothic Past NEPTUN, l’Université de Namur, others |
MIT Sloan Management, St. John’s College Oxford, University of Arkansas, and other universities |
| Other | Bacardi, Fiat, etc. | [All in GLAM, heritage, and education sectors] | Oxfam and other not-for-profit Fujitsu, BAE Systems, Tannoy, and other commercial The Open Data Institute logo is on the client page but I couldn’t find any further reference. |
| Client list | http://www.collectiveaccess.org/clients | http://omeka.org/codex/Sites_Using_Omeka | https://www.resourcespace.com/testimonials |
| Systems architecture | |||
| Technology Stack (turnkey/configuration needed) | Configuration needed | Turnkey, little configuration | Turnkey, little configuration |
| Database | MySQL | MySQL | MySQL |
| Programming language | PHP | PHP, Zend Framework | PHP |
| Search | Elastic Search (Lucene) | SOLR (Lucene), plug-in | SOLR or Elastic Search need to be integrated |
| API | RESTful API | RESTful API | RESTful API |
| Deployment (Cloud/OnPremise) | Both | Both | Both |
| Data schema | |||
| Preconfigured schema | Yes, with sample schema profiles | Yes | Yes, with sample schema profiles, ‘packages’ |
| Configure schema | Yes | Yes | Yes |
| Required schema preconfigured | No | No | No |
| Metadata standards | |||
| Marc, METS, MODS, OAI-PMH | Comprehensive data import support | (Plug-in) | No |
| Dublin Core | Preconfigured | Plug-in | No |
| PBCore | Preconfigured | Plug-in | No |
| EBUCore | Preconfigured | No | No |
| PREMIS | Preconfigured | No | No |
| IPTC Photo Metadata | No | No | Yes |
| http://docs.collectiveaccess.org/wiki/Metadata_Standards | Metadata plug-ins: http://omeka.org/add-ons/plugins/ | https://www.resourcespace.com/knowledge-base/resourceadmin/managing-metadata | |
| Reference metadata (vocabularies) | |||
| GEOnames | Preconfigured | Plug-in | No |
| Library of Congress subject headings | Preconfigured | Plug-in | No |
| Getty Art and Architecture thesaurus | Preconfigured | Plug-in | No |
| Charged services | |||
| Application development | No | No | No |
| Configuration and integration | Yes, degree dependent on requirements | It depends on requirements | It depends on requirements |
| Installation | Yes | Yes | Yes |
| Migration | Yes, unless done in small batches | Yes, unless done in small batches | Yes, unless done in small batches |
| Licence | Open Source | Open Source | Open Source |
| Charge by # admin or end users | No | No | No |
| Annual support and Maintenance | Dependent on choice of deployment and service provider | Dependent on choice of deployment and service provider | Dependent on choice of deployment and service provider |
| Cloud or inhouse | http://www.collectiveaccess.org/hosting | https://omeka.org/codex/Hosting_Suggestions | https://www.resourcespace.com/pricing |
| Additional features | Dependent on requirements | Dependent on requirements | Dependent on requirements |
| Strengths and weaknesses | |||
| Key strengths | EBUCore and PBCore; Comprehensive features and documentation; Linked Open Data; | Online archive exhibitions for non-professional and small organizations with archive collections | Looks great; photo archives, particularly images of people; basic editing; Adobe interoperability (by one key service provider) |
| Key weakness | Relatively complex to configure compared with Omeka and ResourceSpace | Relatively small collections. Not as comprehensive in features as Collective Access | Doesn’t demonstrate an interest in metadata standards and linked open data; not geared towards archive but for current collections; no archive skills at Montala; product roadmap related to photographic images (facial recognition) |
| Sample features | |||
| Cross-platform | Yes | Yes | Yes |
| Multilingual | Yes | Yes | Yes |
| Search | Comprehensive Lucene search syntax: http://docs.collectiveaccess.org/wiki/Search_Syntax |
https://omeka.org/codex/Managing_Search_Settings_2.0 http://omeka.org/add-ons/plugins/solrsearch/, etc. |
http://www.resourcespace.com/knowledge-base/user/advanced-search |
| Batch import | Comprehensive, http://docs.collectiveaccess.org/wiki/Media_import | https://omeka.org/blog/plugin_categories/batch-importing/ | http://www.resourcespace.com/knowledge-base/user/uploading |
| Batch editing | http://docs.collectiveaccess.org/wiki/Batch_Editing | https://omeka.org/add-ons/plugins/bulk-metadata-editor/ | https://www.resourcespace.com/knowledge-base/user/editing-multiple-resources |
| LDAP Access control | http://docs.collectiveaccess.org/wiki/Release_Notes_for_Providence_1.2 | There was an LDAP plug-in but seems to be gone. | http://www.resourcespace.com/knowledge-base/user/plugin-simpleldap |
| Read barcode | http://docs.collectiveaccess.org/wiki/BarCodes | http://omeka.org/codex/Plugins/Barcode | No |
| Audio, audiovisual streaming | Yes | Yes | Yes |
| Visualization options | |||
| Maps | Yes | Yes | No, I don’t think so. |
| Timeline | Yes | Yes, plug-in (MIT’s Simile timeline) http://omeka.org/add-ons/plugins/neatlinesimile/ |
No, I don’t think so. |
© Eibhlín Ní Oisín, Resonance Content and Archive Management Ltd.
