I agree that we should avoid automatically marked names as fully-specified or preferred if it is causing problems. Can you verify my assumptions…
Fully Specified Name
At least one required. All concepts must have at least one fully specified name (in any locale).
Additional locales optional. As long as a concept has a fully specified name in one locale, it may optionally have a fully specified name in other locales.
One per locale. A concept may not have more than one fully specified name in any locale.
Unique within locale. Fully-specified names must be unique within any locale.
Preferred Name
Explicitly Defined. Every concept that has one or more names in a locale must have one marked as locale-preferred.
Only when a concept has names in a locale. If a concept doesn’t have any names in a locale, then (obviously) it won’t have a preferred name in that locale.
Presumably, CIEL validation should fail if the above assumptions are not met, right?
I think this is correct, but there also cannot be two concepts with the same fully-specified name in a locale. I also believe that there cannot be the same preferred name on two different concepts in the same locale.
Good catch. I added the requirement that fully-specified names be unique within a locale.
Interesting twist. I hadn’t considered this. So, in a system favoring brevity, holosystolic murmur and hepatosplenomegaly could not both be configured to have HSM as a preferred name? I understand the importance of avoiding ambiguity; however, given that we cannot predict the variety of contexts preferred name is used, would a warning be more appropriate than a validation rule here?
I thought the same, that was one of main reasons I wanted to get clarity. We clearly don’t want to have two or more names for a concept in a locale without a preferred name (i.e., no indication of which one should be used when a single name is needed). What’s the benefit of allowing a single name (e.g., a synonym) in a locale to not be preferred? That seems more likely to lead to errors (of omission) than provide any benefits.
It was not that locales couldn’t have just one synonym… if there is one FSN and one synonym, one has to be flagged as preferred. We can’t assume the synonym is the one which is preferred. If there are only synonyms in the locale and no FSN, then neither synonym can be assumed to be the FSN. So another requirement is that a FSN is required for any concept which has a concept_name in that locale. If there is only one synonym (by mistake) and no FSN, we considered elevating it to an FSN in that locale, but it turned out that most of those would not be unique and so we should just require the FSN if there are any concept_names in that locale.
I thought we were only requiring one FSN per concept – e.g., you could translate a concept to another locale without the name having to be a FSN or having to add a FSN as well. Instead of auto-elevating names to FSN, perhaps we should examine why we require an FSN in every locale. I can understand requiring a preferred name for each locale, but I don’t see why we need to require an FSN in every locale in which the concept has names.
If you are unable to describe the concept in the locale, how do you know which name should be preferred? I suppose I agree that it would be possible to have a name without specifying it as the FSN, and assume that whoever created that name knew the FSN in the other language (in most cases English)… then as long as the preferred name is synonymous with the FSN (and not just close) then it doesn’t have to be the FSN… but if that were true, why not make it the FSN… or at least require an FSN version?
I think most reference terminologies require the FSN, but am willing to hear this out.
You have more experience than me, but it’s not hard for me to imagine a scenario like this:
My implementation has got a beautiful dictionary that I built from CIEL concepts. Concepts are neatly organized with FSNs like Gastroesophageal Reflux Disease and Esophagogastroduodenoscopy.
As one of the few people bilingual in my local dialect and English, I’m tasked with translating a set of concepts into local dialect so they can be printed on patient handouts. I know the local terms for heartburn and for upper endoscopy and can enter those as synonyms in my locale, but I have no idea how to translate the fully specified name or even if it could translate. Each synonym will be marked as the locale-preferred synonym (since there’s only one) and, if I should make a couple synonyms in my locale, deciding if the second synonym should be preferred is no problem for me. From a pragmatic perspective, there’s no reason I need to come up with a fully qualified and unique name (FSN) in my locale for these concepts. All we need are the synonyms for printing.
If the system forces me to specify a FSN in my locale, then I’m probably going to inappropriately tag my non-fully-specified synonym as an FSN for my locale (just to make the computer happy).
Good point, but the people using those concepts are assuming that their translation of the synonym actually means the same thing as the concept they are mapping to, and without actually doing that conceptual translation in that locale, there is no guarantee that it will be correct. Your pragmatic point is a good one, and part of the reason that we may not want people to make such translations unless they feel qualified to translate the FSN.
But, on a practical perspective, you can’t stop people from making those localizations, so probably better to allow them to not specify a FSN, so they end up with a less-than-perfect synonym rather than a less-than-perfect FSN.
We never automatically mark a name as the fully-specified name (FSN). As long as a concept has at least one name (in any locale) marked as FSN, we’re happy, but we never automatically convert a name into an FSN in a migration or upgrade script. If a concept does not have a FSN in _any_locale, then the concept is invalid.
Explicitly defined preferred names. Our scripts & API should help ensure that whenever there is one or more name for a concept within a locale, one (and only one name) is marked as preferred.
If so, I believe we’re aligned with the functional requirements as described in my [original post] (Clarifying use of fully-specified and locale-preferred names) and , by sticking to these requirements, we can avoid problems like the duplicate name problem arising from upgrade scripts.