From: "Weber, Griffin M" <firstname.lastname@example.org>
Subject: VIVO ontology question
Date: June 6, 2013 10:16:06 AM EDT
To: "email@example.com" <firstname.lastname@example.org>
I'm not sure if you are the right person to answer this, but I have a question about the vivo:linkURI property of a vivo:URLLink class. The vivo:linkURI property is a datatypeproperty. However, its value is a URI, right? So, why isn't it an object property? A related question is 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? Is it a literal or an entity?
Your are correct that the vivo:linkURI property would more correctly be an object property than a data property. The reason we declare it to be a data property has to do with the editor in the VIVO application and the needs of our users to be able to define a unique label for a reference to a website and to be able to specify an order for display on the page; if two entities reference the same URI it would be impossible without this wrapper URLLink to distinguish which label and rank belong to which reference.
To add the actual URI reference we create an individual of type vivo:URLLink and populate the vivo:linkURI property with an xsd:anyURI value. This means as you have guessed that if you create a link to another entity in VIVO that link will have to be manually updated if the URI of that entity changes.
Another reason why we persist in this solution of convenience is that the vivo:webpage object property has little or no semantic meaning. Linking to the URI of a person, organization, or other entity in VIVO or in any external triple store would ideally use a more semantically meaningful property, while vivo:webpage and its vivo:linkURI property are expected to contain references to resources of unknown type, typically in the form of web pages that would not respond to linked data requests.
It would be more correct for us to convert the linkURI property about each URLLink individual to be an object property with the URI as its object, even while keeping our wrapper URLLink class with a unique label and rank. This also gives us the ability to create subclasses for more specific types of resources such as Faculty of 1000 links.
Changing vivo:linkURI to an object property would require some minor changes to the VIVO application, and given the major shift to the ISF ontology for 1.6 we will likely not consider this change until VIVO 1.7, but we appreciate your pointing out this question.
Are there specific cases where this makes a difference in Profiles, or other factors you think we should consider? I've started a wiki page on the topic at https://wiki.duraspace.org/x/w8gQAg and would welcome any further thoughts or questions.