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

Wed Aug 25 01:10:33 CEST 2010

On Mon, Aug 9, 2010 at 8:16 PM, Reed Beaman <rbeaman at 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 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20100824/f33e6a9b/attachment.html 