Page tree
Skip to end of metadata
Go to start of metadata

1048 View 7 Comment In discussion Comments enabled In the category: refset-tooling

I can't remember this was in the demo. In the Netherlands we have the situation that we need more than one language refset. We ofcourse have the dutch language but we also have the language for patients which we want to store in a different language refset. Also in the future we can't avoid the situation that specialists want to use different jargon (for example optometrists and ophthalmologic specialists) and therefore different prefered terms for a concept. That are going to be different language refsets too. So here is my question: Will it be possible (now or in future) to manage more than one translation and export the language refsets in one RF-2 file? I think it will be possible to manage the translations separately and export in different RF-2 files, but I am not sure? I'm curious about the possibilities.

Contributors (4)

7 Comments

  1. Hi, 

    we are not building any limitation on the number of language reference sets, so it should be possible. With regards to the export, I will let Brian Carlsen provide an answer to that. However, at this stage, we would recommend that there is a separate language refset rf2 file per language. Andrew Atkinson may be able to provide more thoughts on that.

    Thanks,
    Rory 

  2. Hi Elze

    I would agree with this - whilst it is technically possible to maintain multiple language refsets within the same RF2 file (via the use of the refsetId distinction), we would recommended using multiple language files (one for each language).  This way you can remain in line with our filename formatting conventions, and set the language code in the filename to the relevant code for each language (eg) der2_cRefset_LanguageFull-en_INT_20160131.txt, and der2_cRefset_LanguageFull-nl_INT_20160131.txt.  Not only does this make the package more human readable, but it also allows for multiple dialects to be represented within each language file.  This is exemplified in our International edition, where we provide 2 language refsets (en-gb and en-us) in the same file in the International edition - as these are both technically dialects of English - we therefore set the language code in the filename to "en".  If we were to include, say, the Spanish language refset int he same package, we would likely include an additional file called der2_cRefset_LanguageFull-es_INT_20160131.txt (with the "es" language code to denote the Spanish language), and within that we would potentially hold multiple language refsets, one for each of the Spanish dialects.

    Having said that, this is an interesting topic, and so I have added it to the agenda for the next Release Advisory Group to discuss (in Q1 2016).  I will let you know if they disagree with this proposed approach, and if so what they recommend instead.

    Hope that helps - please let me know if you have any further questions?

    Kind regards,

    Andrew

    1. Hello Andrew,

      Thank you for your answer. In your example of en-gb and en-us I do agree with you and with patient language I can agree with your solution of separated RF-2 files because it is about the whole SNOMED CT international set. But when I think of jargon it seems a little bit devious to me. In that case it's about a subset of SNOMED CT (actually a refset) where in some cases a synonym becomes a prefered term and the other way round.

      For example in the cardiologist refset:

      Disorder of heart (disorder)

      Disorder of heart -> preferred term for the Netherlands (dutch translation) - all specialists like internal medicin

      Cardiac disorder

      Morbus cordis -> preferred term for cardiologist

      Cardiopathy

      The case is the only thing that is different is that there is a pointer to preferred accept for synonym. The description is usable for as well cardiologist as the general dutch translation. So is it really necessary to make a separate RF-2 for every disciplin that want some other preferred terms as in the general dutch translation, is that the most efficient way to do that?

      We are curious about what will come out of the discussion in Release Advisory Group. We will follow your advice (smile) We assume the IHTSDO tooling will follow your advice as well.

       

      Kind regards,

      Elze

       

       

       

  3. Hi Elze

    Thanks very much for your feedback - I'll ensure that this is discussed thoroughly in the Release Advisory Group, and will inform you of progress as and when recommendations are made.

    Thanks again,

    Andrew

  4. Elze,

    Just for my perspective ... The tool obviously will support multiple language refsets (e.g. translations) though it is currently architected to produce individual RF2 release files for each individual translation.  However, given the nature of RF2, several RF2 files of the same type can always be concatenated together to form a single file.  

    While the tool supports some basic release processing, including the creation of delta (and active snapshot) files, it is presumed that an NRC would use an independent release process to compile the various files needed for an extension into a distributable pacakge.  That provides an opportunity to take multiple RF2 files produced by this system and package them independently in a way that makes most sense for the NRC and its use cases.

    Brian 

  5. Brian, I am happy to hear that the tooling will support multiple language refsets. If you need anyone to test the functionality (or whatever other functionality) we would happy to help you. 

    Ofcourse we can arrange our RF-2 however we would like by combining different RF-2s from the separate language refset files. That is more a matter of principle how to release the different languages and is not something the tooling should support.

    Thanks and best wishes for 2016!

  6. Hi Elze

    As promised, I raised this as part of the Release Advisory Group agenda last night, and the response was overwhelmingly consistent, in that they all considered this to be an implementation specific issue, which means that it is really your choice as to which way that you would prefer to manage them.

    No-one had any case studies or examples of anyone else implementing either approach, and therefore they consider that it's really down to your preference as to how you wish to proceed.

    They did provide a couple of helpful tips however - firstly they said to remember that the key here is to ensure that you include a mechanism to allow the user to choose which term should be assigned as "preferred" in each case.  The second thing to consider is that the Latin terms have separate dialects as well (in that the Dutch Latin term would differ from, say, the Swedish Latin term), and therefore this should be taken into consideration.

    I hope that helps - if I hear anything more from anyone with regard to examples of how anyone else has implemented this, I will be sure to let you know straight away.

    Thanks very much,

    Andrew