[Obo-relations] Class vs. instance level relations and inverse relations
Hogan, William R
Folks,
Presently in the Relation Ontology, it appears that all the relations are assumed to be class-class (or type-type) relations. If so, then there are errors in the asserted properties of relations.
part_of and has_part are stated to be inverses of one another, which is not universally true at the class level (but it is so at the instance level). For example, uterus part_of pelvis, but not pelvis has_part uterus (because not every pelvis has a uterus as a part). Hence the need for the integral_part_of and has_integral_part relations which are truly inverses of one another (note that these two relations are not needed at the instance level, because instance_part_of and instance_has_part are inverses already).
However, RO does not define adjacent_to as symmetric, although its instance-level counterpart is symmetric. This situation is perfectly appropriate if adjacent_to is intended to be a class-level relation.
Similarly, contains & contained_in, located_in & location_of, participates_in & has_participant, and a few other pairs of relations are inappropriately stated to be inverses of one another.
At the very least, we need to remove the incorrect inverse_of associations between such pairs of relations where it does not universally hold (because at present, if I assert pelvis part_of uterus, then my reasoner is justified in concluding that given any particular instance of pelvis, even a male one, then that pelvis has a uterus as a part. Removing the inverse_of assertion will rectify this problem).
However, I’d like to propose that we also explicitly represent instance-level as well as class-level relations.
To that end, I have attached an .obo file that illustrates what that _might_ look like. In this file, I have removed the inverse_of associations between several pairs of class-level relations where it is not universally true, but kept the associations between their instance-level counterparts.
I’d also like to suggest that one way to prevent the erroneous application of instance-level relations to classes and vice versa is the ability to assert that the domain and/or range of a relation is restricted to instances. I realize that this extension may have significant implications for description logic reasoners, but OWL-DL already allows to constrain the range of a relation to a particular instance (the “fills” constructor – see p. 61 of The Description Logic Handbook). However, I know that DL at present also allows the application of any relation to both classes and instances.
The advantages of explicit representation of instance-level relations:
1. I can envision applying them to instances in applications that manipulate and perform inference with data
2. It might help to avoid incorrect assertions like the ones about class-level relations present in RO now
3. We would have a machine- and human-readable catalog and list of the instance-level relations people have used to define class-level relations (as opposed to having to scan through all the textual definitions and comments on class-level relations to get them).
4. Anyone who wished to use first-order logic reasoners for research/practice may want to use them
Bill
William Hogan, MD, MS
Director, Medical Vocabulary Services
UPMC
Associate Professor of Biomedical Informatics
University of Pittsburgh
This e-mail may contain confidential information of the sending organization. Any unauthorized or improper disclosure, copying, distribution, or use of the contents of this e-mail and attached document(s) is prohibited. The information contained in this e-mail and attached document(s) is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify the sender immediately by e-mail and delete the original e-mail and attached document(s).
Cristian Cocos
part_of and has_part are stated to be inverses of one another, which is not universally true at the class level (but it is so at the instance level). For example, uterus part_of pelvis, but not pelvis has_part uterus (because not every pelvis has a uterus as a part). Hence the need for the integral_part_of and has_integral_part relations which are truly inverses of one another (note that these two relations are not needed at the instance level, because instance_part_of and instance_has_part are inverses already).
The RO paper dubs these as “reciprocal,” not “inverses,” and contains pretty much the same type of counterexamples you just listed. As for RO, the RO website specifies that such relations are to be understood as inverses only at instance level.
CC
Hogan, William R
But that information is not accessible to computers. Hence my request to make it so. Furthermore, the information provided to computers in the RO obo file is incorrect. Any reasoner using the ro.obo or ro.owl will derive incorrect conclusions.
Bill
Alan Ruttenberg
At the last OBO Relations meeting we decided to do just as you
suggest. The meeting notes are here:
http://bioontology.org/wiki/index.php/OntologyRelations
Actually it is anticipated that there will be three classes of
relations. Type level, instance level, and "macro", i.e. relations
that are shortcuts for, e.g., compositions of other relations. In
addition there is a plan to publish a new version of BFO which has
relations that are essential to working with BFO as a part of it.
Perhaps Chris can add your obo file to the RO page, which is
collecting other proposals for RO.
Have you been monitoring this mailing list? If so, I wonder what your
opinion on the part_of issue I brought up the other day is.
Regards,
Alan
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Obo-relations mailing list
> Obo-re...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/obo-relations
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Obo-relations mailing list
Obo-re...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obo-relations
Stefan Schulz
> At the last OBO Relations meeting we decided to do just as you
> suggest. The meeting notes are here:
> http://bioontology.org/wiki/index.php/OntologyRelations
>
thanks for the link!
> Actually it is anticipated that there will be three classes of
> relations. Type level, instance level, and "macro", i.e. relations
> that are shortcuts for, e.g., compositions of other relations. In
> addition there is a plan to publish a new version of BFO which has
> relations that are essential to working with BFO as a part of it.
by browsing through some presentation slides of the above meeting I
noticed that the same names, e.g. "proper_part_of" are used for
different relations belonging to different relation classes. The only
distinguishing criterion seems to be the formatting (bold vs.
italics). I anticipate this will create misunderstandings again and
again. Why not introducing some kind of prefix in order to
unambiguously distinguish type-level from instance level relations?
Example:
"proper_part_of" instance level relation, as used in OWL-DL
"t_proper_part_of" type level relation, as used in the OBO format.
Regards,
Stefan
Alan Ruttenberg
think that the labels should should also have some mark?
-Alan
Chris Mungall
Yes, the type level relation and the instance level relation will have
different identifiers/URIs. OWL folks will typically only use the
instance level ones. We will also switch to using a numeric identifier
scheme, as in the other OBO ontologies/
The type level relations will also have formal labels: for example
"part_of_some" or "all_part_of_some". Software can use these in
contexts where there is possibility of confusion. There's also the
option of making these the primary labels, and keeping around the
basic form as the secondary label/synonym.
Alan Ruttenberg
>
> Yes, the type level relation and the instance level relation will have
> different identifiers/URIs. OWL folks will typically only use the instance
> level ones. We will also switch to using a numeric identifier scheme, as in
> the other OBO ontologies/
>
> The type level relations will also have formal labels: for example
> "part_of_some" or "all_part_of_some". Software can use these in contexts
> where there is possibility of confusion. There's also the option of making
> these the primary labels, and keeping around the basic form as the secondary
> label/synonym.
I like the idea of these being the primary labels.
Stefan Schulz
its intended meaning.
"all_part_of_some" is less clear. Is it meant to substitute "integral_part_of" ?
Stefan
2008/10/18 Alan Ruttenberg <alanrut...@gmail.com>:
> On Fri, Oct 17, 2008 at 6:58 PM, Chris Mungall <c...@berkeleybop.org> wrote:
>>
>> Yes, the type level relation and the instance level relation will have
>> different identifiers/URIs. OWL folks will typically only use the instance
>> level ones. We will also switch to using_of a numeric identifier scheme, as in
--
Stefan SCHULZ (apl. Prof. Dr. med.)
Universitätsklinikum - Institut für Medizinische
Biometrie und Medizinische Informatik
Stefan-Meier-Strasse 26 D-79104 Freiburg
[home: Eschholzstr. 70 D-79115 Freiburg]
+49 (0)761 2036725, 2049089, FAX 2036711
http://purl.org/steschu
[stsc...@uni-freiburg.de], Skype: stschulz
Matthias Samwald
> "part_of_some" or "all_part_of_some". Software can use these in
> contexts where there is possibility of confusion.
This reminds me a lot of the "CASA" design pattern I invented when I was too
frustrated with the complexities of class-level relations in OWL. See pages
4 and 5 of
http://neuroscientific.net/res/semsyn/samwald-classes-vs-instances.pdf
SAMWALD M (2006) Classes Versus Individuals: Fundamental Design Issues for
Ontologies on the Biomedical Semantic Web. Workshop on Foundations of
Clinical Terminologies and Classifications in Proceedings of the European
Federation for Medical Informatics, Special Topic Conference, Timisoara,
Romania
Back then I was preferring instance-level relations over class-level
relations, because it was (and still is) often quite hard to query and
process class-level relations of OWL with standard RDF tools.
Cheers,
Matthias Samwald
Barry Smith
>"part_of_some" seems to me a label that paraphrases quite well what
>its intended meaning.
>"all_part_of_some" is less clear. Is it meant to substitute
>"integral_part_of" ?
I think we are making a mistake if we add more relations with
Martian-sounding names. Rather, we should focus on the preferred
definition of part_of (as a relation between types), and make sure
that this definition is properly disseminated. (One of the reasons
for the GO's success, I think, is the choice of a simple design
architecture, including a restriction of this sort.)
Compare the NCIT, which contains dozens of relations with names like
Procedure_May_Have_Completely_Excised_Anatomy
Allele_Not_Associated_With_Disease
and is consequently, one might surmise, less well used than it might
otherwise be.
BS
Michel Dumontier
At 04:07 PM 10/18/2008, Stefan Schulz wrote:I think we are making a mistake if we add more relations with
>"part_of_some" seems to me a label that paraphrases quite well what
>its intended meaning.
>"all_part_of_some" is less clear. Is it meant to substitute
>"integral_part_of" ?
Martian-sounding names. Rather, we should focus on the preferred
definition of part_of (as a relation between types), and make sure
that this definition is properly disseminated. (One of the reasons
for the GO's success, I think, is the choice of a simple design
architecture, including a restriction of this sort.)
Compare the NCIT, which contains dozens of relations with names like
Procedure_May_Have_Completely_Excised_Anatomy
Allele_Not_Associated_With_Disease
and is consequently, one might surmise, less well used than it might
otherwise be.
BS
+1
i find the distinction between "instance-level" and "class-level" just plain weird, and "all_part_of_some" and variants thereof even more bizarre. These are unlikely to be well understood among a growing list of fundamental relations.
-=Michel=-
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Obo-relations mailing list
Obo-re...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obo-relations
Barry Smith
I agree with you regarding "all_part_of_some"; but the material in
http://genomebiology.com/2005/6/5/R46
seems to have been found acceptable by biologists with ontology needs.
BS
>-=Michel=-
>
>
>
>
>
>-------------------------------------------------------------------------
>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>Build the coolest Linux based applications with Moblin SDK & win great prizes
>Grand prize is a trip for two to an Open Source event anywhere in the world
><http://moblin-contest.org/redirect.php?banner_id=100&url=/>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>_______________________________________________
>Obo-relations mailing list
><mailto:Obo-re...@lists.sourceforge.net>Obo-re...@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/obo-relations
>
>
>
>
>--
>Michel Dumontier
>Assistant Professor of Bioinformatics
><http://dumontierlab.com>http://dumontierlab.com
Michel Dumontier
One shouldn't infer that publishing a paper makes the content wholly accepted. It mostly does, however, to the people who authored it.
-=Michel=-
Barry Smith
>Barry,
> One shouldn't infer that publishing a paper makes the content
> wholly accepted. It mostly does, however, to the people who authored it.
I was not referring to the paper, but to the material it contains,
material which has been absorbed successfully in a range of different
communities.
BS
>-=Michel=-
>
>On Mon, Oct 20, 2008 at 10:37 AM, Barry Smith
><<mailto:phis...@buffalo.edu>phis...@buffalo.edu> wrote:
>At 10:03 AM 10/20/2008, Michel Dumontier wrote:
>
>
>
>On Mon, Oct 20, 2008 at 9:33 AM, Barry Smith
><<mailto:phis...@buffalo.edu><mailto:phis...@buffalo.edu>phis...@buffalo.edu>
>wrote:
>At 04:07 PM 10/18/2008, Stefan Schulz wrote:
> >"part_of_some" seems to me a label that paraphrases quite well what
> >its intended meaning.
> >"all_part_of_some" is less clear. Is it meant to substitute
> >"integral_part_of" ?
>
>
>I think we are making a mistake if we add more relations with
>Martian-sounding names. Rather, we should focus on the preferred
>definition of part_of (as a relation between types), and make sure
>that this definition is properly disseminated. (One of the reasons
>for the GO's success, I think, is the choice of a simple design
>architecture, including a restriction of this sort.)
>
>Compare the NCIT, which contains dozens of relations with names like
>
>Procedure_May_Have_Completely_Excised_Anatomy
>Allele_Not_Associated_With_Disease
>
>and is consequently, one might surmise, less well used than it might
>otherwise be.
>BS
>
>
>+1
>
>i find the distinction between "instance-level" and "class-level"
>just plain weird, and "all_part_of_some" and variants thereof even
>more bizarre. These are unlikely to be well understood among a
>growing list of fundamental relations.
>
>
>I agree with you regarding "all_part_of_some"; but the material in
><http://genomebiology.com/2005/6/5/R46>http://genomebiology.com/2005/6/5/R46
>seems to have been found acceptable by biologists with ontology needs.
>BS
>
>
>
>
>-=Michel=-
>
>
>
>
>
>-------------------------------------------------------------------------
>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>Build the coolest Linux based applications with Moblin SDK & win great prizes
>Grand prize is a trip for two to an Open Source event anywhere in the world
><<http://moblin-contest.org/redirect.php?banner_id=100&url=/>http://moblin-contest.org/redirect.php?banner_id=100&url=/>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>_______________________________________________
>Obo-relations mailing list
><mailto:Obo-re...@lists.sourceforge.net><mailto:Obo-re...@lists.sourceforge.net>Obo-re...@lists.sourceforge.net
>
>https://lists.sourceforge.net/lists/listinfo/obo-relations
>
>
>
>
>--
>Michel Dumontier
>Assistant Professor of Bioinformatics
><<http://dumontierlab.com>http://dumontierlab.com>http://dumontierlab.com
Alan Ruttenberg
> At 04:07 PM 10/18/2008, Stefan Schulz wrote:
>>
>> "part_of_some" seems to me a label that paraphrases quite well what
>> its intended meaning.
>> "all_part_of_some" is less clear. Is it meant to substitute
>> "integral_part_of" ?
>
>
> I think we are making a mistake if we add more relations with
> Martian-sounding names. Rather, we should focus on the preferred
Well, we are a heterogeneous community when it comes to what is preferred ;-)
But we can make the simple name the preferred label, and the one with
the quantifiers alternative.
> definition
> of part_of (as a relation between types), and make sure that this definition
> is properly disseminated. (One of the reasons for the GO's success, I think,
> is the choice of a simple design architecture, including a restriction of
> this sort.)
>
> Compare the NCIT, which contains dozens of relations with names like
>
> Procedure_May_Have_Completely_Excised_Anatomy
> Allele_Not_Associated_With_Disease
They wouldn't be so bad if they had clear definitions. Fortunately
ours do. Also, our implementation logic directly supports the all and
some quantifiers, but not the modal ones used in these. I don't think
it will be hard to teach people how to interpret "all" and "some" on
property names.
Barry Smith
The problem is not teaching the committed; the problem is creating an
artifact with results which will seem intelligible to the
non-committed; the committed need to communicate with many sorts of
colleagues without meeting sceptical responses; for this reason the
simpler the overt architecture of what we build the better.
BS
Ward Blondé
Hello,
I was on a meeting during this discussion, though I think it is a quite
essential one for ontological relations. I think that the principle of
orthogonality for names is making things to difficult concerning the
relations. After all we say:
my leg is part of my body.
on the instance level, just as we can say:
leg is part of body
for classes. ('All legs are part of a body', doesn't fit in a nice
schema) For this reason I think we could make different resources for
both relation types, with different URIs, but with the same names (or
labels). The difference between these resources could be made in the
definitions, extra tags, metaclasses, macro's... That is how we could
use intellegible names for relation types in the BioGateway system.
regards,
Ward
--
==================================================================
Ward Blondé wa...@psb.ugent.be
PhD student
Tel:+32 (0)9 331 38 24 fax:+32 (0)9 3313809
VIB Department of Plant Systems Biology, Ghent University
Technologiepark 927, 9052 Gent, BELGIUM
http://www.psb.ugent.be/cbd/people_ward_blonde.php
==================================================================
Barry Smith
>Hello,
>
>I was on a meeting during this discussion,
>though I think it is a quite essential one for
>ontological relations. I think that the
>principle of orthogonality for names is making
>things to difficult concerning the relations. After all we say:
>
>my leg is part of my body.
>
>on the instance level, just as we can say:
>
>leg is part of body
>
>for classes. ('All legs are part of a body',
>doesn't fit in a nice schema) For this reason I
>think we could make different resources for both
>relation types, with different URIs, but with
>the same names (or labels). The difference
>between these resources could be made in the
>definitions, extra tags, metaclasses, macro's...
>That is how we could use intellegible names for
>relation types in the BioGateway system.
In the original statement
http://genomebiology.com/2005/6/5/R46
we used different fonts to capture these
differences -- and of course different URIs would
be needed too. Note that for continuants part_of is a three-place relation
this wheel part_of this car at this time
BS
Stefan Schulz
> http://genomebiology.com/2005/6/5/R46
> we used different fonts to capture these
> differences -- and of course different URIs would
> be needed too. Note that for continuants part_of is a three-place relation
>
> this wheel part_of this car at this time
"leg [class-level]_part_of body"
we make a very strong claim namely that there is never any leg that
is not part of some body, such as states in http://genomebiology.com/2005/6/5/R46:
C [class-level]_part_of C1 = [definition] for all c, t, if Cct then there is some c1 such that C1c1t and c [instance-level]part_of c1 at t.
"leg [cleass-level]_part_of body" would therefore entail that an amputated leg is no longer a leg.
The use of instance level part of in a description logics statement (where the time parameter is omitted due to language constraints), has the same strength:
leg IMPLIES [instance-level]part_of SOME body
It may be doubted whether this is the intended meaning of many uses of [cleass-level]part_of in OBO ontologies, e.g.
MA: Tail [class-level]_part_of Adult_Mouse or
GO: Axon [class-level]_part_of Cell
at least if removed organs or cell components (such as amputated legs or cut mouse tails) are allowed in the world to be represented.
I really do not find a satisfactory way to represent this in the current state of OBO RO. In BioTop I use
"[instance-level]part_of SOME b OR [instance-level]derived_from SOME b" but I'm aware that this does not exacly fit.
In other words, we need a way to express "for every instance a of A there is some instance b of B at some time t so that [instance-level]part_of (a,b,t).
Best regards
Stefan
Barry Smith
> > In the original statement
> >
> > we used different fonts to capture these
> > differences -- and of course different URIs would
> > be needed too. Note that for continuants part_of is a three-place relation
> >
> > this wheel part_of this car at this time
>
>But if we state
>
>"leg [class-level]_part_of body"
>
>we make a very strong claim namely that there is never any leg that
>is not part of some body, such as states in
we would make such a claim, of course, only in the context of a
canonical ontology
>C [class-level]_part_of C1 = [definition] for all c, t, if Cct then
>there is some c1 such that C1c1t and c [instance-level]part_of c1 at t.
>
>"leg [cleass-level]_part_of body" would therefore entail that an
>amputated leg is no longer a leg.
>The use of instance level part of in a description logics statement
>(where the time parameter is omitted due to language constraints),
>has the same strength:
>
>leg IMPLIES [instance-level]part_of SOME body
>
>It may be doubted whether this is the intended meaning of many uses
>of [cleass-level]part_of in OBO ontologies, e.g.
>MA: Tail [class-level]_part_of Adult_Mouse or
This is a typical MA error.
>GO: Axon [class-level]_part_of Cell
>
>at least if removed organs or cell components (such as amputated
>legs or cut mouse tails)
I worry more about Child_Mice (since they too presumably fall within
the scope of a canonical ontology).
I agree with you that GO's treatment of Axons is incorrect (as is
GO's treatment of Extracellular). Both need fixing.
> are allowed in the world to be represented.
>
>I really do not find a satisfactory way to represent this in the
>current state of OBO RO. In BioTop I use
>"[instance-level]part_of SOME b OR [instance-level]derived_from SOME
>b" but I'm aware that this does not exacly fit.
>
>In other words, we need a way to express "for every instance a of A
>there is some instance b of B at some time t so that
>[instance-level]part_of (a,b,t).
The RO framework allows for this (OWL DL, seemingly, not).
BS
>Best regards
>
>Stefan
Stefan Schulz
>> In other words, we need a way to express "for every instance a of A there
>> is some instance b of B at some time t so that [instance-level]part_of
>> (a,b,t).
>
> The RO framework allows for this (OWL DL, seemingly, not).
>
But in practice I don't see any relation [class-level]_**R** suited
for non-canonical structural relations such as
Axon [class-level]_**R** Cell and
Mouse_Tail [class-level]_**R** Mouse
neither in the existing RO nor amongst the candidates for RO
extension. Correct me if I am wrong.
WRT description logics: If we regard a domain as containing all
entities of present or past existence, couldn't we then do without
ternary relations?
--
Stefan
--
Stefan SCHULZ (apl. Prof. Dr. med.)
Universitätsklinikum - Institut für Medizinische
Biometrie und Medizinische Informatik
Stefan-Meier-Strasse 26 D-79104 Freiburg
[home: Eschholzstr. 70 D-79115 Freiburg]
+49 (0)761 2036725, 2049089, FAX 2036711
http://purl.org/steschu
[stsc...@uni-freiburg.de], Skype: stschulz
-------------------------------------------------------------------------
Barry Smith
> >>
> >> In other words, we need a way to express "for every instance a of A there
> >> is some instance b of B at some time t so that [instance-level]part_of
> >> (a,b,t).
> >
> > The RO framework allows for this (OWL DL, seemingly, not).
> >
>If you mean First-order logics, I agree.
>But in practice I don't see any relation [class-level]_**R** suited
>for non-canonical structural relations such as
> Axon [class-level]_**R** Cell and
> Mouse_Tail [class-level]_**R** Mouse
>neither in the existing RO nor amongst the candidates for RO
>extension. Correct me if I am wrong.
The instance level versions of such relations
have been defined in the spatial reasoning community. See e.g. p. 9 of this:
http://www.comp.leeds.ac.uk/qsr/pub/JPL_2003.pdf
The basic spatial relations already included in
RO are designed to be extended by such additional relations according to need.
>WRT description logics: If we regard a domain as containing all
>entities of present or past existence, couldn't we then do without
>ternary relations?
Not if you lose or gain parts over time.
BS
Chris Mungall
On Oct 25, 2008, at 1:12 PM, Barry Smith wrote:
> At 01:27 PM 10/25/2008, Stefan Schulz wrote:
>> > In the original statement
>> > <http://genomebiology.com/2005/6/5/R46>http://genomebiology.com/2005/6/5/R46
>> > we used different fonts to capture these
>> > differences -- and of course different URIs would
>> > be needed too. Note that for continuants part_of is a three-place
>> relation
>> >
>> > this wheel part_of this car at this time
>>
>> But if we state
>>
>> "leg [class-level]_part_of body"
>>
>> we make a very strong claim namely that there is never any leg that
>> is not part of some body, such as states in <http://genomebiology.com/2005/6/5/R46
>> >http://genomebiology.com/2005/6/5/R46:
>
> we would make such a claim, of course, only in the context of a
> canonical ontology
I have a feeling we've been down this path before.... :-)
>
>> C [class-level]_part_of C1 = [definition] for all c, t, if Cct then
>> there is some c1 such that C1c1t and c [instance-level]part_of c1
>> at t.
>>
>> "leg [cleass-level]_part_of body" would therefore entail that
>> an amputated leg is no longer a leg.
>> The use of instance level part of in a description logics statement
>> (where the time parameter is omitted due to language constraints),
>> has the same strength:
>>
>> leg IMPLIES [instance-level]part_of SOME body
>>
>> It may be doubted whether this is the intended meaning of many uses
>> of [cleass-level]part_of in OBO ontologies, e.g.
>> MA: Tail [class-level]_part_of Adult_Mouse or
>
> This is a typical MA error.
The mistake is mostly terminological. You can imagine all the terms in
MA as being prefixed with "adult", which would render the above
statement a perfectly acceptable statement in the context of canonical
anatomy
(of course it would be better if MA stated this explicitly as an axiom
rather than textually)
>> GO: Axon [class-level]_part_of Cell
>>
>> at least if removed organs or cell components (such as amputated
>> legs or cut mouse tails)
>
> I worry more about Child_Mice (since they too presumably fall within
> the scope of a canonical ontology).
> I agree with you that GO's treatment of Axons is incorrect (as is
> GO's treatment of Extracellular). Both need fixing.
Can you explain why the axon case is any different from the leg case?
axon (type-level) part_of cell seems fine in the context of canonical
anatomy to me
>
>> are allowed in the world to be represented.
>>
>> I really do not find a satisfactory way to represent this in the
>> current state of OBO RO. In BioTop I use
>> "[instance-level]part_of SOME b OR [instance-level]derived_from
>> SOME b" but I'm aware that this does not exacly fit.
>>
>> In other words, we need a way to express "for every instance a of A
>> there is some instance b of B at some time t so that [instance-
>> level]part_of (a,b,t).
>
> The RO framework allows for this (OWL DL, seemingly, not).
These kinds of what I think we are calling "time-restricted" type-
level relations are being worked on by David Sutherland and Fabian
Neuhaus.
The proposed family of relations are actually stronger than the one
above, in that they stipulate that the two continuants are never
mutually detached. They are therefore of no use to the non-canonical
amputation scenarios.
Barry Smith
because axon's include also parts outside the cell
BS
David Sutherland
How on earth one could build a non-cannonical anatomy ontology is beyond
me. Surely the best way to deal with annotation that requires refering
to an anatomical class out of cannonical context (e.g. an amputated leg,
or a neuron in primary cell culture) is to use qualifiers in the
annotation to negate properties of the cannonical class. Perhaps:
(leg !part_of body) ?
Stefan Schulz
> ontology is beyond me. Surely the best way to deal
> with annotation that requires refering
> to an anatomical class out of cannonical context
> (e.g. an amputated leg, or a neuron in primary cell
> culture) is to use qualifiers in the annotation to negate properties of
> the cannonical class.
identify a subset of axioms that are valid in any possible
non-canonical case, e.g.
"Every mouse tail is part of some mouse body at some time"
"Every mouse tail contains bones, connective tissue, and skin"
"Every heart contains ventricles"
"Every left ventricle is part of some heart"
"Every human leg is connected to some human trunk at some time"
"Every DNA contains nucleic acids"
David Sutherland
> > How on earth one could build a non-cannonical anatomy
> > ontology is beyond me. Surely the best way to deal
> > with annotation that requires refering
> > to an anatomical class out of cannonical context
> > (e.g. an amputated leg, or a neuron in primary cell
> > culture) is to use qualifiers in the annotation to negate properties of
> > the cannonical class.
> The question is not how to build a non-canonical anatomy but to
> identify a subset of axioms that are valid in any possible
> non-canonical case, e.g.
> "Every mouse tail is part of some mouse body at some time"
I fear we could play this game for ever.
And besides, accurate cannonical partonomies are extremely useful in
providing necessary and sufficient definitions for terms and for
grouping annotations. (In fact combined partomomy/class grouping is
*the* major way that OBO ontologies are used.) For example, If I query
for all genes expressed in the mushroom body of Drosophila, then I
should expect to get back genes expressed in Kenyon cells - as all
Kenyon cells are part_of some mushroom body. At least, all cannonical
Kenyon cells are. But these cells can be grown in primary culture.
Having a system to negate this partonomy in order to post-compose a term
for annotation would allow us to exclude the relevant annotations from
partonomy based groupings.
The same argument applies to other properties like connectivity or
developmental lineage. Encoding cannonical information about
connectivity and and developmental lineage is both useful in itself and
for grouping annotations - e.g.- allowing queries for genes expressed
in cells of a specified lineage or for classes of neuron which connect
two specified parts of the brain.
Best,
David
Stefan Schulz
I fully agree that canonical anatomical descriptions are highly important.
Yet I find it necessary for biomedical ontologies to distinguish between
- assertions that may contradict non-canonical reality
("mouse has-part some tail")
- assertions that universally hold
("mouse tail has-part some bone)
Stefan
2008/10/28 David Sutherland <dj...@gen.cam.ac.uk>:
--
Stefan SCHULZ (apl. Prof. Dr. med.)
Universitätsklinikum - Institut für Medizinische
Biometrie und Medizinische Informatik
Stefan-Meier-Strasse 26 D-79104 Freiburg
[home: Eschholzstr. 70 D-79115 Freiburg]
+49 (0)761 2036725, 2049089, FAX 2036711
http://purl.org/steschu
[stsc...@uni-freiburg.de], Skype: stschulz
-------------------------------------------------------------------------
David Sutherland
Hi Stefan,
> David,
> I fully agree that canonical anatomical descriptions are highly important.
> Yet I find it necessary for biomedical ontologies to distinguish between
> - assertions that may contradict non-canonical reality
> ("mouse has-part some tail")
how many bits can you cut off a cannonical mouse and still have a
(non-cannonical) mouse ?
> - assertions that universally hold
> ("mouse tail has-part some bone)
What is the tail of a mouse which carries a mutation that prevents
endochondrial ossification - leading the bone to remain as cartilage?
As I said, I think there is no end to this game. If anatomy ontologists
were under an obligation to worry about defining non-cannonical universals
as well as cannonical anatomy, I fear we'd do little else but play it.
Cheers,
David
Werner Ceusters
The first one is not the task of an ontology. If you have a mouse in your
lab that doesn't have a tail, then you can easily make an instance level
assertion about that mouse by using the lacks-relation. There is no need to
do that at ontology level.
If we would come to discover that certain types of mice do not have tails,
then the original universal assertion would be invalid, and the ontology
needs to be updated.
Werner