On Disjointedness Between Object & Object Aggregate

[Anthony Petosa]

(For your reference, please see that attached PDF.)

BFO's OWL implementation presents owl:Object & owl:ObjectAggregate as subclasses of owl:MaterialEntity. As I recall, an OWL disjointedness relationship is not asserted between these sibling nodes.

From an ontological perspective, this seems contradictory to me, as any universal (a.k.a., 'type') is unique unto itself. Asserting this uniqueness in OWL via a disjointedness relationship enables a logic-based reasoning engine (e.g., Pellet) to report an inconsistency in the OWL model, for instance, if an OWL Individual of an owl:Object's subclass was asserted to be equivalent with an OWL individual of an owl:ObjectAggregate's subclass. In other words, if owl:Object & owl:ObjectAggregate are disjoint, then their respective subclasses are disjoint by inference. Also by inference, the particulars of those disjoint subclasses cannot be equivalent.

This sounds like a reasonable rationale to suggest that BFO Object & Object Aggregate categories should stand in a disjointedness relationship in BFO's OWL implementation. Actually, I would extend this across all BFO sibling 'categories' within the BFO taxonomy.

In this little experiment, I did not import the BFO OWL model into my model. Instead I borrowed Object & Object Aggregate, implementing them as OWL Classes in my model's namespace. I took this approach because I did not want to override the BFO OWL model semantics, assuming the BFO OWL model does not assert disjointedness relationships across sibling nodes in its taxonomy. Within my model, I made this relational assertion between owl:Object & owl:ObjectAggregate.

My intent was to create a water molecule OWL Individual, whereby its member parts were asserted in the model via the "member part of (at t)" relationship (also borrowed from BFO), implemented in the model as an OWL functional object type property.

Pellet reasoned over the model without incident.

In my opinion, the BFO OWL model should assert disjointedness relationships across sibling nodes of the BFO taxonomy. This should not be left to OWL modelers who extend material domains from BFO and then apply the disjointedness relationships within their model on the imported BFO OWL Classes in the BFO namespace.

Three reasons.

1. Ontological Realism informs us that universals are unique. Why not assert this in the BFO OWL across the sibling nodes of its taxonomy? I suppose it would only be necessary to assert a disjointedness relationship between owl:Continuant and owl:Occurrent and then let the reasoning engine figure out the rest. However, I would feel more comfortable if all BFO OWL sibling nodes were asserted in the model with disjointedness relationships, so that one would not need to rely upon a reasoning engine to infer disjointedness anywhere for BFO OWL taxonomy sibling nodes, and, consequently, for any sibling nodes downstream across domain-specific OWL models that synchronize upward, directly or indirectly, to the BFO OWL model.
   
   
2. The lack of disjointed relationships opens up OWL models to nonsensical ontological assertions. For example, suppose owl:Population is subclassed under owl:ObjectAggregate and owl:HumanBeing is subclassed under owl:Object. An OWL modeler introduces OWL Individuals for owl:Population ("mytown_pop_ind") and owl:HumanBeing ("johnsmith_ind"). Perhaps for some application-specific use based upon a highly subjective "concept", the OWL modeler asserts an equivalence between "mytown_pop_ind" and "johnsmith_ind". Maybe "mytown_pop_ind", representing John's home town, was overrun by a Zombie apocalyptic horde last week, leaving only poor John Smith to fend for himself. Hence the OWL modeler asserts that John's remaining home town population and John Smith are one and the same as of last week. If owl:Object & owl:ObjectAggregate stood in a disjointedness relationship, the aforementioned assertion at the OWL Individual level would be shot down by a logic-based reasoner. In short, why not preserve Ontological Realism semantics in BFO OWL as best as possible?
   
   (By the way, I have something to say about BFO's 'member part of at' definition, which allows an Object Aggregate to have a single member. I will post on this topic at a later date.)
   
   
3. There is no control over which OWL modelers importing BFO OWL will assert disjointedness relationships on the BFO OWL sibling nodes in the BFO namespace and which will not do so. You can see how this will pose a problem in scaling BFO OWL across an ever-growing collection of BFO-based domain-specific OWL models. How does one reason unambiguously over a collective pool of RDF triples from a vast collection of OWL models if this simple disjointedness pattern is not followed strictly?

[Lars Vogt]

Hi Anthony,

I think there is a good reason to have Object and ObjectAggregate as subclasses of MaterialEntity without asserting their disjointedness. This has to do with granularity and that some particulars instantiate several subclasses of MaterialEntity at the same time. Just to give you some very general examples: An atom is an aggregate of subatomar particles and an atom and thus an object in its own right. A molecule is an aggregate of atoms and an object at the same time. A cell is an aggregate of molecules and an object at the same time. A multicellular organism is an aggregate of cells and an object at the same time.

Bottom line: the granular organization of reality and the cross-granular instantiation of different subclasses of MaterialEntity by actual particulars requires us to model these subclasses disjointly. This does not only apply to Object and ObjectAggregate, because the distinction between bona fide and fiat entities is also granularity-dependend, resulting in particulars which can be ObjectAggregates, Objects and FiatObjectParts at the same time (e.g. a cell is an ObjectAggregate at the sub-cellular granularity level, an Object at the cellular and a FiatObjectPart at the super-cellular granularity level).

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/583f7cfb-e3b6-4064-adf4-34a5eb2c6a69n%40googlegroups.com.

Virenfrei. www.avast.com

[Chris Mungall]

Does this mean certain BFO people will stop insisting on single inheritance?

Does this also mean that multiple inheritance will be *asserted*? While there is nothing wrong with inferred MI, asserted MI is usually considered a bad smell engineering-wise. More here: https://douroucouli.wordpress.com/2019/05/10/ontotip-single-inheritance-principle-considered-dangerous/

or perhaps the idea is to infer MI via an equivalence axiom on 'object aggregate', or a domain constraint on member-of?

My personal recommendation is that people do not assert anything more specific than 'material entity'. When ontologies try and get too clever and start cleaving the world on finer-grained more subject divisions like fiat vs bona-fide or aggregate vs whole it just confuses everyone. Represent these as properties if you must: https://github.com/BFO-ontology/BFO/issues/221

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/59f3d775-8399-bdc1-1250-83746f1db482%40googlemail.com.

[Anthony Petosa]

Object & Object Aggregate should be disjoint for the very reason Lars states. A (singular) object and a collection of singular objects are entirely separate universals, even if a singular Object particular appears to be the same particular in its ObjectAggregate context. With respect to granularity (a.k.a., ontological zooming), the scenario you present should be disambiguated across zoom levels. Using your example, a molecule is categorized as an Object Aggregate containing an exact plurality of atoms, which are categorized as Objects. At a finer grained ontological zoom, an atom is categorized as an Object Aggregate containing an exact plurality of subatomic particles, which are categorized as Objects.

Maybe BFO needs to offer a new relationship that expresses a trans-ontological relation across different levels of granularity. It is not that John Smith as a HumanBeing particular existing on 06/21/2021 @ 7:20 PM is not the very same John Smith as a HumanOrganSystemsContainer particular existing on 06/21/2021 @ 7:20 PM. Obviously, this John is that John. However, the semantic context is radically different. In the first case John Smith stands as a singular object; in the latter case he stands as a container of organ system singular objects. Yes, this extends downward with organ systems and their organ system parts, and so on, and so on, and so on...

An Object Aggregate does not require the members in its collection to be of the same Object type. BFO documentation offers, for instance, a symphony orchestra as an example of an Object Aggregate. Clearly, a symphony orchestra's membership consists of various Object types. If Object & Object Aggregate are not disjoint, then what is to prevent one from forming an equivalence between this particular Stradivari violin during last Tuesday evening's performance and the current incarnation of the Vienna Philharmonic symphonic orchestra's instrument collection during last Tuesday evening's performance? Let's not forget BFO is a formal ontology that can extend into untold material domain ontologies. If we play fast and loose and not assert disjointedness between Object & Object Aggregate, then it is highly likely that some ontology model importing models from different material domains will result in an Object / Object Aggregate conflation.

Personally, I believe one should not mix and match universals across different levels of granularity within the same ontology when creating models that intend to implement Ontological Realism principles. If some contextualized information requirement needs to equate John Smith the HumanBeing particular with John Smith the HumanOrganSystemsContainer, then let this occur separately as a rule, in application code, etc. Do not compromise an ontology's objectivity to meet a subject "concept."

[Chris Mungall]

Hi Anthony,

What you say makes sense philosophically, but I'm having issues translating this narrative description into either practical engineering requirements or some kind of formal logic system like OWL.

If JohnSmith has the same identifier/URI then there is no separate statement of equality to be implemented in application code or otherwise. So I am unsure as to how to work with your guidelines.

If we have a more advanced context-aware logic like IKL, then I see how we can make statements like `(that (type JohnSmith Aggregate) ContainerView)`, but no one uses IKL. Most of us use simpler systems with simple invariant class assertions, and I fear that naively following your guidelines will lead to incoherence as soon as we try and combine ontologies.

I really think BFO needs to pay more attention to engineering considerations, we have a lot of issues in OBO caused by naive attempts to implement BFO without understanding the limitations of OWL, leading to various incoherencies when ontologies are combined.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/a7e366bf-7073-445d-9dd7-25fa498179d5n%40googlegroups.com.

[Alan Ruttenberg]

I also choose to represent only at the level of material entity. However, there are some things you can do that land up inferring object aggregate. For example, if you have a material entity m that has member part p then m is inferred to be an object aggregate, and p is inferred to be an object.  Similarly if you have asserted m to be an object. I'm not sure there's a situation where one would have to assert multiple parents and would hope there isn't one. But if there is then it is worth discussion.

Lars' explanation captures the rationale behind not making the three subclasses of material entity disjoint. It was an argument I had with Barry for a long time and a rare case where I won the argument. Even though I choose not to use those classes explicitly, I recognize that *If* someone does choose to represent something as an object, we don't want to screw them by precluding a more detailed description  (e.g. that solid is made up of atoms) ruled out because of disjointness.

My understanding was that the original choice of fiat object part, object, object aggregate was in a framework in which 3 levels of granularity was sufficient. In biology we deal with more than 3, so something had to give.

Alan

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN9Aifuo0rkTpfVWTiuQrAB%3DPCRjnbcGzargN33_Aw93OMynzQ%40mail.gmail.com.

[Anthony Petosa]

I agree with your comment about BFO needing to pay more attention to engineering considerations, but it should do so without contradicting principles of Ontological Realism. After all, BFO was created to express sound ontolgoical principles and its OWL implementation was designed to carry this forward as best as possible using set-theoretic OWL grammar constructs. OWL has limitations, but I do not see the topic at hand as being a side-effect of OWL. One limitation of OWL is that its underlying RDF framework is built on two-tuples. Many ontological relations also include a temporal dimension. This can be modeled in OWL, just not directly between two RDF nodes that require both a temporal relationship and some other relationship concurrently.

JohnSmith will not have the same URI if you create two independent particulars - one that instantiates the owl:Object subclass (e.g., owl:HumanBeing) and a second that instantiates the owl:ObjectAggregate subclass (e.g., owl:Population), the latter which class extension as of last week has a single JohnSmith member.  Some people may equate these OWL Individuals, because, after all, John Smith is John Smith, right? They may conflate the populate of one with the person in their subjective "conceptualized" view.

Someone conflating owl:HumanBeing with owl:Population (of one) could have decided to create two JohnSmith OWL Individuals last week, instantiating one each of the aforementioned owl:Classes, after the Zombie horde ate its way through town. A reasoner would report a model inconsistency if you tried to assert an owl:sameAs relationship between the two JohnSmith OWL Individuals, assuming owl:Object & owl:ObjectAggregate were asserted to be disjoint. If you assert a single JohnSmith OWL Individual, then you must have asserted that this JohnSmith OWL Individual is both of the owl:Object subclass type and of the owl:ObjectAggregate subclass type. In this case, not only have you violated what it means to be a universal, with owl:Object and owl:ObjectAggregate not engaging in a disjointedness relationship, but you have also violated the monohierarchical inheritance principle when modeling domain taxonomies and instead asserted multiple inheritance in the model.

[Alan Ruttenberg]

On Tue, Jun 22, 2021 at 6:00 PM Anthony Petosa <petosa...@gmail.com> wrote:

I agree with your comment about BFO needing to pay more attention to engineering considerations, but it should do so without contradicting principles of Ontological Realism. After all, BFO was created to express sound ontolgoical principles and its OWL implementation was designed to carry this forward as best as possible using set-theoretic OWL grammar constructs. OWL has limitations, but I do not see the topic at hand as being a side-effect of OWL. One limitation of OWL is that its underlying RDF framework is built on two-tuples.

2-tuples?

Do you mean binary relations?

Many ontological relations also include a temporal dimension. This can be modeled in OWL, just not directly between two RDF nodes that require both a temporal relationship and some other relationship concurrently.

 

The BFO temporalized relations in OWL give some ability to do a bit of temporal reasoning in OWL. If you are using the OBO version you don't see them. If you use the BFO-2020 version you do. It still isn't full temporal reasoning but it is at least sound. More can be done if you are willing to express what you want to say in terms of history.

.

JohnSmith will not have the same URI if you create two independent particulars - one that instantiates the owl:Object subclass (e.g., owl:HumanBeing) and a second that instantiates the owl:ObjectAggregate subclass (e.g., owl:Population),

Don't do that. Yes it's possible, but it isn't the intended use. There are a variety of cases where we can't constrain the OWL to disallow unintended interpretations because the normative expression of BFO is in first order logic and OWL is less powerful. It's the compromise you make to get the benefits of OWL's reasoning guarantees.

the latter which class extension as of last week has a single JohnSmith member.  Some people may equate these OWL Individuals, because, after all, John Smith is John Smith, right?

Wrong. Equating means they are the same at all times. An object aggregate is allowed to have one member only temporarily. There has to be some time when there are two members. So it doesn't work for the case of an object and object aggregate where one of the aggregate members is the object. I don't think that that constraint can be expressed in OWL.

 

They may conflate the populate of one with the person in their subjective "conceptualized" view.

Good people do bad things. If there was a mistake to be had it would be thinking that a "conceptualized" view was consistent with how we build BFO-based ontologies.

Someone conflating owl:HumanBeing with owl:Population (of one) could have decided to create two JohnSmith OWL Individuals last week, instantiating one each of the aforementioned owl:Classes, after the Zombie horde ate its way through town. A reasoner would report a model inconsistency if you tried to assert an owl:sameAs relationship between the two JohnSmith OWL Individuals, assuming owl:Object & owl:ObjectAggregate were asserted to be disjoint.

But they are not. 

I'm not sure what the definition of population says about a population of one, but I would hope it has the same constraint as object aggregate.

If you assert a single JohnSmith OWL Individual, then you must have asserted that this JohnSmith OWL Individual is both of the owl:Object subclass type and of the owl:ObjectAggregate subclass type.

No you don't. It can be inferred by asserting a  member relationship.

In this case, not only have you violated what it means to be a universal,

Do you know any formal expression of what it means to be a universal? I don't. I just have some rough ideas that can be helpful in certain situations. On the one hand there are cases where natural kinds make sense and there are cases on the other side where we are grouping in a class things that definitely aren't a natural kind. Like the class of people who have visited at some time the Statue of Liberty. In between is a gray area.

with owl:Object and owl:ObjectAggregate not engaging in a disjointedness relationship, but you have also violated the monohierarchical inheritance principle when modeling domain taxonomies and instead asserted multiple inheritance in the model.

 

I'm so ashamed. Well, maybe just so-so ashamed because the statement about multiple inheritance is incorrect. Incidentally the constraint is on class expressions. Barry has said there isn't a problem with asserting multiple types of an instance.

Look. Early BFO made a bad call on these terms by trying to have an avoid-the-issue way of dealing with granularity. It turned out to be a bad bet and so it  needed to be fixed. For a while Barry tried to argue that the object aggregate of molecules was not the same entity as the macroscopic object. That didn't fly because it violated the "no duplicative relationship" principle, which is an important one. The two choices were to either deprecate the classes or relax the disjointness. Since some people used object and object aggregate in reasonable ways, it seemed better to keep them, but remove the axiom that made them unsuitable for use in science where we need more than 3 levels of granularity.

In the ideal case we will have, in the future, a proper way to deal with multiple levels of granularity in BFO.

Often times I think that the way to go is with more perspectives. Continuants and occurrents were understood as perspectives, The way we do things now we  would add another perspective by creating a sibling to continuant and occurrent, removing the covering axiom on entity. I've been thinking that fields belong in one and the state space perspective belongs in another.

On Monday, June 21, 2021 at 10:34:23 PM UTC-4 Chris Mungall wrote:

Hi Anthony,

What you say makes sense philosophically, but I'm having issues translating this narrative description into either practical engineering requirements or some kind of formal logic system like OWL.

If JohnSmith has the same identifier/URI then there is no separate statement of equality to be implemented in application code or otherwise. So I am unsure as to how to work with your guidelines.

If we have a more advanced context-aware logic like IKL, then I see how we can make statements like `(that (type JohnSmith Aggregate) ContainerView)`, but no one uses IKL. Most of us use simpler systems with simple invariant class assertions, and I fear that naively following your guidelines will lead to incoherence as soon as we try and combine ontologies.

I really think BFO needs to pay more attention to engineering considerations, we have a lot of issues in OBO caused by naive attempts to implement BFO without understanding the limitations of OWL, leading to various incoherencies when ontologies are combined.

 

BFO doesn't pay attention to anything. This BFO developer definitely does attend to engineering considerations. Regarding mistakes in understanding the limitations of OWL: trying to account for people who don't know the rules is a losing battle. It's easier to correct their misunderstanding or to tell them to go read the spec. That said, I *am* interested in knowing about these sorts of cases. Do you have something about these cases I should read?

On Mon, Jun 21, 2021 at 4:52 PM Anthony Petosa <petosa...@gmail.com> wrote:

Object & Object Aggregate should be disjoint for the very reason Lars states. A (singular) object and a collection of singular objects are entirely separate universals, even if a singular Object particular appears to be the same particular in its ObjectAggregate context. With respect to granularity (a.k.a., ontological zooming), the scenario you present should be disambiguated across zoom levels. Using your example, a molecule is categorized as an Object Aggregate containing an exact plurality of atoms, which are categorized as Objects. At a finer grained ontological zoom, an atom is categorized as an Object Aggregate containing an exact plurality of subatomic particles, which are categorized as Objects.

I'm confused here. You say that they should be disjoint at the beginning, but at the end your (reasonable) statements require the opposite.

Maybe BFO needs to offer a new relationship that expresses a trans-ontological relation across different levels of granularity.

Unfortunately the current framework we use isn't one in which there are multiple ontologies and trans-ontological relations. In the original conception of BFO it was that way, and it still can be useful to think in those terms. Maybe we can even make something like that work in practice. But I don't know how to do that at the moment.

There is, in OBI, a different attempt to bridge granularities with the 'has grain' relationship, inspired by Alan Rector's work.

It is not that John Smith as a HumanBeing particular existing on 06/21/2021 @ 7:20 PM is not the very same John Smith as a HumanOrganSystemsContainer particular existing on 06/21/2021 @ 7:20 PM. Obviously, this John is that John. However, the semantic context is radically different. In the first case John Smith stands as a singular object; in the latter case he stands as a container of organ system singular objects. Yes, this extends downward with organ systems and their organ system parts, and so on, and so on, and so on...

 

You can say that the "semantic context" is different, or you can understand that organisms are rich/complicated and so there are a lot of things that are reasonable to say of them. I don't know what a "semantic context" is, so I go with the view that things are rich/complicated.

An Object Aggregate does not require the members in its collection to be of the same Object type. BFO documentation offers, for instance, a symphony orchestra as an example of an Object Aggregate. Clearly, a symphony orchestra's membership consists of various Object types. If Object & Object Aggregate are not disjoint, then what is to prevent one from forming an equivalence between this particular Stradivari violin during last Tuesday evening's performance and the current incarnation of the Vienna Philharmonic symphonic orchestra's instrument collection during last Tuesday evening's performance?

It's prevented because we don't have time-slices of continuants, which is what you are doing when you talk about  when you say "this particular Stradivari violin during last Tuesday evening'"

Let's not forget BFO is a formal ontology that can extend into untold material domain ontologies.

Noted :-/

If we play fast and loose and not assert disjointedness between Object & Object Aggregate, then it is highly likely that some ontology model importing models from different material domains will result in an Object / Object Aggregate conflation.

 

Let's deal with it when it happens. The standard for deciding there's a problem isn't just observing what you consider a conflation. It's finding a case where a representation is responsible for inferring something that's wrong. Do you have any specific cases of that happening in mind?

Personally, I believe one should not mix and match universals across different levels of granularity within the same ontology when creating models that intend to implement Ontological Realism principles.

That's a reasonable point of view if you can show us a way to represent and reason with the scientific facts we need to represent and work with. Do you have an alternative system we can try this out on?

If some contextualized information requirement needs to equate John Smith the HumanBeing particular with John Smith the HumanOrganSystemsContainer, then let this occur separately as a rule, in application code, etc. Do not compromise an ontology's objectivity to meet a subject "concept."

Ok, so I also think there are things that should be handled this way. For instance, we don't believe in possible worlds, but it can be useful to use modal reasoning as part of solving some problem. But I don't see a way to do that in the cases you are discussing and I honestly don't see the need. We recognize that a person is a macroscopic object at the same time we acknowledge that it is made up of itsy bitsy parts. And realistically, we've got bigger fish to fry. Have a look across the OBO ontologies and make a judgement about whether they all make representations in a way that they can be worked on together productively. I don't think you'll find the problem to be that people are conflating object and object aggregate.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/1eb3c9d3-4f35-41ca-abdb-9b9b5f72cf57n%40googlegroups.com.

[Anthony Petosa]

>> One limitation of OWL is that its underlying RDF framework is built on two-tuples.

> 2-tuples?

> Do you mean binary relations?

Yes.

>>  The BFO temporalized relations in OWL give some ability to do a bit of temporal reasoning in OWL. If you are using the OBO version you don't see them.

>> If you use the BFO-2020 version you do.

Here are links I located for BFO, RO & IAO.

• BFO: BFO (classes only)
• RO: Relation Ontology (I grabbed 'ro.owl', 'ro/core.owl' & 'ro/ro-base.owl')
• IAO: Information Artifact Ontology

What I have not found after all these years, is a canonical BFO OWL model that includes all the entities defined in the BFO documentation to include all the Continuants and its subtypes, all the Occurrents and its subtypes and ALL the relations. Not having the BFO-documented relations in the BFO OWL model is highly frustrating. RO has some of the relations and others not specified in the BFO documentation, but I read somewhere that RO relations are being phased out, which is why they were removed from the BFO OWL model. IAO adds its own collection of relations, which is perfectly fine and expected. However, some fundamental BFO relations like s-depends_on, g-depends_on and the several s-dependence relations are missing. The BFO documentation defines these relations and provides their domain and range values.

Why, after all these years, do we not have a true canonical BFO OWL model aligned with the BFO documentation? I realize the BFO documentation speculates on some relations and excluding them from a canonical BFO OWL model is understandable. Yet, why should the community have to rely upon some combination of OWL models to get a rough approximation of BFO? If the BFO OWL model were complete, then we would not need the RO OWL model. The IAO model would simply import the BFO OWL model in its totality and extend it off of Generically Dependent Continuant. Isn't this the whole point of having a formal ontology?

> JohnSmith will not have the same URI if you create two independent particulars - one that instantiates the owl:Object subclass (e.g., owl:HumanBeing) and a second that instantiates the owl:ObjectAggregate subclass (e.g., owl:Population),

>> Don't do that. Yes it's possible, but it isn't the intended use. There are a variety of cases where we can't constrain the OWL to disallow unintended interpretations because the normative

>> expression of BFO is in first order logic and OWL is less powerful. It's the compromise you make to get the benefits of OWL's reasoning guarantees.

What exactly is not the intended use? Why should I not create two independent particulars where each clearly instantiates its respective universal and where each universal is represented by its OWL natural class form? Even though BFO does not assert a disjointedness relation between Object & Object Aggregate, obviously an Object instance is not the same thing as an Object Aggregate instance, even when an Object Aggregate's class membership at time 't' holds a single member of type Object. Are you suggesting it makes sense to type the 'JohnSmith' instance both as Object & Object Aggregate? If so, then you are conflating the Object & Object Aggregate types. A single 'thing' of type 'A' is not identical to a collection of 'things', in this case each of type 'A', even when the collection of 'things' holds a single member of type A at time 't'. A collection is about membership, each item collected is about a single 'thing'.

Using this simple 'JohnSmith' scenario, can you offer an example of amongst the "variety of cases where we can't constrain the OWL to disallow unintended interpretations because the normative expression of BFO is in first order logic"? Can you illustrate how OWL's Description Logics, subsets of First Order Logic, allow for these "unintended interpretations"? I venture most people using OWL, especially those who need to apply it practically, primarily are interested in the decidable & tractable (at least in terms of taxonomic complexity) OWL species: OWL-DL; OWL-EL; OWL-QL; OWL-RL.

> the latter which class extension as of last week has a single JohnSmith member.  Some people may equate these OWL Individuals, because, after all, John Smith

> is John Smith, right?

>> Wrong. Equating means they are the same at all times. An object aggregate is allowed to have one member only temporarily. There has to be some time when

>> there are two members. So it doesn't work for the case of an object and object aggregate where one of the aggregate members is the object. I don't think that

>> that constraint can be expressed in OWL.

(In another post, I would like to address allowing an Object Aggregate temporarily to have a single member.) Yes, equating at the instance level using owl:sameAs means the two instances are the same at all times (in fact, one is an alias of the other), and without Object & Object Aggregate being disjoint, it is possible for someone to ignore disjointedness in their subclasses, create instances for each along the two Object & Object Aggregate subclass lines and then assert an owl:sameAs relation between the two instances. Someone might consider this a reasonable approach, since BFO does not enforce an Object / Object Aggregate disjointedness relation. That person may surmise that the particular derived from an Object subclass is identical to a second particular deriving from an Object Aggregate class which class membership happens to hold only particulars from the Object subclass' class extension. Given this assumption, that person may be convinced that at time 't', when the Object Aggregate subclass class extension loses all but one member and that one member is of the aforementioned type, that the two particulars are identical and should be asserted as such using owl:sameAs.

Unless the modeler asserts a disjointedness relation between some Object subclass & some Object Aggregate subclass that is its sibling node, then a reasoning engine will not report a consistency error for particulars asserted at or below those sibling subclasses. This is perfectly fine for OWL, because although it is the Web Ontology Language, it has nothing to do with Ontological Realism and everything to do with Formal Logic.

> Good people do bad things. If there was a mistake to be had it would be thinking that a "conceptualized" view was consistent with how we build BFO-based ontologies.

You make my point. Again, kindly show me an example with reference to your comment on "unintended interpretations".

>> Someone conflating owl:HumanBeing with owl:Population (of one) could have decided to create two JohnSmith OWL Individuals last week, instantiating one each of the

>> aforementioned owl:Classes, after the Zombie horde ate its way through town. A reasoner would report a model inconsistency if you tried to assert an owl:sameAs relationship

>> between the two JohnSmith OWL Individuals, assuming owl:Object & owl:ObjectAggregate were asserted to be disjoint.

> But they are not. 

> I'm not sure what the definition of population says about a population of one, but I would hope it has the same constraint as object aggregate.

You have no way of knowing if someone decides to model that assertion or, more likely, someone asserts the hypothetical 'JohnSmith' particular to be of two types as mentioned previously.

>> If you assert a single JohnSmith OWL Individual, then you must have asserted that this JohnSmith OWL Individual is both of the owl:Object subclass type and of the

>> owl:ObjectAggregate subclass type.

> No you don't. It can be inferred by asserting a  member relationship.

Let's explore this. I want to make certain I understand your comment. What follows is a Turtle serialization of a very simple OWL model created in Protege, representing the 'JohnSmith' scenario.

@prefix :      <urn:com:example:2021:06:23:test:johnsmith#> .

@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix owl:   <http://www.w3.org/2002/07/owl#> .

@prefix xml:   <http://www.w3.org/XML/1998/namespace> .

@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .

@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .

<urn:com:example:2021:06:23:test:johnsmith>

        a       owl:Ontology .

:ObjectAggregate  a  owl:Class .

:Object  a      owl:Class .

:JohnSmith  a   :Object , owl:NamedIndividual .

:member_part_of  a   owl:ObjectProperty ;

        rdfs:domain  :Object ;

        rdfs:range   :ObjectAggregate .

As you can see, I did not assert a disjointedness relation between Object & Object Aggregate. If I understood your comment correctly, then when running a Pellet reasoner, for instance, it should return a result that infers 'JohnSmith' is a member of Object Aggregate. I ran the reasoner and that inference was not made. I have all the 'Displayed inferences' options checked in the 'Reasoner' preferences in Protege as follows:

Class inferences: satisfiability; equivalent classes; superclasses; class instances; disjoint classes

Object property inferences: satisfiability; domains; ranges; equivalent properties; super properties; inverse properties

Data property inferences: domains; equivalent properties; super properties

Individual inferences: types; object property assertions; data property assertions; same individuals

>> In this case, not only have you violated what it means to be a universal,

> Do you know any formal expression of what it means to be a universal? I don't. I just have some rough ideas that can be helpful in certain situations. On the one hand there are cases

> where natural kinds make sense and there are cases on the other side where we are grouping in a class things that definitely aren't a natural kind. Like the class of people who

> have visited at some time the Statue of Liberty. In between is a gray area.

No, but I understand what it means ontologically based upon Barry Smith's work. Also, you are implying that not having a Formal Logic statement for 'universal' justifies not asserting disjointedness between BFO OWL sibling nodes? I get your grouping point, but it only demonstrates that people take convenient shortcuts in OWL, replacing universal representations with ad-hoc defined classes, simply (a) to satisfy some contextualized view of the domain and/or (b) to make application-level implementations "easier". This happens ALL the time, but I am of the opinion that ad-hoc defined classes should not be expressed in OWL models that are supposed to represent a domain accurately. Create separate RDF-based graph models, OWL or otherwise, for this purpose, but do not use them to federate across domain-specific OWL models and certainly not to reason over them. To me, defined classes are analogous in principle to relational data model tables haphazardly populated with with all sorts of fields that are unrelated to the entity the table allegedly represents. Obviously, the grammars are different, but the idea of ad hoc data structures devoid of ontological forethought is highly common.

Here is a a quote from "Building Ontologies With Basic Formal Ontology" (Arp, Smith, Spear, 2015, Massachusetts Institute of Technology, p.155):

"In the preceding chapters we have distinguished universals (such as person and role), whose instances are entities in their own right, from defined classes, which we can think of as devices to capture certain ways of speaking about reality (as, when we speak of lawyers or students, we are in fact speaking merely of persons with special roles). In the worldview of RDF and OWL, now, universals and defined classes are in effect run together under the single heading of 'classes', and (binary) relations are referred to as 'properties'. (OWL does share with BFO the use of 'instances'; it uses this term to refer to the individuals that are the members of classes as it conceives them.) OWL is in this respect close to a traditional set-theoretic view of reality; however, because it allows for there to be two classes with the same members, OWL classes are in fact intensional."

Even with the common ontological object/role conflation, which can easily be resolved in OWL, there are endless OWL models where the modeler lazily asserted expressions like this (in Turtle notation):

:Lawyer a owl:Class .

:Student a owl:Class .

:Person a owl:Class .

:Lawyer rdfs:subClassOf :Person .

:Student rdfs:subClassOf :Person .

...and, yes, there are defined classes built upon either conjunctive or disjunctive forms of two or more OWL classes where, taken separately, each of the two or more OWL classes are natural class representations of their associated universals. As the text states, there are practical reasons for these logical forms, as in performing clinical research (p.19). However, defined classes, even those that logically combine natural classes, have no place in a domain ontology in my opinion. The hope of ever federating ontologically vetted OWL domain models to preserve the meaning of their associated universals and their inter-relationships, not to mention reasoning over them and without non-sensical results, flies out the window once defined classes are introduced. The real work required is in establishing the proper ontological relationships in the model, but most skip this critical step. I believe part of the reason this occurs is due to the lack of a fully formed BFO OWL model.

>> with owl:Object and owl:ObjectAggregate not engaging in a disjointedness relationship, but you have also violated the monohierarchical inheritance principle when modeling domain

>> taxonomies and instead asserted multiple inheritance in the model.

> I'm so ashamed. Well, maybe just so-so ashamed because the statement about multiple inheritance is incorrect. Incidentally the constraint is on class expressions. Barry has said

> there isn't a problem with asserting multiple types of an instance.

Smile... I'm glad to see you have a sense of humor. It helps. I would love to hear Barry's multiple inheritance guidance in this thread. I thought he said multiple inheritance is okay if instances are inferred, but not asserted, to be of more than one type. Frankly, I am queasy about that, too, but okay. Asserting multiple inheritance on an instance? Why? Assuming we follow the BFO taxonomy, clearly an Object instance is different than a Role instance. A Material instance is not the same as an Immaterial instance. A Process instance is not the same as a Temporal Region instance. In the BFO taxonomy what justification exactly is there to assign an instance to more than one type within the taxonomy?

I do remember an interesting discussion about metamorphosis and how an instance may change its type over time. I'll have to revisit it. However, even in this case, the instance would only be asserted to have instantiated a single type for some temporal duration. That would not be interpreted as "multiple inheritance", where two or more type assignments occur concurrently within the same temporal period.

> Look. Early BFO made a bad call on these terms by trying to have an avoid-the-issue way of dealing with granularity. It turned out to be a bad bet and so it  needed to be fixed. For a

> while Barry tried to argue that the object aggregate of molecules was not the same entity as the macroscopic object. That didn't fly because it violated the "no duplicative relationship" 

> principle, which is an important one.

"No duplicative relationship"? Sorry, I'm unfamiliar with that one. Can you elaborate?

> The two choices were to either deprecate the classes or relax the disjointness. Since some people used object and object aggregate in reasonable ways, it seemed better to keep

> them, but remove the axiom that made them unsuitable for use in science where we need more than 3 levels of granularity.

After relaxing disjointedness, can you give us an example of how specifically Object and Object Aggregate were used in a reasonable way in the manner to which you refer?

> In the ideal case we will have, in the future, a proper way to deal with multiple levels of granularity in BFO.

Looking forward to it.

> Often times I think that the way to go is with more perspectives. Continuants and occurrents were understood as perspectives, The way we do things now we  would add another

> perspective by creating a sibling to continuant and occurrent, removing the covering axiom on entity. I've been thinking that fields belong in one and the state space perspective

> belongs in another.

Could granularity be one of those perspectives?

[Alan Ruttenberg]

On Wed, Jun 23, 2021 at 7:16 PM Anthony Petosa <petosa...@gmail.com> wrote:

>> One limitation of OWL is that its underlying RDF framework is built on two-tuples.

> 2-tuples?

> Do you mean binary relations?

Yes.

>>  The BFO temporalized relations in OWL give some ability to do a bit of temporal reasoning in OWL. If you are using the OBO version you don't see them.

>> If you use the BFO-2020 version you do.

Here are links I located for BFO, RO & IAO.

• BFO: BFO (classes only)
• RO: Relation Ontology (I grabbed 'ro.owl', 'ro/core.owl' & 'ro/ro-base.owl')
• IAO: Information Artifact Ontology

BFO classes only is a version of BFO 2 that OBO is using.

BFO-2020 is the version that is part of the ISO standard. It contains all relations and classes and in the OWL file all the definitions in the ISO standard. Note that there are outstanding issues in the issue tracker. You can report new bugs there. Note that the specification says that any OWL axiom that can be proved from the FOL is considered part of the OWL, however not all provable OWL assertions are in the OWL because I don't know how to create the best OWL approximation of a FOL theory. It's not even sure there is a unique such set of assertions. There is a literature that addresses this problem called theory approximation.

RO is not BFO

There is not currently a version of IAO based on BFO-2020.

<snip further remarks on there not being a complete version of BFO>

> JohnSmith will not have the same URI if you create two independent particulars - one that instantiates the owl:Object subclass (e.g., owl:HumanBeing) and a second that instantiates the owl:ObjectAggregate subclass (e.g., owl:Population),

>> Don't do that. Yes it's possible, but it isn't the intended use. There are a variety of cases where we can't constrain the OWL to disallow unintended interpretations because the normative

>> expression of BFO is in first order logic and OWL is less powerful. It's the compromise you make to get the benefits of OWL's reasoning guarantees.

 

What exactly is not the intended use? Why should I not create two independent particulars where each clearly instantiates its respective universal and where each universal is represented by its OWL natural class form?

Because the entities would be duplicative.

The not intended use is to have two instances with one being an aggregate of one member and the other the member. The intended use is to be able to say things at different granularities.

Even though BFO does not assert a disjointedness relation between Object & Object Aggregate, obviously an Object instance is not the same thing as an Object Aggregate instance, even when an Object Aggregate's class membership at time 't' holds a single member of type Object.

Not obviously. You keep saying this. I explained the situation regarding granularity in my previous email.

Are you suggesting it makes sense to type the 'JohnSmith' instance both as Object & Object Aggregate?

Yes

If so, then you are conflating the Object & Object Aggregate types.

I am not. Reread my last email about granularity.

A single 'thing' of type 'A' is not identical to a collection of 'things', in this case each of type 'A', even when the collection of 'things' holds a single member of type A at time 't'. A collection is about membership, each item collected is about a single 'thing'.

 

Me and the collection of atoms, molecules, sites that I'm made of are the same thing. All those things are parts of me, and there are no parts of me that aren't sums of those. 

Using this simple 'JohnSmith' scenario, can you offer an example of amongst the "variety of cases where we can't constrain the OWL to disallow unintended interpretations because the normative expression of BFO is in first order logic"?

I will give you a simple example with RDF and OWL. OWL offers ways to say that two IRIs refer to the same individual. The representation of that in RDF is <a> owl:sameAs <b>. It also offers a way to declare two IRIs refer to different things. The presentation in RDF is <a> owl:differentFrom <b>. Suppose you add both these triples. Under the OWL semantics the resultant ontology document would be inconsistent. However, the same two triples are not inconsistent using the RDF semantics. Generalizing, if you try to say the same thing in a stronger logic and a weaker logic, for some assertions the weaker logic can't detect some inconsistencies that are found using the stronger logic.

 

Can you illustrate how OWL's Description Logics, subsets of First Order Logic, allow for these "unintended interpretations"?

An example would be the axiom that says for any object aggregate there is some time when it has 2 members. As you correctly point out, OWL only has binary relationships, but time indexed relations need 3 arguments. So you can't even state such axioms in OWL in a way that has the necessary logical force.

I venture most people using OWL, especially those who need to apply it practically, primarily are interested in the decidable & tractable (at least in terms of taxonomic complexity) OWL species: OWL-DL; OWL-EL; OWL-QL; OWL-RL.

That is true. And?

> the latter which class extension as of last week has a single JohnSmith member.  Some people may equate these OWL Individuals, because, after all, John Smith

> is John Smith, right?

>> Wrong. Equating means they are the same at all times. An object aggregate is allowed to have one member only temporarily. There has to be some time when

>> there are two members. So it doesn't work for the case of an object and object aggregate where one of the aggregate members is the object. I don't think that

>> that constraint can be expressed in OWL.

 

(In another post, I would like to address allowing an Object Aggregate temporarily to have a single member.) Yes, equating at the instance level using owl:sameAs means the two instances are the same at all times (in fact, one is an alias of the other), and without Object & Object Aggregate being disjoint, it is possible for someone to ignore disjointedness in their subclasses, create instances for each along the two Object & Object Aggregate subclass lines and then assert an owl:sameAs relation between the two instances. Someone might consider this a reasonable approach, since BFO does not enforce an Object / Object Aggregate disjointedness relation.

I'm not someone who considers that a reasonable approach. If there are sameAs then we are talking about a single entity. I don't see the point of having two instances in the same ontology that are then equated. What sameAs is used for is dealing with the situation in instances of distinct ontologies actually represent the same thing. In that case one has a mechanism for fixing it in sameAs.

That person may surmise that the particular derived from an Object subclass is identical to a second particular deriving from an Object Aggregate class which class membership happens to hold only particulars from the Object subclass' class extension. Given this assumption, that person may be convinced that at time 't', when the Object Aggregate subclass class extension loses all but one member and that one member is of the aforementioned type, that the two particulars are identical and should be asserted as such using owl:sameAs.

I can't address all the cases where people surmise the wrong thing. We do the best we can at documentation (given resources) and if this sort of thing comes across our screen then we can try to help the person understand why there's a problem. But unless I am trying to debug someone's understanding of OWL, I don't pay attention to anything they say that depends on their mistake.

Unless the modeler asserts a disjointedness relation between some Object subclass & some Object Aggregate subclass that is its sibling node, then a reasoning engine will not report a consistency error for particulars asserted at or below those sibling subclasses. This is perfectly fine for OWL, because although it is the Web Ontology Language, it has nothing to do with Ontological Realism and everything to do with Formal Logic.

And?

But you are wrong if you are blaming OWL for this.

> Good people do bad things. If there was a mistake to be had it would be thinking that a "conceptualized" view was consistent with how we build BFO-based ontologies.

You make my point. Again, kindly show me an example with reference to your comment on "unintended interpretations".

You gave the example: equating a person to an object aggregate one of whom's members is the person.

In that example two things are illustrated, One is not using the terms in the intended way and the other  that OWL isn't expressive enough to recognize that an object aggregate that forever has a single member is inconsistent.

>> Someone conflating owl:HumanBeing with owl:Population (of one) could have decided to create two JohnSmith OWL Individuals last week, instantiating one each of the

>> aforementioned owl:Classes, after the Zombie horde ate its way through town. A reasoner would report a model inconsistency if you tried to assert an owl:sameAs relationship

>> between the two JohnSmith OWL Individuals, assuming owl:Object & owl:ObjectAggregate were asserted to be disjoint.

> But they are not. 

> I'm not sure what the definition of population says about a population of one, but I would hope it has the same constraint as object aggregate.

You have no way of knowing if someone decides to model that assertion or, more likely, someone asserts the hypothetical 'JohnSmith' particular to be of two types as mentioned previously.

>> If you assert a single JohnSmith OWL Individual, then you must have asserted that this JohnSmith OWL Individual is both of the owl:Object subclass type and of the

>> owl:ObjectAggregate subclass type.

> No you don't. It can be inferred by asserting a  member relationship.

 

Let's explore this. I want to make certain I understand your comment. What follows is a Turtle serialization of a very simple OWL model created in Protege, representing the 'JohnSmith' scenario.

@prefix :      <urn:com:example:2021:06:23:test:johnsmith#> .

@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix owl:   <http://www.w3.org/2002/07/owl#> .

@prefix xml:   <http://www.w3.org/XML/1998/namespace> .

@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .

@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .

<urn:com:example:2021:06:23:test:johnsmith>

        a       owl:Ontology .

:ObjectAggregate  a  owl:Class .

:Object  a      owl:Class .

:JohnSmith  a   :Object , owl:NamedIndividual .

:member_part_of  a   owl:ObjectProperty ;

        rdfs:domain  :Object ;

        rdfs:range   :ObjectAggregate .

You are missing the necessary assertion. Suppose you say <molecule> member_part_of John. Based on that it is entailed that John is an object aggregate.

Or, if you made a class  Object that has_member_part some thing.

<snip the rest of the text based on the example that didn't have the relevant assertion>

>> In this case, not only have you violated what it means to be a universal,

> Do you know any formal expression of what it means to be a universal? I don't. I just have some rough ideas that can be helpful in certain situations. On the one hand there are cases

> where natural kinds make sense and there are cases on the other side where we are grouping in a class things that definitely aren't a natural kind. Like the class of people who

> have visited at some time the Statue of Liberty. In between is a gray area.

 

No, but I understand what it means ontologically based upon Barry Smith's work. Also, you are implying that not having a Formal Logic statement for 'universal' justifies not asserting disjointedness between BFO OWL sibling nodes?

The non-disjointness of the sibs stands on its own. I've explained the justification.

My comment was directed to your phrase "violated what it means to be a universal,". I don't understand how you could come to that conclusion unless you had a clear idea of how to decide whether something is a universal or not. So I asked you to tell me how you came to that conclusion, a conclusion that hinges on knowing what a universal is and isn't. I explained why *I* can't make that judgement in many cases.

I get your grouping point, but it only demonstrates that people take convenient shortcuts in OWL, replacing universal representations with ad-hoc defined classes, simply (a) to satisfy some contextualized view of the domain and/or (b) to make application-level implementations "easier". This happens ALL the time, but I am of the opinion that ad-hoc defined classes should not be expressed in OWL models that are supposed to represent a domain accurately

I'm sorry, I can't see anything in the last paragraph that rings true.

 

. Create separate RDF-based graph models, OWL or otherwise, for this purpose, but do not use them to federate across domain-specific OWL models and certainly not to reason over them. To me, defined classes are analogous in principle to relational data model tables haphazardly populated with with all sorts of fields that are unrelated to the entity the table allegedly represents. Obviously, the grammars are different, but the idea of ad hoc data structures devoid of ontological forethought is highly common.

 

I don't see how the situation with typical relational databases is relevant to what we are discussing.

Here is a a quote from "Building Ontologies With Basic Formal Ontology" (Arp, Smith, Spear, 2015, Massachusetts Institute of Technology, p.155):

"In the preceding chapters we have distinguished universals (such as person and role), whose instances are entities in their own right, from defined classes, which we can think of as devices to capture certain ways of speaking about reality (as, when we speak of lawyers or students, we are in fact speaking merely of persons with special roles). In the worldview of RDF and OWL, now, universals and defined classes are in effect run together under the single heading of 'classes', and (binary) relations are referred to as 'properties'. (OWL does share with BFO the use of 'instances'; it uses this term to refer to the individuals that are the members of classes as it conceives them.) OWL is in this respect close to a traditional set-theoretic view of reality; however, because it allows for there to be two classes with the same members, OWL classes are in fact intensional."

This doesn't give a definition of universal. I can agree that the conflation can happen based on the fact that I judge some of those classes as universals and other of them defined classes. But I still don't know in many cases which is which. Also, there's a problem with that quote and I've raised it many times with Barry. OWL is not an ontology. OWL takes no philosophical position. OWL doesn't have a view of reality, set-theoretic or not.  It's what people say using OWL that brings these in.

OWL is a tool. A useful tool. But the people who designed OWL are not in the same business as we are.

Even with the common ontological object/role conflation, which can easily be resolved in OWL, there are endless OWL models where the modeler lazily asserted expressions like this (in Turtle notation):

:Lawyer a owl:Class .

:Student a owl:Class .

:Person a owl:Class .

:Lawyer rdfs:subClassOf :Person .

:Student rdfs:subClassOf :Person .

Not sure what to say about this. I'm not really interested in the lazy modeler.

...and, yes, there are defined classes built upon either conjunctive or disjunctive forms of two or more OWL classes where, taken separately, each of the two or more OWL classes are natural class representations of their associated universals. As the text states, there are practical reasons for these logical forms, as in performing clinical research (p.19). However, defined classes, even those that logically combine natural classes, have no place in a domain ontology in my opinion.

Well, we'll simply have to disagree on that. Any universal or defined class of which something true and useful can be said has a legitimate right to be part of an ontology I build.  You're saying that a clinical ontology can't include a class that is relevant for representing some aspect of a clinical trial. I think that's wrong.

 

The hope of ever federating ontologically vetted OWL domain models to preserve the meaning of their associated universals and their inter-relationships, not to mention reasoning over them and without non-sensical results, flies out the window once defined classes are introduced.

You are going to have to justify that statement, because see no evidence for it. I'm not sure I even understand what you are saying.

The real work required is in establishing the proper ontological relationships in the model, but most skip this critical step. I believe part of the reason this occurs is due to the lack of a fully formed BFO OWL model.

BFO-2020

>> with owl:Object and owl:ObjectAggregate not engaging in a disjointedness relationship, but you have also violated the monohierarchical inheritance principle when modeling domain

>> taxonomies and instead asserted multiple inheritance in the model.

 

> I'm so ashamed. Well, maybe just so-so ashamed because the statement about multiple inheritance is incorrect. Incidentally the constraint is on class expressions. Barry has said

> there isn't a problem with asserting multiple types of an instance.

Smile... I'm glad to see you have a sense of humor. It helps. I would love to hear Barry's multiple inheritance guidance in this thread. I thought he said multiple inheritance is okay if instances are inferred, but not asserted, to be of more than one type. Frankly, I am queasy about that, too, but okay. Asserting multiple inheritance on an instance?

One never asserts multiple inheritance. Multiple inheritance is a consequence of some assertions.

We do talk of mono and poly-hierarchies.  In any case, Inheritance is a computer science sort of term, not an ontological one.

We aim to assert mono-hierarchies, but allow polyhierarchy that occurs as a result of reasoning.

 

Why? Assuming we follow the BFO taxonomy, clearly an Object instance is different than a Role instance.

Yup. That's because Object and Role are disjoint.

A Material instance is not the same as an Immaterial instance.

Yup. Those two are also disjoint.

A Process instance is not the same as a Temporal Region instance.

Yup.  Those two are also disjoint.

In the BFO taxonomy what justification exactly is there to assign an instance to more than one type within the taxonomy?

I don't know. Just passing along the info.

I do remember an interesting discussion about metamorphosis and how an instance may change its type over time.

That's bread and butter BFO. http://hl7-watch.blogspot.com/2008/02/weight-of-baby.html

That's also the interpretation of temperature. Unfortunately it's not so easy to work with types in this way. We've talked about how we might handle that but don't have a solution yet.

I'll have to revisit it. However, even in this case, the instance would only be asserted to have instantiated a single type for some temporal duration. That would not be interpreted as "multiple inheritance", where two or more type assignments occur concurrently within the same temporal period.

 

> Look. Early BFO made a bad call on these terms by trying to have an avoid-the-issue way of dealing with granularity. It turned out to be a bad bet and so it  needed to be fixed. For a

> while Barry tried to argue that the object aggregate of molecules was not the same entity as the macroscopic object. That didn't fly because it violated the "no duplicative relationship" 

> principle, which is an important one.

"No duplicative relationship"? Sorry, I'm unfamiliar with that one. Can you elaborate?

Sorry I miswrote. Duplicative entities.

It is commonly illustrated using the statue / clay example. BFO doesn't say there are two material entities, the statue and the clay it is made of. It says there's one material entity and during the period in which it is a statue it has a certain shape quality.

> The two choices were to either deprecate the classes or relax the disjointness. Since some people used object and object aggregate in reasonable ways, it seemed better to keep

> them, but remove the axiom that made them unsuitable for use in science where we need more than 3 levels of granularity.

After relaxing disjointedness, can you give us an example of how specifically Object and Object Aggregate were used in a reasonable way in the manner to which you refer?

I feel like you're asking me to repeat this over and over.  Reread what I've written previously.

> In the ideal case we will have, in the future, a proper way to deal with multiple levels of granularity in BFO.

Looking forward to it.

> Often times I think that the way to go is with more perspectives. Continuants and occurrents were understood as perspectives, The way we do things now we  would add another

> perspective by creating a sibling to continuant and occurrent, removing the covering axiom on entity. I've been thinking that fields belong in one and the state space perspective

> belongs in another.

Could granularity be one of those perspectives?

In principle, yes.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/456f3637-242c-4d75-a9c5-208d8ab59d79n%40googlegroups.com.

[Anthony Petosa]

>  BFO-2020 is the version that is part of the ISO standard.

Okay; thanks. I will check this version.

>  RO is not BFO

That's true. I said BFO OWL used to include the RO OWL model but then later removed the reference.

I understand your point for having a single OWL Individual that is typed both as Object & Object Aggregate (or their respective derivative subclasses). The BFO 2020 definitions for both Object Aggregate and the "member part of at" relation allow for any Object instance to be a member part of Object Aggregate. So, I understand why this example applies:

John Smith is an Object Aggregate in the sense that he has an exact plurality of human organ system member parts.

John Smith who is an Object is that very same John Smith of type Object Aggregate.

How does it apply to a grocery bag example?

This grocery bag is an Object Aggregate. It holds a variety of Object instance members that are of different types: a package of eggs, a carton of milk, a dog treat product, a package of paper plates, a sprayable deodorant, a greeting card, etc.

Yes, each item in the grocery bag is a member part of the bag's content, just as the human organ system instances are collectively member parts of John Smith's content. However, where John Smith's human organ systems inhere within him, the same cannot be said for any of the grocery bag items. None of John Smith's human organ systems can live apart from John Smith's body; they are a proper part of John Smith's content. Yes, they exist separately, but their existence requires a host body. A carton of milk can exist separately and is not a proper part of a grocery bag's content. It can exist independently from the grocery bag.

I understand your argument for a single John Smith OWL Individual, but how does it apply to the milk carton OWL Individual? Applying the same rationale, this suggests a milk carton instance is the very same thing as a grocery bag Object Aggregate instance.

From your previous email:

> Look. Early BFO made a bad call on these terms by trying to have an avoid-the-issue way of dealing with granularity. It turned out to be a bad bet and so it  needed to be fixed. For a while Barry tried to argue that the object aggregate

> of molecules was not the same entity as the macroscopic object. That didn't fly because it violated the "no duplicative relationship" principle, which is an important one. The two choices were to either deprecate the classes or relax

> the disjointness. Since some people used object and object aggregate in reasonable ways, it seemed better to keep them, but remove the axiom that made them unsuitable for use in science where we need more than 3 levels

> of granularity.

As you said, some people use Object and Object Aggregate in reasonable ways (e.g., the John Smith example). It follows that some do not (e.g., the milk carton example). What is reasonable in one's mind is not in another's mind. This is the essence behind the "concept" issue. You would say, "Well, that modeler is being unreasonable to equate the milk carton instance with the grocery bag instance". I would agree with you. BFO is supposed mitigate the side effects of "conceptualizations", which is why I argue for Object / Object  Aggregate disjointedness.

As you stated, a compromise was required. If and when BFO meets the granularity challenge, why not compromise on the "duplicative entities" rule?

> Sorry I miswrote. Duplicative entities.

> It is commonly illustrated using the statue / clay example. BFO doesn't say there are two material entities, the statue and the clay it is made of. It says there's one material entity and during the period in which it is a statue

> it has a certain shape quality.

Why is avoiding the creation of duplicative OWL Individuals in the John Smith Object & Object Aggregate example more important that weakening the intensional meanings of Object and Object Aggregate? It seems the latter is far more important ontologically, and the former can be handled with rules. For example, a rule could be that if an Object Aggregate instance has member parts which Object instances inhere in the Object Aggregate instance, then one is allowed to assert equivalence between the Object and Object Aggregate duplicative instances. Otherwise, this would not be allowed. Of course, this presents a problem. A reasoning engine would scream an inconsistency. So, this rule would need to be implemented external to the OWL model, where those instances that require equivalence are handled separately by some rule using some rule-based implementation.

Just a thought.

[Alan Ruttenberg]

On Sun, Jun 27, 2021 at 11:08 AM Anthony Petosa <petosa...@gmail.com> wrote:

>  BFO-2020 is the version that is part of the ISO standard.

Okay; thanks. I will check this version.

>  RO is not BFO

That's true. I said BFO OWL used to include the RO OWL model but then later removed the reference.

I understand your point for having a single OWL Individual that is typed both as Object & Object Aggregate (or their respective derivative subclasses). The BFO 2020 definitions for both Object Aggregate and the "member part of at" relation allow for any Object instance to be a member part of Object Aggregate. So, I understand why this example applies:

John Smith is an Object Aggregate in the sense that he has an exact plurality of human organ system member parts.

John Smith who is an Object is that very same John Smith of type Object Aggregate.

How does it apply to a grocery bag example?

This grocery bag is an Object Aggregate. It holds a variety of Object instance members that are of different types: a package of eggs, a carton of milk, a dog treat product, a package of paper plates, a sprayable deodorant, a greeting card, etc.

Yes, each item in the grocery bag is a member part of the bag's content, just as the human organ system instances are collectively member parts of John Smith's content. However, where John Smith's human organ systems inhere within him, the same cannot be said for any of the grocery bag items. None of John Smith's human organ systems can live apart from John Smith's body; they are a proper part of John Smith's content. Yes, they exist separately, but their existence requires a host body. A carton of milk can exist separately and is not a proper part of a grocery bag's content. It can exist independently from the grocery bag.

You've sorted part of the problem by using the term "grocery bag content". If I understand your example, you mean it to be an object? I read it as a defined class rather than an object. I suppose if we zoomed out enough it might be an object. However, bfo:object has better criteria for evaluating whether some entity is or is not. You would need to start with reviewing the criteria for causal unity and make the case in those terms.

I understand your argument for a single John Smith OWL Individual, but how does it apply to the milk carton OWL Individual? Applying the same rationale, this suggests a milk carton instance is the very same thing as a grocery bag Object Aggregate instance.

a) I can't see how you mean that is the very same thing. It obviously is not. Do you mean the same type of thing, namely object?

b) The milk carton, as object, can also be understood as an aggregate of the constituent molecules.

From your previous email:

> Look. Early BFO made a bad call on these terms by trying to have an avoid-the-issue way of dealing with granularity. It turned out to be a bad bet and so it  needed to be fixed. For a while Barry tried to argue that the object aggregate

> of molecules was not the same entity as the macroscopic object. That didn't fly because it violated the "no duplicative relationship" principle, which is an important one. The two choices were to either deprecate the classes or relax

> the disjointness. Since some people used object and object aggregate in reasonable ways, it seemed better to keep them, but remove the axiom that made them unsuitable for use in science where we need more than 3 levels

> of granularity.

As you said, some people use Object and Object Aggregate in reasonable ways (e.g., the John Smith example). It follows that some do not (e.g., the milk carton example).

I don't understand why representing a milk carton implies an unreasonable way of using the terms.

 

What is reasonable in one's mind is not in another's mind. This is the essence behind the "concept" issue. You would say, "Well, that modeler is being unreasonable to equate the milk carton instance with the grocery bag instance". I would agree with you. BFO is supposed mitigate the side effects of "conceptualizations", which is why I argue for Object / Object  Aggregate disjointedness.

Sorry, still confused. Either I'm completely missing your point (probably) or there isn't any question here. The milk carton is unproblematically an object but can have member parts..

As you stated, a compromise was required. If and when BFO meets the granularity challenge, why not compromise on the "duplicative entities" rule?

Because duplicative entities are the bane of integration/interoperability. It's one of the principles that drew me to BFO. It's not something to compromise. Granularity doesn't have to be a compromise. We're just not yet at a place where we can do a great job with it.

> Sorry I miswrote. Duplicative entities.

> It is commonly illustrated using the statue / clay example. BFO doesn't say there are two material entities, the statue and the clay it is made of. It says there's one material entity and during the period in which it is a statue

> it has a certain shape quality.

Why is avoiding the creation of duplicative OWL Individuals in the John Smith Object & Object Aggregate example more important that weakening the intensional meanings of Object and Object Aggregate? It seems the latter is far more important ontologically, and the former can be handled with rules. For example, a rule could be that if an Object Aggregate instance has member parts which Object instances inhere in the Object Aggregate instance, then one is allowed to assert equivalence between the Object and Object Aggregate duplicative instances. Otherwise, this would not be allowed. Of course, this presents a problem. A reasoning engine would scream an inconsistency. So, this rule would need to be implemented external to the OWL model, where those instances that require equivalence are handled separately by some rule using some rule-based implementation.

This is very confused. Object instances do not inhere in an object aggregate. Inheres-in is a relationship between a specifically dependent continuant and it's independent continuant bearer.

I think at this point you should come back with some worked examples that demonstrate your claim that "It seems the latter[ is far more important ontologically". We do applied ontology.

Alan

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/59fc1d64-6ddb-4041-ad13-0fa8c5725775n%40googlegroups.com.

[Anthony Petosa]

Sorry for the delayed reply. When I have the time, I will provide a more detailed response.

I fumbled on "inheres in"; should have known better. I guess I was thinking about the colloquial use of this phrase rather than the formal BFO definition. I simply meant to say that it would not make sense for a human organ system to be sustainable, under normal circumstances, external to its human host. If I remember correctly, the "member_part_of_at" relation does not require Object Aggregate members to be so closely tied to Object Aggregate.

Yes, I absolutely need to revisit the three 'causal unity' forms of a BFO Object. I am sure this will aid in clarifying any confusion on my part.

[Anthony Petosa]

Per your recommendation, Alan, I revisited the three forms of causal unity, what it means to be maximal relative and how these collectively elucidate the meaning of a BFO Object. I understood causal unity but do not fully understand maximal relative. Here is what the text says about maximal relative:

"To say that b is maximal relative to some criterion of causal unity CU(n) means:

• b is causally unified relative to CU(n) at t
• & if for some t and c  (b continuant_part_of c at t & c is causally unified relative to the same CU(n) then b and c are identical"

I am going to take a stab at this and say that given that something exhibits causal unity in some form (BFO describes three forms) and that it is maximal relative along that form means that this thing cannot be decomposed into a smaller unit or form, since doing so would destroy it. These two criteria establish what it means to be a BFO Object. Some examples:

• A water balloon is causally unified by its physical membrane and contains as parts the membrane and water within its interior. It is causally unified by a physical covering because the physical covering prevents anything from getting into and out of the water balloon. It is maximally relative because the single water balloon, which is composed of its parts, are required for the water balloon to exist. If a water molecule within the water balloon travels the distance of a backyard when a child throws it to his friend, then all the water balloon parts travel the same distance within their relative positions in the water balloon. If the child's friend accidentally ruptures the water balloon's membrane when attempting to catch it, then the water balloon's internal content emerges and becomes located external to the water balloon's physical covering, thus no longer being causally unified. If two water balloons are placed side by side, then they each are a BFO object. The collection of two water balloons itself is not a BFO Object, because they exceed what is maximal relative for a water balloon. Also, causal unity and maximal relative of a BFO Object are considered under the normal environments within which the BFO Object exists. 
• A water molecule exhibits causal unity as a circumstance of the molecular bonds formed between two hydrogen atoms and one oxygen atom (i.e., casual unity via internal physical forces). This form of causal unity accounts for changes in the states of matter. A water molecule remains one in the solid, liquid and gaseous states of matter.
• A desk fan is causally unified by way of its engineered composition. It is composed of several parts, but each part is designed to be coordinated such that they collectively work together as a whole. This is achieved on account of their "relative rigidity", which is to say the parts neither move nor act independently of one another. They are fastened together and designed to interact as parts of a whole.
  

Now, I would like to revisit Object & Object Aggregate.

For reference, here is the 'member part of at' definition and the 'Object Aggregate' elucidation.

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)

Elucidation: An object aggregate is a material entity consisting exactly of a plurality (>=1) of objects as member parts which together form a unit

The BFO documentation states this, in part, about BFO Object:

"BFO rests on the presupposition that at multiple micro-, meso- and macroscopic scales reality exhibits certain stable, spatially separated or separable material units, combined or combinable into aggregates of various sorts (for example organisms into what are called 'populations')."

For the most part, I think I understand BFO Object, although I remain a bit unclear about "maximal relative". Based upon what it means to be a BFO Object and considering the fact an Object Aggregate's member parts together form a unit explains why you stated the grocery bag in my grocery bag example represents a defined class and not an Object Aggregate. Unless I am mistaken, an Object Aggregate requires that is member parts are necessarily its members and that they are exact in number. A grocery bag holds an exact number of items, but its existence is not determined by the items it holds. In fact, a grocery bag itself is a BFO Object because it is causally unified via its "engineered assembly  of components": the paper (Material Entity - Object), the shape of the space within a grocery bag (Immaterial Entity - Site) and the two-dimensional boundary that is the grocery bag's opening (Immaterial Entity - Fiat Surface). The grocery bag and the items it contains is a defined class formed by a logical disjunction of the grocery bag and each of the items it holds.

A Human Being is a BFO Object, because one is causally unified by a physical covering (skin) and is maximal relative, which I believe means a single Human Being instance is in its most atomic form in that decomposing a Human Being into his member parts would violate causal unity via physical covering.

Is this correct?

A Human Being is a BFO Object Aggregate if one views reality at a level of granularity such that his concern is anatomical structures and not individual human beings, in which case a Human Being has (x(1)..., x(n)) member parts that together form a unit (i.e., in this case, a single human being), whereby there is an exact plurality of one or more member parts. The member parts are the exact plurality of human anatomical components.

Is this correct?

If so, then I understand why you stated that a Human Being OWL Individual can be typed both as a BFO Object and as a BFO Object Aggregate. This does not violate BFO's monohierarchy principle, because the BFO taxonomic structure does not assert multiple inheritance. Instead, with this example, we are typing an OWL Individual to two different BFO 'categories'. I had suggested creating an OWL Individual for Object and Object Aggregate and then asserting an OWL 'sameAs' relation between them. You objected to this approach, stating we must avoid duplicative entities. Next, with a single OWL Individual typed both as Object and as Object Aggregate, a reasoning engine will not report an inconsistency in the model so long as Object and Object Aggregate are not asserted a disjointedness relation.

I still do not understand why it is such a bad idea to assert disjointedness between Object and Object Aggregate, so long as one creates an OWL model that focuses on a particular level of granularity. For example, do not represent Human Being at two levels of granularity within the same model. Assume one OWL model is designed for a macroscopic view of reality, where Human Being is subtyped under BFO Object and Population is subtyped under Object Aggregate. In another OWL model human anatomical parts are modeled as subtypes of BFO Object and Human Being is subtyped under Object Aggregate. In this approach Object & Object Aggregate are in a disjointedness relation, because there is no need to "mix granularities" in the model. I have not thought through the potential side effects of this approach. For example, what happens when one wishes to utilize two disparate OWL models within the same domain but at different granular levels, combining, say, a population study and human anatomy?

• How would one define and enforce granularity?
• How would one express a trans-ontological granular relation that requires Human Being to be an Object in one view and an Object Aggregate in another while simultaneously maintaining Object / Object Aggregate disjointedness in BFO?

I would like to keep this thread going so I can better understand BFO and also because I suspect a large number of people considering BFO in their work are hesitant to use it, in part due to confusion on topics such as the one posed in this thread.

Lastly, since a very large majority of those implementing BFO likely are doing so via an OWL implementation, I think these discussions should primarily focus on OWL and its Description Logics and less so on BFO's FOL axiomatization.