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