[Crm-sig] Implementation recommendation for disjointness

martin martin at ics.forth.gr
Tue Nov 22 19:20:58 EET 2011

Dear Martin,

In the past the CRM-SIG team gave up to define a comprehensive list of disjoint classes,
because there were too many exceptions.

the pairs
 > E2 Temporal Entity&  E77 Persistent Item
 > E18 Physical Thing&  E28 Conceptual Object

are the fundamental ones.

Obviously, also Time-Span, Place and Dimension is disjoint, but hardly worth mentioning, because
nobody will confuse it.

Other combinations might in practice be used in a non-disjoint manner, depending on the
context, because of a 1-1 relationship. For instance, a Physical Feature might be regarded as synomymous with the place it occupies
on the object that "bears" it. Similarly, one may like to get rid of Time-Spans. Why not. Saves a lot
of identifiers and joins.

Then there are the things that may be combined even in a true ontological sense, such
as destruction and activity, Image and Linguistic Object etc.

In general, for events it is very difficult to state any useful disjointness, because that would
in most cases require to exclude any possible immediate interaction between such kinds of events
and to be able to separate participants and space-time volumes.

For instance, if indeed someone removes a part and adds it in the same uninterrupted process, that
would violate an old constraint assumed by your team, but it is common practice for mending furniture.
The practicalities: A conservation department will find evidence that I have removed the leg of my chair. That I have added
the leg of my chair. But no evidence, that I did it to fix the loose leg. So, a conservation department
cannot decide if it was one action. So, they document two events. Then I can tell them it was one. Their
observation was correct. Mine too.

I do not agree with the "enormous loss of expressiveness" as a blank statement.
There should be clear use cases, in which the disjoint declarations are useful.

We found them useful for query formulation aids to check multiple instantiation paths. But there were three levels:
Unlikely combinations, like "dagger-pistols" and other hybrids, likely combinations
like "death&activity", and impossible combinations like E18-E28.

Practically I suggest you publish your list of proposed disjoint statements as issue on this list,
together with relevant use cases.

Then CRM-SIG can comment if a disjoint statement is regarded as "safe" from an implementation point of view,
correct from a theoretical point of view (Feature versus Place), or only "likely".

On 11/22/2011 12:38 PM, 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


  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin at ics.forth.gr |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
  Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
          Web-site: http://www.ics.forth.gr/isl               |

More information about the Crm-sig mailing list