[tcs-lc] "Not" RelationshipTypes

Richard Pyle deepreef at bishopmuseum.org
Fri Sep 23 14:56:00 PDT 2005


I mentioned in a previous post my concern about the various "Not"
RelationshipTypes:

is not congruent to
does not include
is not included in
does not overlap

Last week I wrote a long message to the list about why I thought the "Not"
RelationshipTypes were unnecessary. My initial point was along the lines of
"does not include" is functionally equivalent to "excludes", and so on. But
then I deleted it because I realized that, from a strictly logical point of
view, "does not include" and "excludes" mean different things.  "Excludes"
specifically means no overlap at all;  but "does not include" can
technically be interpreted as "Might overlap, or might not".

For a more specific example, suppose I know that TC1 and TC2 are definitely
not congruent, but I'm not certain whether TC1 includes TC2, or if TC1 is
included in TC2, or if TC1 overlaps with TC2.  Heck... for all I know, it
may be that TC1 excludes TC2 -- I just know for certain that TC1 and TC2 are
not congruent.  Having the "is not congruent to" RelationshipType allows me
to say what I know for certain, without committing myself to one of the
other four explicit RelationshipTypes.

So...I can see a possible informational need for the "Not" alternatives.
But technically, this logic extends to any conceivable RelationshipType.
For example, what if I know that there is at least some overlap between TC1
and TC2, but I don't know if one includes the other, or if they are both
congruent, or if they simply overlap.  In this case, I would want to have a
"does not exclude" option -- which is not currently on the enumerated list.

My point:

Is there a specific reason why there isn't a non-mandatory boolean
Relationship at Not attribute, which if true would indicate the "Not"
equivalent of the indicated RelationshipType?  It seems to me like a much
cleaner way to handle the "Not" RelationshipType information than
effectively doubling the enumerated list.

Also, I'm having a really difficult time imagining a circumstance where one
of the "Not" RelationshipTypes would be used as part of a *definitive*
Relationship (i.e., TaxonConcept/Relationships).  If someone can provide an
example, that would be helpful -- but in general, the logic of the "Not" is
to allow even more vague representations of Relationships than are already
accomodated (i.e., they functionally/logically imply "one of several
possible alternatives, but not this one").  Do we really want to encourage
people to *define* concepts in terms of such vague RelationshipTypes?

Establishing a @Not attribute (rather than providing all the "not"
alternatives in the RelationshipType enumeration) would give us the option
of applying it only to RelationshipAssertion (where any information, however
vague, is potentially helpful), and not to TaxonConcept/Relationships -- and
thereby allow us to use the same enumeration of RelationshipType in both
places, but prevent the use of "not" in establishing *definitive*
Relationships.

If I am missing something fundamental here, I would very much like to be
enlightened.

And again, I'm not sure if this falls into the "minor" or "non-minor"
category.

Aloha,
Rich

Richard L. Pyle, PhD
Database Coordinator for Natural Sciences
Department of Natural Sciences, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: deepreef at bishopmuseum.org
http://hbs.bishopmuseum.org/staff/pylerichard.html






More information about the Tcs-lc mailing list