Inclusion of geo:lat, geo:long, geo:alt in Darwin Core unresolved
Dear all,
I have reviewed both the recent and ancient discussions regarding the proposal to include geo:lat, geo:long, and geo:alt among the recommended terms from Darwin Core. This particular proposal is not being voted on for inclusion by the TAG at this point, because further research has revealed some issues that need to be addressed. I'll include here the issues I raised to the TAG in the hope of stimulating further discussion in pursuit of a public consensus.
The proposal is to recommend the inclusion of the terms from the geo: namespace (xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#").
Support in tdwg-content for this request comes from multiple independent sources. There has been a long history of discussion (http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/000050.html), beginning in anticipation of the 2010 TDWG BioBlitz. The proposal has gone through the minimum 30-day public review and discussion on the forum tdwg-content at lists.tdwg.org:
http://lists.tdwg.org/pipermail/tdwg-content/2011-July/002581.html
There seems to be general support for the additions. However, after reviewing the discussions and the references. I have the following observations/concerns:
1) The discussions presented geo:lat and geo:long as W3C standards. This is not actually the case. These terms were created by the W3C Semantic Web Interest Group in 2003. The documentation for these terms (http://www.w3.org/2003/01/geo/) states:
"This document was created as an informal collaboration within W3C's Semantic Web Interest Group. This work is not currently on the W3C recommendation track for standardization, and has not been subject to the associated review process, quality assurance, etc. If there is interest amongst the W3C membership in standards work on a location/mapping RDF vocabulary, this current work may inform any more formal efforts to follow."
These terms do seem to have widespread usage in the semantic web. Should we be concerned that they are not part of a standard?
2) geo:lat and geo:long are not semantically equivalent to the existing Darwin Core terms decimalLatitude and decimalLongitude, which have been a part of the Darwin Core since it 2003 (or before, if we ignore the missing Datum term in earlier versions). The addition of the geo: terms as a third set of geolocation terms for Darwin Core raised concerns about confusion, having so many spatially-related terms. I share this concern. An option would be to adopt these terms and deprecate dwc:decimalLatitude, dwc:Longitude, and dwc:geodeticDatum. Data that would have occupied these terms would go instead to dwc:verbatimLatitude dwc:verbatimLongitude, and dwc:verbatimSRS. I see a couple of problems with this. First, most of the time the data in the decimal coordinate fields are not the verbatim originals, so this would be a misuse of the Darwin Core terms. Second, this change would make it more difficult for data consumer’s to use existing georeferences. Here’s how. Right now the verbatim fields are meant to hold the original coordinate information, which means they have a wide variety of content - everything from UTMs to custom-encoded coordinates, in any conceivable format. Meanwhile, the data in the decimal coordinates fields can be much more readily transformed into the desired standardized spatial reference system afforded by the geo: terms, because the values are at least standardized on geographic coordinates in decimal degrees and only a datum transformation has to be done on them to get geo_lat and geo:long.
Do we abandon the dwc: terms decimalLatitude, decimalLongitude, and geodeticDatum? Do we abandon them now? Do we build the simplest possible tools necessary for anyone to do the transformations so that these terms are no longer needed? If so, do we wait until those tools exist before we abandon the terms and make millions of georeferenced records less readily usable?
3) A request was expressed by one reviewer that the term geo:alt should be added. No one has made a formal request for this. However, if the other geo: terms were adopted, it might be silly not to adopt this one as well. Doing so would raise a host of issues similar to those raised for lat and lng, but related to the Darwin Core elevation terms. No discussion of these issues has yet taken place.
Cheers,
John
DecimalLatitude and DecimalLongitude are very clear and it is nice to point to their name as an indication of the restrictions on their contents.
Another issue with geo_lat/geo_lng is that while they can be readily adapted by certain applications, there are still other ways of expressing coordinates for consuming applications (e.g. http://www.w3.org/2003/01/geo/wgs84_pos). My view is that the data structures can be clear about what the data contains and communication between webapps can use geo_lat/geo_long, etc....
John Deck
On Tue, Sep 6, 2011 at 3:49 PM, John Wieczorek tuco@berkeley.edu wrote:
Dear all,
I have reviewed both the recent and ancient discussions regarding the proposal to include geo:lat, geo:long, and geo:alt among the recommended terms from Darwin Core. This particular proposal is not being voted on for inclusion by the TAG at this point, because further research has revealed some issues that need to be addressed. I'll include here the issues I raised to the TAG in the hope of stimulating further discussion in pursuit of a public consensus.
The proposal is to recommend the inclusion of the terms from the geo: namespace (xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#").
Support in tdwg-content for this request comes from multiple independent sources. There has been a long history of discussion (http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/000050.html), beginning in anticipation of the 2010 TDWG BioBlitz. The proposal has gone through the minimum 30-day public review and discussion on the forum tdwg-content at lists.tdwg.org:
http://lists.tdwg.org/pipermail/tdwg-content/2011-July/002581.html
There seems to be general support for the additions. However, after reviewing the discussions and the references. I have the following observations/concerns:
- The discussions presented geo:lat and geo:long as W3C standards.
This is not actually the case. These terms were created by the W3C Semantic Web Interest Group in 2003. The documentation for these terms (http://www.w3.org/2003/01/geo/) states:
"This document was created as an informal collaboration within W3C's Semantic Web Interest Group. This work is not currently on the W3C recommendation track for standardization, and has not been subject to the associated review process, quality assurance, etc. If there is interest amongst the W3C membership in standards work on a location/mapping RDF vocabulary, this current work may inform any more formal efforts to follow."
These terms do seem to have widespread usage in the semantic web. Should we be concerned that they are not part of a standard?
- geo:lat and geo:long are not semantically equivalent to the existing
Darwin Core terms decimalLatitude and decimalLongitude, which have been a part of the Darwin Core since it 2003 (or before, if we ignore the missing Datum term in earlier versions). The addition of the geo: terms as a third set of geolocation terms for Darwin Core raised concerns about confusion, having so many spatially-related terms. I share this concern. An option would be to adopt these terms and deprecate dwc:decimalLatitude, dwc:Longitude, and dwc:geodeticDatum. Data that would have occupied these terms would go instead to dwc:verbatimLatitude dwc:verbatimLongitude, and dwc:verbatimSRS. I see a couple of problems with this. First, most of the time the data in the decimal coordinate fields are not the verbatim originals, so this would be a misuse of the Darwin Core terms. Second, this change would make it more difficult for data consumer’s to use existing georeferences. Here’s how. Right now the verbatim fields are meant to hold the original coordinate information, which means they have a wide variety of content - everything from UTMs to custom-encoded coordinates, in any conceivable format. Meanwhile, the data in the decimal coordinates fields can be much more readily transformed into the desired standardized spatial reference system afforded by the geo: terms, because the values are at least standardized on geographic coordinates in decimal degrees and only a datum transformation has to be done on them to get geo_lat and geo:long.
Do we abandon the dwc: terms decimalLatitude, decimalLongitude, and geodeticDatum? Do we abandon them now? Do we build the simplest possible tools necessary for anyone to do the transformations so that these terms are no longer needed? If so, do we wait until those tools exist before we abandon the terms and make millions of georeferenced records less readily usable?
- A request was expressed by one reviewer that the term geo:alt should
be added. No one has made a formal request for this. However, if the other geo: terms were adopted, it might be silly not to adopt this one as well. Doing so would raise a host of issues similar to those raised for lat and lng, but related to the Darwin Core elevation terms. No discussion of these issues has yet taken place.
Cheers,
John _______________________________________________ tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
John,
Comment(s) inline.
John Wieczorek wrote on Wednesday, 7 September 2011 6:49
Do we abandon the dwc: terms decimalLatitude, decimalLongitude, and geodeticDatum? Do we abandon them now? Do we build the simplest possible tools necessary for anyone to do the transformations so that these terms are no longer needed? If so, do we wait until those tools exist before we abandon the terms and make millions of georeferenced records less readily usable?
Assuming the introduction of geo:lat and geo:lng, I think this means that an application that provides lats and longs calculated in an older datum (e.g. one of the old Australian ones that are up to 200 metres off WGS84) would need to be rewritten to convert its lats/longs to WGS84 before sending?
I don't know how many systems still rely on an older reference ellipsoid, but I figured it might be worth a comment. Sending specimen data verbatim would be problematic here.
Cheers, Ben= This email, together with any attachments, is intended for the addressee only. It may contain confidential or privileged information. If you are not the intended recipient of this email, please notify the sender, delete the email and attachments from your system and destroy any copies you may have taken of the email and its attachments. Duplication or further distribution by hardcopy, by electronic means or verbally is not permitted without permission.
participants (3)
-
John Deck -
John Wieczorek -
Richardson, Ben