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

LTER CV check is case sensitive for keywords/keywordSet #106

Open
kzollove opened this issue Mar 7, 2022 · 2 comments
Open

LTER CV check is case sensitive for keywords/keywordSet #106

kzollove opened this issue Mar 7, 2022 · 2 comments

Comments

@kzollove
Copy link
Contributor

kzollove commented Mar 7, 2022

Conductivity will not register as in the LTER CV, but conductivity will.

Would be nice to allow case insensitivity

clnsmth added a commit that referenced this issue Mar 14, 2022
Allows case insensitive matching of user input keywords to the LTER Controlled Vocabullary.
@clnsmth
Copy link
Contributor

clnsmth commented Mar 14, 2022

Thanks for the idea @kzollove. Can you foresee any undesired affects on down stream processes if this assumption is made here? The only one I can think of is a term look up process failing to resolve a term to a specified vocabulary (e.g. "Conductivity" to the LTER CV).

Another option is to issue a warning from validate_templates() if the term is a near match to the LTER CV.

The requested implementation is here: 83a44a3

@kzollove
Copy link
Contributor Author

I could see the term lookup process problem occurring (unless they too assume case insensitivity). Overall, I think the tradeoff of better connectivity/resolution of keywords is more important.

The validate_templates() option would work, but put more work on the users end.

One other option I could imagine is if the word is in the LTER CV then writing the "correct" version to EML. ("Conductivity" in the keywords template would go into the EML as "conductivity"). This only seems worthwhile if we have strong concerns about downstream lookup processes failing.

I would say we should move forward with the implementation in 83a44a3

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

No branches or pull requests

2 participants