Re: [tdwg-content] [tdwg-tag] DwC change review: geo terms
(Sorry if you receive this twice - John asked to repost here.)
Where is adopting these terms now going to put us with respect to OGC standards, which, I think, will ultimately be more authoritative than an informal W3C vocabulary.
I don't have enough insight into OGC standards for vocabularies for describing geolocations, but I have also learned earlier this year from Flip Dibner (copied here) that there are efforts underway within OGC to create RDF vocabularies (presumably corresponding to OGC's XML standards?).
-hilmar
On Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
Hi John,
As you mention from previous discussion I would still adopt option number 1 as I believe there is enough tools out there to handle transformations. The current situation I think is much worst on the consumer part and I think is time to think more on data use than on data mobilization.
Best,
Javier.
On 07/09/2011, at 00:00, John Wieczorek tuco@berkeley.edu wrote:
Perhaps my message was too long for easy digestion and action, as I've received no responses. I will take the initiative to initiate option 3. No further action from the TAG on this at this point. Be prepared though, VOTES by the TAG on publicly resolved issues are forthcoming very soon.
On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek tuco@berkeley.edu wrote:
Hi TAGers,
I am deep in the review process for the proposed changes to Darwin Core, trying to do due diligence. Some of the change requests are challenging to summarize to determine if there is consensus, in spite of, or because of the discussions. One of the requests on which I’d like some TAG help before proposing a solution is the request for 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@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:lng 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:lng 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. 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 decimal degrees and only a datum transformation has to be done on them.
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?
- Additional concern was expressed that the term geo:alt should
also 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.
I don’t have a good solution. The best short-term one, in my opinion, is to leave Darwin Core as it is, and to recommend that if applications (or aggregators) want to share “cleansed” point-based georeferences, that they do so with the geo: tags, the values for which they derive through transformations to WGS84 of the DwC decimal coordinates and geodeticDatum.
Options:
- Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
list of recommended terms for DwC.
- Reject the proposal pending further directed research into a
comprehensive solution that considers all geospatial terms in Darwin Core (including footprintWKT, for example).
- Reject the proposal for now, reopening the public discussion with
these concerns.
Others?
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Yes, there are semantic efforts underway at OGC. Some of them are reaching a degree of maturity, e.g. GeoSPARQ, an extension of the SPARQL query language ( http://www.opengeospatial.org/projects/groups/geosparqlswg ). Other, more recent efforts are building upon the base classes defined by GeoSPARQL.
Flip
On Sep 9, 2011, at 2:17 PM, Hilmar Lapp wrote:
(Sorry if you receive this twice - John asked to repost here.)
Where is adopting these terms now going to put us with respect to OGC standards, which, I think, will ultimately be more authoritative than an informal W3C vocabulary.
I don't have enough insight into OGC standards for vocabularies for describing geolocations, but I have also learned earlier this year from Flip Dibner (copied here) that there are efforts underway within OGC to create RDF vocabularies (presumably corresponding to OGC's XML standards?).
-hilmar
On Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
Hi John,
As you mention from previous discussion I would still adopt option number 1 as I believe there is enough tools out there to handle transformations. The current situation I think is much worst on the consumer part and I think is time to think more on data use than on data mobilization.
Best,
Javier.
On 07/09/2011, at 00:00, John Wieczorek tuco@berkeley.edu wrote:
Perhaps my message was too long for easy digestion and action, as I've received no responses. I will take the initiative to initiate option 3. No further action from the TAG on this at this point. Be prepared though, VOTES by the TAG on publicly resolved issues are forthcoming very soon.
On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek tuco@berkeley.edu wrote:
Hi TAGers,
I am deep in the review process for the proposed changes to Darwin Core, trying to do due diligence. Some of the change requests are challenging to summarize to determine if there is consensus, in spite of, or because of the discussions. One of the requests on which I’d like some TAG help before proposing a solution is the request for 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@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:lng 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:lng 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. 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 decimal degrees and only a datum transformation has to be done on them.
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?
- Additional concern was expressed that the term geo:alt should also
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.
I don’t have a good solution. The best short-term one, in my opinion, is to leave Darwin Core as it is, and to recommend that if applications (or aggregators) want to share “cleansed” point-based georeferences, that they do so with the geo: tags, the values for which they derive through transformations to WGS84 of the DwC decimal coordinates and geodeticDatum.
Options:
- Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
list of recommended terms for DwC.
- Reject the proposal pending further directed research into a
comprehensive solution that considers all geospatial terms in Darwin Core (including footprintWKT, for example).
- Reject the proposal for now, reopening the public discussion with
these concerns.
Others?
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
Thanks, Flip, for the update. That page didn't have any links to candidate standards, working drafts, RDFS/OWL schemas, or other documents that would explain the current approach. Is the development of these proposals open to the public? I'd love to take a look at it.
Thanks, Matt
On Fri, Sep 9, 2011 at 2:01 PM, Phillip C. Dibner pcd@ecosystem.com wrote:
Yes, there are semantic efforts underway at OGC. Some of them are reaching a degree of maturity, e.g. GeoSPARQ, an extension of the SPARQL query language ( http://www.opengeospatial.org/projects/groups/geosparqlswg ). Other, more recent efforts are building upon the base classes defined by GeoSPARQL.
Flip
On Sep 9, 2011, at 2:17 PM, Hilmar Lapp wrote:
(Sorry if you receive this twice - John asked to repost here.)
Where is adopting these terms now going to put us with respect to OGC
standards, which, I think, will ultimately be more authoritative than an informal W3C vocabulary.
I don't have enough insight into OGC standards for vocabularies for
describing geolocations, but I have also learned earlier this year from Flip Dibner (copied here) that there are efforts underway within OGC to create RDF vocabularies (presumably corresponding to OGC's XML standards?).
-hilmarOn Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
Hi John,
As you mention from previous discussion I would still adopt option
number 1 as I believe there is enough tools out there to handle transformations. The current situation I think is much worst on the consumer part and I think is time to think more on data use than on data mobilization.
Best,
Javier.
On 07/09/2011, at 00:00, John Wieczorek tuco@berkeley.edu wrote:
Perhaps my message was too long for easy digestion and action, as I've received no responses. I will take the initiative to initiate option 3. No further action from the TAG on this at this point. Be prepared though, VOTES by the TAG on publicly resolved issues are forthcoming very soon.
On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek tuco@berkeley.edu
wrote:
Hi TAGers,
I am deep in the review process for the proposed changes to Darwin Core, trying to do due diligence. Some of the change requests are challenging to summarize to determine if there is consensus, in spite of, or because of the discussions. One of the requests on which I’d like some TAG help before proposing a solution is the request for 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@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:lng 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:lng 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. 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 decimal degrees and only a datum transformation has to be done on them.
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?
- Additional concern was expressed that the term geo:alt should also
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.
I don’t have a good solution. The best short-term one, in my opinion, is to leave Darwin Core as it is, and to recommend that if applications (or aggregators) want to share “cleansed” point-based georeferences, that they do so with the geo: tags, the values for which they derive through transformations to WGS84 of the DwC decimal coordinates and geodeticDatum.
Options:
- Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
list of recommended terms for DwC.
- Reject the proposal pending further directed research into a
comprehensive solution that considers all geospatial terms in Darwin Core (including footprintWKT, for example).
- Reject the proposal for now, reopening the public discussion with
these concerns.
Others?
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Hm, it appears that it has already been submitted for public review, and is being edited for final release by the working group. There may be some further activity at the upcoming OGC Technical Committee meeting in Boulder, Sep 19 - 22. Here is a better page: http://www.opengeospatial.org/standards/requests/80 . The notice says there's a more current copy on the Standards page, but it doesn't appear to be there yet. So the download on the above URL is probably the most current available.
Flip
On Sep 9, 2011, at 3:18 PM, Matt Jones wrote:
Thanks, Flip, for the update. That page didn't have any links to candidate standards, working drafts, RDFS/OWL schemas, or other documents that would explain the current approach. Is the development of these proposals open to the public? I'd love to take a look at it.
Thanks, Matt
On Fri, Sep 9, 2011 at 2:01 PM, Phillip C. Dibner pcd@ecosystem.com wrote: Yes, there are semantic efforts underway at OGC. Some of them are reaching a degree of maturity, e.g. GeoSPARQ, an extension of the SPARQL query language ( http://www.opengeospatial.org/projects/groups/geosparqlswg ). Other, more recent efforts are building upon the base classes defined by GeoSPARQL.
Flip
On Sep 9, 2011, at 2:17 PM, Hilmar Lapp wrote:
(Sorry if you receive this twice - John asked to repost here.)
Where is adopting these terms now going to put us with respect to OGC standards, which, I think, will ultimately be more authoritative than an informal W3C vocabulary.
I don't have enough insight into OGC standards for vocabularies for describing geolocations, but I have also learned earlier this year from Flip Dibner (copied here) that there are efforts underway within OGC to create RDF vocabularies (presumably corresponding to OGC's XML standards?).
-hilmarOn Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
Hi John,
As you mention from previous discussion I would still adopt option number 1 as I believe there is enough tools out there to handle transformations. The current situation I think is much worst on the consumer part and I think is time to think more on data use than on data mobilization.
Best,
Javier.
On 07/09/2011, at 00:00, John Wieczorek tuco@berkeley.edu wrote:
Perhaps my message was too long for easy digestion and action, as I've received no responses. I will take the initiative to initiate option 3. No further action from the TAG on this at this point. Be prepared though, VOTES by the TAG on publicly resolved issues are forthcoming very soon.
On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek tuco@berkeley.edu wrote:
Hi TAGers,
I am deep in the review process for the proposed changes to Darwin Core, trying to do due diligence. Some of the change requests are challenging to summarize to determine if there is consensus, in spite of, or because of the discussions. One of the requests on which I’d like some TAG help before proposing a solution is the request for 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@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:lng 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:lng 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. 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 decimal degrees and only a datum transformation has to be done on them.
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?
- Additional concern was expressed that the term geo:alt should also
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.
I don’t have a good solution. The best short-term one, in my opinion, is to leave Darwin Core as it is, and to recommend that if applications (or aggregators) want to share “cleansed” point-based georeferences, that they do so with the geo: tags, the values for which they derive through transformations to WGS84 of the DwC decimal coordinates and geodeticDatum.
Options:
- Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
list of recommended terms for DwC.
- Reject the proposal pending further directed research into a
comprehensive solution that considers all geospatial terms in Darwin Core (including footprintWKT, for example).
- Reject the proposal for now, reopening the public discussion with
these concerns.
Others?
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
Thanks, that helps. I looked at it very quickly so far, and so I could very easily have missed key information -- so be sure to let me know what I misinterpreted. Nevertheless, if I'm reading this correctly, they are proposing that instance data be represented as WKT (section 8.5) or GML (section 8.6) literal values. The example they give for encoding a Point is:
<sfg:Point rdf:about="http://somewhere/ApplicationSchema#APointGeom%22%3E <geo:asWKT rdf:datatype= "http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral%22%3E <![CDATA[ <http://www.opengis.net/def/crs/OGC/1.3/CRS84> Point(-83.4 34.3) ]]> </geo:asWKT> </sfg:Point>
Instead of get:asWKT they also allow the geo:asGML property to encode as a GML literal as well. But in either case, there is no direct RDF class that exposes the spatial concepts -- they are buried in a liter syntactic encoding from other languages.
I'm not seeing in there anything corresponding to the W3C lat and lng concepts. Did I miss it?
Matt
On Fri, Sep 9, 2011 at 2:36 PM, Phillip C. Dibner pcd@ecosystem.com wrote:
Hm, it appears that it has already been submitted for public review, and is being edited for final release by the working group. There may be some further activity at the upcoming OGC Technical Committee meeting in Boulder, Sep 19 - 22. Here is a better page: http://www.opengeospatial.org/standards/requests/80 . The notice says there's a more current copy on the Standards page, but it doesn't appear to be there yet. So the download on the above URL is probably the most current available.
Flip
On Sep 9, 2011, at 3:18 PM, Matt Jones wrote:
Thanks, Flip, for the update. That page didn't have any links to candidate standards, working drafts, RDFS/OWL schemas, or other documents that would explain the current approach. Is the development of these proposals open to the public? I'd love to take a look at it.
Thanks, Matt
On Fri, Sep 9, 2011 at 2:01 PM, Phillip C. Dibner pcd@ecosystem.comwrote:
Yes, there are semantic efforts underway at OGC. Some of them are reaching a degree of maturity, e.g. GeoSPARQ, an extension of the SPARQL query language ( http://www.opengeospatial.org/projects/groups/geosparqlswg ). Other, more recent efforts are building upon the base classes defined by GeoSPARQL.
Flip
On Sep 9, 2011, at 2:17 PM, Hilmar Lapp wrote:
(Sorry if you receive this twice - John asked to repost here.)
Where is adopting these terms now going to put us with respect to OGC
standards, which, I think, will ultimately be more authoritative than an informal W3C vocabulary.
I don't have enough insight into OGC standards for vocabularies for
describing geolocations, but I have also learned earlier this year from Flip Dibner (copied here) that there are efforts underway within OGC to create RDF vocabularies (presumably corresponding to OGC's XML standards?).
-hilmarOn Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
Hi John,
As you mention from previous discussion I would still adopt option
number 1 as I believe there is enough tools out there to handle transformations. The current situation I think is much worst on the consumer part and I think is time to think more on data use than on data mobilization.
Best,
Javier.
On 07/09/2011, at 00:00, John Wieczorek tuco@berkeley.edu wrote:
Perhaps my message was too long for easy digestion and action, as I've received no responses. I will take the initiative to initiate option 3. No further action from the TAG on this at this point. Be prepared though, VOTES by the TAG on publicly resolved issues are forthcoming very soon.
On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek tuco@berkeley.edu
wrote:
Hi TAGers,
I am deep in the review process for the proposed changes to Darwin Core, trying to do due diligence. Some of the change requests are challenging to summarize to determine if there is consensus, in spite of, or because of the discussions. One of the requests on which I’d like some TAG help before proposing a solution is the request for 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@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:lng 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:lng 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. 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 decimal degrees and only a datum transformation has
to
be done on them.
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?
- Additional concern was expressed that the term geo:alt should also
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.
I don’t have a good solution. The best short-term one, in my opinion, is to leave Darwin Core as it is, and to recommend that if applications (or aggregators) want to share “cleansed” point-based georeferences, that they do so with the geo: tags, the values for which they derive through transformations to WGS84 of the DwC decimal coordinates and geodeticDatum.
Options:
- Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
list of recommended terms for DwC.
- Reject the proposal pending further directed research into a
comprehensive solution that considers all geospatial terms in Darwin Core (including footprintWKT, for example).
- Reject the proposal for now, reopening the public discussion with
these concerns.
Others?
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
I've only been following this work from a distance. I thought they had gone further, but it appears that you are right, at least in this version. I'm sure the existence of a pure RDF representation would be obvious, and it is not.
This is something to ask about at the upcoming meeting, which I will certainly do.
Flip
On Sep 9, 2011, at 4:27 PM, Matt Jones wrote:
Thanks, that helps. I looked at it very quickly so far, and so I could very easily have missed key information -- so be sure to let me know what I misinterpreted. Nevertheless, if I'm reading this correctly, they are proposing that instance data be represented as WKT (section 8.5) or GML (section 8.6) literal values. The example they give for encoding a Point is:
<sfg:Point rdf:about="http://somewhere/ApplicationSchema#APointGeom%22%3E <geo:asWKT rdf:datatype= "http://www.opengis.net/def/dataType/OGC-SF/1.0/WKTLiteral%22%3E <![CDATA[ <http://www.opengis.net/def/crs/OGC/1.3/CRS84> Point(-83.4 34.3) ]]> </geo:asWKT> </sfg:Point>
Instead of get:asWKT they also allow the geo:asGML property to encode as a GML literal as well. But in either case, there is no direct RDF class that exposes the spatial concepts -- they are buried in a liter syntactic encoding from other languages.
I'm not seeing in there anything corresponding to the W3C lat and lng concepts. Did I miss it?
Matt
On Fri, Sep 9, 2011 at 2:36 PM, Phillip C. Dibner pcd@ecosystem.com wrote: Hm, it appears that it has already been submitted for public review, and is being edited for final release by the working group. There may be some further activity at the upcoming OGC Technical Committee meeting in Boulder, Sep 19 - 22. Here is a better page: http://www.opengeospatial.org/standards/requests/80 . The notice says there's a more current copy on the Standards page, but it doesn't appear to be there yet. So the download on the above URL is probably the most current available.
Flip
On Sep 9, 2011, at 3:18 PM, Matt Jones wrote:
Thanks, Flip, for the update. That page didn't have any links to candidate standards, working drafts, RDFS/OWL schemas, or other documents that would explain the current approach. Is the development of these proposals open to the public? I'd love to take a look at it.
Thanks, Matt
On Fri, Sep 9, 2011 at 2:01 PM, Phillip C. Dibner pcd@ecosystem.com wrote: Yes, there are semantic efforts underway at OGC. Some of them are reaching a degree of maturity, e.g. GeoSPARQ, an extension of the SPARQL query language ( http://www.opengeospatial.org/projects/groups/geosparqlswg ). Other, more recent efforts are building upon the base classes defined by GeoSPARQL.
Flip
On Sep 9, 2011, at 2:17 PM, Hilmar Lapp wrote:
(Sorry if you receive this twice - John asked to repost here.)
Where is adopting these terms now going to put us with respect to OGC standards, which, I think, will ultimately be more authoritative than an informal W3C vocabulary.
I don't have enough insight into OGC standards for vocabularies for describing geolocations, but I have also learned earlier this year from Flip Dibner (copied here) that there are efforts underway within OGC to create RDF vocabularies (presumably corresponding to OGC's XML standards?).
-hilmarOn Sep 6, 2011, at 6:33 PM, Javier de la Torre wrote:
Hi John,
As you mention from previous discussion I would still adopt option number 1 as I believe there is enough tools out there to handle transformations. The current situation I think is much worst on the consumer part and I think is time to think more on data use than on data mobilization.
Best,
Javier.
On 07/09/2011, at 00:00, John Wieczorek tuco@berkeley.edu wrote:
Perhaps my message was too long for easy digestion and action, as I've received no responses. I will take the initiative to initiate option 3. No further action from the TAG on this at this point. Be prepared though, VOTES by the TAG on publicly resolved issues are forthcoming very soon.
On Sat, Sep 3, 2011 at 9:34 AM, John Wieczorek tuco@berkeley.edu wrote:
Hi TAGers,
I am deep in the review process for the proposed changes to Darwin Core, trying to do due diligence. Some of the change requests are challenging to summarize to determine if there is consensus, in spite of, or because of the discussions. One of the requests on which I’d like some TAG help before proposing a solution is the request for 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@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:lng 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:lng 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. 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 decimal degrees and only a datum transformation has to be done on them.
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?
- Additional concern was expressed that the term geo:alt should also
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.
I don’t have a good solution. The best short-term one, in my opinion, is to leave Darwin Core as it is, and to recommend that if applications (or aggregators) want to share “cleansed” point-based georeferences, that they do so with the geo: tags, the values for which they derive through transformations to WGS84 of the DwC decimal coordinates and geodeticDatum.
Options:
- Accept the proposal, adding geo:lat, geo:lng, and geo:alt to the
list of recommended terms for DwC.
- Reject the proposal pending further directed research into a
comprehensive solution that considers all geospatial terms in Darwin Core (including footprintWKT, for example).
- Reject the proposal for now, reopening the public discussion with
these concerns.
Others?
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
participants (3)
-
Hilmar Lapp -
Matt Jones -
Phillip C. Dibner