This help provides an introduction to the KDManage application. Beforehand it is beneficial to briefly look at the following KDDart Environment Overview as this will assist with understanding the role this application performs and how it may overlap, intentionally, in functionality with other KDDArt applications. This will place you in a better position to choose the most appropriate tool for a specific time consuming or possibly repetitive task.
To quickly gain success with KDManage it is suggested you initially follow the order of the help index.
Please Note: As part of DArT’s continuous improvement all KDDart application help resources are ‘works in progress’, hence we would be most grateful for any feedback regarding errors, omissions or suggestions. You may even have some valuable tips and experiences to share with others to better leverage these tools.
This document is intended for the following audience although it is not strictly confined to the roles listed:
|Technical User||An administrator of the KDDart database implementation who is familiar with how various activities of breeding trials and data needs to be organised for your organisation. This role does not require you to be an IT programmer.|
|Data Analyst||Analytical tools may use data retrieved from KDDart for analysis by using DAL. The results from analysis tools along with insertions (updates) may also be stored in the database using DAL.|
|Trial Manager||The manager of a trial/experiment.|
The KDDart environment consists of a three layered architecture consisting of:
- The Applications Layer, containing KDManage and other applications;
- A Data Access Layer which is an API we refer to as ‘the DAL’ that connects the applications with your data; and
- A Database Layer containing the underlying databases.
Benefits of this well established architecture include much greater long term stability and efficiency for both users and developers of the platform.
Note: As depicted in the following KDDart System Architecture diagram, KDManage has an important role within the Applications Layer
The application layer provides an opportunity for applications to be built or modified to suit end user requirements and provide specific functionality to best suit their tasks. Applications designed in this manner, to specialise in a specific role, may have overlapping functionality provided for convenience. Therefore it is recommended that the correct ‘tool’ is chosen for the job at hand.
The following table lists current the KDDart environment application software suite and describes the roles they perform. This should assist in choosing the most appropriate application for a task.
|KDManage||The KDManage application provides a web interface to KDDart allowing users to update and maintain their data using a web browser on their workstations.
The application provides an authenticated user the means to add and amend database records, upload and export data.
|KDXplore||KDXplore is a versatile modular application for online/offline Trial management, Curation, Seed Preparation and Harvest, Genexplore, Inventory and Trial/Nursery design.
It is a useful tool for breeders, researchers, technicians, curators and developers.
|KDSmart||KDSmart is designed to operate on a variety of Android handheld devices to collect data in the field. Containing data selectively exported from your KDDart database, KDSmart allows you to capture and store your phenotypic Trial data in the field for subsequent uploading to KDXplore then KDDart.|
|KDCompute||KDCompute is an application that provides capabilities for extensible data analysis in an efficient and customisable framework. As a tool it allows the technical detail of preparation and configuration of algorithms to be performed by a ‘technical user’ and an interface for ‘analyst users’ to easily employ those algorithms to undertake their research.
Using a cooperative plugin framework for processing algorithms KDCompute is designed for multiple, longer running tasks. Using a queuing server, workstations are free to perform other tasks and demand for KDDart resources is effectively managed.
|KDSens||The KDSens application provides an interface between the KDDart database and various generic environmental sensors, such as weather stations, soil probes, etc. Sensor definitions are maintained within KDDart.|
|DAL||Not an application, but an Application Programming Interface (API). The Data Access Layer, we refer to as ‘the DAL’, connects the applications with databases containing your Trial data. The KDDart DAL API simplifies application development so organisations can develop their own applications, or plugins and algorithms for exisiting applications.|
These applications provide functionality to leverage your trial and nursery data when it is stored in the KDDart environment. They employ some of the diverse capabilities of the KDDart environment and demonstrate opportunities for others to build upon and extend the application layer.
Whether you choose to further enhance an application or develop new ones, the data storage capabilities of KDDart and the DAL API layer are extensible enough to meet current and long term needs.
KDManage allows users to manage their Trial and Nursery data that is stored in a KDDart database using a web browser on their workstation.
During KDDart database setup, KDManage enables administrative tasks to be performed to create entity dependencies. Relationships are not always hierarchical such as this simple example: before adding a Trial, the Site for the trial must be defined which in turn requires the Organisation to be defined for site ownership.
Beyond initial KDDart setup many other functions can be performed, grouped under the menus for Germplasm and Experiment. Within Germplasm, KDManage manages Genus, Genotype, Specimen, Trait and Treatment, whilst Experiment contains Site, Trial, Design Type, Unit Position and Breeding Method. In KDDart the Specimen represents the unit upon which Trials are performed and trait measurements are taken.
As Trials are defined in KDDart and are in progress, other activities within KDManage become more frequent. These include activities such as importing Trial results, data extraction/exporting to perform analysis, etc.
Direct access to data stored within KDDart is possible using other applications such as KDCompute, without first needing to extract data, as it is ‘already there’. This is a big difference to user activity such as moving and manipulating data stored in individual files and spreadsheets. Once data is in place in KDDart, it can be called upon time and again for review and analysis tasks.
Before adding Genotypic data to KDDart for your Trial or Nursery, any data dependencies must first be added to the database, many of which appear in selection lists (i.e. drop downs). As KDDart becomes more populated, various dependences will be already been met making further data addition easier. The order of the following list briefly illustrates dependencies that must be met, however the following diagram provides more complete detail:
- Contact(s) - belonging to Organisations
- Genotypes and Specimens
Without delving into data analysis explanations, Trials and Nurseries are well understood and KDDart design has them resolved to a common data model as Trials.
The following diagram provides a simplified illustration of KDDart data dependencies to assist understand the structure.
Frequently pre-existing data will exist that needs ‘importing’ into KDDart such as Genotypes and Specimens.
Until you are familiar with the import functionality or have large files to import it is recommended that you:
- Backup the KDDart database prior to performing large imports
- Ensure all data Data Dependencies have been addressed beforehand
- Import a small selection of data before embarking on a large import.
Performing item 3 above is important to establish that the:
- Input file has the correct format; and
- Imported data has correctly populated the desired KDDart fields.
KDManage is not the only tool capable of importing data. KDXplore or KDCompute may be better suited to the task, especially if a very large time consuming import is to be performed.
As of KDManage Version 1.9.12, delete function has been added for some KDDArT entities. They are:
Since individual KDDArT entities are a part of a network of dependencies, deleting entities may not always be possible. The following restrictions are in place
- Trials cannot be deleted if there is trial data uploaded to trial.
- Genotypes can not be deleted if there are Genotype Pedigree entries, Specimen entries or Extract entries that are associated with Genotype.
- Specimens can not be deleted if there are Specimen Pedigree entries, Specimen keywords, Item entires that are associated with Specimen. Specimens also can not be deleted if Specimen is used in a Trial.
- Items can not be deleted if it is attached to a Specimen in a Trial Unit. Items also can not be deleted if Item is part of an Item Group or has Item Logs recorded onit.
As such, delete should only be used to reverse accidentally additions or removing test/practice data. To remove data, please contact your Administrator for options. Alternatively, contact the KDDArT team for further options.
KDDart is designed to accomodate many users of the system and Groups enable user access to the data stored within (see the following section Access Settings and Permissions ).
To commence using KDManage you need a valid userid and password to login/authenticate to the KDDart database.
Once logged into KDManage the user must choose the Group to use for the session if they belong to multiple Groups, much like having multiple roles.
Note: Group selection is automatic if the user is attached to a single Group.
A brief introduction to how KDDart manages access and security is described in this section to assist you entering and managing your data.
The following Permission Matrix table outlines what a user can perform with a selected permission setting when creating or updating the user.
|Task||Admin and a Manager||Admin and NOT a Manager||Manager||User||Guest|
|See all records regardless of the record permission||Yes||Yes||No||No||No|
|Change record permission regardless of the permission||Yes||No||No||No||No|
|Add and remove users, add and remove groups, add and remove users from a group and reset user password||Yes||No||No||No||No|
|See their own records||Yes||Yes||Yes||Yes||No|
|Update their own records||Yes||Yes||Yes||Yes||No|
|Change permission of their own records||Yes||No||Yes||No||No|
|Add and update types, design, breeding method etc. (vocabulary entities)||Yes||No||Yes||No||No|
|See public records||Yes||Yes||Yes||Yes||Yes|
Firstly a look at Groups, then the permissions settings that feature on some KDManage screens.
The security model used by KDDart is a common construct based upon record level permissions of which ownership of a record is assigned to a ‘Group’.
Simply put, ‘Groups’ own records, not users. Users, however are assigned to Groups.
Groups are managed by ‘Group Administrator(s)’ who are users with the ability to:
- Assign or add users to the Group
- Assign other users of the Group as a Group Administrator
- Delete records (when available) owned by the Group (except where data dependencies restrict deletion).
- Group Administrators can only conduct administration activities for a Group they are assigned to as Group Administrator.
- The creator of a Group automatically has Group Administrator capability for that Group.
Whilst creating and arranging your Groups and users, those users requiring an administrative capacity should be assigned to the new Group as a ‘Group Administrator’.
First, some understanding of record access permissions is required, to ensure you and the necessary colleagues have the correct access to perform their tasks within KDDart.
Permission setting is mandatory in the following KDManage screens, so this topic has been singled out to avoid repetition:
All the following Add screens have the same requirements for permission settings:
- Specimen List (also referred to as ‘Specimen Group’)
- Marker Data Management.
Permission fields, as above, do not appear on many KDManage screens, however permissions are inherited and full data integrity is maintained internally by the system.
The following table describes the permission settings for the record. These values are available for selection from the three permission field drop downs.
|None||No access to the record.|
|Read||The record may only be read.|
|Read & Link||The record may be read or linked to, which refers to the ability to create an association, or link, with the record.|
|Read & Write||The details of the record may be read or written/updated.|
|Read & Write & Link||The details of the record may be read or written/updated or linked to.|
Record deletion does not appear as this capability is not selectable (not available in KDManage) and is limited to users assigned as Group Administrator.
Permission settings must be set for the three Groups shown in the following table:
|Owner||The ‘Owner Group’ is the Group inherited from the user at the time the record was being created.
E.g. if the user’s Group is set to ‘A’ the record created will have an ‘Owner Group’ = ‘A’.
|Access||The ‘Access Group’ is for the primary users of the record(s), who are not the ‘administrator of the record’.|
|Public||The ‘Public Group’,is ‘the remainder’ of KDDart users who are neither within the Owner or Access Groups.
Note: They are still authenticated users within this installation of KDDart.
Automatic logoff from KDDart may occur following a period of inactivity if the timeout has not been programatically overridden by the application at logon.
The inactive time period setting and automatic logoff option can vary depending upon the configuration chosen for each installation of KDDart.
Maps are used in several locations to define areas such as Sites and Trials.
To commence selecting an area on the map:
- Scroll to the location required and double click on the map to zoom to that location. Keep zooming until you have the required level of detail.
- Select the ‘Draw a new object’ button which will result in a blue circle and central dot appearing.
For moving the selected area or altering it’s shape select the middle button and the drawn area will highlight in another colour. The connection corners will show circular handles.
- To move the shape select the middle handle and move to the desired location.
- To alter the shape select the desired corner hand and stretch the boundary. Where the centre of a line has been moved new midway handles will appear allowing further fine adjustment of the area.
- Select the middle button to exit from this map edit mode.