DecimalLatitude and DecimalLongitude are very clear and it is nice to point to their name as an indication of the restrictions on their contents.† <br><br>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. <a href=""></a>).† 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....<br>
<br>John Deck<br><br><br><div class="gmail_quote">On Tue, Sep 6, 2011 at 3:49 PM, John Wieczorek <span dir="ltr">&lt;<a href=""></a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Dear all,<br>
I have reviewed both the recent and ancient discussions regarding the<br>
proposal to include geo:lat, geo:long, and geo:alt among the<br>
recommended terms from Darwin Core. This particular proposal is not<br>
being voted on for inclusion by the TAG at this point, because further<br>
research has revealed some issues that need to be addressed. I&#39;ll<br>
include here the issues I raised to the TAG in the hope of stimulating<br>
further discussion in pursuit of a public consensus.<br>
The proposal is to recommend the<br>
inclusion of the terms from the geo: namespace<br>
(xmlns:geo=&quot;<a href="" target="_blank"></a>&quot;).<br>
Support in tdwg-content for this request comes from multiple<br>
independent sources. There has been a long history of discussion<br>
(<a href="" target="_blank"></a>),<br>
beginning in anticipation of the 2010 TDWG BioBlitz. The proposal has<br>
gone through the minimum 30-day public review and discussion on the<br>
forum tdwg-content at <a href="" target="_blank"></a>:<br>
<a href="" target="_blank"></a><br>
There seems to be general support for the additions. However, after<br>
reviewing the discussions and the references. I have the following<br>
1) The discussions presented geo:lat and geo:long as W3C standards.<br>
This is not actually the case. These terms were created by the W3C<br>
Semantic Web Interest Group in 2003. The documentation for these terms<br>
(<a href="" target="_blank"></a>) states:<br>
&quot;This document was created as an informal collaboration within W3C&#39;s<br>
Semantic Web Interest Group. This work is not currently on the W3C<br>
recommendation track for standardization, and has not been subject to<br>
the associated review process, quality assurance, etc. If there is<br>
interest amongst the W3C membership in standards work on a<br>
location/mapping RDF vocabulary, this current work may inform any more<br>
formal efforts to follow.&quot;<br>
These terms do seem to have widespread usage in the semantic web.<br>
Should we be concerned that they are not part of a standard?<br>
2) geo:lat and geo:long are not semantically equivalent to the existing<br>
Darwin Core terms decimalLatitude and decimalLongitude, which have<br>
been a part of the Darwin Core since it 2003 (or before, if we ignore<br>
the missing Datum term in earlier versions). The addition of the geo:<br>
terms as a third set of geolocation terms for Darwin Core raised<br>
concerns about confusion, having so many spatially-related terms.<br>
I share this concern. An option would be to<br>
adopt these terms and deprecate dwc:decimalLatitude, dwc:Longitude,<br>
and dwc:geodeticDatum. Data that would have occupied these terms would<br>
go instead to dwc:verbatimLatitude dwc:verbatimLongitude, and<br>
dwc:verbatimSRS. I see a couple of problems with this. First, most of<br>
the time the data in the decimal coordinate fields are not the<br>
verbatim originals, so this would be a misuse of the Darwin Core<br>
terms. Second, this change would make it more difficult for data<br>
consumerís to use existing georeferences. Hereís how. Right now the<br>
verbatim fields are meant to hold the original coordinate information,<br>
which means they have a wide variety of content - everything from UTMs<br>
to custom-encoded coordinates, in any conceivable format. Meanwhile,<br>
the data in the decimal coordinates fields can be much more readily<br>
transformed into the desired standardized spatial reference system<br>
afforded by the geo: terms, because the values are at least<br>
standardized on geographic coordinates in decimal degrees and only a<br>
datum transformation has to be done on them to get geo_lat and geo:long.<br>
Do we abandon the dwc: terms decimalLatitude, decimalLongitude, and<br>
geodeticDatum? Do we abandon them now? Do we build the simplest<br>
possible tools necessary for anyone to do the transformations so that<br>
these terms are no longer needed? If so, do we wait until those tools<br>
exist before we abandon the terms and make millions of georeferenced<br>
records less readily usable?<br>
3) A request was expressed by one reviewer that the term geo:alt should<br>
be added. No one has made a formal request for this. However, if the<br>
other geo: terms were adopted, it might be silly not to adopt this one<br>
as well. Doing so would raise a host of issues similar to those raised<br>
for lat and lng, but related to the Darwin Core elevation terms. No discussion<br>
of these issues has yet taken place.<br>
tdwg-content mailing list<br>
<a href=""></a><br>
<a href="" target="_blank"></a><br>
</blockquote></div><br><br clear="all"><br>-- <br>John Deck<br>(541) 321-0689<br><br>