[tdwg-tag] time and space namespaces in Darwin Core

Tue Aug 24 23:57:01 CEST 2010

+1. Excellent recommendations for BioBlitz.

On Wed, Aug 11, 2010 at 6:52 PM, joel sachs <jsachs at 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 at 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 at 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 at 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 at 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 at 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 at csee.umbc.edu>
>>>> Cc: tdwg-bioblitz at googlegroups.com, tdwg-tag at 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 at 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.
>>>>>
>>>>>
>>>>>       -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 :
>>>>>> ===========================================================
>>>>>>
>>>>>>
>>>> _________________
>>>> Jim Croft ~ jim.croft at 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 at lists.tdwg.org
>>>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>>>>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20100824/d2a7b4ee/attachment.html 