Adopting Dataverse at the Qualitative Data Repository
The process of incorporating Dataverse into the Qualitative Data Repository, featuring insights on the significance of QDR, annotations as data, and evaluation criteria for selecting a data platform. Learn about the considerations, implementation steps, and future outlook in enhancing data management capabilities within research settings.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Adopting Dataverse at the Qualitative Data Repository Nic Weber and Sebastian Karcher, QDR
Annotations as Data https://qdr.syr.edu/discover/projectcontentherrera
Evaluation 11 criteria Criteria Fed DV CKAN Explanation Platform can achieve all of current QDR functionality, and all of specifications from QDR 2.0 document; can be used across different development, testing and production environments. Functionality 5 5 5 Ability for the repository to scale to manage large and heterogeneous collections of digital objects Scalability 5 5 5 Ability to integrate external tools with the repository in order to extend the functionality of the repository (e.g. APIs, OSS, etc.) Extensibility 3 3 5 Ability to interoperate with other repositories -, those included in the Data Pass initiative, and to have content harvested by DPN. Interoperability 5 5 5 Platform can be developed / maintained by our current team, or has requirements that we can affordably recruit from existing developer pool. Labor Force 0 3 5 Initial installation and ease of integration with other needed software. Ease of deployment 3 5 5 Ability of the system to meet QDR + Syracuse security requirements. System security 5 5 5 Ability to deploy multiple instances for offsite and disaster recovery; ability to interface with AWS. System back-ups 5 5 3 In academic settings, or other scholarly communication venues. Demonstrated successful deployments 5 5 5 Quality of documentation and responsiveness of support staff or developer/user community (open source) to assist with problems. System support 5 5 3 Reliability and support track record of the company providing the software; or size, productivity, and cohesion of the open source developer community. Strength of development community 3 5 3
Evaluation How? Interviews with other repositories Documentation Trial Install (Vagrant)
Towards Initial Implementation Simple SAML Authent ication Authent ication Existing Userbase
Outlook Annotations as Data (Open Annotations) Multi-media File Preview Granular Data (Paragraphs, Timestamps, Image Locations)
