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.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/59f3d775-8399-bdc1-1250-83746f1db482%40googlemail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/a7e366bf-7073-445d-9dd7-25fa498179d5n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN9Aifuo0rkTpfVWTiuQrAB%3DPCRjnbcGzargN33_Aw93OMynzQ%40mail.gmail.com.
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.
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.
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.
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."
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/1eb3c9d3-4f35-41ca-abdb-9b9b5f72cf57n%40googlegroups.com.
>> 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.
> 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 .
>> 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?
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/456f3637-242c-4d75-a9c5-208d8ab59d79n%40googlegroups.com.
> BFO-2020 is the version that is part of the ISO standard.Okay; thanks. I will check this version.> RO is not BFOThat'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.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/59fc1d64-6ddb-4041-ad13-0fa8c5725775n%40googlegroups.com.