Annotations review

Hi @Matt Cordell @Dion McMurtrie @michael lawley @Alejandro Lopez Osornio @Mounir Bouzanih (Unlicensed) @Patrick McLaughlin @Mikael Nyström (Unlicensed) @Stuart Abbott (Unlicensed) @Gábor Nagy (Unlicensed) @Reuben Daniels 

We need some quick initial thoughts on this before the next TRAG meeting in October, in order to try to unblock the development, so if you could please read through the options below and let us know

There are 3 options for managing the Language code - see the "Representation of annotation data type" section of the MAG proposal: SNOMED CT Annotations (this is because the other option was to include "@en" in the "annotationValue" field, which would be a problematic idea for implementations as the entire field would have to be parsed each time in order to extract the language code):

1. Add a new column to host the Language code + where this optional field is not required, simply default it to "en".

   1. This is because RF2 files do not really cater for NULL values in fields

   2. Where it's not required, populating it with "en" should not have any impact on implementations as the field can just be ignored

   3. However, in theory this could be slightly confusing for users, but only if they don't know that this is an optional field

2. Add a new refset type for "text type annotations" which includes the additional Language Code column, which is then always populated in this type of refset.  Then have an additional refset type for "non text type annotations (numbers, calculations, etc)" which doesn't include the Language Code column.

   1. This still prevents the inclusion of NULL values

   2. It also prevents any confusion for users which might happen with a redundant "en" populated for non text type annotations

   3. However, it seems like a significant overhead (both for maintenance and for implementers) just to ensure complete clarity, as the number of "non text type annotations" is likely to be very small.  This solution could, therefore, be complete overkill

3. Borrow some OWL syntax and add the language in front of any text which is then wrapped in quotes so    @en "This is an example of an English annotation"

   1. When there is no need for a language (eg for a URL) then the tag would not be used.   

   2. Question perhaps over the use of the quote marks for non-language strings like URLs...

Please provide feedback ASAP on your preferred option + the reasons behind your thinking - thanks very much!

Andrew

I prefer option 3. It is not a model used to represent language in SNOMED yet; however, it could be extended to concrete values as well.

Option 1 is technically unpleasant, with the empty/default column in cases without meaning. Option 2 adds too much complexity.

Best regards

Option 3 seems best to me. 

I'm assuming OWL has a way to handle text that already uses quotes at the start of the word string though. 

Option 1 risks an English default where the annotation may simply not be in English, for example a picture with no words on. 

Adding another refset type of Option 2 just keeps adding more complexity and may not be that easy to implement in authoring tools.