provenance list about ghini.desktop

[mfrasca]

list of provenance, [es]

specification	category
incautación	wild
colecta	wild
nacional	compra
rescate	wild
importado	compra
in vitro	cultivado
división	cultivado
semilla	cultivado

[mfrasca]

From @RoDuth on November 14, 2015 3:32

This is an ITF2 field I believe (see bottom of this post for a definition). Adding more options will break with the standard. Be careful here. It may not mean much to some but it will to others who share/export their records.
While ITF2 may be outdated I don’t think this field is included in any of the more recent standards (DarwinCore, ABCD, etc.). Most likely because many of these sorts of fields are very unique to botanic gardens, DarwinCore, ABCD, etc. have a focus on wild collected samples not living collections (museums, herbaria v BGs or zoos) . I'm happy for the newer standards to trump ITF2 where an equivalent exists and stick to it where there is none but in general I would like to see Bauble become MORE compliant with these standards not less!
To clarify: Invitro (apomictic cloning, etc.), seed (open breeding, controlled breeding, self-pollinated), cutting (vegetative reproduction), (there are many many possibilities) are all "propagules". Propagation TYPE should be collected elsewhere and if I remember right this field (ITF2 transfer code: prohis) is not included in Bauble. It could quite easily sit beside the provenance field in the accession editor, as could potentially some of the other fields from ITF2's section E (Source Data).
Related is this thought:
I always thought that the "Propagations" editor in the "Plant Editor" should automatically link in to any accessions created from that propagation. So that the ITF2 field "Accession Lineage" could be produced automatically for internal propagations at least (as could prohis, prot, wpst). Currently there is no support for "Accession Lineage" in Bauble I believe.

ITF2 Field:
Provenance TypeFlag Transfer code: prot
Description: A code to indicate the provenance of the accession.
Rules of Syntax:

1.      If transferred, the entry must be one of the following values: 
   

Syntax Meaning
W Accession of wild source
Z Propagule(s) from a wild source plant in cultivation
G Accession not of wild source
U Insufficient data to determine which of the above categories apply
Rules of Information:
The terms outlined above are defined as follows: .....
.....

For full standard see here: https://github.com/tdwg/prior-standards/blob/master/itf2/102-525-1-RV.pdf

[mfrasca]

»I would like to see Bauble become MORE compliant« 😄
indeed a stable interaction of professionals on both fields (IT/botany) is what we need.

[mfrasca]

From @RoDuth on December 25, 2015 4:38

Seems to me that some non standard options have made their way in here @mfrasca. I had not noticed this before.
"Impound, collection or rescue" only makes it harder for those of us that would like to stick to the ITF2 standard Wild Provenance Status Flag. Plus isn't "Impound, collection or rescue" all the same thing in terms of the provenance status? Wild Native?
And isn't "purchase or gift" the source not the provenance type?
We deal with these further details within the source description or in notes and/or tags, I feel this gives me plenty of scope to record non standard information.

Also if you do have users that have no desire to stick to the standards that there be some kind of option for this? i.e. I could at very least set the "ITF2 compliant" option in the ~/.bauble/config file and not have these non-compliant options show. (I would encourage anyone keeping botanic records to have a look at ITF2 and ABCD first, before they make the mistakes these standards were set up to prevent and to understand how and why these fields are the way they are and how they are intended to be used.)

When I started my search for a "real" database it was because our old system was not compatible with anything. One of the main things that attracted me to Bauble was its compatibility with the standards, while its not perfect its a major improvement on what we had. Please don't make me go backwards!

[mfrasca]

my mistake
#217
I think I can and should roll this back, assisting the JBQ in keeping the information I let them insert here.
I also think the text should match the standard text, so it's easier to find it back in the literature.

compare

prov_type_values = [(u'Wild', _('Wild')),
                    (u'Cultivated', _('Propagule of cultivated wild plant')),
                    (u'NotWild', _("Not of wild source")),
                    (u'InsufficientData', _("Insufficient Data")),
                    (u'Unknown', _("Unknown")),
                    (None, '')]

with the above

Syntax Meaning
W Accession of wild source
Z Propagule(s) from a wild source plant in cultivation
G Accession not of wild source
U Insufficient data to determine which of the above categories apply 

if I recall correctly, we were so much wondering about the "cultivated" key.

[mfrasca]

From @RoDuth on December 26, 2015 10:53

I agree, its should match the text. To me Insufficient data and Unknown are synonymous and you only have the one in ITF2, from what I gather in your comments in the code you plan on collapsing this into the one, which is great.

My concern is, in this context what is "Purchase or Gift"? Most of our collection comes to us as donations (Gifts) or we buy them from a local expert (Purchase) and they are most commonly of wild source with full collection data. I know its not going to happen for me, but I worry that the others at the gardens who enter data may use it and we'll loose the accuracy of the data.

Also I still stand by the fact that any of these:

+cultivated_prov_status_values = [
+    (u'InVitro', _("In vitro")),
+    (u'Division', _("Division")),
+    (u'Seed', _("Seed")),
+    (u'Unknown', _("Unknown")),

Can apply to any of the provenance types as it is propagation history (ITF2 transfer code: prohis) and has nothing to do with the provenance type or status fields. I'm thinking that you may not get the meaning of Z Propagule(s) from a wild source plant in cultivation? Its about the purity of its provenance, it is referring to the fact that you may have a plant that itself was collected in the wild that is the source that you have propagated from (creating a second generation if you like). I.e. for conservation purposes it is better to have sourced the plant directly from the area your are thinking of reintroducing it to. So a plant in your collection is not an ideal source and the more generations away the worse. A plant in your collection may have been pollinated from plants from other provenances (for a very brief explanation see this: http://wildlife.lowecol.com.au/files/GfW-Nov-2009-The-Importance-of-Local-Provenance.pdf or just google "local provenance plants").

For me these fields are about conservation value and nothing more. If I'm talking exotics or hybrids etc. I don't even use them.

[mfrasca]

From @RoDuth on December 27, 2015 3:35

Sorry, just re-read this and I see

assisting the JBQ in keeping the information I let them insert here.

Also. I'm not sure that I have read the comments in accession.py correctly... are you still suggesting keeping invitro, division etc. (propagation info) with the provenance info in the long run?

I have a very specific use for these fields that works very well the way it was (although I believe that unknown and insufficient data are the same). Our use is very much about the purity of the provenance of the accession. These are very critical fields for us because of our conservation of local flora focus. I would also like to be able to keep propagation info, just not here.

I don't, however, want to ruin it for JBQ if this is how they need it to be to not lose their current data so I apologise for being pushy, but there must be a compromise?

I hope you can allay my fears!

[mfrasca]

I consider a standard like ITF2 as a minimal common base and I guess we should be fine with extending the standard as long as the extension is not in conflict with the standard itself.
my opinion is we should plan a careful global three-sides review of standard and software and users practices.