Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a User I want more standard terms instead of genus, species, infraspecies #235

Open
dimus opened this issue Aug 25, 2022 · 5 comments
Open
Labels
v2 Backward incompatible issue

Comments

@dimus
Copy link
Member

dimus commented Aug 25, 2022

@Archilegt writes in #201

One question: Are "wordType" values open to changes?
For example:
genus to genericName
species to specificEpithet
infraspecies to infraspecificEpithet.

@dimus
Copy link
Member Author

dimus commented Aug 25, 2022

@Archilegt writes in #201

@dimus, great to read about the background! The main motivation for the change is aiming at all of us speaking the same language. In a way, the Codes of Nomenclature are biodiversity informatics standards, and terms and definitions contained in the Codes are being adopted by other standards like DarwinCore. With DC becomes more widely used and understood, that creates a larger community speaking "the language". Any software that reuses the same language would benefit from better understanding by the community. In general, the less "mapping" we need from software to (human or machine) user, the better. :)

@dimus
Copy link
Member Author

dimus commented Aug 25, 2022

I recall a similar request came earlier from @abubelihna

@abubelinha
Copy link

abubelinha commented Aug 25, 2022

I recall a similar request came earlier from @Abubelihna

🤔 I recall having asked you somewhere about interpretation of some api parameters.
I couldn't find that thread, but I don't remember to propose changes in names of any parameters (other than perhaps adding some new parameters: i.e. gnames/issues/92).

Anyway ... if you ask me now, I'd rather prefer to let the APIs stay as stable as possible.
@abubelinha

@dimus dimus added the v2 Backward incompatible issue label Aug 25, 2022
@dimus
Copy link
Member Author

dimus commented Aug 25, 2022

I tag this issue as v2, so it only will be implemented when/if gnparser will need to become backward incompatible for other stronger reasons

@abubelinha
Copy link

abubelinha commented Aug 25, 2022

Thanks.

EDIT: It took me a while (1, 2) to figure out how to search github for my previous comments.
I guess you meant my first gnames/gnparser comment #185 (just wondering about some tags' meaning in api response)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2 Backward incompatible issue
Projects
None yet
Development

No branches or pull requests

2 participants