GOSemSim and Org package with different field name in DB

[Luis-WP-Arge]

Hi all

I have an Org package that I want to use the keytypes GOALL and ONTOLOGYALL, but there is not an option to use these.
So, is possible to add these two options in a new version.

Best regards, Willian

[GuangchuangYu]

GOALL and ONTOLOGYALL are both valid keytypes in the Org packages (keys(org.Hs.eg.db, keytype = "GOALL") returns 21,344 GO terms; keytype = "ONTOLOGYALL" returns MF, CC, BP), so the data is reachable. The reason they are not usable today is a naming clash rather than a missing capability:

parse_orgDb() treats keytype as the gene identifier type:

kk <- keys(OrgDb, keytype = keytype)
select(OrgDb, keys = kk, keytype = keytype, columns = c("GO", "ONTOLOGY"))

So keytype = "GOALL" makes keys() return GO terms and then asks the database to look up GO/ONTOLOGY for those GO terms — the query is well-formed but semantically wrong, and it is pathologically slow (it tried to join 21,344 GO terms; I killed it after several minutes). GOALL / ONTOLOGYALL are meant to be used as columns (columns = c("GOALL", "ONTOLOGYALL")), not as the key type.

What the two columns actually differ in:

columns	rows	distinct GO
GO / ONTOLOGY	direct annotations only	fewer
GOALL / ONTOLOGYALL	annotations plus their ancestor terms	more

GOALL is the transitive closure, so using it would make computeIC() see each gene annotated to its terms and all their ancestors. Since GOSemSim already computes the ancestor closure itself (getAncestors()), feeding it GOALL would double-count and change every IC. So this should not be a silent substitution.

A workable shape would be a separate argument, e.g.

godata(annoDb = "org.Hs.eg.db", ont = "BP", keytype = "ENTREZID",
       columns = c("GO", "ONTOLOGY"))

defaulting to the current c("GO", "ONTOLOGY"), with c("GOALL", "ONTOLOGYALL") available for Org packages that only expose the *ALL variants. That is an API decision, so I am leaving it to the maintainer rather than guessing — but the answer to "is it possible" is yes, and it is a small change in parse_orgDb().