[tdwg-content] Taxon Concept dilemma

Tim Robertson (GBIF) trobertson at gbif.org
Mon Jul 5 07:09:21 CEST 2010

Hi Kevin,

It seems fine to me Kevin, as long as the intention remains the same.   
I would imagine slow changing content behind the object (revisions in  
higher names perhaps) and not complete rewrites of the content.

Is there anything inside the Taxon that you can always rely on  
(something immutable)?  E.g. a constant ID from the nomenclatural  
organisation level, or perhaps some lexcal group ID?  Perhaps you  
could somehow select one reference ID from the nomenclatural or  
concept level as the Taxon ID, and then you could promote the Taxon as  
a dynamically assembled object with the best representation (at  
request time) for ConceptX.  This is then more analogous to  
getTaxonFor(conceptX) than getTaxonById(X).

The alternative to what you are suggesting would presumably be  
creating new ID for any change, which seems like it would be difficult  
to keep anything in sync, unless I can subscribe to and understand  
your changes constantly.


On Jul 5, 2010, at 5:43 AM, Kevin Richards wrote:

> Hello all,
> I have an issue that I would like some comment on…
> We have some data that covers Taxa, Names and Concept relationships.
> Eg
> -          A Taxon table that contains the nomenclatural details +  
> accepted name + parent name
> -          Concept + relationship tables that contain details about  
> the name + references where the name has been used in a taxonomic  
> sense (ie not nomenclatural information) – this is specifically a  
> link between the Name and a Reference
> We have fairly permanent Ids for the Taxon Name (nomenclatural) and  
> the Concepts, but I now what to consider the ID to cover the whole  
> Taxon (ie the Nomenclatural data + taxon rank + parent name +  
> accepted name, etc, as “we” understand them).  (Probably equivalent  
> to the taxonID in Dwc)
> The problem is this tends to be much more dynamic data – ie, in this  
> particular case we have aggregated data from a variety of providers  
> and are in continual revision of this data - as we revise the data  
> the details such as the accepted name may change – this troubles me  
> a bit, because this could be seen as fundamentally changing the  
> definition of the object behind the taxonID.  However, I suspect  
> this is a common case that people find themselves in – ie revision/ 
> tidying of aggregated datasets must be quite common.
> I would prefer to NOT change the taxonID every time we revise that  
> data (taking the angle that these changes are corrections, so are  
> not changing the object itself).
> Should it be OK to have an object type like this, that is likely to  
> change, but keep the ID permanent for it – ie accept that some  
> object types are quite dynamic?
> The only other option is to maintain a hideous version audit trail,  
> that probably hinders the use of the data more than it benefits the  
> end user by providing “stability”.
> Any thoughts?
> Kevin
> Please consider the environment before printing this email
> Warning: This electronic message together with any attachments is  
> confidential. If you receive it in error: (i) you must not read,  
> use, disclose, copy or retain it; (ii) please contact the sender  
> immediately by reply email and then delete the emails.
> The views expressed in this email may not be those of Landcare  
> Research New Zealand Limited. http://www.landcareresearch.co.nz
> _______________________________________________
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-content

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

More information about the tdwg-content mailing list