Should "negation" be represented as part of a predicate or as a qualifier of a core triple?

[sierra-moxon]

Discussed in #826

^{Originally posted by sierra-moxon July 29, 2021}
In the Translator, DataModeling call on 07/29/2021 the definitions of many terms we use in the model were discussed including association, qualifier, predicate, and provenance edge properties. See this slide deck.

In particular:

And we introduced some broad guidelines around how to decide if something should be represented as a predicate or a qualifier:

We will try and use these guidelines and definitions to restructure the qualifier hierarchy in the model and add predicates where necessary.

One of the main tenants of these guidelines is that a 'qualifier' should not change the meaning of the core triple. We currently have a qualifier in the model that violates this tenant: 'negation.' We would like feedback on whether 'negation' belongs in the predicate (ie: we'd have predicates like 'does not treat' and 'does not cause', but we would only add negation-predicates when requested -- these would not be added in bulk), or would be more useful as a qualifier in the model.

From a technical point of view, negation as a qualifier is often burdensome (every time a search, inference, display, or return is executed, the negation flag has to be set). Experience has taught us that it can be missed easily.

Please do comment on this discussion if you have use cases or opinions that could help shape this discussion. And finally, please vote on your preference. 😁

👍 for negation in the predicate (ie: a predicate would be: "does not cause").
🎉 for negation as a qualifier. (ie: a predicate would be: "cause" with the qualifier: "negation").

[sierra-moxon]

sierra-moxon, cbizon, kevinschaper, kshefchek, karthiksoman, and andrewsu reacted with thumbs up emoji
mikebada, vdancik, GregHydeDartmouth, mbrush, cmungall, webyrd, and gglusman reacted with hooray emoji
Replies:6 comments · 6 replies
Comment options

gglusman
on Jul 29, 2021
Arguably, if one already has "causes", adding "does not cause" is proliferation.
The connection between the two also has to be encoded in the model, otherwise if one queries a KS "does X cause Y?", and the KS knows "X does-not-cause Y", the available knowledge might not be returned or might be ignored - depending on how things are handled.

2 replies
@sierra-moxon
Comment options
sierra-moxon
on Aug 4, 2021
Maintainer
Author
@gglusman - so in this use case, "X does not cause Y" is not an incorrect result for the query "does X cause Y"?

@gglusman
Comment options
gglusman
on Aug 4, 2021
Indeed, it is not an incorrect result.
Possible responses are presumably 'yes', 'no' and various flavors of "I don't know" (including no response). It would be strange to accept only 'yes' and 'dunno', and reject 'no' as invalid.

Comment options

cbizon
on Jul 30, 2021
Maintainer
I voted for in-predicate because I anticipate a lot of querying trouble if the negation is a qualifier.

If I want things that cause B and I write (?)-[causes]->(B), then unless I add a qualifier to every query from now on, I will get both the things I am looking for, as well things that are asserted to be explicitly what I am not looking for. Literally every trapi query from now on will require a predicate saying what you want, plus a qualifier saying "yes, really".

1 reply
@gglusman
Comment options
gglusman
on Aug 2, 2021
The problem is that there can be many possible use cases and failure modes if one is willing to accept sloppy processing of results.

Here's a different one. A query (?)-[causes]->(B) elicits the answer 'A' (causes B) from KP1, and if we pay attention to EPC stuff, KP1 does mention that confidence is kinda low. The same query elicits no response from KP2, since KP2 has (A)-[does_not_cause]->(B) ... with very high confidence. Sloppily ignoring the EPC stuff, we conclude that A causes B.

Comment options

kevinschaper
on Jul 30, 2021
Collaborator
My experience with negation as an attribute (qualifier in this case) has been that it's very easy to forget, and sometimes code that ignores that attribute can exist for months or years producing inaccurate results.

0 replies
Comment options

micheldumontier
on Aug 2, 2021
Collaborator
In OWL2, negation on an assertion is specified at the type - e.g. object property assertion and negative object property assertion, data property assertion and negative data property assertion. i would not be in favor of creating negated properties, as we would need them for every defined property. question is whether you can simply add another type statement in biolink (along with the association type)? otherwise, you'll need a slot for it. In Hyque [1], we just had a slot that we would query for, otherwise you could generate an inconsistent OWL knowledge base (i.e. merging positive and negative statements from multiple sources may cause logical inconsistency).

[1] https://jbiomedsem.biomedcentral.com/articles/10.1186/2041-1480-2-S2-S3

0 replies
Comment options

aj95b
on Aug 4, 2021
@gglusman @sierra-moxon: If there is an edge to report that is an 'absolute' negation of an already existing predicate, is it not viable to use the broader predicate of which the actual (already existing, non-negated) predicate a child of and then express the negated precise meaning as a qualifier? This way, the 'subject predicate object' triple still gets to hold on its own; this is of course assuming that the negation semantically falls at the same hierarchical level as the non-negated predicate.

2 replies
@sierra-moxon
Comment options
sierra-moxon
on Aug 4, 2021
Maintainer
Author
yep good point. would there be any concern about being less precise?

@aj95b
Comment options
aj95b
on Aug 4, 2021
It is a concern, but wanting to view a result by stripping off all attributes that put a result in its context, is in itself a concern. There are multiple biolink concepts like qualifiers and relations (supposedly an ontologically precise predicate) that exist to counter it.

Comment options

nlharris
on Aug 12, 2021
Maintainer
We discussed this during the DM call on 12-Aug and the agreement was to go with qualifier.

1 reply
@matentzn
Comment options
matentzn
on Aug 23, 2021
As I am mapping-commons/sssom#40 as well right now, could you share the arguments for that choice? In our view, loss of idempotency can be a great risk - you have a pipeline that deals with <s,o,p> and heals cancer patients, now you get a new assertion in your data source <s,o,p,no>, you recommend a drug based on that and patient suffers the consequences. My argument against the "all kinds of modifiers are required" would be that negation and inverse are special cases that are changing the meaning of the predicate so drastically that unless you can guarantee the systems consuming your files know about the modifier column, the risk is too high. At the very least I would suggest to make the modifier column mandatory to tune systems to look for it?

[nlharris]

Closing now -- we just wanted to preserve this discussion in case we ever need to refer back to it.