Can we use restricitons to ensure absence?

[liamhuber]

I'm playing around making a maximally-complex demonstration for integrating the ontology analysis into pyiron_workflow. To test cancel I went to add a restriction, cancel the relevant triple, and then insist that the triple be absent (to ensure the cancellation worked). I then realized that I didn't know how to phrase such a negative demand. In the notebook example, cancel is used to remove something and then show that if a downstream thing positively requires it, we get failure, which is not quite the same.

As far as I can tell, we don't currently support this because restrictions are always formatted with OWL.someValuesfrom.

I asked claude.ai about it, and got the suggestion to use

restrictions = (
    (my_subject, OWL.onProperty, EX.HasSomething),
    (my_subject, OWL.allValuesFrom, complement_node)
)

To represent

complement_node = BNode()  # or use a URI
restrictions = (
    (complement_node, RDF.type, OWL.Class),
    (complement_node, OWL.complementOf, EX.Something),
    (my_subject, OWL.onProperty, EX.HasSomething),
    (my_subject, OWL.allValuesFrom, complement_node)
)

Ignore the fact I gave my_subject to the restrictions triple -- I just didn't want to confuse the AI with our implicit subjects. Otherwise, I think this heads in a nice direction, but instead of explicitly demanding a complement_node, let's rather a similar trick as you already do with internally generating a EX.HasSomethingRestriction entity. Since OWL.noValuesFrom doesn't exist, I would suggest that we define a new predicate to flag this behaviour, so users ultimately can write something like

restrictions = (
    (OWL.onProperty, EX.HasSomething),
    (SNS.noValuesFrom, EX.ButNotThis)
)

Final caveat: this is all sort of an incremental and piecewise way of extending the restrictions functionality. It's possible that we want to just revise the whole thing. You can read some of my other thoughts on that in #252, but so far none of that has resulted in something conclusively better, so let's be practical and think about iterative improvements in parallel.

[samwaseda]

From what I know, the correct way to address it is to properly define disjoint classes in the ontology. In the case of vacancy, for example, you should ask for Bulk and not "not structure - hasProperty - vacancy". Just in case I also asked ChatGPT and got more or less the same response. I guess this is ok, because the fundamental reason why we started using properties is because we wanted to guarantee transitivity across workflow nodes, and if the reasoner can properly recognize the disjointness, then users still should have a possibility to express this kind of requirement.