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

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?

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.

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)

'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'

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

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?

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 .

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.

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

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?

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

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 :)

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.

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

@shawntanzk Is the CL change you have implemented up above made this pull request moot? If so we will close #577 .