From ICISWiki

Contents 1 Germplasm Management Groups 1.1 Modifying the Pedigree Links 1.2 Adding a Management Group table 1.3 Using the List Management System 1.4 Adding a Management Group Field 1.5 Using a Germplasm Attribute 2 Conclusions

Germplasm Management Groups

The current ICIS Germplasm Model tracks generative, derivative and maintenance groupings and relationships very well but these do not always coincide well with management groups. We note that the decision to make a germplasm the root of a management group is an external decision independent of the biology of the pedigree. The example we have is the management of samples of an accession in a genebank. These are all derived by maintenance methods, but are generally only a subset of the maintenance neighborhood. An accession imported from a foreign genebank is in the same maintenance neighborhood but comes from another management group and we have no simple way of flagging the point at which management responsibility transfers. This is especially important for data concerning IP status, but is generally a problem for all passport data which need to be inherited by samples derived from an accession or sample representing the management root. It is complicated by the fact that sample source (GPID2) is sometimes unknown and group source, GPID1, may point back to a generative germplasm outside the management group from where it is not even possible to uniquely trace the accession. In this case the only way to identify the accession is via names which is not satisfactory in a general system.

We considered several solutions.

Modifying the Pedigree Links

Modifying the contents of the GPID1 field to point to the management root for any maintenance germplasm which is in a management group.

• Under this approach the assignment of GPID1 values for maintenance germplasm follows the same rules as for derivative germplasm except when the germplasm is declared to be the root of a management group. In this case GPID1 is set to its own GID. (Subsequent maintenance generations inherit this value for GPID1).
• This supports germplasm flowing from one management group to another. Pedigree tracing and cross expansion become more complicated with special algorithms to traverse the management bounderies.
• Identifying the management root for any maintenance germplasm is trivial: If GPID1 is a maintenance germplasm (including when it is self referencing) then the MRT is GPID1, otherwise the germplasm is not in a management group.
• The solution gets very complicated when maintenance germplasm reverts to generative or derivative within a management structure. It is not possible to change the meaning of GPID1 in generative germplasm and it complicates processing to do so with derivative germplasm.

Adding a Management Group table

Adding a management group table linking all sample GIDs to a root sample GID. This is a good general solution since it allows a sample to be in many management groups but it is expensive on space and requires new software features to manage.

Using the List Management System

Assigning lists to every accession and adding samples as they are generated. This is expensive on space but is handled by existing software.

Adding a Management Group Field

Adding a management GID field (MGID) to the GERMPLSM table which would link to the management root or accession for any sample and be 0 for GIDs not belonging to any identifiable management group. This is easy to implement, space efficient, but only allows a GID to be in one management group.

Using a Germplasm Attribute

You could use a Germplasm Attribute to store the root node of a management group for any germplasm. This has the flexibility of allowing a germplasm entry to belong to multiple management groups.

Conclusions

Current opinion implemented is adding a management GID field.