Introduction To KDManage

About This Help

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.

Audience

This document is intended for the following audience although it is not strictly confined to the roles listed:

Roles and Responsibilities
Role Responsibility
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.

More Information

For more information on KDDart and Diversity Arrays Technology see the following websites:

KDDart Environment Overview

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 KDDart System Architecture (Select to zoom)

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.

KDDart Applications
Application Description
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.

When to use KDManage?

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.

Data Dependencies

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:

  1. Organisation(s)
  2. Contact(s) - belonging to Organisations
  3. Sites
  4. Genotypes and Specimens
  5. Trials.

Note

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.

Simplified hierarchical view of KDDart data dependencies (Select to zoom)


Importing

Frequently pre-existing data will exist that needs ‘importing’ into KDDart such as Genotypes and Specimens.

Tip

Until you are familiar with the import functionality or have large files to import it is recommended that you:

  1. Backup the KDDart database prior to performing large imports
  2. Ensure all data Data Dependencies have been addressed beforehand
  3. 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.

Note

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.

Deleting

As of KDManage Version 1.9.12, delete function has been added for some KDDArT entities. They are:

  • Trials
  • Genotypes
  • Specimens
  • Items

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.

Login and Switch Group

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.

KDManage switch Group selection after login (select to zoom)

Access Settings and Permissions

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.

Permission Matrix
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.

Groups

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).

Note

  • 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.

Tip

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’.

Permissions

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:

  • Genotype
  • Trait
  • Trial
  • Specimen List (also referred to as ‘Specimen Group’)
  • Marker Data Management.
Permission settings common to the KDManage screens listed above (select to zoom)

Note

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.

What Permissions Can You Set?

The following table describes the permission settings for the record. These values are available for selection from the three permission field drop downs.

Permission Settings
Permission Permission Description
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.

Note

Record deletion does not appear as this capability is not selectable (not available in KDManage) and is limited to users assigned as Group Administrator.

Who is it Set For?

Permission settings must be set for the three Groups shown in the following table:

Group Permissions
# Group Group Description
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.

Logout

The Logout button Logout-btn appears in the Admin Bar admin-bar at the top right of the KDManage screen.

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.

Map Selections

Maps are used in several locations to define areas such as Sites and Trials.

To commence selecting an area on the map:

  1. 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.
  2. 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.