1 (edited by wolfgang@DGfM 18-09-2017 18:36:02)

Topic: Indicia warehouse extension module

Hi everyone,

the German Mycological Society is currently planning to introduce a software for recording distributional records of fungi.

In addition to the standard functionality of Indicia, we need to store identification and ecological characters for each taxon and each sample. There will be at least some hundred characters, each with a predefined set of allowed values (depending on the taxon group).

So, for my understanding, we are not talking about additional columns, but rather an extention module to the indicia warehouse, adding about 5 new tables. In the long run, this functionality should grow to a multilingual synoptic key of central european species of fungi. 

The main functionality should include: administering (insert, update, delete) the criteria and the allowed values for each taxon group and each taxon, adding translations into several languages, summarizing all taxon characters to a description (displayed with the taxon, multilingual), creating an entry form for the characters observed on the sample (and obviously storing with the sample).     

We are totally new to Indicia, and expecting a serious invest in software programming, so sorry for having some very fundamental questions:

- are you aware of any related project?

- do you recommend including the desired features into Indicia, or should we rather plan a completely separate Drupal plugin?

- Since the Kohana framework is out of support, is it wize to add warehouse functionality at the current point of time? What are the future plans for the ORM layer in Indicia?

- has anyone a rough idea on how much we will have to spend for programming such a module for Indicia? Anyone knows Indicia programming freelancers or companies?


Any suggestions will be gratefully appreciated (here, or via E-Mail to wolfgang.pruefert@dgfm-ev.de).

Thanks



Wolfgang

2

Re: Indicia warehouse extension module

Hi Wolfgang,

My name is Andrew van Breda and I work as a self-employed developer for Indicia. Just to give you a little background, I have been working on Indicia related projects for exactly 5 years now, and before that I worked as a tester which included working on Recorder 2002 and 6.
Hopefully I can answer a few of your queries for you.

Keeping in mind that I only know what you have written here, my initial instinct is telling me that the best way forward would be to gather up all your requirements into a list and try to work exactly what Indicia already does, and exactly what it doesn’t do.
I know you have said you have requirements in addition to standard Indicia functionality, but does that take into account that Indicia can be configured and extended, you don’t want to spend effort doing something that you find is built in.

Perhaps you are confident that you have already done this, in which case I would be interested to know what the new tables you envision would contain in more detail, so I can understand in what way what you are suggesting differs from built-in Indicia.

Indicia is actually very extendable without the need of programming, you might find you need to do less programming than you think.
Indicia has a very flexible attribute system that allows data to be saved against samples, occurrences, taxa, locations, people and we can even save information about individual terms in termlists these days.

I think when you are referring .to characters it is what I would refer to as an attribute within Indicia (correct me if I am wrong)
I have been involved with more than one project lately which has involved importing taxa attribute data into an Indicia database (for these particular projects we referred to the attributes as traits), but almost all projects deal with custom attributes in some way.

For instance, you could have a data entry form, and your administrator could come along to the warehouse and add an attribute for habitat along with allowed values without any programming required, just basic Indicia configuration.
This is the most basic example, you can do quite a lot without additional programming.
I am not saying you don’t need any additional programming, I am just making sure you don’t go off and do something for certain requirements that could be done quickly with configuration.

I would certainly be aiming to use in Indicia if you can, it has so much useful built in functionality.
Indicia does many sophisticated things, but a lot of advantage lies in the simple things it does. If you decided to not use Indicia, you might find you want to do something simple but actually it involves a lot of programming, often simple things are not quite so simple when you start from scratch.
Indicia has the advantage that it has been going quite a while now, so a lot of the simple things (and more complex ones) are already built in.

I think it would be too early for me to say how much what you are after would cost, partly as I am not sure how much of what you are after we already can do with some built-in configuration.

What I would say about the Kohana issue is this, Indicia is an involving system, a community, it evolves as needed, people add new functionality as required, we address issues as they are identified such as supporting several Drupal versions.
These are obviously addressed gradually and on a priority basis.
If the Kohana issue was a major problem it would have already been addressed. It will gradually be addressed along with the other issues.
You won’t find a cliff edge scenery where one day you suddenly wake up and find your Indicia system isn’t working anymore. Indicia involves slowly, and your changes will evolve with it.
Also you may find that a lot of your work is not directly related to Kohana, a lot of the logic could be ported or directly linked to Indicia rather than Kohana, so that when Indicia one day moves from Kohana your changes will go with it.

OK, I think that is all for now.

Hope that helps, let me know if you have any questions or think I misunderstood anything (or everything!)

Andy

3

Re: Indicia warehouse extension module

Hi Andy,
thanks for your advice.

We have done a proper requirements analysis in German, which I will translate to English the next days.

We could not reliably map it to Indicia Attribute functionality, as we are not deep enough into it.

Please send me a note (my E-Mail is above), we will definitely need some Indicia professional support in the next months.

Thanks,
Wolfgang

4

Re: Indicia warehouse extension module

Just to add a note:

Conceptually, our problem is fully understood and described. However, there is no web-compliant and multilingual solution, to our knowledge.

You may see for example (I don't really expect anyone to read that...):

epub.uni-bayreuth.de/632

diversityworkbench.net/Portal/DiversityDescriptionsModel_3.0.15


The problem with somewhat "static" attributes is, that the required attributes differ from one taxon group to another. You cannot describe a Fly agaric with the same attributes as a powdery mildew.

5

Re: Indicia warehouse extension module

Hi Wolfgang,

I have sent you an email, so let me know if it doesn’t arrive.

Just a brief note on languages and also the issue of static attributes.

Language wise, we support different languages at the Drupal end of Indicia by having different language files.
In the code, the text on the page can be represented by a token, the code then goes to the language file for that language to get the wording required. So for example for the Dynamic Sample Occurrence form there is an “Add New Sample” button, in the code this is represented by the token “LANG_Add_Sample”. The system (automatically) then goes to the dynamic_sample_occurrence.en.php for the English translation and displays that on screen in the case of English.
So forms can support different languages providing the translation file is available.
The code can then be independent of the language.

We also support multiple languages for species names, for instance, we store welsh names that can be used for data entry. I am looking right now at the Japanese Knotweed invasive species entry and I can see the common names
Japanese Knotweed | eng
clymog Japan | cym

are available, the 3 letter code here is the language.

As for the static attributes issue. For taxa, we create an attribute and this is then made available to the species lists you want it to be made available to.
It would be possible to create different species lists dependent on the taxon group, and then use different data entry forms for each species list and thereby displaying different attributes per form.
Or something dynamic could be programmed, where as the user selects a particular taxon then we hide and show particular attributes….or perhaps we could even write custom code to link the attributes to the taxon group instead.
I realise you might be reading this thinking that won’t be suitable, or that might work. The point I am trying to make really is that there are lots of options.

Andy