gorule-0000027 misses some invalid ID in the with/field

[pgaudet]

Hello,

@alexsign reported that some 'with' data in the exported Noctua GPADs contain "MGI" rather than "MGI:MGI".
https://github.com/geneontology/go-site/blob/master/metadata/rules/gorule-0000027.md mentions that all db prefixes should be found in the dbxref file

Note that the rule states

In all cases, the prefix MUST be in db-xrefs.yaml. The prefix SHOULD be identical (case-sensitive match) to the database field. If it does not match then it MUST be identical (case-sensitive) to one of the synonyms.

However for MGI the database field is MGI, not MGI:MGI.

@kltm do we need to change the dbxref to align with this?

[pgaudet]

Assigning @kltm because we need your input to proceed with this.

[balhoff]

Isn't the prefix MGI? And the local ID values themselves also contain MGI:. Like this: (MGI:)(MGI:96182). So if the second MGI is missing, it's not a dbxrefs file problem, but a problem with the software or data? Sorry if I'm jumping into something without context!

[kltm]

Re: "software or data?"
The answer is both: the data is wrong according to our standards and we are not fixing it. In a perfect world, the first is not true and the failure of the second is not necessary. But, alas...
IIRC, there is an issue about examining the IDs in the "with" column in the GORULES tracker somewhere. There should be some basic checking there, although we have never used the regexps that were added after our pipeline was established (IIRC, added by Tony later on to align metadata a little).
MGI has always been a special case and, until we purge that historical choice from the data stream, it's something that we just have to deal with.

We'd have to look at the flow, but I believe all files (sans uniprot) pass through ontobio at some point and are parsed, so that would probably be the most expeditious place to catch things: python parse. Ideally, our internally produced files are not making the mistake when emitting data (i.e. minerva and PANTHER/PAINT), but as long as it doesn't make it out to end users, it doesn't matter too much. Unfortunately, that means that GO-CAM files /do/ get out as there is no QC occurring there--a running frustration.

I think that the best thing to do for the moment would be to:

• make sure that minerva emits the correct identifier into TTL and and produced GPAD as a special case
• that the rule is added and enforced in the python parsing
• we do a one-time update of current TTL, if this error exists on our side

Again, any TTL/GO-CAM issues are "invisible" to us for the time being, so it's better to err on the side of caution.

[kltm]

Noting too that the GPAD currently emitted by minerva is a bit between specs, IIRC. That makes it a little harder to define what should happen, but that's fine for the moment as long as it is internally consistent.

[pgaudet]

Noting that GOA filters out this data (ie with that have single "MGI:" as the prefix).

[pgaudet]

Related or same as #1218

[pgaudet]

From the test GAF,
tests #4-9 are not failing.

• test 4: Database prefix not in /db-xrefs.yaml
• test 5: Assigned by not in groups
• test 6-9 checks on references

[pgaudet]

@mugitty
It looks like at least the namespace of the 'with' (GAF column 8) is checked in gorule-0000001 (GORULE_TEST:0000001-19)

[pgaudet]

So we should define exactly what is checked in gorule-0000001 and narrow the scope of gorule-0000027

GORULE_TEST:0000027-1
GORULE_TEST:0000027-2
GORULE_TEST:0000027-3
GORULE_TEST:0000027-8 are failing gorule-0000001