time and space namespaces in Darwin Core
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
Shouldn't the RDF for DwC link DwC:lat to geo:lat (using some subtype or better yet equivalency relation)? And shouldn't hence Linked Data browsers be able to use DwC:lat in the same way as geo:lat?
-hilmar
On Aug 6, 2010, at 11:01 AM, joel sachs wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/ wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
On Fri, 6 Aug 2010, Hilmar Lapp wrote:
Shouldn't the RDF for DwC link DwC:lat to geo:lat (using some subtype or better yet equivalency relation)? And shouldn't hence Linked Data browsers be able to use DwC:lat in the same way as geo:lat?
Yes. But no Linked Data browser I'm aware of applies owl:equivalentProperty assetions before rendering the data. (In fact, most do no reasoning at all.) I agree that, whatever our default display, it should include the appropriate mapping statements, either via an rdfs:seeAlso or similar link, or directly in the document.
Joel.
-hilmar
On Aug 6, 2010, at 11:01 AM, joel sachs wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/ wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
There is actually no equivalency between dwc:decimalLatitude and geo:lat because geo:lat is specified to represent the latitude in the WGS84 spatial reference system and dwc:decimalLatitude has no such such restriction.
On Fri, Aug 6, 2010 at 10:08 AM, joel sachs jsachs@csee.umbc.edu wrote:
On Fri, 6 Aug 2010, Hilmar Lapp wrote:
Shouldn't the RDF for DwC link DwC:lat to geo:lat (using some subtype or better yet equivalency relation)? And shouldn't hence Linked Data browsers be able to use DwC:lat in the same way as geo:lat?
Yes. But no Linked Data browser I'm aware of applies owl:equivalentProperty assetions before rendering the data. (In fact, most do no reasoning at all.) I agree that, whatever our default display, it should include the appropriate mapping statements, either via an rdfs:seeAlso or similar link, or directly in the document.
Joel.
-hilmarOn Aug 6, 2010, at 11:01 AM, joel sachs wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/ wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
--
: Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org :
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
I agree. there are a number of tools that can interpret the geo: standard and it is not as if the alternatives are more accurate.
I never understood why this issue is any different that having people standardize on meters.
The issue of error can be dealt with with the addition of another field.
I think a better solution might be easy-to-use tools that let groups convert their records to geo:lat and geo:long before submitting them.
- Pete
On Fri, Aug 6, 2010 at 10:01 AM, joel sachs jsachs@csee.umbc.edu wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
On Tue, Aug 10, 2010 at 1:57 AM, Peter DeVries pete.devries@gmail.comwrote:
I agree. there are a number of tools that can interpret the geo: standard and it is not as if the alternatives are more accurate.
I never understood why this issue is any different that having people standardize on meters.
Everyone except Americans understand meters. And even Americans can type "15 meters in feet" into a Google search and figure out the conversion. ;-)
383 students of our georeferencing workshops to date understand datums (more, if you count the workshop at Yale this week). Of those, I estimate realistically that ten of them knew what a datum was before they attended the workshop. Those same ten are probably the only ones still who would be able to transform coordinates from one datum to another. Therein lies the big difference - it isn't easy. Part of not being easy is not having tools. With existing tools (GIS), you must have expertise that is uncommon among those who are contributing the data. To me it seems an unreasonable expectation under current conditions that the not just the average data contributor, but every data contributor must have the responsibility for this conversion. The reality is that these many of these people do not have the human resources to keep up with actual errors in their databases, let alone prepare data to be more appetizing to developers with a risk of creating further, undetectable errors.
The issue of error can be dealt with with the addition of another field.
A field beyond dwc:coordinateUncertaintyInMeters? If so, for what error?
I think a better solution might be easy-to-use tools that let groups convert their records to geo:lat and geo:long before submitting them.
Now you are talking, except that, better than a tool that the contributors use, a tool that developers use. That way any errors will be systemic, detectable, and correctable in one place. Don't forget that our best practices for data quality recommend that we lose nothing of the verbatim original information.
- Pete
On Fri, Aug 6, 2010 at 10:01 AM, joel sachs jsachs@csee.umbc.edu wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
--
Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 GeoSpecies Knowledge Base About the GeoSpecies Knowledge Base
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
I was wondering if something like the following would be an acceptable compromise for those who would like to expose their data using the geo vocabulary.
geo:lat geo:long dwc:coordinateUncertaintyInMeters
The idea would be that RDF formatted in this way would be acceptable as DarwinCore.
This would not prevent others from using the traditional dwc vocabulary.
The problem for many is that by using only the dwc version they use the ability to take advantage of many existing tools and api's.
- Pete
On Fri, Aug 6, 2010 at 10:01 AM, joel sachs jsachs@csee.umbc.edu wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
Catching up on this diverse thread...
I suspect the sources for coordinates the BioBlitz will be phones and GPS receivers. I don't know of any phone application or consumer GPS receiver that provides coordinates in a reference system other than WGS84 by default. As Peter suggests, under these assumptions it would be fine to capture geo:lat, geo:long, and dwc:coordinateUncertaintyInMeters in the field. The expression of these data in Darwin Core would be dwc:decimalLatitude: dwc:decimalLongitude, dwc:geodeticDatum=WGS84 or wc:geodeticDatum=epsg:4326, dwc:coordinateUncertaintyInMeters.
It would be a nice educational exercise to assess the parameters of the devices before starting to use them to take data. What are the accuracies of those phones compared to the GPSs? And of the GPSs compared to reality and to their theoretical (and ephemeral) accuracy readings?
For completeness one could add the other georeference metadata fields meant to provide completeness (strictly for educational purposes, of course), but I won't push it.
On Sat, Aug 21, 2010 at 8:19 PM, Peter DeVries pete.devries@gmail.comwrote:
I was wondering if something like the following would be an acceptable compromise for those who would like to expose their data using the geo vocabulary.
geo:lat geo:long dwc:coordinateUncertaintyInMeters
The idea would be that RDF formatted in this way would be acceptable as DarwinCore.
This would not prevent others from using the traditional dwc vocabulary.
The problem for many is that by using only the dwc version they use the ability to take advantage of many existing tools and api's.
- Pete
On Fri, Aug 6, 2010 at 10:01 AM, joel sachs jsachs@csee.umbc.edu wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
--
Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 GeoSpecies Knowledge Base About the GeoSpecies Knowledge Base
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
I looked through my iPhone programming book and the iPhone does output an accuracy measure that can be in meters.
I don't now if all the applications expose this functionality but I did find one for iPhone / iPad that does.
http://gps.motionx.com/iphone/overview/
http://gps.motionx.com/iphone/overview/- Pete
On Tue, Aug 24, 2010 at 3:44 PM, John Wieczorek tuco@berkeley.edu wrote:
Catching up on this diverse thread...
I suspect the sources for coordinates the BioBlitz will be phones and GPS receivers. I don't know of any phone application or consumer GPS receiver that provides coordinates in a reference system other than WGS84 by default. As Peter suggests, under these assumptions it would be fine to capture geo:lat, geo:long, and dwc:coordinateUncertaintyInMeters in the field. The expression of these data in Darwin Core would be dwc:decimalLatitude: dwc:decimalLongitude, dwc:geodeticDatum=WGS84 or wc:geodeticDatum=epsg:4326, dwc:coordinateUncertaintyInMeters.
It would be a nice educational exercise to assess the parameters of the devices before starting to use them to take data. What are the accuracies of those phones compared to the GPSs? And of the GPSs compared to reality and to their theoretical (and ephemeral) accuracy readings?
For completeness one could add the other georeference metadata fields meant to provide completeness (strictly for educational purposes, of course), but I won't push it.
On Sat, Aug 21, 2010 at 8:19 PM, Peter DeVries pete.devries@gmail.comwrote:
I was wondering if something like the following would be an acceptable compromise for those who would like to expose their data using the geo vocabulary.
geo:lat geo:long dwc:coordinateUncertaintyInMeters
The idea would be that RDF formatted in this way would be acceptable as DarwinCore.
This would not prevent others from using the traditional dwc vocabulary.
The problem for many is that by using only the dwc version they use the ability to take advantage of many existing tools and api's.
- Pete
On Fri, Aug 6, 2010 at 10:01 AM, joel sachs jsachs@csee.umbc.edu wrote:
All,
When representing observation records in RDF, there are advantages to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/wgs84_pos#) namespaces where possible. For example, if we use DC:date, and geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, then Linked Data browsers can automatically map the records, plot them on a timeline, etc.
My question is: What are the disadvantages to doing this? (For example, is this going to break someone's DwC validator?)
Thanks - Joel.
--
Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 GeoSpecies Knowledge Base About the GeoSpecies Knowledge Base
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
participants (4)
-
Hilmar Lapp -
joel sachs -
John Wieczorek -
Peter DeVries