How to deal with domain ontology grouping classes that are parents to CORE classes, e.g. PCO organismal entity

[cmungall]

PCO includes 'organismal entity' A material entity that is one or more organisms, viruses or viroids.

should this be in core? cc @ramonawalls

If not, then note that pco would not conform to guidelines in that it would contain classes that do not have superclasses in core. perhaps we could have a getout clause - e.g. domain ontologies can still contain grouping classes if they are equivalent to an expression (e.g. a union) all of whose member classes are subclasses of core classes?

[bpeters42]

There should be a 'get out clause' for grouping terms. There were similar concerns about 'chemical entity'. Ideally we should ask ontologies to label such classes as 'grouping terms'?

…

On Wed, Jul 31, 2019 at 4:54 PM Chris Mungall ***@***.***> wrote: PCO includes 'organismal entity' *A material entity that is one or more organisms, viruses or viroids.* should this be in core? cc @ramonawalls <https://github.com/ramonawalls> If not, then note that pco would not conform to guidelines in that it would contain classes that do not have superclasses in core. perhaps we could have a getout clause - e.g. domain ontologies can still contain grouping classes if they are equivalent to an expression (e.g. a union) all of whose member classes are subclasses of core classes? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJX2IX7NZS3XEAZC6QBVS3QCH3XVANCNFSM4IIKPIBQ> .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[cmungall]

Seems reasonable, but lets think this through.

If PCO deems this to be a useful grouping, and being the domain experts in this area, does this warrant further discussion (in this specific case, and the general case).

Furthermore, let's say others want to have this grouping in their own ontology. We are back to a complicate MIREOT situation. In fact it's a bit harder than before: if I want OE in my ontology, then I need to:

1. import OBO CORE
2. MIREOT or extract the OE class from PCO
3. MIREOT or extract the two PCO subClassOf axioms, O is-a OE, PoO is-a OE

Note that 3 doesn't come for free with 2 due to the fact this is 'above' rather than 'below'.

I could instead MIREOT or extract the explicit subclasses from PCO, but this also gets awkward, and wouldn't work if we use a pco-base module and PCO uses core IDs for O and PoO.

All of this could be fixed with the right engineering, but it just seems a bad smell. I worry that putting classes 'above' core could have other side effects.

I don't know what the solution is. If we accept everyone's groupings, then CORE becomes very latticey and less minimalist.

it should be noted here also that mereological groupings are problematic for reasoning in ways class groupings are not.

I do think we want to limit above-CORE groupings as much as possible, although banning in domain ontologies would be too draconian. We could first start by obtaining a list of such groupings as an informative measure before making any recommendations

• Uberon/CARO: anatomical entity (encompasses multiple scales, and both M/IM)
• PCO: organismal entity
• GO: cellular component [mereological grouping]
• probably more...

[bpeters42]

My statement was based on the assumption (which I still think is true) that specific domain ontologies would like to introduce groupings, but others would rarely want to re-use these. And better yet: If grouping classes above the core will essentially be 'union statements' then equivalence between them can be easily asserted.

…

On Thu, Aug 1, 2019 at 8:42 PM Chris Mungall ***@***.***> wrote: Seems reasonable, but lets think this through. If PCO deems this to be a useful grouping, and being the domain experts in this area, does this warrant further discussion (in this specific case, and the general case). Furthermore, let's say others want to have this grouping in their own ontology. We are back to a complicate MIREOT situation. In fact it's a bit harder than before: if I want OE in my ontology, then I need to: 1. import OBO CORE 2. MIREOT or extract the OE class from PCO 3. MIREOT or extract the two PCO subClassOf axioms, O is-a OE, PoO is-a OE Note that 3 doesn't come for free with 2 due to the fact this is 'above' rather than 'below'. I could instead MIREOT or extract the explicit subclasses from PCO, but this also gets awkward, and wouldn't work if we use a pco-base module and PCO uses core IDs for O and PoO. All of this could be fixed with the right engineering, but it just seems a bad smell. I worry that putting classes 'above' core could have other side effects. I don't know what the solution is. If we accept everyone's groupings, then CORE becomes very latticey and less minimalist. it should be noted here also that mereological groupings are problematic for reasoning in ways class groupings are not. I do think we want to limit above-CORE groupings as much as possible, although banning in domain ontologies would be too draconian. We could first start by obtaining a list of such groupings as an informative measure before making any recommendations - Uberon/CARO: anatomical entity (encompasses multiple scales, and both M/IM) - PCO: organismal entity - GO: cellular component - probably more... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJX2IVW3OGGGSGQ6JA2SN3QCN7H3ANCNFSM4IIKPIBQ> .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[mellybelly]

Just a little history - the PCO grouping class was meant to align with the CARO upper union class - folks often need the union of the parent nodes in NCBI Taxon. I think in this context, it might make sense to have this grouping class in the CORE as a superclass of what we've decided for Organism? see #6

We don't want to end up with multiple ontologies creating this same class, especially since its been there all along.

We could also try to get NCBI to make a union parent class?

[cmungall]

The name 'organismal entity' is confusing, but this isn't the same as the caro class, this is the union of organism and population

…

On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel ***@***.***> wrote: Just a little history - the PCO grouping class was meant to align with the CARO upper union class - folks often need the union of the parent nodes in NCBI Taxon. I think in this context, it might make sense to have this grouping class in the CORE as a superclass of what we've decided for Organism? see #6 <#6> We don't want to end up with multiple ontologies creating this same class, especially since its been there all along. We could also try to get NCBI to make a union parent class? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ> .

[bpeters42]

Thanks for clarifying Chris, that is what I understood. I think both that label and the concept of having a union of organism and population is confusing. For example, I can't think of many useful properties that are shared between these two classes, and not by other material entities. If an ontology wants this purely for grouping purposes, that is fine, but it really doesn't help at all for the OBO-Core purposes of making it easy for users to know where there classes should go, but would rather add to the confusion. Given that Melissa misread this is a case in point for that. So I really don't think we should worry about this or other grouping terms (e.g. CHEBI chemical entity), which can be nice for some ontologies for browsing, but are in my opinion an obstacle when we include them in the Core. On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall <notifications@github.com> wrote:

…

The name 'organismal entity' is confusing, but this isn't the same as the caro class, this is the union of organism and population On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel ***@***.***> wrote: > Just a little history - the PCO grouping class was meant to align with the > CARO upper union class - folks often need the union of the parent nodes in > NCBI Taxon. I think in this context, it might make sense to have this > grouping class in the CORE as a superclass of what we've decided for > Organism? see #6 > <#6> > > We don't want to end up with multiple ontologies creating this same class, > especially since its been there all along. > > We could also try to get NCBI to make a union parent class? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #37 >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ> .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[bpeters42]

I think a good deciding principle could be that any class that we can only define as the union of subclasses, while the subclasses can be reasonably well defined individually should be very suspect to be added to the core.

…

On Sun, Aug 4, 2019 at 8:28 AM Bjoern Peters ***@***.***> wrote: Thanks for clarifying Chris, that is what I understood. I think both that label and the concept of having a union of organism and population is confusing. For example, I can't think of many useful properties that are shared between these two classes, and not by other material entities. If an ontology wants this purely for grouping purposes, that is fine, but it really doesn't help at all for the OBO-Core purposes of making it easy for users to know where there classes should go, but would rather add to the confusion. Given that Melissa misread this is a case in point for that. So I really don't think we should worry about this or other grouping terms (e.g. CHEBI chemical entity), which can be nice for some ontologies for browsing, but are in my opinion an obstacle when we include them in the Core. On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall ***@***.***> wrote: > The name 'organismal entity' is confusing, but this isn't the same as the > caro class, this is the union of organism and population > > On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel ***@***.***> > wrote: > > > Just a little history - the PCO grouping class was meant to align with > the > > CARO upper union class - folks often need the union of the parent nodes > in > > NCBI Taxon. I think in this context, it might make sense to have this > > grouping class in the CORE as a superclass of what we've decided for > > Organism? see #6 > > <#6> > > > > We don't want to end up with multiple ontologies creating this same > class, > > especially since its been there all along. > > > > We could also try to get NCBI to make a union parent class? > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > < > #37 > >, > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#37>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ> > . > -- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[hoganwr]

+1

…

On Sun, Aug 4, 2019 at 11:50 AM bpeters42 ***@***.***> wrote: I think a good deciding principle could be that any class that we can only define as the union of subclasses, while the subclasses can be reasonably well defined individually should be very suspect to be added to the core. On Sun, Aug 4, 2019 at 8:28 AM Bjoern Peters ***@***.***> wrote: > Thanks for clarifying Chris, that is what I understood. I think both that > label and the concept of having a union of organism and population is > confusing. For example, I can't think of many useful properties that are > shared between these two classes, and not by other material entities. If an > ontology wants this purely for grouping purposes, that is fine, but it > really doesn't help at all for the OBO-Core purposes of making it easy for > users to know where there classes should go, but would rather add to the > confusion. Given that Melissa misread this is a case in point for that. So > I really don't think we should worry about this or other grouping terms > (e.g. CHEBI chemical entity), which can be nice for some ontologies for > browsing, but are in my opinion an obstacle when we include them in the > Core. > > On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall ***@***.***> > wrote: > >> The name 'organismal entity' is confusing, but this isn't the same as the >> caro class, this is the union of organism and population >> >> On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel < ***@***.***> >> wrote: >> >> > Just a little history - the PCO grouping class was meant to align with >> the >> > CARO upper union class - folks often need the union of the parent nodes >> in >> > NCBI Taxon. I think in this context, it might make sense to have this >> > grouping class in the CORE as a superclass of what we've decided for >> > Organism? see #6 >> > <#6> >> > >> > We don't want to end up with multiple ontologies creating this same >> class, >> > especially since its been there all along. >> > >> > We could also try to get NCBI to make a union parent class? >> > >> > — >> > You are receiving this because you authored the thread. >> > Reply to this email directly, view it on GitHub >> > < >> #37 >> >, >> > or mute the thread >> > < >> https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ >> > >> > . >> > >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub >> < #37 >, >> or mute the thread >> < https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ > >> . >> > > > -- > Bjoern Peters > Professor > La Jolla Institute for Allergy and Immunology > 9420 Athena Circle > La Jolla, CA 92037, USA > Tel: 858/752-6914 > Fax: 858/752-6987 > http://www.liai.org/pages/faculty-peters > -- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJR55R4BK2W3RISETQKNL3QC33DFANCNFSM4IIKPIBQ> .

[cmungall]

Allow me to bang on about this a bit more as I think this is an interesting specific case, and it's good to for discussing more general cases. Agreed that the label is confusing.

I can't think of many useful properties that are shared between these two

classes, I slightly disagree here. E.g looking at evolution of genomes on the individual vs population level. Also from a pragmatic ontology engineering point of view: there is a general problem here with mereological sum classes. The limit case of 1 member is really awkward. Either you allow sums/sets of size one (which can be conceptually weird, but makes a lot of mathematical sense), which in this case would mean Os are subclasses of PoO; or you say minimum of size 2, introducing a mathematical disjunction and limiting the ability to talk about sets that are inclusive of single individuals without introducing a grouping class. All solutions are sucky here (basically because we have set theory operating at two levels), which is why I think it's a good idea to avoid mereological sum classes. Populations of organisms are obviously an exception here as it's such a crucial scientific concept (I use the C word advisedly). Anyway, the more *general* point here is that while I am partially sympathetic to arguments for inclusion of this and other grouping classes, I am extremely skeptical of the notion that this is only *locally* useful to the needs of PCO or one particular ontology. Also I can't emphasize enough as someone who has spent countless hours debugging horrible import chains from poorly modularized ontologies with cyclic imports and stale mireots and patchwork bridges, people superclassing core creates a lot of engineering headaches.

…

On Sun, Aug 4, 2019 at 8:29 AM bpeters42 ***@***.***> wrote: Thanks for clarifying Chris, that is what I understood. I think both that label and the concept of having a union of organism and population is confusing. For example, I can't think of many useful properties that are shared between these two classes, and not by other material entities. If an ontology wants this purely for grouping purposes, that is fine, but it really doesn't help at all for the OBO-Core purposes of making it easy for users to know where there classes should go, but would rather add to the confusion. Given that Melissa misread this is a case in point for that. So I really don't think we should worry about this or other grouping terms (e.g. CHEBI chemical entity), which can be nice for some ontologies for browsing, but are in my opinion an obstacle when we include them in the Core. On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall ***@***.***> wrote: > The name 'organismal entity' is confusing, but this isn't the same as the > caro class, this is the union of organism and population > > On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel ***@***.*** > > wrote: > > > Just a little history - the PCO grouping class was meant to align with > the > > CARO upper union class - folks often need the union of the parent nodes > in > > NCBI Taxon. I think in this context, it might make sense to have this > > grouping class in the CORE as a superclass of what we've decided for > > Organism? see #6 > > <#6> > > > > We don't want to end up with multiple ontologies creating this same > class, > > especially since its been there all along. > > > > We could also try to get NCBI to make a union parent class? > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > < > #37 > >, > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #37 >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ > > . > -- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAMMONF7SCZ2WV5QLB44JLQC3YWBANCNFSM4IIKPIBQ> .

[bpeters42]

Responses inline On Sun, Aug 4, 2019 at 12:05 PM Chris Mungall <notifications@github.com> wrote:

Allow me to bang on about this a bit more as I think this is an interesting specific case, and it's good to for discussing more general cases. Agreed that the label is confusing. > I can't think of many useful properties that are shared between these two classes, I slightly disagree here. E.g looking at evolution of genomes on the individual vs population level.

Can you be more specific? I thought this was a great example where there should *not* be any shared properties, given that evolution impacts a population vs. an individual is dramatically different.

Also from a pragmatic ontology engineering point of view: there is a general problem here with mereological sum classes. The limit case of 1 member is really awkward. Either you allow sums/sets of size one (which can be conceptually weird, but makes a lot of mathematical sense), which in this case would mean Os are subclasses of PoO; or you say minimum of size 2, introducing a mathematical disjunction and limiting the ability to talk about sets that are inclusive of single individuals without introducing a grouping class. We are doing "2 or more vs.1" distinctions throughout, e.g. for the

distinction between a molecule and an atom. Given that we want to do a single cross-granularity ontology, we have to draw borders somewhere, and I thought these work better than anything else we have.

All solutions are sucky here (basically because we have set theory operating at two levels), which is why I think it's a good idea to avoid mereological sum classes. Populations of organisms are obviously an exception here as it's such a crucial scientific concept (I use the C word advisedly). Anyway, the more *general* point here is that while I am partially sympathetic to arguments for inclusion of this and other grouping classes, I am extremely skeptical of the notion that this is only *locally* useful to the needs of PCO or one particular ontology. Either I don't understand the last paragraph, or maybe there is a typo /

word missing? did you mean 'arguments against inclusion'?

…

Also I can't emphasize enough as someone who has spent countless hours debugging horrible import chains from poorly modularized ontologies with cyclic imports and stale mireots and patchwork bridges, people superclassing core creates a lot of engineering headaches. On Sun, Aug 4, 2019 at 8:29 AM bpeters42 ***@***.***> wrote: > Thanks for clarifying Chris, that is what I understood. I think both that > label and the concept of having a union of organism and population is > confusing. For example, I can't think of many useful properties that are > shared between these two classes, and not by other material entities. If an > ontology wants this purely for grouping purposes, that is fine, but it > really doesn't help at all for the OBO-Core purposes of making it easy for > users to know where there classes should go, but would rather add to the > confusion. Given that Melissa misread this is a case in point for that. So > I really don't think we should worry about this or other grouping terms > (e.g. CHEBI chemical entity), which can be nice for some ontologies for > browsing, but are in my opinion an obstacle when we include them in the > Core. > > On Sun, Aug 4, 2019 at 8:01 AM Chris Mungall ***@***.***> > wrote: > > > The name 'organismal entity' is confusing, but this isn't the same as the > > caro class, this is the union of organism and population > > > > On Sat, Aug 3, 2019 at 7:05 AM Melissa Haendel < ***@***.*** > > > > wrote: > > > > > Just a little history - the PCO grouping class was meant to align with > > the > > > CARO upper union class - folks often need the union of the parent nodes > > in > > > NCBI Taxon. I think in this context, it might make sense to have this > > > grouping class in the CORE as a superclass of what we've decided for > > > Organism? see #6 > > > <#6> > > > > > > We don't want to end up with multiple ontologies creating this same > > class, > > > especially since its been there all along. > > > > > > We could also try to get NCBI to make a union parent class? > > > > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub > > > < > > > #37 > > >, > > > or mute the thread > > > < > > > https://github.com/notifications/unsubscribe-auth/AAAMMOMQXLLDRIQZ4JJ2DJ3QCWGDPANCNFSM4IIKPIBQ > > > > > > . > > > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub > > < > #37 > >, > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/ADJX2IU3F2KMQLHFCH67OXDQC3VOLANCNFSM4IIKPIBQ > > > > . > > > > > -- > Bjoern Peters > Professor > La Jolla Institute for Allergy and Immunology > 9420 Athena Circle > La Jolla, CA 92037, USA > Tel: 858/752-6914 > Fax: 858/752-6987 > http://www.liai.org/pages/faculty-peters > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #37 >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AAAMMONF7SCZ2WV5QLB44JLQC3YWBANCNFSM4IIKPIBQ > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJX2ISFZIC6JDQQ6KPBU63QC4R77ANCNFSM4IIKPIBQ> .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[cmungall]

evolution of genomes of individuals vs populations: I don't have a particularly strong argument here, there are of course differences, but it's useful to treat both as genome-bearers. N>1 vs 1: agreed that this is analogous to atom vs molecule. But we have (or did have) a grouping here. So we have the benefits of lumping and splitting here.

Anyway, the more *general* point here is that while I am partially > sympathetic to arguments for inclusion of this and other grouping classes, > I am extremely skeptical of the notion that this is only *locally* useful > to the needs of PCO or one particular ontology. > > Either I don't understand the last paragraph, or maybe there is a typo / word missing? did you mean 'arguments against inclusion'?

No typo, but maybe I wasn't clear. Basically I don't find it satisfying to say "you can keep the grouping class in PCO, but we won't have it in core". Either it has some general utility in which case there is a strong argument for having it in core, or its overall utility is minimal in which case there is a strong argument for removing from PCO. If we trust an ontology in a domain then we should trust its abstractions, and we should have as few competing super-abstractions within OBO as possible. I'm not arguing from any kind of absolutist position here, and maybe the first step in any case is just to list the supercore classes in various trusted ontologies and work from there.

…

[bpeters42]

I certainly can agree with the last point to: "just to list the supercore classes in various trusted ontologies and work from there." Rather than working in the abstract. I would also want to argue that this has much lower priority than finishing defining the classes that were identified as important for cross-ontology work.

…

On Sun, Aug 4, 2019 at 4:09 PM Chris Mungall ***@***.***> wrote: evolution of genomes of individuals vs populations: I don't have a particularly strong argument here, there are of course differences, but it's useful to treat both as genome-bearers. N>1 vs 1: agreed that this is analogous to atom vs molecule. But we have (or did have) a grouping here. So we have the benefits of lumping and splitting here. > Anyway, the more *general* point here is that while I am partially > > sympathetic to arguments for inclusion of this and other grouping > classes, > > I am extremely skeptical of the notion that this is only *locally* useful > > to the needs of PCO or one particular ontology. > > > > Either I don't understand the last paragraph, or maybe there is a typo / > word missing? did you mean 'arguments against inclusion'? > No typo, but maybe I wasn't clear. Basically I don't find it satisfying to say "you can keep the grouping class in PCO, but we won't have it in core". Either it has some general utility in which case there is a strong argument for having it in core, or its overall utility is minimal in which case there is a strong argument for removing from PCO. If we trust an ontology in a domain then we should trust its abstractions, and we should have as few competing super-abstractions within OBO as possible. I'm not arguing from any kind of absolutist position here, and maybe the first step in any case is just to list the supercore classes in various trusted ontologies and work from there. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADJX2IS32PWEEOOMQVPVDALQC5OSBANCNFSM4IIKPIBQ> .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[cmungall]

@ukemi also notes that this holds for GO cellular component

[ramonawalls]

Sorry to be late to the game here. Perhaps some clarification of the history and use of this term will be helpful.

1. Organismal entity (OE) is just a union class in PCO. You will see this in the editors file (https://raw.githubusercontent.com/PopulationAndCommunityOntology/pco/master/src/ontology/pco-edit.owl). Of course, when we run the reasoner for release, it asserts the subclass axioms. I guess this is the case for most grouping classes in OBO ontologies. Does this provide a potential solution? Could PCO just import organism and collection of organisms from CORE and create the union class? I'm not sure how much that solves.

2. OE is not the union of organism, virus, or viroid and population of organisms, but rather the union of organism, virus, or viroid and collection of organisms. I want us to get in the habit of not referring to general collections as populations, because they aren't, either in the statistical or biological sense.

3. OE was first created as a parent class for household, which might be one person or multiple people. There are many use cases that need to refer to single organism or multiple organisms, and it is really convenient for us to keep this union class. Sure, we could just include the union statement in every definition, but who wants to do that.

4. Darwin Core has a class "Organism" which is defined as "A particular organism or defined group of organisms considered to be taxonomically homogeneous." As mush as I dislike the DwC class, it has a purpose. BCO needs to deal with the DwC class, and OE makes the perfect parent class for it.

5. Regarding the discussion about sets and whether they can have only one element, I don't have a philosophical position on it. I just need to be able to talk about three types of entities: those that are one organism, those that are collections of two or more organisms, and those that can be either.

I don't have a strong opinion on whether or not OE should go into the core, as long as we can keep it in PCO and continue to use it BCO.