*Deprecated* See https://wiki.duraspace.org/display/VIVODOC/All+Documentation for current documentation

The W3C vCard standard was adopted for use within the VIVO-ISF ontology during the CTSAconnect project for several reasons:

  1. Recognition of the need to maintain contact information for people that could vary widely in completeness
  2. Recognition that people may have both variant forms of their name as part of one identity and in some cases multiple distinct identities
  3. Recognition that the vCard is a standard by a leading standards organization for the Web
  4. Recognition that vCards are also a standard in other domain areas and have been implemented using other technologies, from Outlook and other calendaring and contact management applications to Drupal modules that support vCards as a custom content type.

Use cases

please add any addition use cases

  • multiple names for the same person (a single identity), including misspellings – e.g., Peter J. Mangurian, P.J. Mangurian, P. James Mangurian, P.J. Mangorian
  • multiple identities (authors who publish under several names, such as Jonathan Cain publishing as Nicholas Cain and Dick Stivers
  • multiple email addresses, web pages, or affiliations associated with the same person
  • similar situations with organizations or groups

Relevance to the unknown author problem

Early on in the NIH-funded VIVO project (2009-2011) the ontology team discussed different approaches to recording the information about authors of journal articles and other publications who are not at the same institution hosting a VIVO instance and may in fact be known only through a last name and first initial.  The VIVO-ISF ontology connects authors to publications via an Authorship relationship that may optionally store author rank information that is important in certain disciplines as a indicator of relative credit for the publication.

The presence of the Authorship node between a person and a publication would also potentially offer the ability to store the name of the author as listed in the publication citation, for subsequent use in disambiguating authors and/or differentiating works published under alternative forms of a name. When that desire led to requests for several new properties holding much the same information as typically stored with a foaf:Person, including first and last name, email address, etc. the ontology team instead recommended always creating a foaf:Person record and adding the name parts or email information there.  This approach, however, had the consequence of introducing larger numbers of foaf:Person records into VIVO about whom very little if anything was known.

The thinking in using vCard is that a person may have multiple vCards where the name listed in each case would correspond to the name used in a citation — either every authorship would have an associated vCard record (or a full graph comparison could be made to see whether two vCards are identical, though that opens up the possibility of error). By linking that particular vCard to an authorship, the name form associated with a citation can be determined.  In contrast, if we instead use a citationName on a foaf:Person there’s no association with any particular authorship, and by extension, with any particular publication. If a person uses a small set of name variants there’s no harm in having them associated with the foaf:Person record, but I believe the goal under consideration is to know which name variant is associated with which publication, along with the potential for being email address or affiliation information from the full publication citation record as well.


The vCard structure has been a lot for VIVO sites to adapt to, although John Fereira recently commented that having vCards in VIVO data made it easy to use an off-the-shelf Drupal module to export data from VIVO to Drupal.  That was the idea – use a standard that is widely supported rather than inventing our own with 80% of the complexity.


Don Elsborg suggested at the Hackathon that we look to develop some kind of intermediate interface that ingest scripts could write to that would mask some of the complexity of the vCard structure — that could be an alternative to modifying the ontology.





  • No labels