[NTR] has_completed

[shawntanzk]

Related to https://github.com/obophenotype/cell-ontology/issues/1481

Currently CL uses custom relations: http://purl.obolibrary.org/obo/cl#has_completed http://purl.obolibrary.org/obo/cl#has_not_completed This seems to refer to cells that have/have not completed some GO biological process Would be good to move this to RO.

rdfs:label has completed definition: a relation between a material entity and a process in which the material entity exists, at least in part, due to the completion of the process. Example of usage: memory T cell has_completed some 'memory T cell differentiation'

rdfs:label has not completed definition: a relation between a material entity and a process in which the material entity has the potential to complete the process, but has yet to complete it. Example of usage: immature T cell has_not_completed some 'T cell selection'

[cmungall]

how would this compare with output of?

I am not sure this is quite right.

• Every human exists at least in part due to the completion of some egg fertilization process, but it's odd to say they have completed this.
• A student may have completed their exams but they don't exist even in part due to the examination process

These process relations are hard...

a relation between a material entity and a process where the objective of the process is to transform the material entity, and the primary output of the process is the material entity in a particular state, and the primary input is the same material entity in a different state

[shawntanzk]

how would this compare with output of?

Looking at the def for has output, I don't have a good logical answer, might have to rethink this.

I totally get your point and it almost seems like the definition I gave fits more as 'formed as a result of' which I wonder if the CL terms using 'has completed' is actually referring to that (the example I gave does fit). Thoughts on this @addiehl?

[dosumis]

Looking at this some more, I think the case needs to be made for why we need these as opposed to just using 'output of' and 'capable of' respectively. For the classification use case.

• Are there any other outputs of 'T-cell maturation' or similar developmental/cell state activation processes that are not cells? (I think probably not)
• Are there any other cells that are capable of 'T cell selection' (Doesn't T-Cell selection invovled multiple cells, if so maybe we want some sub-process here?)

For query use cases:

• Do we need to be able to query directly for cells by the developmental processes they have completed rather than just processes they are the output of?
• Do we need to be able to query directly for cells by the processes the are capable of but have not yet undergone/completed?

If the answer to these questions is yes, then I suggest making new sub-properties of output of and capable of respectively.

[shawntanzk]

RO call - Not creating new relations, instead:

• potentially use a more general term like output_of
• negative (has not complete) not great -> capable_of instead?

Figure out if @addiehl has any use cases for completed - if not we should just use output_of

current T cell stuff in CL (examples) is not quite right -> make a ticket on CL about this (tag @bpeters42 in this)

[addiehl]

'T cell selection' is not a cell-autonomous process, but rather a series of interactions between immature T cells in various stages of differentiation and support cells in the thymus (typically). 'capable of' relates a cell to one of its functions expressed as a GO process term. The thymus, as an organ, is capable of carrying out T cell selection. A given immature T cell is not capable of T cell selection on its own. On the other hand, a mature T cell has completed T cell selection.

I'm willing to accept an equivalence axiom for 'mature T cell' as T cell' and ('has plasma membrane part' some 'T cell receptor complex') and ('output of' some 'T cell selection')

(of course this contains the undesirable 'has plasma membrane part' relation as well; I'll take that up elsewhere -- not sure if your expresses relationship can handle a protein complex as a range)

If you are against using has_not_completed some 'T cell selection' why not just cheat and resort to using the PATO term 'immature'. We can leave the textual definitions alone.

'immature alpha-beta T cell': "An alpha-beta T cell that has an immature phenotype and has not completed T cell selection." with equivalence axiom 'alpha-beta T cell' and 'has quality' some immature and 'participates in' some 'T cell selection'

[shawntanzk]

If you are against using has_not_completed some 'T cell selection' why not just cheat and resort to using the PATO term 'immature'.

happy to do this for this case, but I guess that means we should look case by case for has_not_completed - basically we are trying to remove any non RO relation, so anyway to do that is good :) thanks

of course this contains the undesirable 'has plasma membrane part' relation as well

this isn't undesirable actually, we've add this on RO so once the release is out we can replace it with a RO term

[shawntanzk]

CL call:

Alex: has_completed -> output_of is ok, not_completed is problematic

Bjeorn: negation in general is hard to deal with - reasoning doesn't work well with that (logically can handle it, but EL doesn't pick it up) has_not_complete -> is output_of only not

Alex: using quality immature, eg 'alpha-beta T cell' and 'has quality' some immature and 'participates in' some 'T cell selection'

Bjeorn: however we will not find the something that have is_output and participates in -> basically reasoner will not find the conflicted

Alex: certain def, capable_of can be used <- problem is that same problem as above

Bjeorn: Keep relationships and translate dependent on what the reasoner can deal with general question in general: has a process passed? yes/no -> conflicts can be caught. is there a general approach we can use for this?

[bpeters42]

Sorry: I wrote this before seeing Shawn's summary above, which captures what I meant. Just adding a bit more detail here in my own words:

I think that we have a general problem with linking a material entity to its history, that goes beyond cells. We could create a relationship: "not output of" between a material entity (or continuant...) and a process P, and then we deal with reasoning over X "not output of" P by replacing it with X "output of' only (not P) for those reasoners that can deal with it, similar to what we did with 'lacks membrane part'. This could be an overall approach to negations, and ideally we would have a unified technical solution to test for it. Copying @cmungall .

[balhoff]

I think any properties representing negations should be defined as annotation properties, definitely not object properties. A current example is never in taxon. We can have a unified technical solution for these via defined expansions using robot expand.

[bpeters42]

Hi Jim, is there a link to the discussion why using annotation properties is preferred? It seemed that using object properties would give some desired inferences even if the property is not expanded, but I wouldn't be surprised if I am wrong, and would like to learn.

Either way, it seems to be a good idea to have a shared pattern for all 'negation relations' in terms of naming and how they are expanded. Looking at the expansion for 'never in taxon' that Jim pointed to, "Class: ?X DisjointWith: 'in taxon' some ?Y" works just fine, and should in principle be equivalent to what I had written but avoids the 'only' and 'not' in favor of disjoints, which I understand are handled better by some reasoners?

I would then propose a naming convention though, where for a given property labeled "XXX", we would label the negation property as: "not-XXX", put them all under one 'negation property' or the like parent in RO, and expand them all in the same way. As reasoners evolve, we will ideally be able to change that expansion, and eventually, drop them entirely in favor of just writing 'not' 'XXX'.

• Bjoern

On Wed, Mar 16, 2022 at 11:16 AM Jim Balhoff @.***> wrote:

I think any properties representing negations should be defined as annotation properties, definitely not object properties. A current example is never in taxon http://purl.obolibrary.org/obo/RO_0002161. We can have a unified technical solution for these via defined expansions using robot expand https://github.com/ontodev/robot/issues/963.

— Reply to this email directly, view it on GitHub https://github.com/oborel/obo-relations/issues/574#issuecomment-1069409531, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX2IWEGWIYK5EDHLWG22TVAIQPRANCNFSM5P2ZYONA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

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

[dosumis]

OPs with buried negation => incorrect inferences.

e.g.

X subClassOf Cell X SubCLassOf lacks_part some 'lobed nucleus' enucleate cell EquivalentTo cell that lacks part some nucleus 'lobed nucleus' subClassOf nucleus => x subClassOf enucleate cell

(real example from CL history)

Lots of potential for this any time the subject of the OP with the embedded negation is part of a class hierarchy. In the case of linking to GO - the classification is very rich. With PRO we mostly get away with it because PRO is pretty flat - although it still has the potential to cause problems.

In this case, I'd like to understand more what the use cases are for asserting this as a negation. Autoclassification? Queries?

Can we achieve these with with a positive assertion?

One other option is to use punning of class to Individual + value restriction. Can still be used (to v.limited extent) for classification, avoiding errors caused by inheritance. Jim has a paper on this. https://arxiv.org/abs/1410.3862

[bpeters42]

Thanks David, that was crystal clear, so no 'shortcut' objected properties with hidden negation

I am coming at this naively, as in our own work, we have just used plain OWL, which for your example gives enucleated cell=def: cell and not (has_part some nucleus), which causes no problems. But as I understand using 'not' gives problems with reasoners you guys are using? Did I understand at least that correctly? I thought that was the reason why we had relations like "lacks plasma membrane part" in CL to begin with?

The reason why we have been using negation for immune cells is to handle e.g double-negative T cells defined by the absence of CD4 and CD8 surface markers, but the presence of CD3 (the T cell receptor). I was assuming you run into this when doing cell classification by transcriptome data all the time as well, where the absence of expression of a gene is at least as useful as the presence?

• B

On Wed, Mar 16, 2022 at 3:07 PM David Osumi-Sutherland < @.***> wrote:

OPs with buried negation => incorrect inferences.

X subClassOf Cell X SubCLassOf lacks_part some 'lobed nucleus' enucleate cell EquivalentTo cell that lacks part some nucleus 'lobed nucleus' subClassOf nucleus => x subClassOf enucleate cell

Lots of potential for this any time the subject of the OP with the embedded negation is part of a class hierarchy. In the case of linking to GO - the classification is very rich. With PRO we mostly get away with it because PRO is pretty flat - although it still has the potential to cause problems.

In this case, I'd like to understand more what the use cases are for asserting this as a negation. Autoclassification? Queries?

Can we achieve these with with a positive assertion?

One other option is to use punning of class to Individual + value restriction. Can still be used (to v.limited extent) for classification, avoiding errors caused by inheritance. Jim has a paper on this. https://arxiv.org/abs/1410.3862

— Reply to this email directly, view it on GitHub https://github.com/oborel/obo-relations/issues/574#issuecomment-1069681587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX2ISGBLDPQ7SJKICSX3LVAJLSBANCNFSM5P2ZYONA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

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

[balhoff]

Yep David covered the issue. ELK does not support classification based on not (has_part some nucleus). It's not an error; it just ignores it for finding subsumptions. HermiT handles it but doesn't scale to the bigger terminologies. ELK does support these negations for finding some unsatisfiable classes. I think missing subsumptions is better than creating wrong subsumptions. There are some procedures for asserting the right classification (e.g. in my paper) from the negations, but they require custom code and not guaranteed to be complete. I wonder if we should add such a procedure to ROBOT?

[bpeters42]

Thanks Jim! I did read up on the paper, specifically section #3 talking about the ELK implementation. I think we are all on the same page that it would be good to have a standardized way to deal with negation, both on (1) how they should be expressed in OBO ontologies and (2) how we can incorporate them into reasoning without asking ontology developers to write custom code.

Regarding (1), the more I think about it, the more I prefer to just use the OWL 'not' syntax rather than creating custom annotation properties. That would have the benefit of requiring no change at all for smaller ontologies that Hermit etc. can handle right now, and as reasoners get better, we don't have to adjust the logical definitions. The advantage of the annotation properties is that it is easier to trigger scripts to expand them to owl statements, but it seems like the same could be done when parsing owl statements for the presence of 'not' (this might be a lot more complicated than I think)? Really this should be something done by the reasoner itself, but as it doesn't seem we have any control over reasoner development, integrating this into ROBOT would also be much better.

• Bjoern

On Thu, Mar 17, 2022 at 9:42 AM Jim Balhoff @.***> wrote:

Yep David covered the issue. ELK does not support classification based on not (has_part some nucleus). It's not an error; it just ignores it for finding subsumptions. HermiT handles it but doesn't scale to the bigger terminologies. ELK does support these negations for finding some unsatisfiable classes. I think missing subsumptions is better than creating wrong subsumptions. There are some procedures for asserting the right classification (e.g. in my paper) from the negations, but they require custom code and not guaranteed to be complete. I wonder if we should add such a procedure to ROBOT?

— Reply to this email directly, view it on GitHub https://github.com/oborel/obo-relations/issues/574#issuecomment-1071067984, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX2ISD3773Q5RMUDJSNNTVANOI3ANCNFSM5P2ZYONA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

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

[nlharris]

Is this still a new term request, or is it now something else? A ROBOT feature request?

[shawntanzk]

Is this still a new term request

It was, but I am unsure on how to proceed from here. Happy to do what needs to be done, but need some actionable steps for it.

Thanks :)

[addiehl]

On RO call, decided to change 'has completed' to 'output of' in the CL.

@shawntanzk will look at all uses of 'has not completed' in CL and we will decide how to change them on an ad hoc basis.

[shawntanzk]

Using the following sparql query on ubergraph (figured given complex equiv that use it, querying the materialised triple store would be easier)

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

# selecting only unique instances of the three variables
SELECT DISTINCT ?subject ?property ?object WHERE
{
  VALUES ?property {
    <http://purl.obolibrary.org/obo/cl#has_not_completed>
  }
?entity rdfs:isDefinedBy <http://purl.obolibrary.org/obo/cl.owl> .
?s ?property ?o.
?s rdfs:label ?subject .
?o rdfs:label ?object .
}

We get the following (sorry for it being in google sheets, too long to paste here directly): https://docs.google.com/spreadsheets/d/1ONiiW_CC4i5XsU-no-YxMxG2r3qEByth9ZRDCa6X-mI/edit?usp=sharing