Talk:AVH data

Type status information in Darwin Core
NielsKlazenga (talk) 16:27, 11 November 2013 (EST)

Something in the minutes got me thinking. Type status information is of course specimen metadata, not image metadata, so, if how type status information can be represented in Darwin Core is going to be a problem once we start providing images of types, it is because there will be higher requirements for the specimen data. And most herbaria already deliver type information to AVH, so it is really already an issue and we might as well figure it out straight away.

In ABCD, and hence HISPID, type status information is covered in the NomenclaturaltypeDesignations element. Most herbaria currently deliver TypifiedName, TypeStatus and DoubtfulFlag, which are the most important elements. MEL also delivers Verifier, VerificationDate and VerificationNotes, because it is required for the GPI metadata and we were asked by David at some stage to look into the feasibility of extracting the GPI metadata from AVH, so we had it and thought we might as well – and we were told to deliver everything we could – but I think AVH might be able to cope without. Darwin Core ostensibly only has typeStatus, so what I did at the time was concatenate all the terms mentioned above into [DwC] typeStatus and also provide them all separately as AVH custom fields.

In contrast to ABCD, Darwin Core is not only meant to be suitable for transferring specimen information, but also for taxonomic and nomenclatural information. As type information is at least as important in nomenclature-based systems as in specimen-based systems, it would be strange if Darwin Core couldn’t deal with type information. There is a GBIF Darwin Core extension TypesAndSpecimen, in which [DwC] scientificName corresponds with [ABCD] TypifiedName. Although not mentioned, I think it could be argued that in such an extension [DwC] identificationQualifier, identifiedBy, dateIdentified and identificationRemarks correspond – sort of – with DoubtfulFlag, Verifier, VerificationDate and VerificationNotes. However, the TypesAndSpecimen extension is part of GBIFs Global Names Architecture and is intended as an extension to a Taxon core, while AVH records are Occurrence records.

So it is possible to deliver comprehensive type status information in Darwin Core: in an extension and as part of a Taxon record. At the moment ALA doesn’t really support extensions, but I have been told they are working on it (or intend to work on it). In the flat format which is currently used for AVH data we obviously can’t use scientificName for TypifiedName, but I still think we can do slightly better than we are currently doing. In Darwin Core there is an element originalNameUsage, which is in the Taxon class, but then so are scientificName and several other concepts we use in Occurrence records. The documentation for the element says there is no equivalent in ABCD, but I reckon TypifiedName is close enough. Also, the element was called basionym in an earlier version of Darwin Core, which happens to be what we called TypifiedName in earlier versions of HISPID.

So I think we can already map the most important type information to Darwin Core and I propose to change the mapping in AVH as follows:

I think it is important to map our data to Darwin Core as comprehensively as possible, as we can’t really expect AVH users to know multiple standards and we would want fields in AVH to have similar contents to fields in OZCAM and elsewhere in the BioCache. This I also find back somewhere else in the HISCOM minutes in slightly different words (I would like to see 'might' there changed to 'should'; it is not just a convenience thing). There are a couple of other things in AVH data that can only be presented in custom fields and that I feel should really be represented in the core record, but I’ll pester you about those later.

There are two new concepts in the TypesAndSpecimen extension: typeDesignationType and typeDesignatedBy. I can’t see we would have a use for the former – it applies more to types of genera – but I think the latter might be nice to have, even if it is only so that we have got something JSTOR doesn’t have. typeDesignatedBy is the reference for the publication in which the type was assigned. The ABCD equivalent (I think) is NomenclaturalReference. I am not sure if any herbarium would currently be able to deliver it, but we might be able to get it from APNI.


 * It all sounds good to me. Thanks for the thought you put into it. My topic for discussion is more about using the discussion page. I think it's a good thing, but if only those people who elect to watch the page get emails about changes to it, we might leave some people out of the conversation (and you only see that you can watch the page if you've chosen to edit it). I'm also not sure I've added this comment in a very useful place. --Alisonv (talk) 17:07, 11 November 2013 (EST)
 * This wasn't supposed to be an either–or thing. My problem with doing this kind of thing over the HISCOM list is that in several months time when this might become important, nobody will be able to find back the e-mails or remember that there ever was an e-mail. Also, this wasn't something of immediate importance, so I wasn't expecting comments right away. But yes, we shouldn't rely on the watchlist; I don't even think it sends e-mails (I did assume that it did earlier). If someone thinks something important is happening on the Wiki, they can send an e-mail to the list (which is what I did). Discussions about real things shouldn't be happening on the HISCOM list alone, as they would be lost over time. I suggested using the Discussion pages as the place for these discussions, so that we can keep it from the Main Wiki pages, while still keeping the link with these pages and the organisation and retrievability of the Wiki. --NielsKlazenga (talk) 12:32, 8 December 2013 (EST)


 * Seems ok. As you point out originalNameUsage is in the Taxon class of Darwin Core, so I see it as a slight twist of the definition for the term - so would have preferred the GBIF extension if the name had not clashed with the field in the Current Determination.  Given that  a specimen may be type for more than one name, I wonder if an alternative would be to pass this information in an extension file like the Det. History (to allow for the 1 to many), and to use the GBIF extension?  -- AWilton
 * scientificName is also in the Taxon class, but I see your point. originalNameUsage is for a name, not a specimen/occurrence, but then so is basionym, which we have always used in HISPID. We could deliver nomenclatural type status designations in a determination history extension, but (1) ALA can't deal with extension files (as I also pointed out) and (2) nomenclatural type status designations are not identifications.
 * In botany at least, the only situations where a specimen can be a type of more than one name is where all but one of the names are illegitimate, in which case you choose the legitimate one (you would do that anyway, as HISPID calls this 'basionym' and only legitimate names can be basionyms), or where the specimen is a holo-, iso-, lecto- or neotype of the more recent name and a syn- or paratype of the older one, in which case you choose the more recent name, as syn- and paratypes are not really types (they are part of the type material, not types) --NielsKlazenga (talk) 03:22, 7 December 2013 (EST)


 * This will all become moot – I mean the whole thing, not the comments – if the proposal to add typifiedName to Darwin Core is ratified. --NielsKlazenga (talk) 03:22, 7 December 2013 (EST)