W3C home > Mailing lists > Public > public-lod@w3.org > April 2011

Re: Best Practice for Renaming OWL Vocabulary Elements

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Thu, 21 Apr 2011 15:28:16 +0200
Cc: semantic-web@w3.org, public-lod@w3.org
Message-Id: <DE1BC2AE-F2B8-40B1-A048-0412072645F8@ebusiness-unibw.org>
To: Bob Ferris <zazi@elbklang.net>
Hi Bob,
Thanks!

In my opinion, explicit versioning of ontologies should be avoided in general; rather, one should evolve deployed ontology in a backwards-compatible fashion only. While there is is quite some academic work on ontology versioning, fact is that in practice, if you use fine-grained versioning, the Semantic Graph will break more frequently and you will need a lot more inferred triples.

So in GoodRelations, we use only one version of the ontology (http://purl.org/goodrelations/v1) and all modifications are as much backwards-compatible as possible. From time to time, we have widened the domain or range of a property from a single class to the union of multiple classes or other minor changes, but the side-effects of that are practically irrelevant, in particular if you judge them in the light of real-world data quality of WWW data.

Thus, we do not use owl:priorVersion, owl:versionIRI, owl:backwardCompatibleWith etc., because it is still the same ontology. 

I intend to keep it like that ;-)

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 

- update data or
- update derived ontologies or
- change queries.

owl:sameAs for all classes, properties, and individuals would further reduce the type of reasoning needed to ensure backward-compatibility, but would at the same time turn GoodRelations into OWL Full.

As for the SemWeb Vocab Status ontology: For keeping things simple, we just use owl:deprecated for the few elements that have been deprecated over time. From my perspective, the popularity / usage of an existing element is more important than the indicated degree of stability.

Martin

On Apr 21, 2011, at 2:43 PM, Bob Ferris wrote:

> Hi Martin,
> 
> I think this issue is also related to ontology versioning and assigning an applied version of an ontology in a dataset (see, e.g., [1]).
> OWL provides some properties to describe an version of an ontology, e.g., owl:priorVersion, owl:versionIRI, owl:backwardCompatibleWith (see [2,3]). However, all these relations have a range and domain of owl:Ontology. I'm unsure, whether you also like to type every property or class as an ontology (I think from a philosophical point of view this doesn't matter).
> So far your class and property alignment to prior versions looks good. Albeit, I would separate these axioms from the core ontology, because they are only need if one likes to process reasoning with backward compatible term definitions.
> Furthermore, you can make use of the SemWeb Vocab Status ontology [4] to mark an term, e.g., as 'archaic'.
> 
> Cheers,
> 
> 
> Bob
> 
> 
> [1] http://answers.semanticweb.com/questions/2815/how-do-i-knowmodel-the-applied-version-of-an-ontology-specification
> [2] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_IRI_and_Version_IRI
> [3] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_Annotations
> [4] http://www.w3.org/2003/06/sw-vocab-status/ns#
> 
> On 4/21/2011 11:46 AM, Martin Hepp wrote:
>> Dear all:
>> 
>> I am considering to rename a few conceptual elements in the GoodRelations ontology. However, they are already in use in data, queries, and applications. Thus, I am thinking of the least intrusive way of implementing this. I think this question is also relevant for many other OWL vocabularies on the Web.
>> 
>> Attached, please find my proposal. It critically depends on the ability of typical triple-stores to compute basic(*) inferences for
>> 
>> - owl:equivalentProperty for owl:DatatypeProperty and owl:ObjectProperty entities,
>> - owl:equivalentClass for pairs of owl:Class and
>> - owl:sameAs for pairs of "ontological" instances, e.g. value nodes defined in the vocabulary.
>> 
>> With "basic", I mean that additional triples for the additional class membership or property or instance must be materialized; this could be a subset of the complete theoretical implications.
>> As far as I know, Virtuoso does support this to a sufficient degree, but I am unsure about other parts of widely deployed infrastructure.
>> 
>> It would be no problem to express the necessary inferences by means of a SPARQL CONSTRUCT rule or in SPIN.
>> 
>> Please share any suggestions and concerns with me.
>> 
>> Old, but in use:
>> ---------------
>> foo:LongClassName a owl:Class ;
>> 	rdfs:label "LongClassName" .
>> 
>> foo:LongPropertyName1 a owl:DatatypeProperty ;
>> 	rdfs:domain foo:LongClassName ;
>> 	rdfs:label "LongPropertyName1" .
>> 
>> foo:LongPropertyName2 a owl:ObjectProperty ;
>> 	rdfs:domain foo:LongClassName ;
>> 	rdfs:range foo:SomeOtherClass1 ;	
>> 	rdfs:label "LongPropertyName1" .
>> 
>> foo:LongNameIndividual a foo:SomeOtherClass2 ;
>> 	rdfs:label "LongNameIndividual" .
>> 
>> Now, we want to rename those elements as follows, without breaking old data nor old queries / applications:
>> 
>> foo:LongClassName -->  foo:NewClassName
>> foo:LongPropertyName1 -->  foo:NewPropertyName1
>> foo:LongPropertyName2 -->  foo:NewPropertyName2
>> foo:LongNameIndividual -->  foo:NewNameIndividual
>> 
>> Proposal:
>> --------
>> a) Step 1: Define new classes, properties, individuals and link back to their old variants
>> 
>> foo:NewClassName a owl:Class ;
>> 	owl:equivalentClass foo:LongClassName .
>> 	rdfs:label "NewClassName (Note: This was foo:LongClassName previously)" .
>> 
>> foo:NewPropertyName1 a owl:DatatypeProperty ;
>> 	owl:equivalentProperty foo:LongPropertyName1 ;
>> 	rdfs:domain foo:NewClassName ;
>> 	rdfs:label "NewPropertyName1 (Note: This was foo:LongPropertyName1 previously)" .
>> 
>> foo:NewPropertyName2 a owl:ObjectProperty ;
>> 	owl:equivalentProperty foo:LongPropertyName2 ;
>> 	rdfs:domain foo:NewClassName ;
>> 	rdfs:range foo:SomeOtherClass1 ;	
>> 	rdfs:label "NewPropertyName2 (Note: This was foo:LongPropertyName2 previously)" .
>> 
>> foo:NewNameIndividual a foo:SomeOtherClass2 ;
>> 	owl:sameAs foo:LongNameIndividual ;
>> 	rdfs:label "NewNameIndividual (Note: This was foo:LongNameIndividual previously)" .
>> 
>> b) Step 2: Deprecate the old elements in OWL 2 style (using owl:deprecated)
>> foo:LongClassName a owl:Class;
>> 	owl:deprecated true;
>> 	rdfs:label "LongClassName - Deprecated, use foo:NewClassName instead" .
>> 
>> foo:LongPropertyName1 a owl:DatatypeProperty ;
>> 	owl:deprecated true;
>> 	rdfs:domain foo:LongClassName ;
>> 	rdfs:label "LongPropertyName1 - Deprecated, use foo:NewPropertyName1 instead" .
>> 
>> foo:LongPropertyName2 a owl:ObjectProperty ;
>> 	owl:deprecated true ;
>> 	rdfs:domain foo:LongClassName ;
>> 	rdfs:range foo:SomeOtherClass1 ;	
>> 	rdfs:label "LongPropertyName1 - Deprecated, use foo:NewPropertyName2 instead" .
>> 
>> foo:LongNameIndividual a foo:SomeOtherClass2 ;
>> 	owl:deprecated true ;
>> 	rdfs:label "LongNameIndividual - Deprecated, use foo:NewNameIndividual instead" .
>> 
>> c) Since the owl:deprecated property is not defined in OWL1, I would also add the following axiom in order to remain within OWL 1 DL:
>> #OWL 1 DL compatibility of the OWL2 deprecated property
>> owl:deprecated a owl:AnnotationProperty.
>> 
>> Thanks in advance!
>> 
>> Best
>> 
>> Martin
> 
Received on Thursday, 21 April 2011 13:28:43 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:32 UTC