Order the Track Repository According to a Unified System

[janothan]

Problem

The track repository is structured in three dimensions:

1. Track
2. Version
3. TestCase

Version and TestCase are currently used inconsistently. Sometime versions are used to model testcases.

Solution

• Add consistent definitions to the documentation so that others understand the logic.
• A track should be used in the way the OAEI defines tracks: A track is a collection of test cases evaluated by one organization body. In some cases, it is reasonable to have multiple tracks in the repository for "sub-track-like" problems, i.e. one track has multiple sets of test cases that are evaluated individually.
• A track version should be used to represent different (time) versions of a track. A track evaluated in one campaign (e.g. 2021) should never have multiple track versions but only one version. The track version does not have to be a year. Any versioning system is possib.e.
• A test case represents one matching task.

Re-Organization

Phenotype

• Track: Phenotype
• Version: vX (the 2017 version is kept for reference, but deprecated since not all TC are available in the repository)
• Test Cases:
  • hp-mp
  • doid-ordo

LargeBio

• Track: LargeBio Small / Large / All []
• Version: 2016
• Test Cases:
  • FMA-NCI-{flavor}
  • FMA-SNOMED-{flavor}
  • FMA-NCI-{flavor}

Multifarm

• stays as is