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.

Background

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.

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 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.

5 Comments

was listed in several proposed end user features. synchronize means "agree in time or to make (things) happen at the same time and speed", which is quite costly. Another option is to link to primary personal profile, which has its own challenges. We need to make the distinction between the two, i.e. when and what data to exchange vs when to link.

Yes. The VIVO user experience would likely be enhanced if people could put data in one place and it would "show up" some other place. Under their control. To avoid confusion (or over specification) of the features using the term synchronization, I changed synchronization to "update" in each. Thanks!

Looks to me like #12 and #14 are alternate approaches to the same problem – each VIVO is creating its own URI for potentially the same entities. In #14, the approach appears to be to provide common data sets that we can each load into our own VIVOs. Data is replicated by ingesting these standard data sets, but the URI are in common, each coming from the standard data set. #12 suggests that common URI be used for common entities when such common URI exist. An example might be ORCID. Rather than each of us creating a URI for Mike Conlon, we agree to use the common URI http://orcid.org/0000-0002-1304-8447, or some other common URI. #12 was unclear. I've reworded to focus on the URI issue.