- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Thu, 21 Apr 2011 15:28:16 +0200
- To: Bob Ferris <zazi@elbklang.net>
- Cc: semantic-web@w3.org, public-lod@w3.org
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:30:47 UTC