Add NAS evidence code & reference to all Yeast Pathway models

[suzialeksander]

As discussed on this morning's Managers call, YP models do not have any evidence/references. Next steps:

• [ ] Add NAS evidence code added to all the YP models. @dustine32
• [ ] @pgaudet will add the GOREF for the reference field
• [ ] Add above reference to all models @dustine32

...sometime later, do:

• [ ] automated backfill of imported (existing) full annotations to replace most of the above EC/Ref (this might be an AI/bot action, and/or use EC (enzyme commission) number to map back to the existing SGD annotation)

[pgaudet]

@suzialeksander I am happy to create a GO_REF, but could you send me some text describing the method?

Inspiration can be found here: https://github.com/geneontology/go-site/tree/master/metadata/gorefs

Thanks, Pascale

[thomaspd]

On the managers call, I understood that there was currently no evidence on the triplets in the YeastPathways models. But @dustine32 just showed me the GPAD from the models, and there is TAS evidence pointing to the YeastPathways pathway ID in the reference field. Since as I recall, @suzialeksander noted that the YeastPathways site will be around for a while, I'd suggest that we keep this evidence on the models. This way, Dustin won't need to make any additional changes. to the evidence. What do you think, especially @suzialeksander and @kltm?

[dustine32]

Here's an example GPAD export line for the YeastPathways_YEAST-SALV-PYRMID-DNTP "salvage pathways of pyrimidine deoxyribonucleotides" model:

SGD S000004235  involved_in GO:0043099  SGD_PWY:YEAST-SALV-PYRMID-DNTP  ECO:0000313         20230810    SGD     contributor=GOC:sgd_curators|noctua-model-id=gomodel:YeastPathways_YEAST-SALV-PYRMID-DNTP|model-state=development

SGD_PWY:YEAST-SALV-PYRMID-DNTP is the Reference field value. ECO:0000313 is "imported information used in automatic assertion" (no 3-letter code, but it's a descendant of IEA).

[kltm]

There is nothing inherently wrong with SGD keeping a site up, especially if it is marked as deprecated or something. As well, there is nothing wrong with us holding them as development on the GO side. However, we should not allow the SGD and GO sites to diverge and there should be a documented relationship between them.

As long as there is a single source of truth for the information, I'll be fine. If the intent is to port them over and do final edits or fixes on the GO side, that's fine (as well as my understanding a while ago). If the intent is to have them editable on the SGD side and periodically port them over to GO, that's fine. However, if there is a PURL for an entity or model, that should be driven by a single source of truth.

My hope here is to find some way of getting a little annotation out of the models, if possible, to get them to conform to GO-CAM a little more, and then declare the GO versions the SoT. However, there is room here if other needs need to be met.

[suzialeksander]

the intent is to port them over and do final edits or fixes on the GO side

This is the plan because the SGD-hosted models are uneditable (we currently have no access even to the software, let alone have anyone trained that can use the Ptools software). I don't know that SGD has explicitly discussed labelling the yeastpathways.sgd site as deprecated, but that is more or less what is happening.

there should be a documented relationship between them.

This is what is lacking, and it seems like a GOREF would accomplish this, although since the models apparently have the SGD_PWY: I'm not sure where the GOREF would go.

I think, from @dustine32's paste above, what actually needs to be done is just the automated backfill.

[suzialeksander]

Automated backfill sounds like a wishlist/future project; the models are in Noctua and inaccuracies such as circular pathways have to be manually fixed by SGD curators