Option to store the LSID of a taxon in the database about ghini.desktop

[mfrasca]

From @RoDuth on January 2, 2016 4:52

@tmyersdn Poke 😄

@tmyersdn see issue #221 for the discussion, this came from a suggestion you originally made I think. You may have more to add?

[mfrasca]

From @tmyersdn on January 4, 2016 22:27

@RoDuth, @mfrasca

Okay, been gathering my thoughts on this one..

1. Capturing and storing the LSID (or other stable URL format) acts as a reference / citation for the name. NB1: in a crude sense this capture could be made by copy and paste, or alternatively by using a tool to look up names on a taxonomy service (see #214, where a primary service is used, but can be overridden to look in other sources). NB2: It is important that the individual garden be able to choose the name provider it wants, eg in NZ we may use LSID from Landcare Research, in Australia you may use APNI, in Peru? But where a name is not covered by our local service, we would use another source that we choose to follow. NB3: This is different to the bulk checking of name data

2. The link may potentially be used to hyperlink to the taxonomy provider website for a garden user to visit the source website. You could hyperlink the name?

3. Depending on the provider, it may be possible to use the LSID / URL to flag if the name is currently accepted or has any problems. NB - this may also be needed for running background bulk checking. There are a number of bulk name checking services, but these generally require user interaction. If you want to run this in the back ground and curate how the results are used within the database, then the LSID / URL may be needed to work with a name service API.

4. It is useful to note names that do not yet have LSID / URL. These need to be verified in other ways, and also could be reported to a name service provider. Many cultivar names and botanical "tag names" (temporary working names) will not have a LSID / URL (example of tag name that does have and LSID: URN:LSID:landcareresearch.co.nz:Names:FA622893-A829-4B8C-AC0C-E7BC18205F28)

This is all just for discussion, won't pretend to be an expert. What are your thoughts?

[mfrasca]

From @RoDuth on January 12, 2016 21:18

I think this is another milestone issue @mfrasca @tmyersdn ... I think we do need to store it somewhere and make use of its functionality, maybe to extend the taxonomic check functions at some point as in 3)??? No matter how we use it we need to first store it and I think this means not until adding the field to the database which I'm assuming @mfrasca your going to say is not until the next milestone.

[mfrasca]

"next milestone"... I mean, I can also start opening the new distribution line. then the trouble will be how we migrate the data without missing any information. and I think we better, for the time being, stick to the old csv_export→csv_tweaking→csv_import migration procedure.