CommonCoreOntology
Group of Persons
The current definition of Group of Persons reads:
"A Group of Agents that has only Persons as parts."
I would like to propose to change the definition to the following to allow for subgroups of Groups of Persons (the definition of Organization already works like this):
"A Group of Agents that has only Group of Persons or Persons as parts."
or (even better im my opinion, see discussion in the other issue)
"Object Aggregate that has only Group of Persons or Persons as parts."
What do you think?
@eliasweatherfield You are relying on has-part being a transitive property, right? In the version of CCO that conforms to BFO 2.0, has-continuant-part-at-all-times is transitive, but has-continuant-part-at-some-time is not. How would this affect your definition?
@swartik Good question.
This problem arises for all continuants with temporary continuant parts (and also those temporarily located_in some continuant), doesn‘t it? (Including Organization)
There are four interpretations of has_part that I can see:
- Permanent generic. Part does not need to be the same instance at all times. (Some working on RO seem(ed) to find this useful.)
- Permanent specific/at all times. Part needs to be the same instance at all times. Transitive.
- Temporary specific/at some time. Not transitive.
- Temporary specific/at a specific time (e. g. phase). Transitive. (BFO 2020 temporalized)
What is the interpretation of the has_part relation in CCO? My current understanding is this: The interpretation changes from permanent specific/at all times to temporary specific/at a specific time as soon as there is a Stasis of Part Role. Transitivity always holds.
@swartik What do you think about that solution?
@mark-jensen @rorudn Does this sound about right to you?
https://www.youtube.com/watch?v=fkkWkTIxrNQ
Barry's slide at 06:37 classifies at-a-specific-time relations as „hidden“ at-all-times relations.
Regarding permanent generic: It is not representable as a property in OWL. A permanent generic relation would need to be able to handle the following, where x and y are continuants and R is some relation.
- x R y at t1
- not (x R y) at t2
- x R z at t2
- not(x R z) at t1
But there's no place for the "at t" in OWL. But if we drop the time then the above is inconsistent because you have.
- x R y
- not (x R Y)
In other words, there's no way to have a generic relation because there's no time, which means there's no time that something can be different. (x R y) is necessarily specific.
There is a way to express the permanent generic relation using histories, but it's somewhat involved.
It's interesting that some working on RO seem to find this useful. I'm curious how they can think it is useful given that they can't representing it in their OWL. They must be ascribing the usefulness to something different, perhaps unknowingly.
The BFO relation you want is one of the member part relations rather than part. member part is not transitive. None of the offered definitions actually work:
- "A Group of Agents that has only Persons as parts."
- "A Group of Agents that has only Group of Persons or Persons as parts."
- "Object Aggregate that has only Group of Persons or Persons as parts."
These don't work because they rule out the persons having parts, which they do. They are trying to express something like: For the purpose of representing groups of people, the only parts we are interested in are the person parts.
In some cases you can get around this sort of situation by saying something like: the only parts there are are X things or parts of those X things. The problem with that, in this situation, is that it would allow a group of persons to be just the legs, say, of some set of persons.
The last definition is the closest. Changing "as parts" to "as member parts" or just "members" and adding an axiom has-member-part-at-some-time only 'group of persons' or 'person'
It also has the advantage of removing the term "agent" from the definition, which is superfluous. if "agent" was a good term then all persons would be agents, and so it adds nothing. I don't think it is a good term but will post another issue at some time with my objections to it.
But I'm also concerned with the disconnect between the common understanding of "group of persons" is something like a set of persons, and a set of persons would only have members that are persons. I think defining organization in this way makes perfect sense, but not this term. So if I had my druthers the definition I'd choose is:
Group of persons: an Object Aggregate that has only has Persons as member parts. with a restriction has-member-part-at-some-time only 'person'
On reflection I think using agent, given the current definition in common core, is problematic. It would mean that, say, all the patients in a vegetative state in a hospital do not form a group of persons because they aren't capable of performing intentional acts.
Thanks for the helpful reply.
I agree on the needed relation as well as on your point regarding the desirability of empirical adequacy of the definition.
But I'm also concerned with the disconnect between the common understanding of "group of persons" is something like a set of persons, and a set of persons would only have members that are persons. I think defining organization in this way makes perfect sense, but not this term.
I thought some more about this... is the empirical everyday folk "concept" of a group of persons really incompatible with subgrouping?
Let's assume a group of students in a class room is split into two subgroups by the teacher for an exercise. Would we now stop to refer to the group of students in the class room as a "group of persons"? Or would we want to say that the subgroups are not really part of the original group? To me personally, both options prima facie sound odd.
Is a though experiment like this the best way to empirically constrain our definition?
How about this?
Group of Persons =def. An Object Aggregate that has min 2 Persons as member parts and only has (Group of Persons or Persons) as member parts.
The member part relations are transitive, right?
The member-part relations are not transitive. That's how they are distinguished from part relations.
So this is the definition I currently prefer:
Group of Persons =def. An Object Aggregate that only has (Group of Persons or Persons) as member parts.
What is the interpretation of the has_part relation in CCO? My current understanding is this: The interpretation changes from permanent specific/at all times to temporary specific/at a specific time as soon as there is a Stasis of Part Role. Transitivity always holds.
I now believe that the correct temporal interpretation is permanent specific/at all times and that this is not changed by the existence of a Stasis.
@eliasweatherfield group of persons definition is coherent as long as the implications are understood. I think the label isn't quite right but it's only a label. Because of disjointness of members you can't have a person that's a member of some group that's member that's also a direct member. Any member that is a group of persons means that group of persons is an object, by ramge of the member part relation. Finally member part is time indexed so for bfo-2020 you need to decide at-all-time vs at-some-time.
@alanruttenberg Thanks for the very helpful reply.
Any member that is a group of persons means that group of persons is an object, by range of the member part relation.
Object wouldn't work though, would it? I just checked BFO-2020 and RO/CCO. The former specifies "material entity" as range, the latter doesn't specify any range. Am I missing something?
Because of disjointness of members you can't have a person that's a member of some group that's member that's also a direct member.
I saw this in the BFO-2020 definition (but not in the RO/CCO definition). It is definitely a big problem for my use case. Do you have any objections against having a variant of the relation without disjointness?
Finally member part is time indexed so for bfo-2020 you need to decide at-all-time vs at-some-time.
I agree with you that at-some-time is needed here.
The member-part domain and range is a known issue and should be fixed in the near future: https://github.com/BFO-ontology/BFO-2020/issues/8
I agree that object doesn't seem to be the right thing. It isn't disallowed as there are valid cases of something being considered being an object aggregate at one granularity but an object at another.
If you want to proposed a variant, offer a definition. The current definition is:
member part of
DEFINITION: b member part of c at t =Def. b is an object & c is an object aggregate & there is at t a mutually exhaustive and pairwise disjoint partition of c into objects x1,..., xn (for some n ≠ 1) with b = xi (for some 1 ≤ i ≤ n) DOMAIN: object RANGE: object aggregate EXAMPLES: Each tree in a forest is a member part of the forest; each piece in a chess set is a member part of the chess set; each Beatle in the collection called The Beatles is a member part of The Beatles; each human being is a member part of the population homo sapiens; employee of an industrial company.
I can't speak to the RO/CCO definitions as I wasn't involved in their creation. I'm more familiar with the RO relations. The problem is that RO took a bunch of BFO relations and made different versions of them. Part of the motivation for doing the BFO FOL axiomatization was that when I pointed out the problems with the should-be-temporal relations such as part-of I got a lot of pushback. We needed a way to have arguments that were more constructive than "we disagree". The challenge now for RO is, to the extent that they want to be compatible with BFO, provide definitions for their relations that have a FOL translation in terms of BFO. With that we can have a back and forth that is based on something more formal.
CCO is progressing towards using BFO relations as appropriate, so that's good.
What to do? There's always the option of defining some other relation that meets your needs. It's my desire that such relations, to the extent that they interact with BFO, are well-defined, but that's just a desire (for now).
Maybe you could say what your use case is in some more detail and we can see what's available to satisfy it.
One thought is to, instead of having a groups have groups as members, flatten the members and make them all members of the group. Then, for the cases where you wanted a subgroup as member, define that also as a group and make it part (well, it is whether you assert it or not) of the larger group. e.g.
group of persons =def An object aggregate that only has persons as member parts.
Members:
- m1, m2, m3, m4.
Groups:
- g1 with members m1, m2, m3, m4.
- g2 with members m1, m2.
- g2 part of g1.
@alanruttenberg Thanks for the reply.
I can't speak to the RO/CCO definitions as I wasn't involved in their creation. I'm more familiar with the RO relations.
I was referring to the "member of" relation that CCO imported from RO, sorry for the confusion.
CCO is progressing towards using BFO relations as appropriate, so that's good.
I agree.
Maybe you could say what your use case is in some more detail and we can see what's available to satisfy it.
My use case requires representing mereological polyhierarchy. (Actually I also have a more complicated use case involving roles in mind, but let's stick to groups, hopefully that will do.)
Disjoint (fundamental) Members:
m1, m2, m3, m4.
Groups:
Upper Level Group g1 with members m1, m2, m3, m4. Mid Level Group g2a with members m1, m2, m3. Mid Level Group g2b with members m2, m3, m4. Lower Level Group g3a with members m1, m2. Lower Level Group g3b with members m2, m3. Lowest Level Group g4 with member m3. Non-Leveled Group g0 with members m1, m3. g2a part of g1. g2b part of g1. g3a part of g2a, g1. g3b part of g2a, g2b, g1. g4 part of g3b, g2a, g2b, g1, g0. g0 part of g2a, g1.
I think this is in line with what you wrote. So far so good.
But I now want to e. g. say that a Mid Level Group can, by definition, only have a group on a lower level as part. As far as I can see, I can not use the standard transitive has_part relation here (because Persons might have all kinds of parts) and the non-transitive, disjointness-requiring has_member_part relation won't work either (because Lower Level Groups are not disjoint).
(1) Idea 1: (transitive relation with custom domain and range)
Assuming
Upper Level Group is_a Leveled Group Mid Level Group is_a Leveled Group Lower Level Group is_a Leveled Group Lowest Level Group is_a Leveled Group
I guess I could use a has_leveled_group_part version of the standard transitive, no disjointness requiring part_of relation with domain and range Leveled Group.
I could then say:
group of persons =def An object aggregate that only has persons as member parts.
Mid Level Group =def. A Group of Persons that only has Lower Level Groups and Lowest Level Groups as leveled group parts.
I guess the problem here is that a leveled group part that satisfies the conditions of a member part becomes a (non-asserted) member part.
At first sight, it looks like that problem can be fixed by using Group of Persons =def. An object aggregate that only has persons or Groups of Persons as member parts.
(2) Idea 2: (non-transitive relation without disjointness)
I thought a non-transitive version of part_of without disjointness would allow for the following definitions:
group of persons =def An object aggregate that only has persons as member parts.
Mid Level Group =def. A Group of Persons that only has Lower Level Groups as not-necessarily-disjoint member parts. Lower Level Group =def. A Group of Persons that only has Lowest Level Groups as not-necessarily-disjoint member parts.
Pros: This does not require to llist all lower levels (just the next lower level). And we might not always have an obvious common superclass like Leveled Group. Plus we do not need new relations for every superclass.
I guess the problem here is that a leveled group part that satisfies the conditions of a member part becomes a (non-asserted) member part.
That problem seems to arise here, too. A not-necessarily-disjoint member part can become a (non-asserted) member part.
Again, it looks like that problem can be fixed by using Group of Persons =def. An object aggregate that only has persons or Groups of Persons as member parts.
(3) Idea 3:
I guess the problem here is that a leveled group part that satisfies the conditions of a member part becomes a (non-asserted) member part.
Does this problem not also arise for the solution you proposed?
One thought is to, instead of having a groups have groups as members, flatten the members and make them all members of the group. Then, for the cases where you wanted a subgroup as member, define that also as a group and make it part (well, it is whether you assert it or not) of the larger group. e.g.
Could not a subgroup become a (non-asserted) member part due to disjointness and exhaustiveness and thereby violate the definition of the supergroup?
group of persons =def An object aggregate that only has persons as member parts.
Before I give a technical response: Maybe this matters, maybe not. No one has, as an end goal, to have a (poly)hierarchy. They want a (poly)hierarchy that means something. If you can say, what does your hierarchy mean? What's the relationship (in the real world) between child and parent? What problem does it solve?
Same goes for an ontology, FWIW. An ontology isn't (shouldn't be) an end goal. It's a tool towards accomplishing an end goal.
I ask this because it's not infrequent that knowing more about what's meaningful suggests a more natural, equally effective, approach.
@alanruttenberg You're right of course. I'm open for any suggestions.
So what I am trying to do is this. I have social (legal) roles. The realization of some of the lower roles is supposed to count as the realization of some of the upper roles. E. g. an act 1a performer role and an act 1b performer role (fundamental level 1) can both realize an act 1 performer role (level 2). I use a version of the mod-part_of relation (suggested here: http://ceur-ws.org/Vol-2050/FOUST_paper_10.pdf) to represent this:
act 1a performer role mod-part_of act 1 performer role act 1b performer role mod-part_of act 1 performer role
act 1a performer role and act 1b performer role are not exhaustive mod-parts of the act 1 performer role in the sense that the act 1 performer role can be realized in ways additional to the ways the two mod-parts can be realized. act 1a performer role and act 1b performer role do not necessarily need to be part of any act 1 performer role, they can exists separately.
All roles need to realize a top role (level 4):
act 1a performer role mod_part_of general capability to perform an act bearer role act 1b performer role mod-part_of general capability to perform an act bearer role act 1 performer role mod-part_of general capability to perform an act bearer role
One of the roles on level 1 might also realize a role on an intermediate level 3:
act 1b performer role mod-part_of special capability to perform an act bearer role special capability to perform an act bearer role mod-part_of general capability to perform an act bearer role
A role should only be able to have a role as mod-part that is lower in level than itself.
To be a little more concrete: The general capability to perform an act bearer role could be the legal person role that inheres in an entity in virtue of it legally being regarded as a legal person (and is realized in all existent processes that the entity can participate in because of this status).
OK. Where does the object aggregate come into this?
BTW, is the ELK graph supposed to scroll? The diagram is cut off at the right and I don't see how to get the rest of it other than shrinking it, in which case it gets too small.
OK. Where does the object aggregate come into this?
Sorry, I have two separate use cases: Groups of Persons and the one with the roles.
BTW, is the ELK graph supposed to scroll? The diagram is cut off at the right and I don't see how to get the rest of it other than shrinking it, in which case it gets too small.
It does not scroll for me, but I can drag it.
Regarding Group of Persons I need to represent organizations and bodies within organizations that can have overlapping members.
OK. I've reached out to Barry to ask about this issue. I've made a couple of suggestions on how we could deal with it but haven't heard back. One of the ideas is to have a different relationship between organizations and member organizations. I'll report back.
Is there are connection between the role stuff and the group of persons issue?
Thanks. The connection is that I use member part without disjointness to deal with both cases.
Sorry to be a bit dense. You aren't using member-part-of for the roles, right? Is it that you are defining organizations in terms of them?
You aren't using member-part-of for the roles, right?
I am. I'm using member-mod-part_of as a non-transitive version of mod-part_of to ensure the mereological hierarchy between the levels e. g. level 2 roles can only have level 1 roles as member mode parts (level 1 roles themselves might have mode parts I don't know about and that I don't want to disallow).
Object aggregate and member-part-of are definitely not appropriate for the roles. Recall the discussion of the domain/range of member-part-of with domain and range being material entity and that being too loose ?
Roles are not material entities. I see the CCO has-member doesn't have a set domain and range. The BFO relations do. I expect that will be fixed as CCO moves towards BFO-2020 compatibility.
So, for roles you will need to define an intransitive part relation. Regarding groups, I still waiting to hear back.
Object aggregate and member-part-of are definitely not appropriate for the roles. Recall the discussion of the domain/range of member-part-of with domain and range being material entity and that being too loose ?
Roles are not material entities. I see the CCO has-member doesn't have a set domain and range. The BFO relations do. I expect that will be fixed as CCO moves towards BFO-2020 compatibility.
So, for roles you will need to define an intransitive part relation. Regarding groups, I still waiting to hear back.
Sorry, I should have been a lot more explicit. I am aware that BFO-2020:member-part-of cannot be adapted for my role use case. My member-mod-part-of relation is not a subrelation of member-part-of, but of mod-part-of which in turn is a subrelation of part-of. The reason I presented the role case was that this is another case where I have the problems of multiple parents, overlapping parents, overlapping children, and levels (some or all of which might possibly be avoided somehow?) and where I also use an intransitive part-of relation.