Allow user define valid "Type of Material" values.

[sehrgut]

In all four major classes of plants with which I work (bromeliads, orchids, aroids, and succulents), the distinction between an offset and a cutting is important. For all bromeliads and most orchids, cuttings are impossible. Taking offsets is also distinct from clump division, since the offset when removed is often completely unrooted, or growing on a distal portion of the plant such as an inflorescence (or leaf, in some Pleurothallids).

Tuberous aroids as well produce offset tubers, while sometimes being propagable by leaf cuttings. This distinction is even more important due to the fact that not all offsets sprout the first year, while still being alive; as opposed to seed-grown tubers of the same size, which will almost certainly sprout in the next possible growing season.

Many succulents are highly-propagable by both cuttings and offsets, but the techniques are different, and the ramifications for hardiness and rat of growth are important.

I believe referring to these as unrooted cuttings, root suckers, or divisions is inaccurate, and would be better represented by "offset", and possibly "rooted offset".

[mfrasca]

I'm a somewhat afraid of an excessively verbose list, in which users will not immediately recognize all options as meaningful, if we keep adding items.
we could make the enumeration a configurable one, and in order to keep translations possible, we could offer a list of (translated) options from which to choose. I think that the configuration should then live in the database. I'm keeping database impacting issues for a later moment (milestone 1.1).

[sehrgut]

I wouldn't be opposed to the enum being configurable and stored in the db. Unless there's an interchange format that specifies a controlled vocabulary (ABCD and ITF don't seem to), there's no real reason to force a specific vocabulary.

[RoDuth]

I can see the point for configuration here and agree that we should avoid an overly verbose list. Maybe keep just a small list of the most common and then the ability to add to it. I haven't checked ITF2, ABCD/Darwin Core but if @sehrgut is correct (and I would think so) then lets not restrict it.

I wish I had a way to say it was an advanced tree that was planted, or a 140mm pot or just a tube stock. I tend to just put "plant" for almost everything, which doesn’t tell you a lot. Almost everything else on the current list rarely gets used in our garden.

[mfrasca]

»I wish I had a way to say it was ...«
@RoDuth , share your wish list, in case we want to do this in the code, without impacting the database.

[RoDuth]

For me the issue is that there is no easy way to say what size the plant was when received. While I would prefer to have complete control of the terms available I would be happy to have some arbitrary ranges where I decide what they mean to me, e.g. tube stock (this is what 85% of our plantings tend to be, forestry tubes), small plant (140mm pot), medium plant (20L bag), large plant (100L bag), small ex-ground stock (2-4m trees etc., this could be called "balled and burlapped plant" I guess but this is not a term in common usage in my part of the world) and advanced ex-ground stock (things such as 6m tall palms; mature trees; 400yr old, wild collected, cycads, etc.) but am not entirely sure where the best place to put this is. Similarly, I occasionally receive grafted standards that are quite advanced, not quite the same as a grafted fruit tree or rose! So maybe grafted standard also?
As it is I don't feel I get much value out of this field and think that it should be a free text field, like the "category" field for notes where each garden can making up there own list and add to it as needed. Would avoid the overly verbose problem and also help with the fact that the terminology can be different dependant on where you are. Each garden has different priorities, approaches and collection types, why lock everyone in to having the same fields.

[mfrasca]

I'm searching for documentation, I don't find where to look for values that are expected in this field. the page http://www.bgbm.org/TDWG/CODATA/Schema/ABCD_1.03/abcd-1.03.html defines the AccessionMaterialType by just copying the definition of AccessionStatus.
same here: http://rs.tdwg.org/abcd/1.2/ABCD-1.20.xsd
others, like http://rs.tdwg.org/tapir/rs/abcd_2_06b.xsd, do not attempt a description.

[mfrasca]

the list currently in Bauble was developed specifically for the UBC (University of British Columbia). there is no need for it to be the way it is other than the UBC needed this list and not something else.
from my point of view, this looks like the issue about official authors list, #53 .
I am going to inspect if there's space in the current database structure, to host such dictionaries, or if we need expand the database structure (justifying postponing to milestone 1.1).

[mfrasca]

this is an abstract from the ITF2 document:

B.5 Accession Material Type Flag Transfer code: acct

Description: A flag to indicate the type of material the current living accession is composed of.
Rules of Syntax: If transferred, the Living Accession Material Type must consist of at least one of the following characters:

Syntax

Meaning:
P Whole plant
S Seed or Spore
V Vegetative part
T Tissue culture
O Other
Guidelines: If the value in the Accession Status field is 'D', then this field should not be transmitted.
If the accession consists of a combination of the above states e.g. a whole plant and stored seed, a combination of the above codes may be sent e.g. acct 'PS',
However, it is recommended that gardens assign unique accession identifiers to material held in different states. This will be one field that gardens may have difficulty in keeping up to date, especially transferring the record to another institution when it should flag the type of living material being physically sent, not the material currently held at the sending institution.
Example: acct "S",

[mfrasca]

this field, "Accession Material Type", relates to a field described in ITF2 (section B5). it is one example of many such fields. ITF2 dictates legal values (in imports and in exports), so we either use those values in Bauble, or we relate the standard values to one or more internal values, and if it's more than one, one has to be indicated as the default one after an import from an ITF2 exchange file.

I'm afraid we need scan the Bauble database structure and check which other fields relate to ITF2 or ABCD.

some users want flexibility, some need compliance with standards, some want both.

• what if I want to comply with ITF2?
• what if I want to comply with ABCD?
• what if a standard gets updated or added?
• what if I just want my own dictionary?
• what if I want to relate my own dictionaries to one or more standards?

[RoDuth]

I would be more inclined to stick to ITF2 where you can. Generally speaking I would say that ABCD is backward compatible with ITF2 but ABCD, being somewhat more focused on field observation and biodiversity in general (versus living collections and just botany), doesn't cater well for some of those things that are BGs specific. This field being an example. In terms of preference I would say ITF2 first then ABCD. (Although having said that, ABCD is more current and usable so you wouldn't want to break that. Would have to asses it their compatibility on a field by field bases but I don't remember there being any big issues last I compared them. )

My vote would be to scrap the list that was generated for a garden (UBC) that no longer uses Bauble in preference for 2 fields (no doubt another milestone 1.1 issue?).

1. A new field for Material Type which is the ITF2 field (I would find this field useful) and
2. A field adapted from the current "Type of Material" field, which I would suggest calling Material details, where we can add whatever is relevant to us, in my case the pot sizes and in @sehrgut's case "offset", "rooted offset", etc. this field would not be transferred as part of an ITF2 export.

If its got a standard then strict adherence to it, if not - provide maximum flexibility.

What if a standard gets updated or added?

From what I have seen they tend to be backward compatible. Anything that isn't (rare) would just need to be addressed in an update at the time..

I'm afraid we need to scan the Bauble database structure and check which other fields relate to ITF2 or ABCD.

@mfrasca I think this would be a really good exercise. Would take sometime but be well worth doing. You may pick up a few anomalies where the field has deviated from it's original intent or it could be implemented better. I know I have picked up a few things over the years that don't quite sit right with the standards. Just now I was having a look at ITF2 and I noticed the Species Epithet and Hybrid Flag and how they are intended to work, particularly the H option, which is not present in Bauble. It made me think that if you can use the species epithet field in the ways described in the guidelines that maybe getting rid of whitespace wasn't a good idea!?! Not wanting to second guess you @mfrasca but could it have been better to just have a warning stating that the field contains whitespace rather than disallowing it altogether??? Also, could having the H option solve our issue of hybrids? at least in the short term? (I sent our data from work - still on v 1.0.11- home and I have been using the species field to enter hybrids formulas. See my latest comment on issue #179) Another scenario where whitespace should be allowed in the species epithet is this from ITF2:

If the plant represents a new species which has not been formally described, sp. nov., sp. A,
sp. 1 (or other acceptable codes) should be entered, if possible followed by a unique
identifier, such as the collector's name and number or the locality.

I guess these are the "botanist tag" names I refer to in mfrasca#9

I keep coming back to the fact that there has been a great deal of work gone into these standards over many years by taxonomic database minds greater than I and it would be folly to deviate from them. They should always be treated as the first source of wisdom on the topic, although they may not fit our desires ideally there is normally good reasoning behind them that does not always immediately come to light. I believe it is more of a case of having to learn to work with and within the limitations. Documentation is crucial here, I always have a copy of ITF2 handy when entering data so I can check syntax rules and guidelines. There is plenty of scope for fields and functionality that are not defined by any of the standards (i.e. would not be part of a ITF2, ABCD, HISPID, etc, transfer) but we should stick to them wherever we can. Increased compatibility whenever possible, allow great freedom when not.

One of the things I have seen in the past is "drift" from the standards. i.e. a database that was once designed as ITF2 compliant that over time, due to well meaning users, who are not aware of the standards, modifying it to add extra values (usually horticulturalists with the aid of database developers and without a taxonomist in sight) or start using incorrect syntax etc. making the data no longer appropriate for an ITF2 transfer. Which in turn makes the collection a lot harder to work with in terms of sharing data and hence plant material etc.. I think I have said it before, the balloon help texts for any standard fields could stress the importance of this and provide guidance for syntax etc. E.g for Genus the balloon help could say:

The full generic name of the plant.  Syntax: a single word with first letter 
capitalised (A-Z) and the rest of the word in lowercase letters (a-z),  1 or 2 
hyphens are permitted.  No other characters accepted. 
(refer ITF2 p19 for full details)

In particular for us smaller, under resourced gardens I feel that adherence to these standards adds great value to our collections by making them more easily accessible. Yet we are the most likely to not understand them and hence deviate from them. From what I have seen gardens like ours, who are more resource poor, often have living collections that are of greater conservation/scientific value than our larger, more established city counterparts, but few seem to knows it. I love it when Botanist, Conservationist, etc. from other institutions access our collection and see that Bauble could play a large role to enabling this further. Bauble is easier than most systems for people without a botanic record keeping background to maintain and could make our records and hence collections easier to share (for a start - a one click BGCI PlantSearch update please!).

Sorry, that's my rant for the week! 😄

[mfrasca]

My vote would be to scrap the list that was generated for a garden (UBC) that no longer uses Bauble in preference for 2 fields (no doubt another milestone 1.1 issue?).

I totally agree. »scrap the list«, work towards ITF2 compatibility, replace this with 2 fields, do this in 1.1.

but what do you both suggest we do while staying in 1.0?

@RoDuth , I'm totally fine with your “rants” as you call them, my only difficulty is in doing house-keeping with them. 😆 ...

[RoDuth]

Apologies, I know I should try to keep more focused 😄 and I hate adding issues without checking that they haven't been covered elsewhere first.

In 1.0, could the field be more "user set", where we have the ability to add to the list or edit it's contents or the like? As in it would become my Material details field in the long run but for now it stays where it is and we can add the extra options we need some how?

[mfrasca]

scrap the list (hard coded allowed content)
keep the current content as is.
allow user define more valid values.
the content of this field is a 4char code, translated into a longer string which is the one you see.

this is also the reason why I recently focused on the institution code, because it's a dictionary too and it's implemented without having its own table.

»include "Offset" and "Rooted Offset"«

I am inclined to change the (externally visible) name of this field, since it's part of ITF2 and within ITF2 has a very clear definition which we are not following. it's a bit like saying "cake" when you mean "bread".

[mfrasca]

step by step (technical guideline to myself):

• reserve a prefix for this field, so we can write the dictionary in the 'bauble' table.
• write the current dictionary values) to the database.
• retrieve the values from the database.
• write an interface to add more values to the database.

I am afraid I need keeping the hard coded values for a while, so that the database table can be initialized with them if not yet in the database.
I don't like having to develop a new model-view-presenter thing, in particular while we're so much talking of going to web-based.
before I offer the GUI for it, the adventurous user can add values themselves by directly connecting to the database.

[mfrasca]

moved to Ghini/ghini.desktop#9