Hi Gregor,
Sorry to remain confusing (it's all so clear to me ;-) ).
I think what you are trying to do is relate records by features they have in common, features that one might find in gazetteers of named places. That's not what the locationID is for.
locationID is the identifier for the Location. The Location consists of all of those fields having to do with place. If two Locations differ in any of the content of any of the fields in Location, they should have different locationIDs. This is consistent with the use of class identifiers throughout the rest of the Darwin Core.
So, you said, "I assume that the locality is known in detail, e.g. "E of little pond 100 S of village X". Can the localityID for village X be given or not?" The answer is "No, the locationID for village X can exist, but it shouldn't be the locationID of the record referring to the detailed place that mentions village X."
I hope that's clearer.
John
On Tue, Aug 18, 2009 at 2:41 PM, Gregor Hagedorng.m.hagedorn@gmail.com wrote:
But I think you misunderstood me. The localityID can apply to any level of granularity, but it should always be the id for the whole of the Location, not some arbitrary part of it, such as the stateProvince in one case and country in another.
In other words, if a country, stateProvince, and county were given with a localityID, that localityID should apply to the combination of the three (in other words, the county, within that stateProvince within that country). If a locality were also given, then the id shoould be for that locality within that county within that stateProvince within that country. The id could even apply to individual georeferences within named places.
Thanks John, but sorry, I still don't understand. I assume that the locality is known in detail, e.g. "E of little pond 100 S of village X". Can the localityID for village X be given or not? I thought your counterexample would preclude that. You say "the whole content of the Location part of the record, not just one part of it". Is the village Gazetteer ID a "part" in that sense or not? Or, shall the location details (sublocation) be given elsewhere?
Gregor
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).
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 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.
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?
---------
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.
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
Gregor
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.
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%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.
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
On Tue, Aug 25, 2009 at 12:18 PM, Gregor Hagedorng.m.hagedorn@gmail.com wrote:
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.
Yes, I agree. They are very different. Assuming there was a "city" term in DwC, I would not want someone to put San Francisco as the city if the Location was outside of the city. In other words, no geographic term is to be used to represent a "nearest named place", instead, they are to be used only to designate containment of the specific place.
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?
You understand correctly. Darwin Core can transmit all of the detail about the place, no matter how specific, but it cannot transmit any gazetteer id that does not correspond to the whole Location in all its detail.
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.
Though the gazetteer IDs may be stable over time, the geographic entities to which they refer may not be. Thus, I prefer the georeferences again for stability and analytical power.
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%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.
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/).
These very capable and pragmatic people haven't addressed any of the issues I raised about the fallibility of named places and their somewhat arbitrary and changing hierarchical categorization systems - issues that Darwin Core can solve only with spatial entities (georeferences) to represent the Location.
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.
Some other very capable and pragmatic people came up with the TDWG Geographic Region Ontology (http://rs.tdwg.org/ontology/voc/GeographicRegion), including controlled vocabulary, and others are working hard to make actual shapes associated with these features. Should we adopt all of that as well despite the fact that much more inclusive and venerable vocabularies exist in the Getty Thesaurus of Geographic Names (TGN, http://www.getty.edu/research/conducting_research/vocabularies/tgn/) and the Global Administrative Areas (GADM, http://biogeo.berkeley.edu/gadm/) data sets? How would we reconcile the terminology and differences in opinion of administrative levels. I don't think we can, and I certainly don't think we should waste our time trying.
I'm nothing if not pragmatic. That's why I expressed and rejected my own purist ideas in the 13 Aug posting. I can be convinced to include a "city" term, but only if you promise never to populate it with a city if the actual Location is not at least partly within that city. ;-)
In return, I'd ask to not have to change any other term names in the Location class.
John
Gregor
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.
Yes, I agree. They are very different. Assuming there was a "city" term in DwC, I would not want someone to put San Francisco as the city if the Location was outside of the city. In other words, no geographic term is to be used to represent a "nearest named place", instead, they are to be used only to designate containment of the specific place.
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?
You understand correctly. Darwin Core can transmit all of the detail about the place, no matter how specific, but it cannot transmit any gazetteer id that does not correspond to the whole Location in all its detail.
Would it hurt to put the gazateer ID into a higher geographic term?
for the county of san francisco: dwc:county=TGN:1002859
for the city one could use the locality is there is no finer description of the exact place: dwc:locality=tgn: 7014456
Remarkably the getty thesaurus also uses similar terms for the geographic hierarchy: http://www.getty.edu/vow/TGNFullDisplay?find=san+francisco&place=city&am... North and Central America (continent) United States (nation) California (state) San Francisco (county) San Francisco (inhabited place)
Well, for a German town this is slightly different: Europe (continent) Germany (nation) Lower Saxony (state) Hannover (national district) Holzminden (inhabited place)
If all it takes is to add a dwc:city or dwc:inhabitedPlace term, I think I would second that.
Alternatively the most relevant bit apart from the locationID and exact locality is the next higher region that contains the exact location - no matter what rank. Something like a dwc:namedArea
Markus
I just realized that there is dwc:higherGeographyID already that fits perfectly to hold the city gazeteer ID: http://rs.tdwg.org/dwc/terms/index.htm#higherGeographyID
so for a location within the city of san francisco we can use: dwc:higherGeographyID =tgn: 7014456
Markus
On Aug 26, 2009, at 15:41, Markus Döring (GBIF) wrote:
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.
Yes, I agree. They are very different. Assuming there was a "city" term in DwC, I would not want someone to put San Francisco as the city if the Location was outside of the city. In other words, no geographic term is to be used to represent a "nearest named place", instead, they are to be used only to designate containment of the specific place.
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?
You understand correctly. Darwin Core can transmit all of the detail about the place, no matter how specific, but it cannot transmit any gazetteer id that does not correspond to the whole Location in all its detail.
Would it hurt to put the gazateer ID into a higher geographic term?
for the county of san francisco: dwc:county=TGN:1002859
for the city one could use the locality is there is no finer description of the exact place: dwc:locality=tgn: 7014456
Remarkably the getty thesaurus also uses similar terms for the geographic hierarchy: http://www.getty.edu/vow/TGNFullDisplay?find=san+francisco&place=city&am... North and Central America (continent) United States (nation) California (state) San Francisco (county) San Francisco (inhabited place)
Well, for a German town this is slightly different: Europe (continent) Germany (nation) Lower Saxony (state) Hannover (national district) Holzminden (inhabited place)
If all it takes is to add a dwc:city or dwc:inhabitedPlace term, I think I would second that.
Alternatively the most relevant bit apart from the locationID and exact locality is the next higher region that contains the exact location - no matter what rank. Something like a dwc:namedArea
Markus
One more thing came to my mind just now. For taxa we have a taxonAccordingTo, shouldnt there also be a geographyAccordingTo term to indicate the source of the place names? That could be pretty useful I would think.
On Aug 26, 2009, at 16:16, Markus Döring (GBIF) wrote:
I just realized that there is dwc:higherGeographyID already that fits perfectly to hold the city gazeteer ID: http://rs.tdwg.org/dwc/terms/index.htm#higherGeographyID
so for a location within the city of san francisco we can use: dwc:higherGeographyID =tgn: 7014456
Markus
On Aug 26, 2009, at 15:41, Markus Döring (GBIF) wrote:
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.
Yes, I agree. They are very different. Assuming there was a "city" term in DwC, I would not want someone to put San Francisco as the city if the Location was outside of the city. In other words, no geographic term is to be used to represent a "nearest named place", instead, they are to be used only to designate containment of the specific place.
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?
You understand correctly. Darwin Core can transmit all of the detail about the place, no matter how specific, but it cannot transmit any gazetteer id that does not correspond to the whole Location in all its detail.
Would it hurt to put the gazateer ID into a higher geographic term?
for the county of san francisco: dwc:county=TGN:1002859
for the city one could use the locality is there is no finer description of the exact place: dwc:locality=tgn: 7014456
Remarkably the getty thesaurus also uses similar terms for the geographic hierarchy: http://www.getty.edu/vow/TGNFullDisplay?find=san+francisco&place=city&am... North and Central America (continent) United States (nation) California (state) San Francisco (county) San Francisco (inhabited place)
Well, for a German town this is slightly different: Europe (continent) Germany (nation) Lower Saxony (state) Hannover (national district) Holzminden (inhabited place)
If all it takes is to add a dwc:city or dwc:inhabitedPlace term, I think I would second that.
Alternatively the most relevant bit apart from the locationID and exact locality is the next higher region that contains the exact location - no matter what rank. Something like a dwc:namedArea
Markus
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Yes, I think the "accordingTo" term would be useful and nicely parallel to what we do with Taxon. It will allow gazetteers to be shared with Darwin Core using records having dcterms:type="Location". I would call it locationAccordingTo, and it would be distinct from georeferencedBy.
I didn't think about using higherGeographyID in the way you are suggesting, but you're correct, it fits perfectly. Given this epiphany, I don't think the city term is needed to cover Gregor's use case. Please correct me if I am wrong.
I would not use id's in the other geographic terms (Country, stateProvince, county, etc.).
On Wed, Aug 26, 2009 at 7:18 AM, "Markus Döring (GBIF)"mdoering@gbif.org wrote:
One more thing came to my mind just now. For taxa we have a taxonAccordingTo, shouldnt there also be a geographyAccordingTo term to indicate the source of the place names? That could be pretty useful I would think.
On Aug 26, 2009, at 16:16, Markus Döring (GBIF) wrote:
I just realized that there is dwc:higherGeographyID already that fits perfectly to hold the city gazeteer ID: http://rs.tdwg.org/dwc/terms/index.htm#higherGeographyID
so for a location within the city of san francisco we can use: dwc:higherGeographyID =tgn: 7014456
Markus
On Aug 26, 2009, at 15:41, Markus Döring (GBIF) wrote:
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.
Yes, I agree. They are very different. Assuming there was a "city" term in DwC, I would not want someone to put San Francisco as the city if the Location was outside of the city. In other words, no geographic term is to be used to represent a "nearest named place", instead, they are to be used only to designate containment of the specific place.
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?
You understand correctly. Darwin Core can transmit all of the detail about the place, no matter how specific, but it cannot transmit any gazetteer id that does not correspond to the whole Location in all its detail.
Would it hurt to put the gazateer ID into a higher geographic term?
for the county of san francisco: dwc:county=TGN:1002859
for the city one could use the locality is there is no finer description of the exact place: dwc:locality=tgn: 7014456
Remarkably the getty thesaurus also uses similar terms for the geographic hierarchy:
http://www.getty.edu/vow/TGNFullDisplay?find=san+francisco&place=city&am... North and Central America (continent) United States (nation) California (state) San Francisco (county) San Francisco (inhabited place)
Well, for a German town this is slightly different: Europe (continent) Germany (nation) Lower Saxony (state) Hannover (national district) Holzminden (inhabited place)
If all it takes is to add a dwc:city or dwc:inhabitedPlace term, I think I would second that.
Alternatively the most relevant bit apart from the locationID and exact locality is the next higher region that contains the exact location - no matter what rank. Something like a dwc:namedArea
Markus
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
participants (3)
-
"Markus Döring (GBIF)" -
Gregor Hagedorn -
John R. WIECZOREK