UniProt.ws
doesn't generate a database. Instead, what it does is to download all the UniProtKB IDs for a given species, and puts them in an object (your 'db' object). Then when you do a query, the package uses the RCurl package to generate a correctly formed URI to send to www.uniprot.org to do the query.
You could hypothetically hack things to get the mouse UniProtKB IDs into your human 'db' object, and some of the queries would work. But the result you would get is the same if you did the queries separately and then used rbind to combine. As an example, I generated a 'hacked' UniProt.ws
object that contained both human and mouse IDs:
> select(zzz, c("Q9Y478","Q8R2R3"), "ENTREZ_GENE")
Getting mapping data for Q9Y478 ... and P_ENTREZGENEID
'select()' returned 1:1 mapping between keys and columns
UNIPROTKB ENTREZ_GENE
1 Q9Y478 5564
2 Q8R2R3 66939
I also have separate human and mouse UniProt.ws
objects (z, and zz, respectively) that I can do separate queries on:
> rbind(select(z, "Q9Y478", "ENTREZ_GENE"), select(zz, "Q8R2R3", "ENTREZ_GENE"))
Getting mapping data for Q9Y478 ... and P_ENTREZGENEID
'select()' returned 1:1 mapping between keys and columns
Getting mapping data for Q8R2R3 ... and P_ENTREZGENEID
'select()' returned 1:1 mapping between keys and columns
UNIPROTKB ENTREZ_GENE
1 Q9Y478 5564
2 Q8R2R3 66939
So with two separate UniProt.ws objects I can get the same output I would get if I make the combination object, without having to do the hacking (and which may result in unintended results).