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
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.
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
Conductivity will not register as in the LTER CV, but conductivity will.
Would be nice to allow case insensitivity
The text was updated successfully, but these errors were encountered: