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

Thu Aug 12 16:48:03 CEST 2010

FWIW, timestamps extracted from EXIF data that a camera put there are
typically no more than +- 12 hours accurate, because most devices
don't record and/or stamp the timezone.  My Android X seems to, but my
Canon PowerShot SD750 does not. Your extractions are going to need to
add it based on your knowledge about the timezone at the time and
location of the bioblitz. Alas, it gets worse, because many people
fail to reset their cameras or phones to the local time.  To make any
kind of educated guess about what time the timestamp \actually/
represents may require knowledge of the device capabilities, what the
timezone is where the picture was taken and what it was in the
timezone the device thinks its in. The latter might be knowable from
specs of the device, e.g. if it can be discovered from those specs
that the camera knows its time from a network it is connected to, and
if you can deterimine that it actually was connected.  But for
consumer cameras, this is probably hopeless, and you need metadata
from the camera owner.

Curiously, the errors from this are not a range, but an enumeration,
because timezones worldwide differ from one another by an integral
multiple of 1/2 hour.

Field biologists of my acquaintance simply keep their cameras always
set at GMT.  Then at least they know that all their pictures have
comparable times. For the bioblitz, participants might consider
agreeing to set the cameras to a common time. Aside from the accuracy
of hand setting the current time, you would then mainly face social
problems about the accuracy of the time: (a) can and will the
participants actually do this with the devices they carry; (b)how much
will they curse the bioblitz when they forget to set the timezone back
to what they intend and (c) do they care whether a picture they took
of a pollinator in Massachusetts apparently at high noon, actually was
taken in Massachusetts at a time corresponding to high noon in Berlin.
At the very least you probably should ask each contributor to record
the time on their camera at specified  local time each day.

All accuracy assertions are about fitness for use. It's not the case
that data without accuracy assertions are unfit for any use whatsover.
This is because scientific statements are always qualified by either
"to the best of current knowledge" or "if we accept the model X into
which we put the data". For example, a taxonomic determination may or
not be location dependent to the best of current knowledge. For those
which aren't, and for the use case "taxonomic determination", geo
accuracy is irrelevant. To the best of current knowledge.

Bob Morris

On Wed, Aug 11, 2010 at 9: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
>>>
>>>
>>
>
> _______________________________________________
> tdwg-tag mailing list
> tdwg-tag at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>
>

-- 
Robert A. Morris
Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390
Associate, Harvard University Herbaria
email: ram at cs.umb.edu
web: http://bdei.cs.umb.edu/
web: http://etaxonomy.org/FilteredPush
http://www.cs.umb.edu/~ram
phone (+1) 857 222 7992 (mobile)