up to all Development Components for VIVO 1.5

Component description

VIVO currently has a mechanism to restrict the display of properties based on the permission level the user. Current permission levels are:

• public (not logged in)
• self-editor (a user who normally has logged in via external authentication hooked up to an institution's single sign-on, and can only edit his or her own profile. Note that proxy editors edit other people's pages with self-editor permissions.
• editor (a logged-in user having rights to edit any content, but not to change the ontology
• curator (a logged-in user having the right to see and edit the ontology
• site admin (a logged-in user having privileges to edit menu pages, perform tasks such as rebuilding the search index, and add/remove data
• root user (a single account having all available privileges)

When a property has been set to be visible only to a certain level, that restriction applies throughout the application and is not configurable for one person's profile vs. another's.

This component addresses needs expressed by multiple sites to have controls at the individual, or single page, level, potentially including:

• Hide individual properties, e.g. email address, phone
• Hide property groups, e.g. publications are not relevant to your particular career or you don’t have enough publications, so you hide the entire publications property group
• Hide classes/class groups, e.g. don’t want any academic articles to be shown, but do want your great American novel
• Hide particular data entry, e.g. hiding a specific publication or one of the phone numbers added – reasons include fear of retribution by animal rights groups
• Hide the whole profile, e.g. you have created the profile page but there is no real data there yet, and until appropriate data has been added/ingested, you don’t want to display the page

There are ample use cases for hiding data in the VIVO pages for other types of individuals, such as organizations – department may not have a strong research program and may not the relatively small number of grants they administer to be displayed, for example.

There is also the additional factor of Linked Open Data – do we need separate controls for the data served up in response to a linked data request, or can we follow the same permissions scheme?

• we have at least one use case where a publisher has been willing to provide citation count information for display on VIVO pages but not for download via linked data
• there could easily be cases where the opposite would be true – a person might wish all of her publications to be available via linked data while only displaying 10 selected publications in her VIVO page

Scope of the component for v1.5

VIVO makes extensive use of "context nodes," or intermediate connector nodes between one type of individual and another.

• For example, a position connects a person and the organization they work for, and carries information about the term of their employment and the applicable official and/or working title.
• Publications, grants, awards, professional service, and several other sections of VIVO profile pages all make use of context nodes, and these provide a logical place to store individual-level display preferences.
  • While one author may not wish to show a publication in her profile, a co-author might very much want to. Each author's contribution to the publication is represented via a context node carrying their author rank, and could be extended to store a personal display preference by the addition of a new ontology property.

Hiding a direct object property statement is more challenging, since the <subject><predicate><object> format of a triple store would have to be augmented through reification (adding at least 4 statements about the statement), graph separation (moving data from one designated implementation graph to another), or some other means.
The same problem holds true for data property statements, or triples where the <object> of the statement is a literal value rather than the URI of another individual.

Adding distinct control for linked data vs. website display adds complexity but may be important.

Note that we never recommend storing sensitive data in VIVO, such as social security numbers, home addresses, medical leave information, or salaries. This component deals with display preferences, not fundamental privacy or security requirements. The best rule of thumb is to never put any truly private data into VIVO – linked open data is meant to be open, and if a SPARQL endpoint is opened to your data the VIVO application is not well equipped to control what data are queried or revealed in query results.

Design work needed for the component

Ontology

We propose a third ontology layer, on top of VIVO ontology (domain) and VITRO (application/editing and display configuration). This third ontology will be the user configuration ontology that will allow representation of these choices on a per-user basis. Note that an ontology can contain individuals and property statements (data), not just properties and classes. In effect, an ontology to hold structured annotations on data statements in VIVO, as had been envisioned as a way to save CV or biosketch specifications within VIVO for export to the Digital Vita docs module developed during their mini-grant.

• If certain data is not displayed but is stored, should a linked data request also hide that data? We propose controlling both of these levels.
• Approximate time: 2 weeks

User Interface

• How will the interface know what to display and what not to display?
• Developing a user configuration interface: allowing the user to select levels of visibility for data
  • What are the levels of visibility? You can hide this content in your page but it will public in the context of linked data?
• Approximate times: UI design and prototyping/Freemarker markup: 1 week

Application

• Connecting the interface to controller logic, etc.
• What different portions of the individual profile back-end will need to be aware of the new user configuration ontology in order to hide/display content?
  • Individual template model (properties, groups), list views (per property)?

Questions

• What is the intersection between authorization (roles, etc.) and user configuration?
• How does this work relate to Jim’s individual page refactoring?
• What permission levels or roles should we support? E.g. curators, administrators controlling display of content for other individuals - individuals controlling content on their own profiles? Proxy editors? Are we only going to support foaf:persons controlling their own content?
• Hiding data type properties (e.g. phone, email) are also included as likely scenarios. In this case, should we rename this JIRA issue/change its scope so the issue handles content in general and not just context nodes?
• What model should the user configuration settings be stored in?
• How will this ontology affect knowledge base migration?
• Should we consider adding this same kind of functionality to Vitro? Allowing Vitro users to control what content they would like to display/hide?

Can this component be addressed in stages?

• Starting small: perhaps one property, one instance, linked data vs. display
• Proposed (smallest scope):
  • Applying to context nodes only, not to simple object property or data property statements
  • Limit to individuals of type foaf:Person

Making this compatible with Vitro

• The same mechanics should apply to Vitro - e.g. user configuration ontology generic (these classes, properties)
• Which classes and properties may be defined in a configuration file, allowing flexibility/independence from a specific domain ontology

Dependency on any other component

Evaluate whether this interacts with Content display and creation - development component for v1.5

A suggested incremental plan

• develop a design and UI wireframes
• implement at the Vitro level
• implement for context nodes (easiest, could be done as part of the data) and for both object and data property statements via the new ontology graph