4
3

Okay, I saw it now several times that in ontology specifications the ontology developers redefine statements, which came originally from other ontologies. Often they marked this in a comment as OWL-DL Compliance. They did this to redefine, e.g. foaf:Person, foaf:maker or several annotation properties, they used for annotating their ontology specification. I don't believe that it is a good design to redefine concepts/properties, which came originally from another ontology. In particular, these concepts and properties are often 'very important', because they are taken from upper (e.g. FOAF) or meta (e.g. OWL) ontologies. I believe that by using owl:imports, it is possible to import the affected ontologies and hence no redefinitions are needed and OWL DL Compiliance should also be fine, because it taken now place at the whole graph (incl. the imports). I think importing other ontologies is no real problem, because they are often not very big (we are at the T-Box level!).

Okay, for clarification: Why do we have to include existing concepts/properties, e.g. foaf:Person, foaf:maker, dc:date, dc:description, dc:title etc., in our ontology specification, although they are already existing in their own ontolgies?

You can nearly look at every 'well-defined' ontology (marked as OWL-DL Compiliance), e.g. FOAF or SIOC -they are including these concepts/properties, but it is not really clear to me, why they do that and don't use owl:imports instead.

asked 27 Jun '10, 13:47

zazi's gravatar image

zazi
3.4k213
accept rate: 13%

edited 27 Jun '10, 17:56


In addition to what Dave Reynolds said:

Many ontologies that exist in the wild are not OWL DL compliant, and importing them will lead to a DL-non-compliant ontology. This is particularly true for ontologies that have been defined as RDFS vocabularies, without taking OWL into consideration. One contributor to DL non-compliance in RDFS vocabularies are property declarations of the form:

ns:p rdf:type rdf:Property .

OWL (1/2) DL needs ns:p to be declared as one of owl:ObjectProperty, owl:DatatypeProperty or owl:AnnotationProperty. The problem now is which kind of OWL-style property is ns:p intended to be? rdfs:range axioms for declared properties can be helpful to find out. But, firstly, range axioms cannot be expected to always exist and, secondly, they don't have to necessarily be a safe or an appropriate criterion for distinction, e.g. if the range is rdfs:Resource or rdfs:Class.

Additionally, even if the original intention of the author is known, it may still depend on the usage context or on pragmatic considerations which kind of property declaration to use. For example the original specification of DCTerms at [1] is an RDFS vocabulary specification with all of its many property declarations given as the one above. I have seen DC-terms being re-defined as annotation properties in some situations, and as data- or object properties in other situations, and I remember having heard people giving reasonable arguments for both options. DC-terms even has a few properties, such as dcterms:title [2], that can have both individuals and data values as their values. So one is forced to make a decision for either object or data property in OWL DL.

To summarize, if you care about OWL DL-compliance, it is not an option to simply import the whole DC-terms ontology into your OWL DL ontology. It is also not perfectly possible to give a single generally-accepted "OWL DL-repaired" version of the original DC-terms ontology, and then import that. So using "inline-re-definitions" of DL-compliant variants for those DC-terms that you actually need within your OWL DL ontology seems to me a reasonable practice. And this discussion holds for RDF vocabularies with property declarations in general.

[1] http://purl.org/dc/terms/

[2] http://dublincore.org/documents/dcmi-terms/#terms-title

link

answered 28 Jun '10, 20:43

Michael%20Schneider's gravatar image

Michael Schn... ♦
6.1k1612
accept rate: 34%

edited 28 Jun '10, 20:49

1

Very insightful thoughts, Michael. There should maybe guide somewhere, on how to do these 'inline-re-definitions' and when. I think "<concept property=""> rdf:type <type> ." is good a way, as also proposed from Dave. However, I saw also more complex 'redefinitions' sometimes.

(28 Jun '10, 23:07) zazi zazi's gravatar image

Indeed you don't normally need to redefine concepts from another ontology in your own. Typically you would just refer to that concept, or import the whole ontology. In general reuse is better than redefinition so if there is no good reason to redefine the concept then don't do it.

However, the issue of DL compliance is a genuine one. Specifically in the case of FOAF then FOAF is not DL compatible (e.g. foaf:mbox_sha1sum is an owl:InverseFunctionalProperty but in DL only ObjectProperties can be inverse functional, some properties are declared as sub-properties of rdfs:label which is not allowed in DL). Thus if someone wanted to create a DL compliant ontology they cannot import FOAF. To be DL compliant then the entire import closure of the ontology has to meet the DL restrictions.

Danbri has had various attempts at making FOAF be DL compliant, and thus importable into other DL compliant ontologies. For example, foaf:LabelProperty has been introduced presumably in an attempt to defuse the issue with foaf:name. At one time the troublesome owl:InverseFunctionalProperty declaration was commented out but it is currently back in again for reasons I haven't followed.

link

answered 27 Jun '10, 20:21

Dave%20Reynolds's gravatar image

Dave Reynolds
3.1k311
accept rate: 46%

1

"Typically you would just refer to that concept" - do you mean with 'refer' also definitions like these ones: 'rdfs:Class a owl:Class .' or 'dc:date a owl:AnnotationProperty .' in ontologies, which in general make use of these terms, rather than defining them? From my point of view, these are also 'redefinitions'. However, very insightful answer, Dave!

(28 Jun '10, 08:07) zazi zazi's gravatar image
1

Sure you could regard that as re-definition but is still useful. Consider an example where you are defining some category of people and want to say that your category is a specialization of foaf:Person. If you have my:category rdfs:subClassOf foaf:Person and have no declaration for foaf:Person then you violate strict DL constraints. If you import FOAF then you also break DL. Whereas if you add a simple foaf:Person a owl:Class then you can remain in DL yet still include the relationship to FOAF which others, who don't care about DL, can then exploit.

(28 Jun '10, 10:53) Dave Reynolds Dave%20Reynolds's gravatar image
1

Maybe we should force an OWL-DL Compliance for FOAF again ;) DL compatibility is a key feature from my point of view.

(28 Jun '10, 17:13) zazi zazi's gravatar image

Actually I think it is important to be able to redefine other ontology terms for your own purposes. This is essential for decentralising authorship and publication of ontologies. Each ontology provider needs to ensure that what they create is consistent and has the computational requirements they require. They can't wait to convince every other ontology author to do the same.

Basically when you redefine other ontology's terms in your own ontology you are stating: "If you want to work with my ontology and with instance data that has these terms in then these are the additional constraints that are necessary for compatibility".

link

answered 27 Jun '10, 15:07

Ian%20Davis's gravatar image

Ian Davis
2.3k1414
accept rate: 13%

1

I think redefining existing ontology terms for own purpose,will destroy the whole ecosystem,because in general everyone believes, that when he/she uses a specific concept,it has everywhere its same definition.Okay,sometimes these concepts have also the same definition,but at one time the author of the used ontology changes something in this ontology.Then the ontology,which uses this ontology,has to keep track of this changes.The easiest way in my mind is,to use owl:imports,because every time,when my ontology will be loaded,it retrieves also up-to-date ontology specifications of the used ones.

(27 Jun '10, 18:05) zazi zazi's gravatar image
1

I must confess that I profoundly disagree with this one. One of the main purposes of ontologies is data integration: if you change the axiomatisation of a term, you change its meaning, which in turn, makes mapping intensely difficult. There are also issues of granularity: say the axtiomatisation of the parent term is less precise and you specify the term through additional axioms. If I come to this from the outside and wish to integrate data marked up with terms from those two sources, I will have a jolly hard time, because it is alost impossible to decide whether they are mappable.

(28 Jun '10, 12:52) Nico Adams Nico%20Adams's gravatar image
1

I totally agree with you here, Nico. That's what I'm thinking all the time re. this 'common (bad?) practice'. So, forcing owl:imports, rather then redefining existing terms in own ontologies.

(28 Jun '10, 17:11) zazi zazi's gravatar image
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×596

Asked: 27 Jun '10, 13:47

Seen: 1,582 times

Last updated: 28 Jun '10, 20:49