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

Reply via email to