Verbatim Coordinates or Locality?

[tucotuco]

From Rich Rabeler (University of Michigan Herbarium):
"While it's clear that decimal lat/long is the desired information standard for any specimen to be considered "georeferenced", a specimen label often includes some coordinates; lat/long, UTM, TRS. etc. Where should one put that information? Into a Verbatim Coordinates field or lumped into locality? The former seems more correct from a DwC perspective, but if one wants to georeference the specimens via Geolocate (the main protocol that we have decided to use), I've been told that any information that you want Geolocate to use in determining the georeference has to be in the locality field. So, we then have a locality field that has all sorts of "extra" stuff besides the locality name itself. If one were going to try to match a locality against a global gazetteer, I would assume that the extra items would make that match more difficult (?).

[tucotuco]

From @debpaul:

"My two cents. Both. Why? Because "verbatim" localities are important for many semantic reasons. If you tease apart all the pieces of a locality string on a herbarium sheet -- but you don't include a "verbatim" string in your data -- some semantic meaning conferred by the text --- is lost (and can't even be gotten back, unless you are looking at the label).

At least at FSU, (years ago) I suggested to digitization staff, to capture verbatim, and then also put any coordinates offered in that locality string, into Verbatim Coordinates (this includes TRS).

I love this question. As you know, herbarium plant locality data is often all mixed in with habitat, associated species, soil information, etc. Whether this would "confuse" a gazetteer to "match" or not -- a marvelous question.

At least for herbaria, if everyone was collecting verbatim, and we could compare all verbatims, that'd be fun yes?"

[nelsonrios]

In general, I do not think it is a good idea to modify what is published as Darwin Core to accommodate any particular tool, even GEOLocate. Any concatenation or other preliminary processing should be handled by the client interface in question and ideally would be configurable to a given dataset.