Dear Barry, (01)
Thank you for pointing me to your paper: (02)
http://genomebiology.com/2005/6/5/R46 (03)
Which shows how you use relations between classes. (04)
I have now had a chance to read this, so I can make a considered comparison to
our approach in ISO 15926. (05)
I notice that for a number of relations you identify at the individual level
you single out a relation between classes in addition to the relation at the
individual level. You have: (06)
Part_of
Located_in
Contained_in
Adjacent_to
Co-adjacent_to
Transformation_of
Derives_from
Preceded_by
Has_participant
Has_agent (07)
You also recognise a reciprocal relation (e.g. has_parts to indicate
necessary parts) and one that combines the two (e.g. integral_parts). (08)
I will take part_of as an example. (09)
The relevant piece from your paper to this discussion is below (some formatting
lost in cut and paste). (010)
QUOTE (011)
Parthood as a relation between classes. To define
part_of as a relation between classes we again need to distinguish
the two cases of continuants and processes, even
though the explicit reference to instants of time now falls
away. For continuants, we have C part_of C1 if and only if any
instance of C at any time is an instance-level part of some
instance of C1 at that time, as for example in: cell nucleus
part_ of cell. (012)
Formally: (013)
C part_of C1 = [definition] for all c, t, if Cct then there is some
c1 such that C1c1t and c part_of c1 at t. (014)
Note the 'all-some' structure of this definition, a structure
which will recur in almost all the relations treated here.
C part_of C1 defines a relational property of permanent parthood
for Cs. It tells us that Cs, whenever they exist, exist as
parts of C1s. We can also define in the obvious way C
temporary_part_of C1 (every C exists at some time in its
existence as part of some C1) and also C initial_part_of C1
(every C is such that it begins to exist as part of some instance
of C1). (015)
END QUOTE (016)
I should start by questioning whether this is even a true or useful
statement. From your initial comment: (017)
> > > > > Uniquely, among existing
> > > > > contributions, the BFO Relation Ontology allows the
> > > > > drawing of a
> > > > > clear distinction between relations on the level of
> > > > > instances (e.g.
> > > > > between your heart and your body) and relations on the
> > > > > level of types
> > > > > (e.g. between the type human heart and the type human body). (018)
I presume you mean that: (019)
human heart part_of human body (020)
Would be a (good) example of your class level part_of relation. However,
hearts can clearly be removed from bodies, and have been successfully
transplanted to another body, with at least some period in between,
and I suspect even specimen hearts that have been preserved would still
be considered and recognised as hearts. (021)
Perhaps a more appropriate thing to say is that human hearts are created
in and as part of a human body (though I remember seeing a photo of a mouse
with a human ear growing on its back). (022)
So perhaps what you really want to say is that hearts are NORMALLY parts
of bodies. But that is not what your axiomatisation says. (023)
If we move up a level, and look at what you are doing, then what we see
is that you are really defining some constraints that might apply to
some subset of a part_of relation at the individual level. (024)
This is a more general problem and there is certainly more than one set of
constraints that one might wish to apply to the individual level part_of
relation. For example (following your approach of using relations between
classes): (025)
part_may_be_part_of_whole (e.g. impellers may be part of pumps - but may
be on a shelf) (026)
For additional reciprocal relations we could have: (027)
has_exactly_one_part (e.g. cars have one steering wheel)
has_exactly_two_parts (e.g. mammal has two eyes)
... (028)
What I fail to see is why the particular constraint you have picked out
for the relation between classes and its reciprocal are privileged.
Certainly no explanation is offered. (029)
This pattern is repeated with the other class level relations. It seems
you consider that there is only one pattern in each case. This does not
reflect our experience. (030)
Reflecting on this at a different level: (031)
> > > > > Uniquely, among existing
> > > > > contributions, the BFO Relation Ontology allows the
> > > > > drawing of a
> > > > > clear distinction between relations on the level of
> > > > > instances (e.g.
> > > > > between your heart and your body) and relations on the
> > > > > level of types (032)
I am not sure quite what is 'unique' or indeed 'clear' about this distinction
between relations between classes and individuals. (033)
I understand that over a 100 years ago Frege introduced predication for
non-monadic properties and since then there has been a clear distinction
in type between 'relations on the level of instances' and 'relations on
the level of types' - (for non-monadic predicates) between ordered tuples
and predicates. So, I do not understand why you think your contribution
unique in drawing this distinction. (034)
Furthermore, it seems to me that your exposition makes less of a
distinction between these two things - as both these levels appear to be
the same ontological type. (035)
I would also like to clarify the relationship between some different sorts
of relation. (036)
You state: (037)
1) There is a general category of Relation (038)
2) There are the following sub-types (sub-kinds, sub-classes, etc) of the
Relation Category: (039)
<class, class>
<instance, class>
<instance, instance> (040)
3) The type <class, class> has among its sub-types (etc.) 'is a' and this
has sub-types 'C is a C' and 'P is a P'. (041)
4) The type <instance, class> has among its sub-types (etc.) 'instance
of' and this has sub-types 'c instance_of C at t' and 'p instance_of P'. (042)
As a hierarchy this looks like: (043)
Relation
<class, class>
'is a'
'C is a C'
'P is a P'.
<instance, class>
'instance of'
'c instance_of C at t'
'p instance_of P'.
<instance, instance> (044)
Ordinary language would lead us to believe that the sub-type 'links'
shown in this hierarchy are 'instances of' the 'is a' relation. Is this
the case or is there some ontological queasiness or logical nicety that
stops you from taking this natural approach? (045)
As an aside, it would appear from this that you are restricting yourself
to first order objects - in other words, you do not recognize classes of
classes (or higher order universals). Hence you use individual/particular
and instance inter-changeably. Is that correct? Do you not find this an
onerous restriction? (046)
Other questions arise from your use a format of T r t - where T is a
class, r is a relation and t is an individual - similar to typed logics.
This would seem to imply a 'relation' between r and T and r and t (for
example, in the case of 'p instance_of P' between this relation and the
class of process particulars and the class of process classes - in other
words, the relation is between members of the class of process particulars
and members of class of process classes). (047)
This seems to me very similar to the notion of role in entity modelling.
Is this correct? (048)
And, what kind of relation is this in your scheme of things? It does not
seem to fit well into any of the categories in the hierarchy above. (049)
Coming back to the two part_of relations that are at the heart of the
'clear distinction' being proposed. (050)
"c part_of c1 at t - a primitive relation between two continuant
instances and a time at which the one is part of the other" (051)
and (052)
"For continuants, we have C part_of C1 if and only if any
instance of C at any time is an instance-level part of some
instance of C1 at that time, as for example in: cell nucleus
part_ of cell." (053)
It would seem to me that there is a common natural understanding that
there is a relation between these this class and instance level relation.
This does not seem to appear in your ontology. It also appears difficult
to place it - for example, it cannot be 'instance of' as these are both
relations and that relation is between instances and classes. Do you feel
the need for this relation, and if so, how would you fit it into your
framework? (054)
It also seems to me useful to look at the normal set-theoretic
interpretation of the relations you describe. (055)
a) For the first, there would be a class of ordered triples <c, c1, t>
for which it is true that 'c is a part of c1 at t' - and this would be
the extension of that relation. (056)
b) For the second, there would be a class of ordered pairs <C, C1> for
which it is true that 'C is a part of C1' - and this would be the
extension of that relation. (057)
Is this how you envision what you describe working? If not, how do you
see this working? (058)
I think it is worth noting that your description of the class level
relation C part_of C1 above, implies the existence of a class of ordered
triples <c, c1, t> that range over C, C1 and time - and that this class
is a sub-class of the instance level part class mentioned in a) above. As
I understand it, this is the more common way of showing the relationship
between the instance and class level. It also provides a natural
explanation of the relation between the two. (059)
Given this class, I do not see the utility of introducing another more
distantly related instance of class level relations to play the same
role. I'd be interested in an explanation of your rationale in doing
this. (060)
Still I suppose that is just preamble to the question of whether instances of
class_of_composition are actually classes (well I guess in your terminology
sub-relations). (061)
>From below: (062)
> > > > > Uniquely, among existing
> > > > > contributions, the BFO Relation Ontology allows the
> > > > > drawing of a
> > > > > clear distinction between relations on the level of
> > > > > instances (e.g.
> > > > > between your heart and your body) and relations on the
> > > > > level of types
> > > > > (e.g. between the type human heart and the type human body).
> > > >
> > > >MW: Just for the record, ISO 15926 also supports this.
> > > > (063)
Note the use of the word "support". What I described reflects how we support
specifying the kind of constraints you have specified. However, our approach to
this problem is more fine grained, not restricting ourselves to two constraints,
one for the relation and another for its reciprocal. (064)
We use an entity relationship formalism that is well understood in the
database and systems design world, but may not be familiar to you. (065)
To support the constraint you wish to say, we create an instance of
class_of_composition. This is in essence a subrelation of
composition_of_individual. (066)
Let us take your example of heart part_of_ body, and the constraint
that a heart must be part of some body (and assume for the moment it is
true). (067)
I think we can do a useful bit of generalisation. It seems to me that
what is true for a heart is probably true for any organ - let us assume
so anyway. So I name my instance of class_of_composition (say)
OrganPartOfBody. Despite being implicit in the name, I now need to
specify the restricted domain of individuals that can be parts and
wholes. This is done through two relationships, one of which will
point to the class_of_individual, organ, the other to the class_of_individual,
body. (068)
I now have the opportunity to add cardinality constraints, so I can say
that each organ must be a part an OrganPartOfBody relationship. (We can add
the reciprocal constraint as well if required). These relations are an
essential
part of the definition of the class of relationship, and so are often brought
into
the English definition. (069)
The relation that you have constructed, and the constraint it carries is
implicit in this. Hence the claim of support. (070)
See below for specific responses. (071)
> -----Original Message-----
> From: ontac-forum-bounces@xxxxxxxxxxxxxx
> [mailto:ontac-forum-bounces@xxxxxxxxxxxxxx]On Behalf Of Barry Smith
> Sent: 21 November 2005 08:22
> To: ONTAC-WG General Discussion
> Subject: RE: [ontac-forum] ISO 15926 and BFO
>
>
>
> > > > > Uniquely, among existing
> > > > > contributions, the BFO Relation Ontology allows the
> drawing of a
> > > > > clear distinction between relations on the level of
> > > instances (e.g.
> > > > > between your heart and your body) and relations on the
> > > level of types
> > > > > (e.g. between the type human heart and the type human body).
> > > >
> > > >MW: Just for the record, ISO 15926 also supports this.
> > > >
> > > >
> > > >Regards
> > > >
> > > >Matthew West
> > >
> > > ISO 15926 does indeed distinguish between relationships
> and classes
> > > of relationships:
> > >
> > > A <relationship> is an <abstract_object> that indicates something
> > > that one thing has to do with another.
> > >
> > > A <class_of_relationship> is a <class_of _abstract_object> whose
> > > members are members of <relationship>.
> > >
> > > However, it does not provide an account of the distinction between
> > > relationships BETWEEN CLASSES (for example in general
> assertions such
> > > as: human heart PART_OF human body, capital city PART_OF
> country) and
> > > relationships BETWEEN INSTANCES (such as Matthew's heart part_of
> > > Matthew's body; London part_of England).
> >
> >MW: It does precisely this. We have
> class_of_composition_of_individual
> >for classes of relationship between classes (e.g. heart part of body)
> >and composition_of_individual for relationships between individuals,
> >e.g. Matthew's heart part of Matthew (which would of course be an
> >instance of the former example).
>
>
> You have both this relation (call it 'r')
> ---
> composition_of_individual
>
> A <composition_of_individual> is a <relationship> that indicates that
> the part <possible_individual> is a part of the whole
> <possible_individual>. A simple composition is indicated, unless a
> subtype is instantiated too.
> ---
> at the instance level, and this class
> ---
> A <class_of_composition_of_individual> is a <class_of_relationship>
> whose members are members of <composition_of_individual>.
> EXAMPLE: That piles of sand may have grains of sand as parts is an
> example of <class_of_composition_of_individual>.
> ---
> The name of the class 'class of composition_of_individual' looks at
> first sight as if it would mean 'class of composition of individual'.
> (This would be good, wouldn't it?*) The example, suggests, however,
> that it does not mean that, but that it means rather something like:
> the analogue of composition_of_individual at the class level. (072)
MW: Well your inference is incorrect, though not unreasonable since
the class level relation is implicit in the class_of_composition_of_
individual taken together with its key relations. (073)
MW:A look at the subtype graph should have reassured you that it really
was a class. (074)
> That
> is, it designates not a class of relations but rather a relation (at
> the class level) in its own right. Call this relation 'R'.
>
> If I understand your example correctly, (075)
MW: (Un)fortunately you do not. (076)
> then you are asserting that
> the class grain_of_sand stands in R to the class pile_of_sand. (The
> analogue at the class level, therefore, if this instance-level
> statement: this grain of sand here before me now stands in r to this
> pile of sand here before me now.)
>
> My question now is: what is the relation between r and R? The latter
> cannot be just the class of which the former is an instance, for a
> class of relations is not itself a relation, just as a class of
> horses is not itself a horse.
> BS
>
> *It is one of my complaints about ISO/FDIS 15926, as you know, that
> its semi-regimented English language is both counterintuitive for
> normal users and hard to learn even for experts. (077)
MW: You inferred from the example that a relation that is implicit
in the structure around the the class_of_composition_of_individual is
what it actually was. Since this was the basis of your complaint here, when
it was in fact what the name suggested, this complaint would seem
unjustified.
>
>
>
> >MW: We also recognise that in some cases there are
> relationships between
> >classes that are not classes of relationship. Specialisation would be
> >an example of this. Do you support this sort of distinction
> too? We even
> >have class_of_specialisation for saying that a member of one
> class has
> >a member of another class as a superclass.
> >
> > > As is shown in
> > >
> > > http://genomebiology.com/2005/6/5/R46
> >
> >MW: I've downloaded the PDF. I'll take a look when I get a
> moment. Its a
> >bit late now.
> > >
> > > these are formally two quite distinct sorts of relationships. And
> > > only if we provide an account of how they are connected one to the
> > > other can we understand how an ontology (which deals with
> > > relationships BETWEEN CLASSES) can be linked to the real
> world of oil
> > > rigs and generators.
> >
> >MW: Indeed, which is why we do.
> >
> >MW: For you not to have seen this I wonder
> >how you are looking at the model. Have you found the diagrams? If you
> >click on the little icon beside the entity type name in the list, you
> >will be taken to a diagram of the part of the model that
> entity type is
> >in. I find diagrams much easier than text, and since you use diagrams
> >in your ontologies you might too.
> > >
> > > BS
> > >
> > >
> > >
> > > _________________________________________________________________
> > > Message Archives: http://colab.cim3.net/forum/ontac-forum/
> > > To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
> > > Subscribe/Unsubscribe/Config:
> >http://colab.cim3.net/mailman/listinfo/ontac-forum/
> >Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
> >Community Wiki:
> >http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyC
oordinatingWG
>
>
>
>_________________________________________________________________
>Message Archives: http://colab.cim3.net/forum/ontac-forum/
>To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
>Subscribe/Unsubscribe/Config:
>http://colab.cim3.net/mailman/listinfo/ontac-forum/
>Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
>Community Wiki:
>http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (078)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (079)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (080)
|