On Tue, Aug 25, 2009 at 11:03 AM, Gregor Hagedorng.m.hagedorn@gmail.com wrote:
Thanks for the clarification. So indeed I am trying something locationID is not meant for. I am thus not proposing to change LocationID.
However, I believe what I am describing is a very valid use case.
It seems to me to be a gap in Darwin Core in principal to be unable to transmit Gazetteer IDs for the kind of object that are present in Gazetteers (which to all my experience, never provider IDs for the ditch 10 m away from the street intersection (which may have an ID).
Darwin Core is able to transmit Gazetteer IDs for the kind of objects you are talking about (generally called "features" or "named places") that are present in gazetteers. Not only that, gazetteers can have detailed information (georeferences with uncertainties) about places with complex descriptions as well as simple named places. BioGeoBIF does this, and a Locality service I have long wanted to build has exactly this intention. What Darwin Core can't do is give a gazetteer id for some part of the Location, only for the whole. In other words, it can't do what you want it to do. I don't think Darwin Core should. I think the far better solution is to use universal terms - the spatial data - for the use case you are proposing.
I believe in most cases it is *interesting* (for re-finding purposes) to have a free-form very detailed location description, but *sufficient* for all analysis purposes to have a higher-level location amendable to analysis.
It simple isn't true that sufficient is sufficient in all cases. The fitness for use depends on the question (see "Principles of Data Quality" http://www.gbif.org/prog/digit/data_quality/DataQuality). Having an identifier to some feature (even if the most specific named place in the Location) does nothing to help the user to know if the record is fit for use. Only the georeference can do that. That's why I pose that the spatial forms of the Location queried by spatial querying are the universal antidote to the problem.
Example: "200 km W of San Francisco" In this example, the feature would be "San Francisco" but the actual place has nothing to do with San Fransisco except to use it as a staring reference point. In other words, your proposed solution doesn't stand up across scales.
It seems to me undesirable to be able to analyse records where the collectors did not care to add detailed information (such as in a collection only citing the city name) and unable to analyse any records where in addition to the same city name a careful collector also provided additional information. However, according to your definitions, this is presently the situation with DWC.
I have to assume that by "analyse" you mean "query for". In any case, the DwC supports both - by spatial data as mentioned above and by substring querying on the locality term.
Is there any way to make Darwin Core able to transmit such information? Iif LocationID is not the correct property - which property is the correct one?
There is no place for a "mentioned feature id". The appropriate thing to do would be to put the feature, if it contains the specific locality, into an administrative subdivision term. In my 13 Aug response in this thread I proposed that generic terms for administrative levels (countrySubdivision1, countrySubdivision2) could be substituted for the biased term names (stateProvince, county) we have now. We could also add enough terms to cover the most administratively divided regions on the planet (countrySubdivision5). But, as I mentioned before, this doesn't solve any of the ambiguities about the content of any given level.
Separately, and referring back to the start of the question: do you plan to change DWC so that it is possible to transmit the name of cities or villages.
The proposal in the 13 Aug response should take take of this, but I have had no feedback on that proposal.
Or could we even accept the IPTC Extension 1.1 as a relevant standard and accept its definitions (I previously wrongly quoted a version 2, I meant the 1.1. Also note that these fields are not new, they have been moved from core to extension.
The link to the specs is here:
http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata%28200...
It defines for the {location detail} class the following properties (available as RDF vocabularies)
World Region Country ISO-Code Country Name Province or State City Location Details Sublocation
These would be committing the same mistakes that make DwC problematic for geographic subdivisions as it currently stands. If DwC is to change, it seems to me that it should be for the better, not for a similar alternative.
Gregor
--
Dr. Gregor Hagedorn Heinrich-Seidel-Str. 2 12167 Berlin skype: g.hagedorn
This message is sent on a personal basis and does not constitute an activity of the German Federal Government or its research institutions. Together with any attachments, this message is intended only for the person to whom it is addressed and may not be redistributed or published without permission.