Hi, while designing disjointness axioms is a very good practice in most ontologies, they can lead to problems when ontologies are intended for broad, unforeseen uses, or when they easily get aligned to other ontologies in realistic applications. This is becoming more and more true in linked data scenarios. My suggestion is indeed to design such axioms, but to keep them in a separate module, which can be plugged in and out according to the intended usage of CIDOC-CRM, Best Aldo
On 22 Nov 2011, at 11:38, Martin Scholz wrote: > Dear all, > > while working on the Erlangen CRM (<http://erlangen-crm.org>), we came across > the problem of how to deal with disjoint classes. OWL DL offers the > possibility > to mark two classes as disjoint. We would like to effectively use it. Are > there > any recommendations for the implementation of disjoints, like there are for > property quantifiers and primitive values? > > Unfortunately, the CRM is quite unclear about which classes should be > considered > disjoint: In the current version of the standard there is a section about > "Disjointness" (page xvi) saying that > "Classes are disjoint if they share no common instances in any possible > world. > There are many examples of disjoint classes in the CRM. > A comprehensive declaration of all possible disjoint class combinations > afforded > by the CRM has not been provided here; it would be of questionable practical > utility, and may easily become inconsistent with the goal of providing a > concise > definition. ..." > Afterwards, only two disjoints are explained: > E2 Temporal Entity & E77 Persistent Item > E18 Physical Thing & E28 Conceptual Object > Whereas the scope of E2 also directly mentions the disjointness with E77, > this > is not the case for E18 & E28, nor for any other class. > > An (out-dated) list of possible disjoint classes is mentioned in issue 92 > (<http://www.cidoc-crm.org/issues.php?id=92>). But the current proposal > section > of the issue also states that a comprehensive list should not be supplied and > that > "we should abandon the idea of disjoint class declararations altogether". > Nonetheless, scope note proposals are given for E2, E77, E18, and E28 which > confirm both aforementioned disjoints (also E18 and E28!). > > How should disjointness be dealt with? Is it merely informative and should be > omitted by implementations, just like the property quantifiers? This would > mean > an enormous loss of expressiveness. > Are there essential disjoints like E2 and E77 that have to be implemented, > while > others are "optional"? Why then among the 5 "second level" classes E2, E52, > E53, > E54, and E77 only E2 and E77 are disjoint? > > Regards > Martin Scholz > > > -- > Martin Scholz, Diplom-Informatiker > Friedrich-Alexander-Universität Erlangen-Nürnberg > Department Informatik 8 > Haberstr. 2 > 91058 Erlangen > Tel: +49 9131 852-8984 > Fax: +49 9131 852-8986 > Mail: martin.scholz at cs.fau.de > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig _____________________________________ Aldo Gangemi Senior Researcher Semantic Technology Lab (STLab) Institute for Cognitive Science and Technology, National Research Council (ISTC-CNR) Via Nomentana 56, 00161, Roma, Italy Tel: +390644161535 Fax: +390644161513 [email protected] http://www.stlab.istc.cnr.it http://www.istc.cnr.it/createhtml.php?nbr=71 skype aldogangemi okkam ID: http://www.okkam.org/entity/ok200707031186131660596
