Taxonomies - kwantu/platformconfiguration GitHub Wiki
Taxonomies are used to manage lists of data. Examples include a list of provinces or districts or a list of users on a community. There are different kinds of taxonomies, which may also be specified at different levels.
Types of taxonomies
| Taxonomy type | Description | Example |
|---|---|---|
| Simple | Simple taxonomies have a fixed set of terms. They may be a single level only or have multiples levels | A list of age ranges or a hierarchy of provinces, districts and wards |
| Dependent | Dependent taxonomies include multiple levels. However, unlike simple taxonomies they are split into multiple files, such that users may select one option, and then in the next menu select another option dependent on the first option selected | First select a province, then select a district in that province. |
| Search | Search taxonomies return a set of terms based on a search query. The query may operate on any field in any data object. | A list of projects |
| Server | Server taxonomies are generated by the server. They are useful when the criteria needed to generate a taxonomy are more complex than can be covered by a search query | A list of students enrolled in a course with specific grades |
Configuring a data object to reference a taxonomy
Explain which widgets can be used Explain that this points to taxonomy ID In certain instances taxonomies must be referenced and maintained globally in order to ensure consistency of data across a community. However, in other instances this doesn't apply, and provision should be made for taxonomies to be specified on an application level, or even at a community or a community-adopted application level.
To accommodate this, each DO refers to a taxonomy only. This may be inherited from: the "global taxonomy library", or may be specified when configuring the application; Or it may be deferred to a taxonomy specified by the community that adopts the application.
In order to achieve the above, a fairly fixed structure is defined for taxonomies, and they are stored as data objects in the config bucket referenced by their UUID. There are the following scenarios:
- The definer configuring a DO may define a taxonomy and define that this taxonomy may only be used for that specific DO. In such a case the taxonomy will be managed as a "global taxonomy" by the data registry. An example is "a specific age breakdown" that needs to be used commonly by all users of the DO in order to ensure consistency of that data.
- The definer may specify a taxonomy that is required at the "application level". In this case the taxonomy is specified by the application configuration, and not directly in the data registry. All adopters of the application will adopt the taxonomy with the application and use it accordingly. An example of such a taxonomy would be one in which some application specific calculation of a result is dependent on the taxonomy for instance. eg. Rating of satisfaction for a particular activity that might not apply to other applications.
- The community adopting applications may want to specify their own taxonomy that defines the regions in which they are working, which is specific to that community.
The community includes a "taxonomy mapping file" that maps the taxonomy id in the DO configuration to the actual taxonomy that needs to be used. In that mapping file the scope for change at the application or community level may be specified.
Levels at which taxonomies are referenced
While data objects reference a taxonomy ID, the taxonomy configuration file is stored under it's UUID. To find the UUID the platform will first check the community configuration file to see if it references the taxonomy. If not there, it will then check the app adoption configuration file. If not there it will then check the app configuration file. This mechanism allows communities to over-ride taxonomies specified in an app with community specific ones.
| Level | Explanation |
|---|---|
| App | The taxonomy is referenced at the app level |
| App adoption | The taxonomy is referenced when the app is adopted by a community |
| Community | Core taxonomies (for example location taxonomies) may be defined in the community |