Re: [tdwg-tag] time and space namespaces in Darwin Core
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote:
Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.comwrote:
I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
*Javier de la Torre* *www.vizzuality.com*
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote:
Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
Hi,
Ok. That being said, I dont want anybody to die!, why dont we do the same as with dates. We have a verbatimLatitude and verbatiumLongitude already, why those people dont use that? They should only use DecimalLatitude if they know they have WGS84. If they use them incorrectly, well, thats happening all day on the network of GBIF data providers, and I dont think DWC can changed much on that. What we need is better tools for them to publish their data, no overcomplicate the standard just to avoid people using it wrong.
What I want is to help developers using data. If our data will not correctly get displayed on a map we have an issue. I would say that considering the defacto standard of WGS84 for coordinates we will find lot of wrong maps out there because developers think that this is all WGS84 (they also dont know what this is), they will just throw them into Google Maps and they will be wrong, even if providers set the geodeticDatum.
Probably this discussion is about where to push, the data provider or the developer. Beacuse the developer has to deal with thousands of providers, I think he has a worst job than the provider, plus is the last on the chain of data transformation. We dont want Pumas dissapearing because developers didnt handle SRS transformations that he didnt even knew.
Finally, SRS I dont think are standarized, look at the reference you give (http://spatialreference.org/) and you will see that you can Upload your own. Ok I am a provider and decide to use my own SRS that I have created (or more normally, something is wrong) and upload it there... there is no tool that will resolve SRS automatically to do transformations.
Now, if the provider knows what an SRS is, which Darwin Core force them to declare, I think they should might be able to actually transform previously to WGS84 and place their own stuff in Verbatium.
Finally, I am a developer, get data from 100 providers, some got really wrong the SRS, how am I gonna know which ones? Now the provider has a good tool, visualize his data in Google Maps for example and discover that the locations look wrong. I think the second is a much easier place to resolve the issue.
But I am a developer and maybe biassed.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:46 PM, John Wieczorek wrote:
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.com wrote: I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
What I want is to help developers using data. If our data will not correctly get displayed on a map we have an issue.
Could you just add derived coordinate properties (separate from Darwin Core) to your data? Then you could document these properties as "mappable as WGS84" and then your developers don't need to worry about underlying projection issue.
What I want is to help developers using data. If our data will not correctly get displayed on a map we have an issue.
Could you just add derived coordinate properties (separate from Darwin Core) to your data? Then you could document these properties as "mappable as WGS84" and then your developers don't need to worry about underlying projection issue.
Well, I dont have data, I mean, I am a developer which is worry that other developers will not get it right, and making the most obvious LatLng properties of DWC not matching current trend is what worries me. This thread actually get started because of this issue.
On Mon, 9 Aug 2010, Javier de la Torre wrote:
Hi,
Ok. That being said, I dont want anybody to die!,
Me neither.
I've copied in the tdwg-bioblitz group, which at some point got dropped from this discussion. If anyone is interested, the full discussion can be found at http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/thread.html
For the bioblitz, I think we can do the following:
i. Since GPS uses WGS84, any smartphone app that's getting coordinates from the phone's built in GPS can correctly label the coordinates "geo:lat", and "geo:long". The semantics of the location columns in the Google Fusion Table will be "WGS84". (see (iii) for the exceptions.) When we publish DwC from the Fusion Table, we can and should use DwC:decimalLatitude, DwC:decimalLongitude, and DwC:geodeticDatum (set to WGS84).
ii. We should record uncertainty. GPS uncertainty varies with the weather, whether the user is moving, availability of WAAS, etc. So developers should ensure that uncertainty is captured each time their app makes a measurement. We'll add an uncertainty column to the Fusion table. (It will be interesting to see the range of uncertainty measures in the observations.)
iii. If someone does precision surveying using a local datum, instead of WGS84, she must take care that the column names for lat and long in her Fusion Table are not the same as the column names in the master table. Thus, when the data is merged, her coordinates won't end up in the columns with the implied WGS84 semantics.
Can we agree on that?
Many thanks! Joel.
why dont we do the same as with dates. We have a verbatimLatitude and verbatiumLongitude already, why those people dont use that? They should only use DecimalLatitude if they know they have WGS84. If they use them incorrectly, well, thats happening all day on the network of GBIF data providers, and I dont think DWC can changed much on that. What we need is better tools for them to publish their data, no overcomplicate the standard just to avoid people using it wrong.
What I want is to help developers using data. If our data will not correctly get displayed on a map we have an issue. I would say that considering the defacto standard of WGS84 for coordinates we will find lot of wrong maps out there because developers think that this is all WGS84 (they also dont know what this is), they will just throw them into Google Maps and they will be wrong, even if providers set the geodeticDatum.
Probably this discussion is about where to push, the data provider or the developer. Beacuse the developer has to deal with thousands of providers, I think he has a worst job than the provider, plus is the last on the chain of data transformation. We dont want Pumas dissapearing because developers didnt handle SRS transformations that he didnt even knew.
Finally, SRS I dont think are standarized, look at the reference you give (http://spatialreference.org/) and you will see that you can Upload your own. Ok I am a provider and decide to use my own SRS that I have created (or more normally, something is wrong) and upload it there... there is no tool that will resolve SRS automatically to do transformations.
Now, if the provider knows what an SRS is, which Darwin Core force them to declare, I think they should might be able to actually transform previously to WGS84 and place their own stuff in Verbatium.
Finally, I am a developer, get data from 100 providers, some got really wrong the SRS, how am I gonna know which ones? Now the provider has a good tool, visualize his data in Google Maps for example and discover that the locations look wrong. I think the second is a much easier place to resolve the issue.
But I am a developer and maybe biassed.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:46 PM, John Wieczorek wrote:
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naivet�, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.com wrote: I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
+1 for bioblitz.
I will add that because Fusion tables use WGS84 for geometries it is important that we don't mix them. We will be relying on the spatial capabilities on fusion tables for data visualization.
Javier www.vizzuality.com
On 12/08/2010, at 03:52, joel sachs jsachs@csee.umbc.edu wrote:
On Mon, 9 Aug 2010, Javier de la Torre wrote:
Hi,
Ok. That being said, I dont want anybody to die!,
Me neither.
I've copied in the tdwg-bioblitz group, which at some point got dropped from this discussion. If anyone is interested, the full discussion can be found at http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/thread.html
For the bioblitz, I think we can do the following:
i. Since GPS uses WGS84, any smartphone app that's getting coordinates from the phone's built in GPS can correctly label the coordinates "geo:lat", and "geo:long". The semantics of the location columns in the Google Fusion Table will be "WGS84". (see (iii) for the exceptions.) When we publish DwC from the Fusion Table, we can and should use DwC:decimalLatitude, DwC:decimalLongitude, and DwC:geodeticDatum (set to WGS84).
ii. We should record uncertainty. GPS uncertainty varies with the weather, whether the user is moving, availability of WAAS, etc. So developers should ensure that uncertainty is captured each time their app makes a measurement. We'll add an uncertainty column to the Fusion table. (It will be interesting to see the range of uncertainty measures in the observations.)
iii. If someone does precision surveying using a local datum, instead of WGS84, she must take care that the column names for lat and long in her Fusion Table are not the same as the column names in the master table. Thus, when the data is merged, her coordinates won't end up in the columns with the implied WGS84 semantics.
Can we agree on that?
Many thanks! Joel.
why dont we do the same as with dates. We have a verbatimLatitude and verbatiumLongitude already, why those people dont use that? They should only use DecimalLatitude if they know they have WGS84. If they use them incorrectly, well, thats happening all day on the network of GBIF data providers, and I dont think DWC can changed much on that. What we need is better tools for them to publish their data, no overcomplicate the standard just to avoid people using it wrong.
What I want is to help developers using data. If our data will not correctly get displayed on a map we have an issue. I would say that considering the defacto standard of WGS84 for coordinates we will find lot of wrong maps out there because developers think that this is all WGS84 (they also dont know what this is), they will just throw them into Google Maps and they will be wrong, even if providers set the geodeticDatum.
Probably this discussion is about where to push, the data provider or the developer. Beacuse the developer has to deal with thousands of providers, I think he has a worst job than the provider, plus is the last on the chain of data transformation. We dont want Pumas dissapearing because developers didnt handle SRS transformations that he didnt even knew.
Finally, SRS I dont think are standarized, look at the reference you give (http://spatialreference.org/) and you will see that you can Upload your own. Ok I am a provider and decide to use my own SRS that I have created (or more normally, something is wrong) and upload it there... there is no tool that will resolve SRS automatically to do transformations.
Now, if the provider knows what an SRS is, which Darwin Core force them to declare, I think they should might be able to actually transform previously to WGS84 and place their own stuff in Verbatium.
Finally, I am a developer, get data from 100 providers, some got really wrong the SRS, how am I gonna know which ones? Now the provider has a good tool, visualize his data in Google Maps for example and discover that the locations look wrong. I think the second is a much easier place to resolve the issue.
But I am a developer and maybe biassed.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:46 PM, John Wieczorek wrote:
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.com wrote: I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 : ==========================================================>>>>>
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
+1. Excellent recommendations for BioBlitz.
On Wed, Aug 11, 2010 at 6:52 PM, joel sachs jsachs@csee.umbc.edu wrote:
On Mon, 9 Aug 2010, Javier de la Torre wrote:
Hi,
Ok. That being said, I dont want anybody to die!,
Me neither.
I've copied in the tdwg-bioblitz group, which at some point got dropped from this discussion. If anyone is interested, the full discussion can be found at http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/thread.html
For the bioblitz, I think we can do the following:
i. Since GPS uses WGS84, any smartphone app that's getting coordinates from the phone's built in GPS can correctly label the coordinates "geo:lat", and "geo:long". The semantics of the location columns in the Google Fusion Table will be "WGS84". (see (iii) for the exceptions.) When we publish DwC from the Fusion Table, we can and should use DwC:decimalLatitude, DwC:decimalLongitude, and DwC:geodeticDatum (set to WGS84).
ii. We should record uncertainty. GPS uncertainty varies with the weather, whether the user is moving, availability of WAAS, etc. So developers should ensure that uncertainty is captured each time their app makes a measurement. We'll add an uncertainty column to the Fusion table. (It will be interesting to see the range of uncertainty measures in the observations.)
iii. If someone does precision surveying using a local datum, instead of WGS84, she must take care that the column names for lat and long in her Fusion Table are not the same as the column names in the master table. Thus, when the data is merged, her coordinates won't end up in the columns with the implied WGS84 semantics.
Can we agree on that?
Many thanks! Joel.
why dont we do the same as with dates. We have a verbatimLatitude and verbatiumLongitude already, why those people dont use that? They should only use DecimalLatitude if they know they have WGS84. If they use them incorrectly, well, thats happening all day on the network of GBIF data providers, and I dont think DWC can changed much on that. What we need is better tools for them to publish their data, no overcomplicate the standard just to avoid people using it wrong.
What I want is to help developers using data. If our data will not correctly get displayed on a map we have an issue. I would say that considering the defacto standard of WGS84 for coordinates we will find lot of wrong maps out there because developers think that this is all WGS84 (they also dont know what this is), they will just throw them into Google Maps and they will be wrong, even if providers set the geodeticDatum.
Probably this discussion is about where to push, the data provider or the developer. Beacuse the developer has to deal with thousands of providers, I think he has a worst job than the provider, plus is the last on the chain of data transformation. We dont want Pumas dissapearing because developers didnt handle SRS transformations that he didnt even knew.
Finally, SRS I dont think are standarized, look at the reference you give (http://spatialreference.org/) and you will see that you can Upload your own. Ok I am a provider and decide to use my own SRS that I have created (or more normally, something is wrong) and upload it there... there is no tool that will resolve SRS automatically to do transformations.
Now, if the provider knows what an SRS is, which Darwin Core force them to declare, I think they should might be able to actually transform previously to WGS84 and place their own stuff in Verbatium.
Finally, I am a developer, get data from 100 providers, some got really wrong the SRS, how am I gonna know which ones? Now the provider has a good tool, visualize his data in Google Maps for example and discover that the locations look wrong. I think the second is a much easier place to resolve the issue.
But I am a developer and maybe biassed.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:46 PM, John Wieczorek wrote:
The reason is simple, we want to help data publishers. It doesn't help
data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.com wrote: I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information
(dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 : ===========================================================
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.comwrote:
I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
*Javier de la Torre* *www.vizzuality.com*
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote:
Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
tdwg-tag mailing list
tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
We are not helping the data providers if we suggest that they publish in a way that is not usable, re-usable to downstream research. In fact, you/we are doing the data providers a disservice by suggesting that they do not need to do so. If indeed we do, then the data brokers, whether GBIF, Manis, Ornis, Vertnet, etc, have the responsibility to ensure that the data can be transformed into standard reference systems. Given the investment already made in these data improvement tools, I can't quite see why these rather simple geospatial transformations aren't extant. If we can't support the geo: namespace, then I'm starting to believe that we deserve the perception in various research/development communities that these data are not particularly useful.
Verbatim geo-temporal information is fine, and DWC is honest with this representation. Let's just make sure we accompany with standard reference systems resolved appropriately. If you have a a lat/long coordinate pair associated with an unknown datum and an uncertainty measure of your pleasure, then you can also represent it as some WGS84 based feature.
On Aug 9, 2010, at 10:47 AM, John Wieczorek wrote:
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.com wrote: I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
Javier de la Torre www.vizzuality.com
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/ lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote: Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept
the geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
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
On Mon, Aug 9, 2010 at 8:16 PM, Reed Beaman rbeaman@ufl.edu wrote:
We are not helping the data providers if we suggest that they publish in a way that is not usable, re-usable to downstream research. In fact, you/we are doing the data providers a disservice by suggesting that they do not need to do so.
I disagree for reasons set forth in the previous response to Peter DeVries.
If indeed we do, then the data brokers, whether GBIF, Manis, Ornis, Vertnet, etc, have the responsibility to ensure that the data can be transformed into standard reference systems.
I agree wholeheartedly.
Given the investment already made in these data improvement tools, I can't quite see why these rather simple geospatial transformations aren't extant.
I agree again. I could do it properly with two months of free time. Maybe this field season.
If we can't support the geo: namespace, then I'm starting to believe that we deserve the perception in various research/development communities that these data are not particularly useful.
Verbatim geo-temporal information is fine, and DWC is honest with this representation. Let's just make sure we accompany with standard reference systems resolved appropriately. If you have a a lat/long coordinate pair associated with an unknown datum and an uncertainty measure of your pleasure, then you can also represent it as some WGS84 based feature.
Yes. Lets. Just as we use appropriate terms from Dublin Core in Darwin Core, let's do so with geo:lat and geo:long for the sake of interoperability and rigorously correct semantics.
The next steps toward adoption are explained under section 3.4 of the Darwin Core Namespace Policy ( http://rs.tdwg.org/dwc/terms/namespace/index.htm#classesofchanges). I hereby make a formal request of the Technical Architecture Group (TAG) to add these two terms to the Darwin Core documentation. I have added the recommendation to the Darwin Core issue tracker as Issue 82 (http://goo.gl/XhxM). It is now up to the TAG to pursue a public request for comments if the request is deemed to have merit.
On Aug 9, 2010, at 10:47 AM, John Wieczorek wrote:
The reason is simple, we want to help data publishers. It doesn't help data publishers if they can't publish what they have - it would mean there is no room for data improvement tools. That would be sad. Worse, most people haven't a clue what a datum is, or how it can ruin your whole day (or life, in at least one sad case of a crashed helicopter in Patagonia). Given this naiveté, people would simply put whatever geographic coordinates they have into geo:lat/lon and no one would have any way to know that they are incorrect.
Note that Darwin Core offers data publishers options to publish event information with year, month, day, startDayOfYear, endDayOfYear, and verbatimEventDate in addition to eventDate and eventTime - same philosophy.
On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre jatorre@gmail.comwrote:
I am not sure I understand why we can not set DWC fields to conform to WGS84 and then use what everybody else is using.
For example in eventDate DWC conforms to ISO 8601, why dont we do the same for location... it would allow to simplify it quite a lot and be more compliant with other standards-existing apps, etc.
Just an idea.
*Javier de la Torre* *www.vizzuality.com*
On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote:
The partially good news is that if enough information (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can be determined from it. More disturbing to me is that anyone would think geo:lat/lon alone is sufficient for any application, as it carries no notion of uncertainty and therefore fitness for use. Add dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you must) to the mix and I would be much happier.
On Sun, Aug 8, 2010 at 11:26 PM, Garry.Jolley-Rogers@csiro.au wrote:
Hi Jim, Thanks. Had this aside to read in detail later. I think John is right... As same value with different constraints mean different interpretations are possible and seems to be the key thing. How are the values to be interpreted.
G
-----Original Message----- From: Jim Croft [mailto:jim.croft@gmail.com] Sent: Monday, 9 August 2010 4:12 PM To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, Crace); Greg Whitbread Cc: tuco@berkeley.edu Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core
Did you catch this thread on tdwg-tag? It is an almost exact mirror of the conversations we have be having in the taxon profile space, but involving the specimen locational data.
From John's comments it would appear he is not prepared to accept the
geo: and dwc: lat/long as 'exact match' because, although they are the same values, they have different constraints (or more precisely one one has a constraint and one doesn't).
I wouldn't have picked it but this looks like a case for 'closematch'.
jim
---------- Forwarded message ---------- From: John Wieczorek tuco@berkeley.edu Date: Mon, Aug 9, 2010 at 3:56 AM Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core To: joel sachs jsachs@csee.umbc.edu Cc: tdwg-bioblitz@googlegroups.com, tdwg-tag@lists.tdwg.org
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 :
Jim Croft ~ jim.croft@gmail.com ~ +61-2-62509499 ~ http://www.google.com/profiles/jim.croft 'A civilized society is one which tolerates eccentricity to the point of doubtful sanity.'
- Robert Frost, poet (1874-1963)
Please send URIs, not attachments: http://www.gnu.org/philosophy/no-word-attachments.html
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
participants (5)
-
Aaron Steele -
Javier de la Torre -
joel sachs -
John Wieczorek -
Reed Beaman