Rethinking restrictions

[liamhuber]

And the other keywords, although I think restrictions is at the heart of it. I'm still not sure what this should look like, as evidenced by fulfills introducing its own set of problems (#252). I keep running into issues where things behave in ways that are either outright broken, or suboptimal from my subjective perspective:

• Can we use restricitons to ensure absence? #259
• Derivation and restrictions don't play nicely with cancel #260
• Strict validation is applied inconsistently with restrictions #261

Since I'm not even sure what a solution would look like for these issues, but they keep multiplying, I want a central location to keep track of them.

I also thought it would be useful to begin collecting a set of MWE and how they are failing (or "failing" for subjective cases) so that when we do set about to change things, we can get a good test suite up and running quickly.

To that end (on v0.0.22):

import rdflib

from semantikon import ontology as onto
from semantikon import workflow
from semantikon.metadata import u

EX = rdflib.Namespace("http://example.org/")

def provides_it(x: str) -> u(
    str,
    uri=EX.Something,
    triples=(EX.hasProperty, EX.it),
):
    return x

def requires_it_and_provides_other(
    y: u(
        str,
        uri=EX.Something,
        restrictions=(
            (rdflib.OWL.onProperty, EX.hasProperty),
            (rdflib.OWL.someValuesFrom, EX.it),
        ),
    ),
) -> u(
    str,
    derived_from="inputs.y",
    triples=(EX.hasProperty, EX.other),
):
    return y

def requires_other(
    z: u(
        str,
        uri=EX.Something,
        restrictions=(
            (rdflib.OWL.onProperty, EX.hasProperty),
            (rdflib.OWL.someValuesFrom, EX.other),
        ),
    ),
) -> str:
    return z


def wf(w: str) -> str:
    gives_it = provides_it(w)
    # takes_it_and_gives_other = requires_it_and_provides_other(gives_it)
    takes_it_and_gives_other = requires_it_and_provides_other()  # Break link
    needs_other = requires_other(takes_it_and_gives_other)
    return needs_other

wf_dict = workflow.get_workflow_dict(wf)
graph = onto.get_knowledge_graph(wf_dict)
val = onto.validate_values(graph)
val
>>> {'missing_triples': [(rdflib.term.URIRef('wf.requires_it_and_provides_other_0.outputs.y'),
...    rdflib.term.URIRef('http://example.org/hasProperty'),
...    rdflib.term.URIRef('http://example.org/it')),
...   (rdflib.term.URIRef('wf.requires_it_and_provides_other_0.inputs.y'),
...    rdflib.term.URIRef('http://example.org/hasProperty'),
...    rdflib.term.URIRef('http://example.org/it')),
...   (rdflib.term.URIRef('wf.requires_other_0.inputs.z'),
...    rdflib.term.URIRef('http://example.org/hasProperty'),
...    rdflib.term.URIRef('http://example.org/it'))],
...  'incompatible_connections': [],
...  'distinct_units': {}}

The nature of the failure here is a false positive -- 'wf.requires_other_0.inputs.z' has only specifically demanded the EX.other property, but because of the way types are inherited (so that uri= correctly gets inherited, #241), we see here that it also demands EX.it.

I suspect the nature of the solution here is, in some way, to distinguish between triples that are added and triples that are required, and to inherit all those added from upstream but not to inherit those required.

[samwaseda]

I had a discussion with someone from the PMDco team, and he thinks the types should not be inherited to the downstream ports. I'm feeling more and more the same way to be honest. Basically, properties should be inherited, but not types. This way, we would have to write our own reasoner to check type consistency, but otherwise this would solve quite some problems that we are encountering right now.

[samwaseda]

Now looking at the current implementation, I still think inheriting types should not be automatic. The first reason is, as I already stated somewhere, it is not wrong to ask the users to write all types explicitly. These are anyway not end users, but in principle node developers, so I think it's worth for them spending time to annotate their nodes explicitly. Also it's not like it just doesn't work if it's missing; it just does not do anything in the type checking, so I don't think it's a deadly problem anyway.

Here's another thing that came to my mind: It appears natural to add and cancel properties, as we do now with triples and cancel. Now, imagine what if a vacancy structure is used for the input, and the node fills the vacancy? This can be obviously expressed with properties, but the user might wish to do so with the class, in which case the input is VacancyStructure while the output is VacancyStructure and BulkStructure at the same time. Not only there is currently no way to prevent the type inheritance, but also this implicit inheritance appears to me like a bigger problem than not giving a type hint at all.

[liamhuber]

I can live with switching paradigms, but I will need a few simple examples of how it ought to work. It sounds to me like we are going to be setting up a custom set of "properties" that run parallel to types but do get passed along. I have some reservations, but let's try it.

One thing I am sure of is we will need to be very careful and very intentional about our language choices in order to correctly distinguish what gets propagated and what doesn't. Doable, but care is required.

The first reason is, as I already stated somewhere, it is not wrong to ask the users to write all types explicitly. These are anyway not end users, but in principle node developers, so I think it's worth for them spending time to annotate their nodes explicitly.

I would be a bit more careful here. You are going to get some pushback on the "let them write it again" concept. I think this concern has legs to the extent that we want to have a minimal barrier between "user" and "node developer". I expect all but the GUI-only users to regularly cross back and forth between the roles, even if they don't think of themselves as "programmers", much less "ontologists". So in this particular case and with my caveat about being very careful with language and UX, I can get behind re-writing uri types. But generally I want to be very conservative about placing expectations on node developers.

[samwaseda]

I will need a few simple examples of how it ought to work.

I don't think we can fully figure it out in the discussions between you and me, since we are only imagining things and don't know how the users would use it. The only things I can say is that there are practical problems with things like OWL restrictions, and more fundamental problems with cases like filling a vacancy structure (ergo turning VacancyStructure into BulkStructure), while the argument about users potentially omitting the type in the output is... well, I guess I have to see whether it is a too common problem.