Applies to Matrix key projects
Import merging allows key authors to work collaboratively, with individual keys, or parts of keys, edited separately and then merged into a single key. Feature, States, Entities and scores in the individual keys are merged.
To merge keys, open the base key (usually the most complete version of the key; but see under Score Merging below to understand score dominance) into which the others will be merged, then import a second key (the import key) using the Import option from the File menu. If the Feature/State or Entity lists in the two keys being merged are not identical, the merged key will comprise the entire, combined set of Feature/States and Entities.
All import options support merging.
During the import process, if an item in the imported key is found to be identical to an item in the base key, the imported item’s score data will be merged with the base key’s item’s scores. If an imported item is not identical to any items in the base key, it will be added, with its score data, to the base key’s item tree. In some cases, imported data will result in unresolvable conflicts, usually due to tree structure constraints; see below for information relating to resolving such conflicts.
Score Merging
In all cases the imported item’s scores are dominant compared with the base key’s scores, and are merged using the following rules:
- Multistate scores: Present > Rare > Misinterpretation > Absent > Uncertain
- Dependency scores: Negative > Positive > Absent
- Subset scores: Present > Absent
Numeric scores are merged using the following rules:
- Features to be merged must have equivalent measurement units.
- Rows are merged based on equality and overlap, as shown below.
| Imported | Existing | Result |
|---|---|---|
| Non-overlapping import | ||
| (1-)2-3(-4) | (10-)20-30(-40) | (1-)2-3)(-4), (10-)20-30(-40) |
| Overlapping import | ||
| (5-)8-15(-30) | (10-)10-20(-40) | (5-)8-20(-40) |
Import Conflicts
If any unresolvable conflicts are detected during the merging process, the imported nodes that resulted in the conflict will be placed under an ‘Unmerged’ node at the root of the tree. These nodes will need to be dealt with manually dragging and dropping them to a suitable location in the key. Typical causes of unresolvable conflicts are tree structure constraints (E.g. Attempting to import a Feature as a child of a multistate Feature).