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.
Indeed,
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: [email protected] |
|
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 |
--------------------------------------------------------------
