[tdwg-content] dwc: city to county

[John R. WIECZOREK]

On Tue, Aug 25, 2009 at 11:03 AM, Gregor Hagedorn<g.m.hagedorn at 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%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.


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