FSN Issues and Decisions
Comments
Apr 13, 2017
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
SNOMED Spaces
The specification currently states that exactly one rdfs:label will be generated for the English FSN of a given concept. While this works with the International Edition, there are several circumstances that occur in other editions/extensions that need to be addressed:
Are FSN's module specific? When creating an rdfs:label (or rdfs:labels) for a concept, do we recognize labels whose:
Description file and corresponding language refset entries are not from the module we are emitting.
Description file entry is not from the module we are emitting but there IS a refset entry in that module
Description file entry is from the module we are emitting, but do not have a language refset entry in the module we are emitting
How do we address two or more FSN's?
Case A: Two or more different languages, one of which is English?
Case B: Two or more different languages, none of which is English?
Case C: Two or more FSN's in the same language?
The Spackman Perl Script assumes that every concept has exactly one FSN, which is English. It pays no attention to the module.
The first thing that needs to be answered is whether any of the above situations are not allowed – which would not be considered valid RF2.
From an RF2 perspective:
Is an English FSN required?
Are FSN's language specific?
Can extensions add FSN's to concepts that are not defined in that extension?
If so, how should that addition be represented?
Can an extension change the FSN of a concept that is not defined in that extension?
If so, how should that change be represented?
At the moment, the transformation script implements the following rules. (Note that these rules only recognize active entries. Inactive entries are ignored):
If there are no FSNs for a given concept id, an error is thrown.
If there is exactly one FSN, it becomes the rdfs:label for the concept with the language set to the language code in the description file record. The module id of the description entry is ignored
If there are any FSN's whose language code matches a target language of the conversion (e.g. if target languages are ("en-us", "en-gb" and "es"), the first (random) matching FSN is emitted (e.g. a FSN with a language code of either "en" or "es")
If no matching language codes are found, the first "en" FSN is used (if any)
If neither case 3 nor 4 apply, a random FSN is returned.