Review group / providedBy handling, especially in workbenches

[kltm]

Review group handling (providedBy), especially in workbenches. Currently:

• [x] graph editor: all actions will append a group, including annotations; uses default group
• [ ] cytoscape layout tool: does not use group, but only creates layout hint annotations
• [ ] function companion: creates providedBy dynamically as: http://purl.obolibrary.org/go/groups/' + assby (see: https://github.com/geneontology/noctua/issues/458#issuecomment-367081428 )
• [ ] macromolecular complex creator: does not use groups, but does not produce evidence
• [x] simple annoton editor: does not use groups

All of the above tools have at some point created some type of annotation without using groups.

@cmungall @tmushayahama I want to make sure we're aligned on what need groups and in what way. This is important as we look at what we want to do for #458.

[balhoff]

Maybe this is a good place to put this question: is it okay for group labels that end up being used as a value for assigned-by in GPADs to contain spaces, e.g "GO Central"?

If this is not okay, we likely need to add a separate property to groups in groups.yaml to hold an appropriate value.

[cmungall]

No, we use underscore here

http://amigo.geneontology.org/amigo/search/annotation

Although labels conventionally can have spaces, we're overloading it here to be short-computer-friendly-label

We should really add descriptions to some of these, as it may not be obvious to many what GO Central means

[balhoff]

So it should be sufficient to replace space with underscore during GPAD export.

[kltm]

https://github.com/geneontology/go-site/pull/531#issuecomment-365748722

[kltm]

@balhoff I've had some disagreement with @cmungall about what exactly the groups.yaml file is doing, with my formulation being somewhat more broad. He seems to be open to revisiting this a little though. The short of it is that I believe the label field is fungible and should never be used as a mapping mechanism.

My proposal is this: add an additional field to the groups.yaml file for this mapping, rather than overloading label, which should always be the user-facing label/branding for the group. In the future, we'll be offering the ability to have things like accounting groups (sub-groups within a mod) and having multiple groups assign for any action. For this new proposed field, it may also be wise to allow more than one "short name" as there may occasionally be inconsistencies in the assigned-by field.

[balhoff]

@kltm I agree—a dedicated field will also help prevent the label being changed without consideration for its usage as a "key" elsewhere.

[kltm]

@balhoff Okay, then, do you have a good name for the field and should it be a string or a list?

[balhoff]

We could use shorthand and map it to oboInOwl:shorthand, which is found as an annotation property in GO. However, I don't see shorthand actually declared in http://www.geneontology.org/formats/oboInOwl.

[kltm]

That sounds like a very sensible place to start. When I get in, I'll redo @cmungall 's PR, adding the (single string) fields where necessary for the GAF mapping. I assume that there are changes that will be made in Minerva as well to correct for this?

[balhoff]

Yes, I'll need to update the annotation property used to get the value for GPAD.

[kltm]

Noting that when looking at what we have in the GAFs right now, there are some issues:

AgBase / AGBASE
FlyBase / FLYBASE
GOC / GO_Central / GO_CENTRAL / GOC-OWL / GO_Noctua
RefGenome / REFGENOME
SynGO / SynGO-UCL
UniProt / UniProtKB
WB / WormBase

I'll take the most sensible, but we should probably for the groups review this file to make sure it aligns with what they do/want...

[kltm]

@balhoff https://github.com/geneontology/go-site/pull/537

[balhoff]

Group shorthands have now made their way into the GPAD Jenkins job.

[cmungall]

How do we know when this is done?

[kltm]

@cmungall Closure can be the sign-off on the behavior of group handling by all workbenches.

[vanaukenk]

@kltm - is there any more work we need to do here?

[kltm]

@vanaukenk As it stands, the items in the initial checklist are not finished, so this should probably stay open until we can touch bases on whether this is still worthwhile considering the currently most commonly used suite of clients.