...
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), 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 isf:has_url_link property?
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.