VIVO-1062: Develop a means for public discovery of software and ontology versions

[chenejac]

Jon Corson-Rikert (Migrated from VIVO-1062) said:

VIVO has a way for sysadmins to determine detailed version information, but not for someone trying to harvest the linked data; and apart from looking for telltale artifacts in the ontology, the version of the ontology being used is also not directly discoverable.

This may not need to be as granular information as the attached image for sysadmins -- the request is "I understand that the question is whether the version is pre or post 1.5. Having this information in some kind of footnote/about page/api in VIVO would ease the work of potential data users."

[chenejac]

Jon Corson-Rikert said:

From: Jing Wang Reply-To: VIVO Development List Date: Thursday, September 10, 2015 at 1:39 PM To: VIVO Development List Subject: Re: [Vivo-dev-all] Determining VIVO's ontology version used

Hi, Thomas, I second that getting vivo ontology version in a machine readable way, either via API or other, would be helpful, especially when connecting and exchanging linked data among VIVO sites in a networked environment.

I also wonder what is your use story for harvesting data from these vivo sites. The VIVO in networked research ecosystem task force group has gathered a few scenarios and I am interested to know the background of your inquiry.

Thanks,

Jing

[chenejac]

Mike Conlon said:

Why not two extra triples in the triple store:

"x" "y" These two triples would be supplied by VIVO at config/build time. Each element of these triples would need to be defined, of course, but one would expect to find "v1.7" as the "x" value for UF, for example. Defining "this" would be very advantageous (perhaps an ISNI style URI). We would then be able to track where triples came from in scenarios such as search, index, reuse, etc. Might have a series of "hasOntology" assertions sufficient for building all prefix statements for the collection. Just some thoughts.

[chenejac]

John Fereira said:

Although the addition of the triples that Mike suggests can be helpful, in the use case of harvesting linked data from a VIVO instance it is probably not enough. For example, in the instance of VIVO one is harvesting has the admin turned on the serveExtendedLinkedData property in the runtime.properties file? That could make a difference if one is making a linked data request using the URI for a person. A LD request for a Person URI might return the vcard:Individual but not the vcard:Name, vcard:Email, vcard:Address, etc classes. If the site is created SPARQL construct queries in WEB-INF/rich-export directory, that's going to define what RDF is returned, and the out-of-the-box files were created primary to support Digital CVs and only the site admin would know if they were modified.

If one is going to harvest data from another VIVO instance, there will almost certainly be some sort of dialog required between the two site admins.