While we are waiting for the reupload - where you interested in any other AH ids besides the two above? I might be able to implement a temporary work around while the rest of the files are being processed?

Greetings, I spent some time hunting down the errors for these resources and found that they fall into two classes.

First. fungidb.org does not have transcript data for: Coccidioides.immitis.RMSCC.2394, Coccidioides.immitis.RMSCC.3703, Cryptococcus.neoformans.var.neoformans.B.3501A, Coccidioides.posadasii.CPA.0001, Coccidioides.posadasii.CPA.0020, Coccidioides.posadasii.CPA.0066, Coccidioides.posadasii.RMSCC.1037, Coccidioides.posadasii.RMSCC.1038, Coccidioides.posadasii.RMSCC.2133, Coccidioides.posadasii.RMSCC.3700, Naganishia.albida.NRRL.Y.1402, and Phytophthora.plurivora.AV1007. These should have been removed from the metadata I uploaded to AnnotationHub, but due to an error my filter failed; this has been corrected and the metadata regenerated.

Second. For a small number of species in the various eupathdb projects, including 3 from fungidb: Cryptococcus.neoformans.var.neoformans.B.3501A, Phanerochaete.chrysosporium.RP.78, and Phytophthora.capsici.LT1534; there are some utterly unexpected things in the data downloaded from the eupathdb, including random EOF entries in the middle of the data. I added logic to check for these strange cases and now have the OrgDB/TxDB/GRanges files for them.

I am committing the relevant changes now. If you wish I can upload the 18 or so new files at your leisure.

Other than download, one more thing I would like to add is, no data given for species Candida glabrata. Though it is present in fungiDB online version

One more thing I would like to get here is, the AnnotationHub::snapshotDate() The timestamp of online version of annotationHub is 2019-08-02 12:51:11 +0000. However, when i run locally - AnnotationHub::snapshotDate() time stamp is snapshotDate(): 2019-05-02. i wonder why this discrepancy ? Is this correct ?

P.S. I run time stamp after running hub <- AnnotationHub(). So there is no issue of using available local version.

Thanks.

TL;DR; The fungidb website returns to you the union of the GO and GOSLIM tables. As of now, the OrgDb data that I generate only has the GO table. While answering below, I figured out how to get the GOSLIM data, and will be adding that in future revisions.

Here is the long version:

Greetings! I am not certain that I have a complete answer, but I can quickly identify a couple of things which are relevant. Focusing on secondary metabolic process (GO:0019748), I wanted first to duplicate your query. I first put the GO ID into the 'Gene Text Search' which returned 699 genes, of which 98 are in Aspergillus nidulans. I therefore assumed this is not your query. which retrieves 660 genes. In an attempt to do so, I sent my web browser to fungidb.org and put into the 'Gene Text Search' button the string "GO:0019748". In a separate search, I went to: https://fungidb.org/fungidb/showQuestion.do?questionFullName=GeneQuestions.GenesByGoTerm and put in "GO:0019748". this netted me 660 entries. So I think I can safely assume that is your query.

I then asked the web interface to show me all 660 entries in one table on my left screen. On my right screen, I asked for the first 100 godata entries for all genes along with the first 30 annotation table entries. The first fungidb entry for GO:0019748 (secondary metabolic process) is AN0014, which has as its putative annotation: "protein of unknown function", checking my top-level annotations for A.nidulans, that matches my AN0014, checking the godata, I see that in my version of the data, AN0014 is in groups 'GO:0008150 (biological process), GO:0044550 (secondary metabolite synthetic process), GO:0005575 (cellular component), and GO:0003674 (molecular function)'. So, 3 of the 4 annotations are basically meaningless for our purposes. However, GO:0044550 provides (I think) the answer to your question; in the go heirarchy, it is a child node of both 'GO:0019748' (your query) and 'GO:0009058' (biosynthetic process).

Here is the catch: when I download the GO tables from the various eupathdb data sources, the table I receive (and therefore dump into the OrgDB) contains the GO annotations from the various data sources at whatever level of the GO tree they came from, not the levels above it. I think for that information, you need to cross reference against GO.db or GOSLIM or whatever.

With that in mind, I think we can find a more explicit answer by clicking on the AN0014 entry in the GO table. When I do that, it returns me the full set of annotations for this gene, if I click on the little section '15' on the left (Function Prediction), it shows me exactly what is going on: The first table is the set of EC numbers assigned for this gene (there are none), the second is the set of GO SLIM entries (and lo, there is GO:0019748 in the third row, GO Slim ID column!). The third table is exactly the data I download to create the Orgdb in the columns prefixed GO_ (e.g. the columns you downloaded in your select to create go_data). I have not yet written a function to download GOSLIM data from the eupathdb (I am not sure they have a REST query for it yet -- at least it is not listed in the set of services available and I think I tried a long time ago and failed).

I have a new email chain with the kind folks at the eupathdb in which I asked (again) about querying for a specific version of the data(they cannot); I will ask about this tonight. Actually, I recently figured out how to get more information about stuff like the linkout tables -- let me try modifying that query... Oh! It worked! I can now add the goslim information as a separate table, the missing IDs are in the column 'GOSLIMGOID'. Unfortunately, in order to get the full 660 IDs, you are going to need to separately query the GO table and GOSLIM table, otherwise I think AnnotationDBI will throw an error due to how it merges rows off of separate tables. I will add the GOSLIM data in the next round of OrgDb creations. If they are something you are desperate for now, I can regenerate them now and send you a link to the sqlite files and/or orgdb packages and you can make a local ah instance using them.

Tangentially, your initial commands (hub to tibble) can be written as

mcols(hub) %>% as_tibble(rownames="ah_id")

and the discovery phase could be written using AnnotationHub::query() directly.

> query(hub, c("FungiDB", "nidulans", "OrgDb"))
AnnotationHub with 1 record
# snapshotDate(): 2019-09-17
# names(): AH74340
# $dataprovider: FungiDB
# $species: Aspergillus nidulans FGSC A4
# $rdataclass: OrgDb
# $rdatadateadded: 2019-09-17
# $title: Transcript information for Aspergillus nidulans FGSC A4
# $description: FungiDB 42 annotations for Aspergillus nidulans FGSC A4
# $taxonomyid: 227321
# $genome: FungiDB-45_AnidulansFGSCA4
# $sourcetype: GFF
# $sourceurl: http://FungiDB.org/common/downloads/release-42/AnidulansFGSCA4...
# $sourcesize: NA
# $tags: c("Annotation", "Eukaryote", "EuPathDB", "Fungi", "Fungus",
#   "Parasite", "Pathogen")
# retrieve record with 'object[["AH74340"]]'
> query(hub, c("FungiDB", "nidulans", "OrgDb"))[[1]]

I don't know anything about FungiDB, but I'm a little perplexed by the description / genome / sourceurl discrepancy and don't really follow the explanation in a previous question...; maybe more generally I see

> mcols(query(hub, c("FungiDB", "nidulans"))) %>%
       as_tibble(rownames="ahid") %>%
       select(ahid, rdataclass, description, genome)

# A tibble: 4 x 4
  ahid    rdataclass description                               genome
  <chr>   <chr>      <chr>                                     <chr>
1 AH65324 GRanges    FungiDB 39 transcript information for As… FungiDB-39_Anidu…
2 AH74026 GRanges    FungiDB 42 transcript information for As… FungiDB-45_Anidu…
3 AH74340 OrgDb      FungiDB 42 annotations for Aspergillus n… FungiDB-45_Anidu…
4 AH74665 TxDb       FungiDB 42 Transcript information for As… FungiDB-45_Anidu…

This seems like a great resource so I look forward to getting the kinks (in the data or my understanding!) worked out...