...
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.
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, and indeed we don't know anything about the type of the URI so should not infer that it is a document, person, organization, or anything else.
By doing this we would lose two features that are important for the VIVO application 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.
This is a case where the needs of the application have been allowed to trump the most straightforward way of representation in the ontology. However, if we know what the remote URI is, it seems like we should type it as a Person or Document or Organization, however, and use a more semantically meaningful property relationship than the generic 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?
How do you store the value of the vivo:linkURI property in a VIVO instance if that value is a URI in that same instance of VIVO?
The application doesn't attempt to parse the xsd:anyURI strings in a vivo:URLLink entity in any special way if you set a vivo:linkURI property that points to the same VIVO application. That link will break if resource URIs get changed, just like any other link.
If we adopted the strategy described just above of using the desired URI as the URI of the vivo:URLLink rather than storing the URI in the vivo:linkURI property, a VIVO URI would be updated if that entity's URI was modified through the VIVO application (although this can only be done by administrators).
This introduces the philosophically challenging notion of whether the URI refers to the person or the webpage of a person, however – normally a reference to a URLLink references a webpage and a different object property would be to link an organization to a person, for example.
Would this even have the desired effect?