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

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

I was thinking about the extensions and translation that was brought up in the telco from yesterday. In the Netherlands we are using an extension and we create our own concepts. Translation is hot topic now in our country and we will more exhaustively translate in the near future (so we really need this tool!!). If in the authoring tool of IHTSDO it will not be possible to add dutch descriptions (including definitions) to newly created concepts we will have to do it with the translation tool. But I do hope it is possible? However, translations are driven by refsets in the tool, but I hope it will be possible to add our own concepts from our extension to refsets, also the intensionally created refsets? We are willing and be able to test the tool for the combination refset/translation, we have plenty of use cases to use as test data. The plan is to start using the tool as soon as it is deployed (if everything works ok for our needs).

Contributors (4)


  1. Hi Elze,

    In the first instance, the translation tool will currently allow you to create the new translations based on any reference set you create from the International release, and so would not include any concepts that you have specifically created in your extension. 

    However, we will be discussing with each Member country interested how we could do that. The challenge for the IHTSDO  is when we do not manage the release of an extension, there is little we can do outside of hosting published releases.

    I'll let Brian Carlsen comment as well.


    1. Thanks for your answer Rory. I think the tooling is not usable for NRCs with an extension when concepts in the extension can't be part of a refset. Almost all the refsets we manage include concepts that are in our extensions and not in the international release. I was wondering if it can be possible to access our own terminology server (where our extension is hosted) from the translation/refset tooling as long as it not possible to load our extension in the IHTSDO terminology server. I do understand that is a longer term solution that we ofcourse do prefer. If we can access our extension from the tooling that might be a short term solution.

  2. Could a pre-release version of the extension be loaded but not publicly accessible? We have an approx. 3 week period to review the subsets against the forthcoming release to be synchronous with it.  If you were able to load the candidate release into the international tooling that might enable adoption with or without the international authoring environment. Whilst I think the integrated solution will be desirable long-term there may be inhibiting factors for some extensions that slow adoption of certain elements of the platform.

    1. This is a possibility, but we need to consider the support overhead for IHTSDO to be able to do this for every NRC. Unfortunately, this is the challenge we have with a lot of local reference sets. We can only host so much before it starts to have implications on running costs and responsibility, just as each NRC would only host their own extension. At this point, the initial version will be fro reference sets from the International edition.

      1. Thanks Rory, this will be interesting to see this develop and whether the Member Forum would support this type of functionality.

  3. Not sure if this went anywhere, in management the extensions often have the most challenging areas due to large numbers of primitaves and migration of concepts from the extension to the international edition. It is also importantant to understand how versioning is managed during the transition as typically the refset and extension release is some months after the International release. Brian Carlsen, Rory Davidson

  4. I can see there is a real use case for being able to author new concepts in an extension as well as add translations to existing international content.  A concept developed in an extension may eventually migrate to the international edition (in which case it would have English names as well as extension-language names), or it may just live in the NRC extension (in which case maybe it only needs extension-language names).

    The refset/translation tool isn't a concept authoring tool, so it relies on pointing to a data source (e.g. terminology server integration) that contains the data against which the refset is being developed.  One can imagine a scenario where either the refset tool is pointed to the same data source as the authoring tool used to create new concepts - in which case it would be possible to bring together the points of creation of new content (to be included in refsets) along with development of additional translations.   There are a variety of potential modes of interoperation between an authoring tool and the refset tool depending upon the specific  use case, need for "real time" access, and whether translated names are being developed in the authoring tool or in the refset tool.

    I think exploring the various ways in which NRCs want to manage (a) new extension concepts, (b) refsets that include new extension concepts, and (c) translations of international edition concepts is needed so that a consistent approach can be developed.

    This is all said in the context of Rory's comment above about the potential unfeasability of supporting this all at the IHTSDO level and may under some circumstances require local installation of the technology and tooling stack to achieve the desired result.  

    This seems like a fruitful topic for a future tooling group meeting.