cmungall
commented
3 years ago Error1:
in fact the reporting is correct. We do not allow assertions MF part-of MF. Remember, this is not a reasoner report, this is a shex validation report, which imposes structure on the asserted graph, not the entailed graph
Error2:
Just reading the shex response, it indicates enabled_by (00033) should target a protein complex or a chemical entity... which is wrong and indeed does not reflect our shex:
There is no 00033; I think in fact this is complaining about the has-input to the SO dna binding motif. So this does in fact violate the shex
(we may want to extend it to allow SO, I believe that discussion is happening elsewhere as a result of greekc work @pgaudet @vanaukenk? In any case, I recommend a separate ticket for this, and putting an rdfs:comment in the shapefile for the interim)
I think this explains your "however"
So in summary, I think the shex validator is working as intended. We may or may not want to consider relaxing constraints in certain areas, but that would be for other tickets. So I think we can close?
lpalbou
I saw that in the past and fixed one of those issues with ben, but we still have (randomly) wrong error reporting when a model has multiple violations.
Taking example http://noctua.geneontology.org/editor/graph/gomodel:59bee34700000179 , activating the reasoner will show 2 shex errors.
Error 1
I thought error 1 was because we don't allow a MF has part MF. Not sure that's great but we actually do: https://github.com/geneontology/go-shapes/blob/e05a415d8b5178c4ac2b4662d42171d14f19a1cf/shapes/go-cam-shapes.shex#L368 So this reporting is wrong.
Side note : I am unsure about the actual distinction we want to make between MF and molecular events since all activities have both root types.
Error 2:
Just reading the shex response, it indicates enabled_by (RO:0002233) should target a protein complex or a chemical entity... which is wrong and indeed does not reflect our shex: https://github.com/geneontology/go-shapes/blob/e05a415d8b5178c4ac2b4662d42171d14f19a1cf/shapes/go-cam-shapes.shex#L366
So that's another wrong violation reporting. In essence, when the shex engine is reporting those violations, if the first error doesn't make sense, other reported violations won't.
However
If the shex violation reporting are wrong, they still indicate accurately the model is invalid. I've had that experience with other models too. Fortunately, the subject & object reported in that shex response are still valid and usable. For that model, the subject/object ids allowed to track the violation from the activity to a node xxx1244 (DNA motif) linked through a has_input relationship. And indeed has_input should target a protein complex or a chemical entity: https://github.com/geneontology/go-shapes/blob/e05a415d8b5178c4ac2b4662d42171d14f19a1cf/shapes/go-cam-shapes.shex#L371
And the model is stating activity has_part SO term "DNA motif" :
Removing that DNA motif removed the shex violations (also created some issue with minerva/graph when trying to undo the change: https://github.com/geneontology/minerva/issues/371). So the reporting has still some usefulness but it can not be used directly when there are multiple violations. @balhoff @cmungall