[tdwg-content] dwc: city to county

Gregor Hagedorn g.m.hagedorn at gmail.com
Tue Aug 25 21:18:16 CEST 2009


Hi John

> 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.

There is a big difference between city being S. Francisco and the
location being detail inside of it, and city being S. Francisco and
the location being 200 km S of it.

So for the use case where the the detailed location is inside the
boundaries defined by a gazeetter ID, I am still assuming that DWC can
transmit the data ONLY if no more detailed data are given. Or this a
misunderstanding?

Note that the need for gazetteer IDs arises primarily because multiple
cities or villages, even within a state, bear the same name. In part
that could be solved by fully citing all administrative subdivisions,
but in our experience this is extremely tough (in part because the
data are unavailable, in part because these division change every year
- in Germany we of course have had even more drastic changes, which
made even the normally relatively reliable states problematic.
Gazetter IDs are nice and stable.

>> 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.

No I mean aggregate and compare.

>> 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%28200907%29_1.pdf
>>
>> 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.

I disagree. I think IPTC and xmp have been carefully drafted by very
capable and pragmatic people. That includes the digital still image
and video recorder manufactures who currently implement these
standards (see http://www.metadataworkinggroup.org/members/).

I personally think undefined terms like geohierarchy1 to geohierarchy8
are not very practical, easily misunderstood or abused, not amendable
for human consumption, liable to be not interpretable (where higher
and lower geographic regions have the same name). I think the proposal
is not in the laudably pragmatic spirit of most of the current Darwin
Core.

Gregor



More information about the tdwg-content mailing list