Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We also have a need for the application to treat the URI of a resource in VIVO differently from a resource known to be native to another application (so far another VIVO, but it could be Profiles or anything else). The VIVO application can be configured to treat certain namespaces as external namespaces to redirect to rather than render locally. This configuration was developed to allow storing the URIs, rdf:type statements, and rdfs:labels of Weill Cornell Medical College people and organizations in the Cornell Ithaca VIVO instance while ensuring that these URIs were redirected to the Weill Cornell VIVO for rendering, since the Weill Cornell VIVO has much more complete information about that URI.

We can't possibly know all the namespaces of URIs that will be referenced in a VIVO instance, so if we wanted to just redirect to an arbitrary URI the VIVO application would have to instead keep track of all the namespaces that it should try to render locally.  This would include all the namespaces of ontologies included in VIVO as well as any namespaces beyond the default namespace established in configuring a VIVO instance – more tractable than the impossible task of recognizing a namespace as external, but not something we've attempted to date.

It might also be possible for the application to redirect to the object of the isf:has_url_link property rather than ever trying to render that URI – this would require adding a parameter to the URL on a VIVO page to tell VIVO that if the user clicks

When rendering the object of an isf:has_url_link property, however, we change the application to link directly to the URI of the URLLink itself rather than looking for a vivo:linkURI data property of the URLLink entity. This would require some data migration in the transition to VIVO 1.6 and would require making the application robust enough to display an rdfs:label if present but just render the URI otherwise; an rdf:type statement would also have to be made optional but could be inferred by a reasoner if the range of isf:has_url_link were to be vivo:URLLink (which it presently is not declared to be).

By doing this we would lose two features that are important if the same URI is referenced from two different entities in VIVO and wants to be ordered or labeled differently when displayed on each entity's individual page.  For example, if the same URI is the object of multiple isf:has_url_link properties there could be multiple rdfs:labels and multiple vivo:rank properties for the same URI in the triple store and the application would not have any way of knowing which to use.

 Would this even have the desired effect?