From IMarine Wiki

Jump to: navigation, search

July 2014 validation comments

TabularDataLab is a framework of services to manage tabular data. It supersedes ICIS, in that it is now designed to better serve the needs of the EA-CoP. The current approach has better support for data structures, validation, aggregation, and dissemination (please refer to ICIS validation comments to understand the full list of EA-CoP requirements).

The validation case presented here places TabularDataLab in charge of managing the FAO Tuna Atlas data.

However, the validation also considers other scenarios, and where needed and relevant, reference is made to functionality outside the limited scope of the FAO Tuna Atlas. Also here, there are thus 2 validations:

one by Tuna Atlas Data Managers in charge of requirements engineering, 
another validation with a wider scope of serving mainly the first Business case in the Marine Fisheries data management domain

The first aims to result in a product exploitable within the project life-cycle, while the other validates the suitability of the iMarine platform to support many other data workflows, and is thus a review of the market opportunity for data management tools.

TabularDataLab in this validation report is presented as a single tool reviewed by validators, and only one report is generated. However, being a framework, there could be many more tools. The framework presented for validation by the larger audience was not tuned to their needs or expectations. The taxonomists’ validation was performed mainly by 2 envisioned BiOnym data managers. The iMarine Board and iMarine extended Board were invited to partake to this larger end-user validation.

The validation progress by the Tuna Atlas can be checked through their meeting reports on the iMarine wiki. The validation dome by the Board and Extended Board of June 2014 resulted in sometimes private email that were discussed at iMB5, but were not fully included in the wiki or reports. This page captures the most relevant comments resulting from this validation.


The Feature set specified by the EA-CoP in several meetings was fully implemented; The main requirements was to match user files against Taxonomic Authority Files (TAF), with control given to the user through a GUI enabled matching panel.

The matching can be organized and boosted by users, with a BiOnym manager in charge of users and content (TAF) management.

The capabilities were further enriched by FIN who designed and implemented a simpler GUI for a generic audience. This was very important to position BiOnym in a 'market' for matching tools. The functionality of this GUI was deemed sufficient for most users. The validators saw generality in the framework based approach and delivered solutions, and immediately recognized how and where BiOnym features could be re-utilized.

Some questions remain on accessing biodiversity datasets and the security and confidentiality arrangements needed to ensure dataproviders accept the exploitation of their data repositories.


Some issues remain open on Human factors; the design and Aesthetics of iMarine solutions often do not match with existing or expected solutions. The core team of validators expected that the complexity of UI design should be reduced for generic end-users. The taxonomists need the rich tuning options on the matchers, but generic users would prefer more productivity oriented screens and work-flows. The generic users are also expected to have a need for single name comparison, rather than file based comparisons.

This invoked the design and implementation of the FIN GUI for single name comparison.

The Consistency in design and work-flow of all iMarine components was appreciated. However, being newly released, the Documentation and training materials were deemed incomplete.


No issues related to failures, recoverability, predictability, or accuracy that are not related to ‘poor’ data remain open as of July 2014.


The use of a framework had an impact on speed, efficiency, throughput, and response times. These were expected, and while validating, all users were informed that performance would be low. The performance can be much improved once the requirements are fully known.

For taxonomists, this was the case, and not performace issues remain. 
For the generic users, modifications can be implemented if resources can be made available. 


The EA-CoP at large does not validate supportability. However, the BiOnym approach rests on a solid framework in the e-infrastructure, and as long as developers and infrastructure remain avialble, supportability is good.

The EA-CoP misses the option to localize BiOnym (by managers) to support local languages.

Personal tools