...
When 2 URIs are declared to be the same in VIVO, all the statements about both will be displayed for either (e.g., Israel and Israel). Improvements are needed, however:
- A constrained could disable sameAs reasoning in our simple reasoner, which will start filling in for one URI everything that is inferred about the other
- add the switch to configuraiton
- offer it as a standard predicate to add values for
- modify the interface to allow adding those statements and to display the statements
- there is no way via the current UI to add or remove owl:sameAs assertions – they have to be added as tiny RDF files via the add/remove RDF command
- sameAs in the subject position
- It will adversely affect performance to require VIVO to detect that two or more URIs for an individual have been declared to be sameAs each other and then retrieve and blend all the data for each URI for rendering on a single page
- This becomes more complicated when the 2nd or higher URI is not in the local VIVO
- It may be a first step to simply show a link to the equivalent URI, with some form of "see also" label
- It will adversely affect performance to require VIVO to detect that two or more URIs for an individual have been declared to be sameAs each other and then retrieve and blend all the data for each URI for rendering on a single page
- sameAs in the object position
- when another VIVO individual is linked to one or the other of these Israels, the application is not yet smart enough to show only one object property statement to one instance of Israel, and it looks to users like a duplicate of both the country and the relationship
- Colorado has a use case to assert sameAs relationships between people's profiles in their university-wide VIVO and the separate implementation at the Laboratory for Atmospheric and Space Physics, where additional information about research projects, equipment, and facilities will be stored behind a firewall. They would like to pull data from the CU VIVO into the LASP VIVO dynamically, and pull any publicly visible data from LASP VIVO to supplement the CU VIVO content about a person.
- Colorado also has a need to pull data from the Harvard Profiles system used by the University of Colorado Medical School in Denver to the CU VIVO without replicating more than is necessary. This is a similar use case to the connections needed between VIVO on the Cornell Ithaca campus and the Weill Cornell VIVO.
...