[Crm-sig] Implementation recommendation for disjointness

Aldo Gangemi a.gangemi at istc.cnr.it
Tue Nov 22 18:22:42 EET 2011


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
> Crm-sig at ics.forth.gr
> 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
aldo.gangemi at cnr.it
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20111122/7fc364ea/attachment.htm 


More information about the Crm-sig mailing list