Date: Fri, 29 Mar 2024 10:25:00 -0400 (EDT) Message-ID: <141497800.145.1711722300433@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_144_388426839.1711722300433" ------=_Part_144_388426839.1711722300433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
back up to How to plan data ingest for VIVO
previous topic: Typical sources of VIVO data
Whenever possible, leave non-public information out of the public VIVO, = since including private information will complicate a user's picture of his= or her VIVO profile and make the entire project more difficult to manage. = Semantic web tools have been developed to share data by exposing it for dir= ect consumption in other tools as well as for human eyes to read, and while= the Vitro software underlying VIVO offers ways to limit the visibility of = the data on websites, a complete RDF export of a VIVO database will be dire= ctly readable by other tools that may make no attempt to filter by any crit= eria.
As with any data and any software, this is a common sense balance of ben= efits and risks. There are many reasons to include data such as department = identifiers in VIVO that should be hidden from view to avoid clutter but ar= e essential for aligning new data; the project will add more ways for users= to limit the visibility of certain research-related information a person m= ay not wish to share, such as a network of informal colleagues or a new are= a of investigation. However, we see little to gain and much to lose by putt= ing any confidential data into VIVO, such as salary history, termination da= tes, leave status, or identification information (age, sex, race, nationali= ty, marital status, home phone or address, etc). Cornell's VIVO instance li= nks users to the campus directory rather than holding contact information d= irectly, since our HR system frequently lags employees' own updates of thei= r contact information.
Should VIVO become a System of Record (SOR) at your institution? That's = really up to you, but you need to carefully consider the risks as well as b= enefits. VIVO may well become the SOR for information such as research area= s and keywords, brief statements of research purpose, and perhaps publicati= ons. For other information such as grants and appointments that are current= ly maintained elsewhere for administrative purposes, VIVO should remain a d= ownstream consumer of SORs rather than seeking to supplant core systems. At= Cornell the college administrators feel a pressing need to have a data mar= t that combines all the information they need about faculty, including HR, = grants, courses, course evaluations, and assorted other information includi= ng some they track directly. They have wide-ranging requirements for runnin= g reports on that data, however, and need to include salary history, grades= , performance reviews, and other data that would be much better managed thr= ough a data warehousing and report generation tool behind appropriate firew= alls than by a VIVO instance designed for public information discovery and = sharing.
next topic: Ingest tools: home brew or off the shelf?