Overview
Documentation on what projects, refsets, and translations are and how they are used in this application.
Projects
To organize the collection of users and roles that are used to maintain refsets and translation, the tool makes use of a Project.
Following are some important features of the Project that need to be chosen when it is created
| Field | Purpose |
|---|---|
| description | The description of the project |
| exclusionClause | A top-level exclusion clause that will be used by all intensional reference sets |
| feedbackEmail | An email address endpoint for feedback on published Refsets or Translations (e.g. this shoud be something like Siebel or Freshdesk, ideally) |
| moduleId | The default SNOMED module id, when creating Refsets |
| name | The name of the project |
| namespace | The default SNOMED namespace id, when creating refsets |
| organization | The organization name |
| terminology | The default terminology-server supported value indicating the SNOMED edition. |
| terminologyHandlerKey | The handler key (from config.properties) corresponding to the terminology-server integration. BROWSER is the IHTSDO browser, SNOWOWL is for a SnowOwl endpoint (e.g. an IHTSDO authoring environment branch) |
| terminologyHandlerUrl | The default URL for the terminology server integration (e.g. IHTSDO browser API, or the authoring tool endpoint) |
| version | The default version for the terminology |
| workflowPath | The workflow path to use, DEFAULT is the standard workflow, SNOMED corresponds to a workflow that implements the standard IHTSDO workflow for translations (uses the same workflow for refsets as DEFAULT). Valid values here are driven by the terminology integration itself. For SNOWOWL, this is the path to use. |
Refsets
The tool is for creating and maintaining "Simple" pattern refsets only. In this context, a Refset represents a subset of SNOMED concepts defined either as a list (extensional) or as a definition (intensional). Refsets are defined in the context of a Project (and some of the key values are defaulted from the Project definition).
| Field | Purpose |
|---|---|
| active | Indicates whether the refset is active (typically this is always true) |
| effectiveTime | For "published" refsets, indicates the effectiveTime in an RF2 sense. |
| moduleId | Indicates the moduleId for the refset, in an RF2 sense |
| Refset id | The refset concept id for the refset. |
| description | Description of the refset |
| domain | An open-ended field for describing the general domain for the refset |
| feedbackEmail | The feedback email for the refset (defaults to the project value but can be overridden) |
Local Sets
A local set is a refset that does not require a namespace id or a module id. In other words, it represents a lightweight Refset in the context of the International edition of SNOMED that is not associated with an extension.
Translations
Translations hang off of Refsets in a sense. To create a Translation you must reference a Refset which provides the overall "scope" definition for the translation. Translations may contain concepts that are not in the refset itself, so it is used more as a means to drive workflow. In other words, un-translated concepts in the refset will show up as "available" for editing. This allows managers of translations to control the volume and extent of concepts to be translated.
In general, the moduleId, namespace, and refsetId of the refset corresponding to the translation are effectively "borrowed". Thus a translation release will make use of the namespaceId for descriptionId assignment. It will make use of the moduleId for both description and language files in a release, and the refsetId itself will be used as the language refset id.
There are really only three important fields that can be chosen when creating a translation:
| Field | Purpose |
|---|---|
| name | The translation name |
| description | The translation description |
| language | The language for the translation |
Translations can have only a single language. And generally, it's a good idea to have only a single translation for a given "scope refset". Try to avoid creating multiple translations for a single refset as this may prove confusing later.
Translations make use of phrase memory and spelling correction entries which allow for buliding up of some intelligence over the course of a translation project. These files can be exported/imported or borrowed from other translations. Thus, if you have an existing "correctly spelled word" list for your language, it can be imported and used from the beginning of a project.