Re: Best Practice for Renaming OWL Vocabulary Elements

Hi Bob,

On Apr 21, 2011, at 6:00 PM, Bob Ferris wrote:

>> It's only now that I would like to use shorter labels for 2 - 3 conceptual elements that are already in use, without forcing anybody to
> 
> Yes, if you only like to introduce some new labels, then you can easily on change the value of the related rdfs:label relation. However, you proposal includes the introduction of new identifiers for concepts and relations. The naming of identifier should be well thought-out**.
> **) from my POV an example of a rather bad identifier naming in GoodRelations is gr:ProductOrService

gr:ProductOrService is the union of products (in the sense of objects) and services (in the sense of happenings). I do not see a better name for this class.
GoodRelations does not distinguish between products and services because the underlying analysis indicated that a majority of potential data sources does not support this distinction. For example, most shops have one representation in the RDBMS for products and for related services, which they cannot partition into products and services before publishing RDF data (at least not reliably). So we need the union anyway. If you know that your data includes only services, simply define your own specialization

foo:Service a owl:Class;
	    rdfs:subclassOf gr:ProductOrService.

and our are done.


> Btw, DC relates versioning information to each concept or relation definition by utilising dcterms:hasVersion [3].
> 
>> From my perspective, the popularity / usage of an existing element is more important than the indicated degree of stability.
> 
> Well, this is a metric which is not measurable, because some terms are due its nature more often applied as other ones. For example, a label property, such as dc:title, has a higher usage than a very specific (/narrow) property of a specialised purpose ontology, e.g., void:sparqlEndpoint of the VoID vocabulary.

It is not easy to measure, and there is no single objective metric, but this does not at all imply that it should not be considered. Web ontologies are not engineered artifacts, but instead proposals, engineered by an individual or small group, and then used / adopted by a larger community. The ontology is the combination of the proposal and the usage in the wild - if your users use the ontology in a way incompatible with the specification, it is not immediately clear whether your ontology specification is wrong or their data is wrong. You may just have failed to establish a proper treaty between your brain and their brains.

> That is why, information about a design status of a term of an ontology specification might sometimes be useful, e.g., properties that are marked as 'experimental' should rather be avoided in a dataset of a production.
Actually, I think a good ontology engineer does not put any "experimental" features into a publicly deployed ontology.

Ontology engineering is, IMO, a serious form of art, and a good artist does not put "experimental" features into a piece of art to check which ones are more appealing to the audience. Instead, an artist works hard on the prototype until he / she releases the best possible conceptualization. Ontologies must be community grounded, but not in the naive sense that they can be changed by everybody at will because of economic and technical reasons.

Martin

> 
> Cheers,
> 
> 
> Bob
> 
> 
> *) for example it might be better to utilise, e.g., http://purl.org/goodrelations/, as generic URI of GoodRelations ;)
> 
> [1] http://answers.semanticweb.com/questions/2815/how-do-i-knowmodel-the-applied-version-of-an-ontology-specification
> [2] http://dublincore.org/documents/dcmi-terms/#terms-conformsTo
> [3] http://dublincore.org/documents/dcmi-terms/#terms-hasVersion
>

Received on Friday, 22 April 2011 07:59:43 UTC