You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Happy to make a PR to attempt to fix this if you'd like, but since this could be a breaking change I thought I'd get your eyes on it first.
I suppose that since taxizedb is a drop-in replacement for taxize, it would probably be best to conform to whatever taxize returns - but that is obviously your call.
The only intersects between taxize and taxizedb databases are ncbi and itis (keeping in mind #80, which excludes worms and bold).
A deeper comparison:
NCBI
taxizedb: idnamerank
taxize: childtaxa_idchildtaxa_namechildtaxa_rank
ITIS
taxizedb: idrank_idnamerank
taxize: parentnameparenttsnranknametaxonnametsn
where id = tsn, name = taxonname, and rank is similar to rankname (capitalization differs). rank_id has no equivalent.
It's your call if you think that the lack of harmony is a bug or a feature - frankly I quite like the standard interface of names that taxizedb provides, but if most people who use taxizedb are those moving from taxize, a more harmonized solution might be preferable.
It would be nice if taxize and taxizedb user interfaces were more harmonised but it's unclear to me whether the extra effort from the two teams to maintain this harmony would be justified. Currently these are independent projects.
What I think "is" an issue here is that the output of taxizedb::children() should have the same structure regardless of db. However, db = "itis" returns an extra column which I think is not needed. A named list with three columns, "id", "name", "rank", in this order, regardless of db would probably be a more streamlined behaviour. What do you think?
I'm okay with breaking changes, CRAN does not list any reverse dependencies and the current version number clearly indicates that taxizedb is under development.
Happy to make a PR to attempt to fix this if you'd like, but since this could be a breaking change I thought I'd get your eyes on it first.
I suppose that since
taxizedb
is a drop-in replacement fortaxize
, it would probably be best to conform to whatevertaxize
returns - but that is obviously your call.taxize
taxizedb
Session Info
The text was updated successfully, but these errors were encountered: