Re: Best Practice for Renaming OWL Vocabulary Elements

Le 21/04/2011 15:28, Martin Hepp a écrit :
> 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.

OWL 2 distinguishes the versionIRI and the ontology IRI. 
http://purl.org/goodrelations/v1 is the ontology IRI. Goodrelations does 
not have a versionIRI but it could and it should. It doesn't break 
anything, most ontology engines ignore the version IRI, which is just an 
informative reference to differentiate the current version from possibly 
other versions. It's good that tools and people can check (if they want) 
that the ontology has changed.

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

It is indeed the same ontology, but the version is different and this 
should be reflected in the owl:versionIRI. When one dereferences the 
versionIRI, it should lead to the ontology as it was at this version, 
with additional annotations pointing to the previous and next version 
and possibly the backward compatibility status.

> I intend to keep it like that ;-)

Unfortunately. As I said, it does not need breaking anything. I cannot 
see how adding an ontology annotation can break compatibility and make 
anything worse.

> 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.

It woud not make it OWL 2 Full, but this is not what you want to do. The 
old and the new classes are really distinct entities, even though they 
have the same extensions. For instance, the old class has a label 
"OldClassName" which the new class does not have. With owl:sameAs, both 
classes (which would be actually one) would have the same labels and 
would be deprecated.

> 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.

Agree and disagree. The status can be a hint for the consumer about how 
the publisher considers the term. If a status is "highly unstable", 
consumers may want to be cautious when they make software that provides 
functionalities based on the term. However, I'm not sure if there is at 
all software that cares about the stability status.

> 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
>>
>
>


-- 
Antoine Zimmermann
Researcher at:
Laboratoire d'InfoRmatique en Image et Systèmes d'information
Database Group
7 Avenue Jean Capelle
69621 Villeurbanne Cedex
France
Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13
Lecturer at:
Institut National des Sciences Appliquées de Lyon
20 Avenue Albert Einstein
69621 Villeurbanne Cedex
France
antoine.zimmermann@insa-lyon.fr
http://zimmer.aprilfoolsreview.com/

Received on Thursday, 21 April 2011 14:01:30 UTC