behavior process is a process

[wdduncan]

The term behavior process needs to be placed under process.

[diatomsRcool]

I have just changed behavior process from GO to NBO (NBO:0000313). Does that solve this problem?

[wdduncan]

Currently, behavior process is a top level entity. Shouldn't it be placed under processual entity? These are processes ... right?

[diatomsRcool]

Yes, these are all processes. It looks like NBO asserts that behavior process is a processual entity. Are you saying that this assertion needs to be made in ECTO too?

[wdduncan]

Yes. I think it should be asserted as a subclass of processual entity. Do you see a reason why it shouldn't?

[diatomsRcool]

No, I just thought that if another ontology asserted it, I didn't have to.

[wdduncan]

It depends on whether you also import the axiom that it is a subclass of processual entity. Otherwise the ontology won't know about it. Do you know if the axiom is imported during the build process? It doesn't show up in the version of ecto-full.owl that I just pull from github.

[matentzn]

While I agree that behaviour process should be under processual entity, I dont think this is Anne's job -> @diatomsRcool I suggest you make an NBO ticket and link the issue. If its fixed there, ECTO will automatically update!

[wdduncan]

@matentzn Are you saying that as part of the build process behavior process will be classified correctly? NBO doesn't have any axioms of this sort (see image below).

It would be best if NBO fixes things on there end. Otherwise, we may have to fix things ourselves.

[matentzn]

NBO should change it - and yes, they would simply place behavior process under processual entity. They do use BFO, so it should not be an issue. Although I really prefer all this stuff to be done by COB and get rid of these direct BFO classifications altogether. In any case, this issue here can, if you want, be closed, and the discussion continued on the NBO tracker. I would generally never axiomatise terms that do not belong to your ontology; every axiom in ecto-base.owl should contain at least one ECTO term; the axioms NBO:behaviour process subClassOf: BFO:processual entity does not contain an ECTO term and should therefore not be asserted anywhere but NBO (analogously for GO:behavior).

[wdduncan]

Nico, we just going to have to disagree about this. It is perfectly fine to assert axioms when building ontologies. It is how you get your framework to fit together in a coherent manner.

[matentzn]

Just to be clear, I am not against asserting axioms; I just want to avoid redefining terms that belong elsewhere. A majority of my work comes from the problem that people redefine terms, and all our work about ontology bases is to get rid of this practice. Say for example this:

GO:

A Sub B

ECTO: "I dont like A sub B"

A disjoint B

Now Monarch.owl:

A Sub B
A disjoint B

You see what I mean? We have had an endless flurry of meetings to reach to the conclusion that we are solving this issues by moving to bases, and a base is an ontology that asserts axioms only about terms in their realms of responsibility. So we cant have say, NBO saying NBO:behavioural process is a BFO:XYZ and ECTO stating that NBO:behavioral process is an BFO:ABC (the most common actual situation this happens is when Model organism ontologies say that some anatomical entity is immaterial and UBERON says the it is not; instant unsatisfiable class).

[matentzn]

As an aside, I dont mind the debate on this; I think we both want to make the OBO world a better place, so we should get on the same page. I am happy to have this argument till we are both happy!

[wdduncan]

Hi @matentzn I don't mind the debate :)

I see your point, but I think in this case that asserting that behavior process as a subclass of processual entity (which should really be a subclass of BFO:process) is fine. Unfortunately, OBO Foundry ontologies are not always as well put together as we would like. For instance, many OBO ontologies don't explicitly import BFO as their upper-level ontology, which makes it difficult to interpret developer intentions. Also, many of these developers are resistant to change.

In the case of ECTO, as far as I know it is an application ontology. This, gives us latitude make judgment calls about how to best model the ontology. Otherwise you end up with weird situations in which not all "processes" are classified as processes. This kind of defeats the purpose of having an upper-level ontology.

Hopefully, NBO changes things on their end. But if not, then we need to decide whether to have two top-level classes that are processes, or to make a judgment call and assert each as a being a process. In this case, I think the latter choice is better for ontology development.

The development needs of Monarch are much different, and some of decisions made for that ontology may not hold for ECTO.

[matentzn]

Ok, well we disagree in more than one thing then; for me an application ontology (for which, if I were to accept this premise, I would also be more inclined to accept your conclusion) is an ontology that combines existing ontologies to cater for some specific use case, like EFO, CIDO, and similar. I would categorise ECTO more as a domain ontology, which models a particular domain of discourse (environmental exposure) consistently.

So what I hear basically from you is that you challenge the assertion that the threat of inconsistent modelling is lower than incomplete modelling? In your view of the onto-world, would it also be acceptable to import a term A from an ontology that claims that A is a continuant, and you, for the purpose of your ontologies, reject that claim and say A is an occurrent?

[wdduncan]

Re: domain vs application ontology. I thought this was more of a specific use case of how humans interact with the environment. But, if you see it as larger, that is fine with me. Making a distinction between application/reference ontologies is difficult at times.

In your view of the onto-world, would it also be acceptable to import a term A from an ontology that claims that A is a continuant, and you, for the purpose of your ontologies, reject that claim and say A is an occurrent?

This is not my view at all. A behavior process is not just a process to me. It (as far as I can tell) is a process in NBO. Again, I don't know why the developers didn't import BFO's upper-level classes. This is not a problem for just NBO, but other OBO ontologies too (see for example the Disease Ontology).

Are you saying you don't want ECTO to conform to BFO? If so, that is fine with me, but we need to be explicit about non-conformance instead being indecisive about it. If NBO is not committed to behavior processes being processes, then why would want to use their term? When ontologies are non-committal about the meaning of their terms what is wrong with giving them clarity? Especially when the label (i.e., 'behavior process') and subclasses all refer to processes. In your examples, you assume that A has already been clearly defined. I think my assertion that behavior process is a process is quite reasonable even though the NBO developers did not put the axiom in.

[matentzn]

(its gotten a bit late here - coffee next week to continue debate? :)

[wdduncan]

Updating this issue with reference to NBO issue obo-behavior/behavior-ontology#101.

The last comment made by @matentzn says:

for practical reasons we assume now that the two root classes NBO:behavioral process and GO:behaviour refer to the same thing

Currently NBO:behavior process is subclass of GO:behavior. Should make them equivalent?