Please share your comments regarding this document. Use the comments area below, share your thoughts in listservs and in other email. Please let your voice be heard. The ideas below were collected from many emails, documents, meeting notes, presentations, and personal conversations. Please share comments, concerns, suggestions, improvements, questions. This document will be revised throughout the roadmap process. A draft roadmap should be in place in time for the conference.
This document lists proposed features for inclusion in the VIVO roadmap process. Significant refinement of the items is expected by the Steering Group before discussion in the community and by the community prior to prioritization. See the Proposed Roadmap Process document for a description of the steps for transforming proposed features into an approved roadmap.
In this document, “End User,” means a person who is using VIVO for their work. This would include faculty, students, librarians, support staff, administrators, executives, agency personnel and others. It does not include developers, system administrators or data managers.
By “Stewards” we mean the people providing application support for VIVO at local sites. This includes system administrators, data managers, user support staff, trainers, and local developers. It does not include community members working on the VIVO software and its related materials.
By “Technical” we mean architects, developers, and ontologists contributing to the technical effort required to improve VIVO.
Many members of the community are end users, stewards and technical.
The remainder of this document names “features” — high level descriptions of capabilities that could enhance VIVO. Each feature might have one or more use cases. The refinement of features is part of the software design process. The roadmap process attempts to identify features which should be pursued in subsequent design and development. Clarification of features is needed in order to roughly estimate the amount of effort needed to developer the feature, and to prioritize features based on their descriptions and estimated effort.
Proposed End User Features
- Improve the interface, particularly regarding person profiles — more attractive, more focused on scholarship
- Provide biosketch and CV output. Extensible standard formats such as NIH, NSF, CVN, Acumen, CASRAI
- Ensure that VIVO profiles appear on screen in under 2 seconds
- Improve the interface for non-profile items — fewer lists, more visualization, more data summary, drill down
- Provide one button bi-directional profile update with other VIVO systems. That is, if a profile exists in two VIVO systems representing the same person, provide a mechanism for synchronizing the two profiles
- Provide one button bi-directional profile update with ORCID
- Provide one button bi-directional profile update with Fedora
- Provide one button bi-directional profile update with SciENCV
- Provide one button upload/download of a person’s works to/from BibTex
- Provide one button upload/download of a person’s works to/from EndNote
- Provide one button load of meta data from Figshare
- Improve the manual editing interfaces — drag and drop a presentation to a profile, a PDF to profile, a photo to profile, draw connections between things (people to people, people to concepts, people to works)
- Support personal annotation of anything in VIVO
- Support grouping of anything in VIVO — define a group, add/sub from group, show group, email group.
- Provide mobile interface — VIVO should have optimized presentation on phone and tablet
- Provide the Duke embeddable widgets for non VIVO websites, bring VIVO content to other university sites
- Support social network analysis — exports to SNA tools, simple SNA visualizations and metrics
- Support for research impact analysis. Ontology extensions, and outputs for gathering and using research impact data
- Repair/replace/augment all visualizations — put anything with a location on a map. Put anything with dates on a timeline. Put anything with connections in a dimension free network diagram. Use standard iconography to orient user
- Reporting improvements — provide a suite of 50-100 queries which are presented as finished reports in CSV and PDF formats. Publications by department over time, grants over time. Course, grants, papers, by faculty per unit.
- Provide cross site search capability
- Provide a VIVO Searchlight application
- Provide expert finding capability, including “people like me”
- Provide alt metrics for scholarly works in VIVO
- Provide single sign on using a user’s ORCID and their ORCID password. Provides opportunity to host profiles for end users across institutions.
Proposed Stewardship Features
- Simplify theming. Provide a simple theming option — logos, color, welcome text. Provide a full theming option — CSS control. Support theming improvements without having to rebuild
- Include ingest from DOI. From a spreadsheet and manually.
- Include ingest from PubMed. Given one or more PubMed IDs, add publication data including abstract, MeSH terms and grants cited to VIVO
- Include ingest from ISBN. Given an ISBN, or a list of ISBN, use a standard data source to get attributes of the book in real-time and add to VIVO
- Ingest from NIH Reporter
- Ingest from USPTO
- Ingest from grants.gov included
- Ingest from clinicaltrials.gov included
- Enforce data integrity from ontology (cardinality, domain and range). Prevent data from entering VIVO that is contradictory to the ontology
- Provide a collection of open social plug-ins that can be augmented locally, and selected by end users at run time
- Provide Karma scripts for ingest with guide and training for local implementation and customization
- Use standard URIs, such as those from registry services, when possible, for shared entities rather than creating redundant local URIs. Examples include DOI, ORCID, DBpedia
- Provide data analyst interfaces for SAS, SPSS and R. Include batch processes for exporting large amounts of data in formats ready to be used by data analysts
- Provide standard input data sets for journals, universities, publishers, cities, dates. Possibly from WikiData. Provide a simple process for updating these data sets
- Provide dot releases of software that do not require an upgrade
- Provide dot releases of the ontology that do not require an upgrade
- Load ontology from files that are automatically generated from VIVO-ISF, replacing the manually generated files that are loaded now.
- Support technical assessment of VIVO through one button install, sample data, sample outputs, and guided tour
- Allow better configuration of the user interface based upon annotations on the ontology
- Add common local extensions into VIVO-ISF, reducing need for local extensions
- Provide easier mechanism for both central and local extensions of the ontology, and easy import of modules relevant for the local VIVO instance
- Provide latitude and longitude in ontology
- Provide attribution ontology for indicating the role an individual played in the development of a scholarly work
- Provide data citation capability
- Provide software citation capability
- Provide ontology extensions for support of humanities scholarship
- Provide ontology extensions for support of provenance (data lineage)
- Provide a store (catalog) of selectable third party web apps for inclusion in the interface
- Support third party triple stores
- Provide an ingest from SHARE Notify Harvester, populating VIVO with elements from SHARE. Some sites might populate their entire VIVO solely from SHARE Notify
Proposed Technical Features
- Move to Maven
- Reorganize repos so that everything needed to develop and run VIVO is available from a single repo
- Provide software from GitHub
- Provide one button repo to IDE capability
- Move to continuous integration
- Move to Assembla
- Move to Github issues
- Include VIVO Vagrant with distribution
- Continue modularization work
- Continue separation of interface (view/controller) from model. Use API to put/get data from the VIVO backend.
- Application plug-in capability — provide a simple mechanism for a web app to appear in VIVO.
- Improve ontology extract and load
- Integrate ontology and software development into a single open source process
- Eliminate distinction between ontologies loaded at start-up and ontologies loaded at run-time. Support only run-time
- Restructure code to use more information from the ontologies and store less business logic in the code
- Provide a standard set of APIs that simplify and standardize the use of VIVO data in other applications
- Provide a means for an API developer to register a new API
- Provide a means for a web app developer to register a new web app
- Remove features from the application that do not work — visualizations, CSV ingest, others.
- Rewrite the custom editing forms to improve functionality and modularity
- Provide a binary release for developers
- Provide Docker as part of the standard distribution
- Provide coding standards and code training
The following references were used to gather proposed features
- Leadership Group notes
- IFest Notes
- Steering Committee notes
- VIVO Strategic Plan
- Workgroup notes
- Task Force notes
- Additional wiki pages on use cases, proposed features, release planning for future releases, others
- Personal conversations and emails
The community discusses process and features in preparation for preference activity the week of July 6. See Roadmap Process for the complete process