[tdwg-content] Data capture software and Darwin Core

Richard Pyle deepreef at bishopmuseum.org
Mon Jul 22 07:16:00 CEST 2013

Thanks, Justin.  Keep in mind that the description I sent represents my own
interpretation of these DwC class terms - not necessarily shared by others
(and, thus, not necessarily representative of the true "intent" of the dwc





From: Justin Steventon [mailto:justin at steventon.com] 
Sent: Sunday, July 21, 2013 7:11 PM
To: 'Richard Pyle'; tdwg-content at lists.tdwg.org
Subject: RE: [tdwg-content] Data capture software and Darwin Core


Hi Rich,


Thank you, this certainly does clarify the intent. 


Snapped was indeed referring to taking a GPS reading, date and time.
Therefore it makes more sense as an Event rather than a Location. In the
interim basisOfRecord (HumanObservation and MachineObservation) is a good
way to distinguish these.


Aggregating the timer tracks into higher level structures is a longer term
goal. Good luck at the next meeting. I'll continue to track changes as this





From: Richard Pyle [mailto:deepreef at bishopmuseum.org] 
Sent: Sunday, July 21, 2013 4:07 PM
To: 'Justin Steventon'; tdwg-content at lists.tdwg.org
Subject: RE: [tdwg-content] Data capture software and Darwin Core


Hi Justin,


These questions strike at the heart of some of what I think are the key
unresolved aspects of DarwinCore - aspects that I hope will be the focus of
some specific attention at the next TDWG meeting.


I will provide some answers from my own personal perspective.


In my mind, Location = Place (and all metadata associated with describing a
place in three-dimensional space).


Event adds the fourth dimension of Time (i.e., Place + Time).  Depending on
who you talk to, Event may also include metadata related to "who" (which
doesn't necessarily need to be a human - it might involve telemetry devices
as well).  And, assuming there is some sort of sampling activity associated
with the Event, there may be some metadata related to that sampling and its


I'm not entirely sure what you mean by "snapped" for Timer tracks.  Does
"snapped" refer to capturing images or some other sort of other data
capturing protocol?  Or does "snapped" simply mean that you log a timestamp
and Lat/Long coordinates?  If the latter, then I would treat each node on
the Timer track (i.e., each "snap") as representing an Event (Location +
Time).  If something other than the simple logging of Lat + Long + Time
happens at each "snap", then that opens up another set of issues which I'd
be happy to comment on.


Likewise, presuming that each Sighting comes with its own Lat/Long
(Location) data, as well as a time, then these, too, would represent Events.
But anything documented at those Events (e.g., sightings of an individual
organism) would represent Occurrence instances.  Non-biological
documentations (such as weather) would probably best be represented as
properties of the Event.  In DwC you'd probably express those in
dwc:fieldNotes or dwc:eventRemarks.


A different (and equally legitimate) interpretation of how to represent
Timer tracks in DwC would be to represent the entire Track as a single
Event, capturing the "Location" component as a sequence of Lat/Long points
(effectively describing a linear path as a single location), or as a simple
polygon (bounding box or point+radius), and the "time" component as a range
from the time of capture for the first "snap" to the time of the last


My own personal approach (which extends beyond what DwC:Event class is
currently set up to accommodate) would be to do both for your timer tracks.
That is, represent one Event as the entire track, with the Location
described either with an ordered array of Lat/Long points or as a bounding
box or point+radius that describes the smallest rectangle or circle that
encompasses all of the points, and range of min-max timestamps to represent
the Time component of the Event.  Then I would capture each "snap" on the
track as a distinct Event (in our data model, we support hierarchical
events, so the individual points would be referenced as "child" events of
the "parent" Event representing the entire track).


I'm not sure if that helps or only confuses things; but perhaps after the
next TDWG meeting we might have more clarity and/or consensus on these







From: tdwg-content-bounces at lists.tdwg.org
[mailto:tdwg-content-bounces at lists.tdwg.org] On Behalf Of Justin Steventon
Sent: Sunday, July 21, 2013 10:32 AM
To: tdwg-content at lists.tdwg.org
Subject: [tdwg-content] Data capture software and Darwin Core


Hi folks,


Just starting to get into Darwin Core. Thanks for any help and suggestions
you can provide.


I'm the builder of a data capture application (using PDAs and smart phones)
called CyberTracker (http://www.cybertracker.org). We want to create a
feature to export to Simple Darwin Core as XML.


We have two kinds of data: timer tracks and sightings. Timer tracks are
automatically snapped at regular intervals and only contain a timestamp and
location. Sightings are manually captured data and vary quite a bit. For
example, they could represent the weather or a direct sighting of an animal.


It seems clear that a sighting maps directly to an "Event".


If we have a long list of timer track points, should these show up as many
"Location" records?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20130721/3de36f4f/attachment.html 

More information about the tdwg-content mailing list