It is helpful to understand that the VIVO web application is built using "triples" consisting of a subject (an individual in ontology terms, also sometimes referred to informally as an item or entity), a predicate (an object property or a data property) and an object (once again, any individual in VIVO).
These "triples" are also called statements and reflect the structure of a sentence in ordinary language.
Subject-predicate-object triples express the relationships among the individuals in VIVO using object properties and support attributes of individuals (e.g., first name, start date) using data properties.
Individuals in VIVO are typed as members of one or more classes organized and displayed as a hierarchy. Child or sub-classes inherit the properties of their parent or super-classes. A child class is a specialization of a parent class – if Person is the most general class for people, then Faculty Member and Student are more specialized child classes . The class hierarchy in an ontology acts much like a taxonomy, where everything about a parent is also true for its children.
Once classes have been created, they can be populated with individuals – as data on an underlying framework.
A thesaurus extends a taxonomy by providing certain standard relationships among concepts or terms – not only the broader term and narrower term relationship of the hierarchy itself but also relationships such as related term or see also. In an ontology, the class hierarchy framework can be extended with more open-ended relationships, called object and data properties.
Object properties connect two individuals (a subject and object) with a predicate, while with data properties the predicate connects a single subject with some form of attribute data. Data properties have defined datatypes including string, integer, date, datetime, or boolean. Both object and data properties are often but not always defined to have a domain class, such as Person or Event, specifying the class membership of the individuals serving as subjects for each object or data property statement. Object properties also may have a range class that specifies the class membership of the individuals serving as objects of the property predicate.
VIVO has two property editors – one for object properties and another for data properties. Data properties are simpler to create and edit because only a domain class and a datatype need to be selected. Object properties also have a range class and additional decisions must be made about whether or not to create an inverse property.
VIVO as an application is designed to create and show object properties from the subject to the object and vice-versa. Bi-directional relationships allow users to navigate from a person to a related department or grant while also supporting lists of department members on department pages or investigators on grant pages. This feels natural, is less work to maintain, and helps assure that an end user arriving at a VIVO page from a Google search can see and navigate easily to contextual information. The properties are typically directional in nature and opposite in meaning – if the Biology Department is part of its parent College of Life Sciences, the College has part Biology Department.
Object properties can be uni-directional, however, and they can also be defined as symmetric. A symmetric property asserts the same relationship in both directions, with the most common example being related terms.
VIVO supports keeping an internal list of ontology namespaces and corresponding prefixes to facilitate using external ontologies as well as to help differentiate local ontology additions from VIVO core.
VIVO uses the common shorthand prefix when referring to an ontology in the ontology editor, such as bibo: (short for Bibontology), foaf: (short for Friend of a Friend), or core: (short for VIVO core). The prefix stands for the fully qualified namespace for the ontology – http://purl.org/ontology/bibo/ for the Bibontology, http://xmlns.com/foaf/0.1/ for FOAF, and http://vivoweb.org/ontology/core# for VIVO core.
When an ontology namespace has not been added to this list, no prefix appears before a class or property name in the ontology editor. If then a class or property name happens to be duplicated from one ontology to another (e.g., bibo:Image and foaf:Image), it's not evident on the VIVO ontology editor's pick lists which name is which.
The Site Admin > Ontology List command lists the ontology names, namespaces, and prefixes that your installation of VIVO is currently aware of. If an ontology is listed but no prefix has been specified yet, the ontology name will be used as the prefix in the ontology editor – making the names on pick lists more bulky. To add a prefix, click on the ontology name and then the edit button in the center column of the blue control area on the form that appears. Specify a prefix (without the colon) and click the Submit changes button to save. Note that while the editor allows spaces in the prefix, it is conventional not to use spaces in ontology prefixes.
Adding another ontology namespace to the ontology list will allow VIVO's ontology editor to recognize and include that namespace as a selection option when adding new classes or properties.
Site Admin > Ontology List > Add New Ontology To add a new namespace, click on Add new ontology at the top of the ontology list or on the right on the blue control area of the ontology list editing form. Specify a name, namespace, and prefix for the ontology and then submit the form with the Create New Record button.
The added ontology should be visible in the ontologies listed under "Ontology List".
For example:
You use this form to add an individual (aka entity) of a specific class or type. You can see examples of adding content in another section.
Site Admin > Data input - Add individual of this class
For example: Add a Faculty Member
Site Admin > Data input - Add individual of this class
NOTE: In Ontology terminology, an "individual" is equivalent to a node. A node is anything from a person to a conference.
All information in VIVO is stored one way or another as subject-predicate-object statements known as triplesi. The subjects and predicates (and many objects) in these triple statements are references that can be repeated in many statements; references are expressed as identifiers that in the RDFi world take the form of URIs.
All the statements referencing the same identifier as either a subject or object collectively describe an individual in the VIVO system. You may encounter various alternative names for indivdual including resource, entity, item, node, or object. Note, however, that the individual in RDF has no fixed structure, unlike objects in object-oriented programming languages or records in relational databases.
Individuals in VIVO are, however, typed (using the rdf:type property) as members of one or more classes organized and displayed as a hierarchy. Child or sub-classes inherit the properties of their parent or super-classes. A child class is a specialization of a parent class – if Person is the most general class for people, then Faculty Member and Student are more specialized child classes. The class hierarchy in an ontology acts much like a taxonomy, where everything about a parent is also true for its children.
The class hierarchy provides a framework to help identify the different types of individuals modeled in a VIVO application. Class definitions are combined with specifications of the relationships or properties that may be associated with members of the class. Classes and properties together determine what statements can be created to describe individuals (either as assertions by users or imported from other data sources, or as inferences through reasoning).
Classes are much more evident when defining a VIVO ontology or adding content than they are from the public view of a VIVO installation. They do appear in search results and on the Index page as the second-level faceting (or sub-types) under the broad, top-level class groups such as people, activities, events, and organizations.
To add or edit classes, see Class Hierarchy.
Class groups are a VIVO-specific extension to support using VIVO as a public website as well as an ontology and content editor.
Class groups are what the name implies: informal groupings of classes to organize pick lists, search results, and the VIVO Index page. Most often they mirror the top levels of the class hierarchy, with notable exceptions:
To review, add or edit class groups, see Class Groups.
In the Class Hierarchy page, you can edit/add classes, add individuals/entities to a class, and add autolinks .
Site Admin > Class Hierarchy
Site Admin > Class Hierarchy
Only very seldom will a new class be added at the top level of the class hierarchy. It is much more common to add a class as a subclass of an existing class at the most detailed level of the current hierarchy in order to provide more granularity as needed for a local VIVO installation. This allows the more detailed information to be differentiated locally while still allowing the more general form to be harvested for national-level analysis, searching, and browsing.
Note that in a deep class hierarchy it is possible that not all classes will be displayed from the top level; by clicking on any class partway down the hierarchy (e.g., Person) and then selecting the Show hierarchy below This Class option, a browsing view is generated that shows only the hierarchy below the selected starting class.
To add a new subclass in the desired place in the hierarchy, navigate to the desired class via the hierarchy as described above or by selecting* Class Hierarchy > All classes* and searching for the name of the desired class in alphabetical order within the listing.
The added class should be visible in the Site Admin > Class Hierarchy, via Site Admin > Class Hierarchy > All classes, and under the appropriate class group from Site Admin > Class Groups
Note also that any class can be positioned at a lower level of the class hierarchy after creation by specifying a Class Control Panel > New Link to Superclass from the class, or by specifying Class Control Panel > New Link to Subclass from the desired parent class.
Site Admin > Class Hierarchy
For example: Add a Class Autolink to Librarian tab to bring items of type Librarian into Librarian tab)
Class groups are a means to organize the classes in VIVO into groups. They represent the facets seen when VIVO is searched (people, activities, events, organizations, etc).
A class that is not in a class group will not appear on the pick list for adding new individuals on the Site Admin page or on the list of classes (by class group) on the Index page. To add an individual in a class not in a class group, navigate to the class in the class hierarchy and click the Add New Individual in this Class button.
Site Admin > Class Management - Class Groups
Site Admin > Class Management - Class Groups
If classes define what each individual in VIVO is, properties define how that individual relates to other individuals and allow an individual to have attributes of its own.
Object properties connect two individuals (a subject and object) via a predicate functioning as the verb phrase in a sentence. For example, the verb phrase "is teacher of" or "teaches" connects a subject Person with the object Course in an RDFi statement in the same way as the verb connects the subject and the object in the sentence, "Professor Smith teaches Economics 101."
In contrast, a data property connects a single subject with some form of attribute data. While in theory every bit of information in VIVO (or any RDF database) could be modeled as a full-fledged individual member of a class, it is more convenient to store some information in simpler form using defined datatypes including string, integer, date, datetime, or boolean. The objects of data properties are not shared, nor can they be the subjects of other statements.
Both object and data properties are defined to have a domain class as a way to limit when they apply – if not specified, the most general class of Thing implicitly serves as the domain. For example, when a property such as credit hours is given a domain class of Course, any new individual entered into VIVO and typed as a Course may have a property listing its credit hours, while that property would not be offered as an option for an individual typed as a Person.
Object properties also have a range class that specifies the class membership of the individuals serving as objects of the property predicate. If no class is specified, the range class is implicitly considered to be Thing, meaning that any individual could serve as an object of the property.
Taken together, the class hierarchy and the object properties and data properties that have been defined in an ontology form a framework for adding statements. Ontologies can be reused in multiple applications based on different software and can be combined to serve additional purposes. Statements created to populate an ontology can be combined or exchanged among applications sharing the same ontology, independently of the software.
Note that it's possible to introduce inconsistencies in a semantic data model by changing the data or by changing the model after information has been entered. One of the advantages of a semantic web approach to data modeling is that reasoning can help detect inconsistencies when they occur, as well as reduce the likelihood of inconsistencies by limiting the choices made available when users are adding data.
VIVO has two property editors – one for object properties and another for data properties. Data properties are simpler to create and edit because only a domain class and a range datatype need to be selected (or left with their default values of Thing for the class and untyped for the datatype).
Object properties are need a range class specification instead of a range datatype, and additional decisions must be made about whether or not to create an inverse property.
VIVO was designed to create and show object properties as pairs in opposite directions – from the subject to the object and vice-versa. These bi-directional relationships allow users to navigate from a person to a related department or grant while also supporting lists of department members on department pages or investigators on grant pages. This feels natural, is less work to maintain, and helps assure that an end user arriving at a VIVO page from a Google search can see and navigate easily to contextual information. Paired directional properties are complementary in meaning – if the Biology Department is part of its parent College of Life Sciences, the College has part Biology Department.
Object properties can be specified to be uni-directional, however, if the complement or inverse would make no sense or if creating and storing the inverse would provide no value to the application.
Object properties may also be defined as symmetric. A symmetric property asserts the same relationship in both directions, without any notion of complementary or inverse meaning. When two terms are defined as "related" there is no implication that one has precedence over the other in the relationship, whereas if one term is "derived from" another, the second term would have the different and complementary property called "has derivation."
Like class groups, property groups are a VIVO-specific extension to support using VIVO as a public website as well as an ontology and content editor. They are stored as RDF within the overall VIVO data model but as annotations on the model do not factor into any reasoning processes.
Property groups are a means to form informal groupings of object and data properties for the purposes of ordering page displays. As discussed in more detail under Verbose Property Listing, property groups have a display rank that determines precedence in page rendering, and object and data properties within a property group each carry a display rank affecting the order they are drawn within their group.
Object properties represent "the glue" in the triples that make up VIVO; an object property connects any two entities (also known as items or individuals) in VIVO to complete the triple. Object properies can be created and edited from the Object Property Hiearchy screen or from the Object Properties alphabetical listing of all object properties. You need to be an admin or a curator to add or edit object properties.
Add New Object Properties
Site Admin > Ontology Editor - Property Management - Object Property Hierarchy
Fields below this on the form control specialized functionality and may be left blank or in their initial state.
Save your work by clicking Create New Record and return to the Object Property Control Panel screen for the new object property created.
To return to the full list, select Root Properties for the Object Property Hierarchy screen or See All Properties for the Object Properties screen listing all object properties in alphabetical order by public display name.
There are no differences between the object property creation form and the editing form, and the above instructions apply.
A data property connects a single subject individual (e.g., a Person or Event) with some form of attribute data. These attributes can be untyped and have a language identifier or can be defined to adhere to one of a number of pre-defined international standard datatypes including string, integer, date, datetime, or boolean.
Data property statements have the same 3 parts as any other RDFi statement – the subject or domain (an individual), the predicate indicating which data property is involved, and a datatype value as the object. The objects of data properties are not shared, nor can they be the subjects of other statements.
When the object of a data property is set as untyped or string, the contents are free text. Other datatypes are constrained to accept values consistent with that datatype.
For example, a data property defined to accept only boolean datatypes allows only 'true' and 'false' and will reject 'yes', 'no', or any other value. Values defined as dates must conform to a standard data format (YYYY-MM-DD). VIVO has only recently begun enforcing these datatypes, and the editing screens do not yet provide calendar widgets or even very clear indications of the required value formats.
Data properies can be created and edited from the Data Property Hiearchy screen. You need to be an admin or a curator to use this screen.
As an example, we will create a new local ID number data property.
All sites should create this new ID property, as well as a new Department ID property, for storing local identification numbers.
Site Admin > Ontology Editor - Property Management - Data Property Hierarchy
When all desired information has been entered, save the new data property using the Create New Record button. The Datatype Property Control Panel screen is shown with the new property as the active property.
From the Data Property Hierarchy listing or the Data Properties alphabetical listing of all data properties, click on the desired property to edit. The Datatype Property Control Panel screen is displayed; click Edit this Datatype Property in the center column of the blue-shaded edit control box.
Property groups are a way to group similar object properties in VIVO.
Site Admin > Property Management - Property Groups
Site Admin > Property Management - Property Groups
Turning verbose property listing on will provide property information as an aid to specifying the desired order of appearance of what can become a large number of object and data properties appearing on a VIVO page.
Note that a user must be logged in and have editing privileges to have the option to turn on verbose property listing.
The order of properties is managed by simple integer rankings on property groups and on properties themselves, with lower numbers appearing first. Group rankings have higher precedence – all the properties included as members of the group ranked first will drawn before any of those in the group ranked second. Properties not included in any property group are drawn last (in the order specified by their own internal display rank value).
Within any property group, properties are drawn in the order specified, again with lower numbers appearing first.
Property groups may include both object properties and data properties.
Managing display order for properties across a whole VIVO installation can be tedious - we recommend using numbers in increments of 10 at first to allow inserting a few properties before or after the initial choices of rankings without having to renumber the entire list of properties.
When a user has activated the verbose property display option for a session, it makes all relevant annotations for the properties on a rendered VIVO page visible to that user. While this is ugly, it greatly facilitates diagnosing the settings interfering with the desired ordering and provides direct links to each property for changing the offending setting.
Note that this is a user-specific setting that does not persist between sessions. It must be turned on each time you log in.