revise negation

[harryhoch]

Prior model of

mapping: "type": &typeObjectRef type: map mapping: "id": *idRef "label": type: str

support for negation

              "not":
                type: map
                mapping:
                  "id": *idRef
                  "label":
                    type: str

was possibly redundant and did not validate. Suggest revision to simpler

        mapping:
          "type": &typeObjectRef
            type: map
            mapping:
              "id": *idRef
              "label":
                type: str
              # support for negation
          "negated": 
            type: bool
            default: false

if the double negative of "negated:" false is confusing, this could be switched to read simply "present". In any case, the spec should clearly indicate defaults (assume phenotypes listed in a profile are present by default?).

Example files all validate with this revision.

[cmungall]

A couple of disadvantages:

• boolean flag in danger of being accidentally ignored, inverting intended semantics. Yes, developers should RTFS, but in practice many code-by-example
• not compatible with the JSON-LD/OWL representation and generally not extendadable to boolean/OWL combos, which we mant to allow in levels >1

But appreciate the alternative adds some opacity. Also wondering if we need something with a bit more clarity than kwalify (works well for small schemas, perhaps less so for larger ones)

[harryhoch]

@cmungall, yes, I agree, negation has problems. The "not" concept is a bit problematic in its own right. Another possibility might be to consider a (slightly) more expressive approach that allows for degrees of penetrance.

not sure if the term "penetrance" is what we want, but we could imagine default value of "present", with alternatives including "absent" and "partial", with partial including some tbd details.

agreed that something clearer than kwalify might be a good idea. Suggest that this question, together with the discussion going on in https://github.com/monarch-initiative/phenopacket-format/issues/24 might be aided by some explicit design principles. Who is the audience/user community? Where do we fall on expressivity vs. simplicity, etc?

[pnrobinson]

A simpler solution would be to add the relationship "phenotype_ruled_out" In a perfect solution, the evidence code for this would be the method used to arrive at the inference (e.g., cerebral MRI). This solution would leave it to downstream software to figure out what to do with the negative assertion, without needing to use any YAML syntax to achieve negativity.

[harryhoch]

@pnrobinson, is that evidence always going to be available? If we have "phenotype_ruled_out" as a traceable author statement, that's not very different from saying that it's absent..

[pnrobinson]

Typically, an article will report a small number of negative findings that are important for the differential diagnosis, thus, the evidence is essentially the same as for the positive findings. And yes, they are saying the phenotypic feature is absent. My suggestion was that it is probably simpler from a YAML point of view to add another relationship rather than to add explicit negation.

[cmungall]

The disadvantages of new relationship types

• they are easy for the lazy consumer to ignore. Yes, they should RTFS...
• fir full extensibility we have to have 2N relationship types, a negated form for every positive one

On 16 Feb 2016, at 0:03, Peter Robinson wrote:

Typically, an article will report a small number of negative findings that are important for the differential diagnosis, thus, the evidence is essentially the same as for the positive findings. And yes, they are saying the phenotypic feature is absent. My suggestion was that it is probably simpler from a YAML point of view to add another relationship rather than to add explicit negation.

---

Reply to this email directly or view it on GitHub: https://github.com/monarch-initiative/phenopacket-format/pull/25#issuecomment-184567520