Issue 7597: LQS: parsing of QualifiedNameStrs (lqs-rtf) Source: Foundation for Research and Technology (Mr. Stelios Sfakianakis, ssfak(at)ics.forth.gr) Nature: Uncategorized Issue Severity: Summary: According to the LQS specification (00-06-31), paragraph 2.1.4, the delimiter between a NamingEntity (NE) and a LocalName (LN) is the character '/', possibly excluding only the case of the 'OTHER' RegistrationAuthority. Reading this paragraph it is clear to me that in order to parse a QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's not 'IDL' or 'OTHER'), the *first* '/' is the delimiter between a NE and a LN, which also means that, in these cases, a '/' is not permitted inside a NE. If a QualifiedNameStr starts with "IDL" then the delimiter is the *last* occurence of '/'. The problem is that subsequent paragraphs in the specification (and also coding schemes and codes defined in the idls of LQS) DO NOT use these rules. For example the ICD-9-CM coding scheme should be represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which clearly is illegal because it uses the slash character inside the NE (which is the "hl7.omg.org/I9C"). There are numerous such cases throughout the spec. It is clear that if this kind of QualifiedNameStrs is acceptable then it is not feasible to have a "generic" implementation of the translation_library's str_to_qualified_code method: If I have a PIDS that supports a trait to represent the patient's spoken language and as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6) then according to 2.1.4 I should search LQS for the coding scheme "DNS:usmarc.omg.org" but I would probably find nothing because the ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). Thus I should be aware that when I see such codes, the coding scheme is the "DNS:usmarc.omg.org/041" and the rest is the concept code. But this forces me, as implementer of the translation library, to know all the possible coding schemes in order to parse them correctly. So my questions are: - Are the remarks mentioned above correct and well known? - If yes how the OMG is going to tackle this issue? - If the OMG considers it too costly to change all the examples in the spec. and the stringified coding schemes in the idls, what is the proposed way to implement the translation_library interface? (One solution might be to have the LQS expose a translation_library interface through the TerminologyService interface and let the LQS server do the "correct" transformation ...) [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it refers to "UniqueName" and "UniqueNameStr" which are unknown and it possibly means QualifiedName and QualifiedNameStr respectively. Secondly, it says that the character ':' should be the delimiter between NE and LN (!!).] Resolution: Revised Text: Actions taken: July 22, 2004: received issue Discussion: End of Annotations:===== te: Thu, 22 Jul 2004 11:20:15 +0300 From: "Stelios G. Sfakianakis" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en To: healthcare@omg.org Subject: LQS: parsing of QualifiedNameStrs X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Hello, According to the LQS specification (00-06-31), paragraph 2.1.4, the delimiter between a NamingEntity (NE) and a LocalName (LN) is the character '/', possibly excluding only the case of the 'OTHER' RegistrationAuthority. Reading this paragraph it is clear to me that in order to parse a QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's not 'IDL' or 'OTHER'), the *first* '/' is the delimiter between a NE and a LN, which also means that, in these cases, a '/' is not permitted inside a NE. If a QualifiedNameStr starts with "IDL" then the delimiter is the *last* occurence of '/'. The problem is that subsequent paragraphs in the specification (and also coding schemes and codes defined in the idls of LQS) DO NOT use these rules. For example the ICD-9-CM coding scheme should be represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which clearly is illegal because it uses the slash character inside the NE (which is the "hl7.omg.org/I9C"). There are numerous such cases throughout the spec. It is clear that if this kind of QualifiedNameStrs is acceptable then it is not feasible to have a "generic" implementation of the translation_library's str_to_qualified_code method: If I have a PIDS that supports a trait to represent the patient's spoken language and as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6) then according to 2.1.4 I should search LQS for the coding scheme "DNS:usmarc.omg.org" but I would probably find nothing because the ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). Thus I should be aware that when I see such codes, the coding scheme is the "DNS:usmarc.omg.org/041" and the rest is the concept code. But this forces me, as implementer of the translation library, to know all the possible coding schemes in order to parse them correctly. So my questions are: - Are the remarks mentioned above correct and well known? - If yes how the OMG is going to tackle this issue? - If the OMG considers it too costly to change all the examples in the spec. and the stringified coding schemes in the idls, what is the proposed way to implement the translation_library interface? (One solution might be to have the LQS expose a translation_library interface through the TerminologyService interface and let the LQS server do the "correct" transformation ...) [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it refers to "UniqueName" and "UniqueNameStr" which are unknown and it possibly means QualifiedName and QualifiedNameStr respectively. Secondly, it says that the character ':' should be the delimiter between NE and LN (!!).] I am looking forward to your comments Best Regards Stelios P.S. Please reply directly to me (in addition to replying to this list) because, due to bureaucrasy, we haven't yet access to the OMG's mailing lists :-( Thanks a lot! -- Stelios G. Sfakianakis | Center of Medical Informatics Voice: +30-2810-391650 | Institute of Computer Science To: "Juergen Boldt" , issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org Subject: Re: issue 7597 -- Lexicon Query Service RTF issue (RTF to be re-chartered??) From: "David Forslund" Reply-To: "David Forslund" X-Mailer: Bloomba Personal Edition 2.0 Date: Thu, 29 Jul 2004 16:19:26 -0600 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6TMTtlj002194 I think I agree in principle with the ambiguity pointed out by the author of this question. The LQS specification seems to consider in practice the boundary between the CodingSchemeId and the LocalName to be arbitrary rather than in accordance with the NamingAuthority specification. Perhaps this is intentional in the implementation of the specification. I'm interested in other interpretations particularly from those who have implemented LQS. I'm not sure it requires knowing all CodingSchemes to implement it. It may be more akin to understanding a hierarchical coding scheme strategy, which is actually pretty reasonable. Dave > ------------Original Message------------ > From: Juergen Boldt > To: issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org > Date: Wed, Jul-28-2004 1:13 PM > Subject: issue 7597 -- Lexicon Query Service RTF issue (RTF to be re-chartered??) > > I'll put the issue out there. The last RTF expired in 1999, the spec > appears to be in use...so.... > > > This is issue # 7597 > > LQS: parsing of QualifiedNameStrs > > According to the LQS specification (00-06-31), paragraph 2.1.4, the > delimiter between a NamingEntity (NE) and a LocalName (LN) is the > character '/', possibly excluding only the case of the 'OTHER' > RegistrationAuthority. > > > Reading this paragraph it is clear to me that in order to parse a > QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's > not 'IDL' or 'OTHER'), the *first* '/' is the delimiter between a NE > and a LN, which also means that, in these cases, a '/' is not > permitted inside a NE. If a QualifiedNameStr starts with "IDL" then > the delimiter is the *last* occurence of '/'. > > > The problem is that subsequent paragraphs in the specification (and > also coding schemes and codes defined in the idls of LQS) DO NOT use > these rules. For example the ICD-9-CM coding scheme should be > represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which > clearly is illegal because it uses the slash character inside the NE > (which is the "hl7.omg.org/I9C"). There are numerous such cases > throughout the spec. > > > It is clear that if this kind of QualifiedNameStrs is acceptable then > it is not feasible to have a "generic" implementation of the > translation_library's str_to_qualified_code method: If I have a PIDS > that supports a trait to represent the patient's spoken language and > as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6) > then according to 2.1.4 I should search LQS for the coding scheme > "DNS:usmarc.omg.org" but I would probably find nothing because the > ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). Thus > I should be aware that when I see such codes, the coding scheme is the > "DNS:usmarc.omg.org/041" and the rest is the concept code. But this > forces me, as implementer of the translation library, to know all the > possible coding schemes in order to parse them correctly. > > > So my questions are: > > > - Are the remarks mentioned above correct and well known? > > > - If yes how the OMG is going to tackle this issue? > > > - If the OMG considers it too costly to change all the examples in > the spec. and the stringified coding schemes in the idls, what is > the proposed way to implement the translation_library interface? > (One solution might be to have the LQS expose a > translation_library > interface through the TerminologyService interface and let the LQS > server do the "correct" transformation ...) > > > [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it > refers to "UniqueName" and "UniqueNameStr" which are unknown and it > possibly means QualifiedName and QualifiedNameStr > respectively. Secondly, it says that the character ':' should be the > delimiter between NE and LN (!!).] > > > > > > ================================= > Jürgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ > > To: "Tim Brinson" , "Juergen Boldt" , issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org, "Stelios G. Sfakianakis" , "Harold Solbrig" Subject: Re: issue 7597 -- Lexicon Query Service RTF issue (RTF to bere-chartered??) From: "David Forslund" Reply-To: "David Forslund" X-Mailer: Bloomba Personal Edition 2.0 Date: Fri, 30 Jul 2004 11:51:22 -0600 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i6UI1vlj011133 Good to hear from you, Tim. I agree with your assessment. The only issue with "private" interpretations might be a problem with interoperability. I've done this in areas where there was no existing vocabulary. Dave (BTW, I'm now retired from the Lab, but basically have an "emeritus-like" status as a Laboratory Fellow). I still will be active in this and other areas. > ------------Original Message------------ > From: "Tim Brinson" > To: "David Forslund" , "Juergen Boldt" , issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org, "Stelios G. Sfakianakis" , "Harold Solbrig" > Date: Fri, Jul-30-2004 11:38 AM > Subject: Re: issue 7597 -- Lexicon Query Service RTF issue (RTF to bere-chartered??) > > All, > > Dave, good to see you are still at LANL. Hope all is going well. > > I responded to Stelios, the guy submitting the issue (See attached). > As I > was responding to Stefios it took me a few iterations before I zeroed > in on > my final understanding of the issue. > > As one of the submitters on the LQS I don't recall meaning to break the > rules of the NamingAuthority. I think there may have already been an > issue > entered for this, a long time ago. I think we didn't have anyone > interested > in leading a RTF. > > When using the DNS registration authority, I think hierarchical coding > schemes were intended to be created via the dns rules. So the two > coding > schemes Stefios pointed out should have been changed in the spec like > this: > > DNS:hl7.omg.org/I9C -> DNS:i9c.hl7.omg.org/ > DNS:usmarc.omg.org/041 -> DNS:041.usmarc.omg.org/ > > I worked on a project that had on the order of 100 coding schemes. > There > was an extensive hierarchy to them. We used DNS as the registration > authority and we used the dns rules for the hierarchy. That is, we > followed > the NamingAuthority spec and we did not have any problems with it. > > However, in a particular environement one could define what ever rules > they > want to use for a stringified qualified code and provide their own > parsing > for it. As Dave points implies, you could do it in a way where the > rules > are consistent enough that you don't need to know the coding schemes in > the > translation library implementation. > > Tim > > > ----- Original Message ----- > From: "David Forslund" > To: "Juergen Boldt" ; ; > ; > > Sent: Thursday, July 29, 2004 3:19 PM > Subject: Re: issue 7597 -- Lexicon Query Service RTF issue (RTF to > bere-chartered??) > > > > I think I agree in principle with the ambiguity pointed out by the > author of > this question. > The LQS specification seems to consider in practice the boundary > between the > CodingSchemeId > and the LocalName to be arbitrary rather than in accordance with the > NamingAuthority specification. > Perhaps this is intentional in the implementation of the specification. > I'm interested in > other interpretations particularly from those who have implemented LQS. > I'm > not sure it requires > knowing all CodingSchemes to implement it. It may be more akin to > understanding a hierarchical > coding scheme strategy, which is actually pretty reasonable. > > Dave > > > ------------Original Message------------ > > From: Juergen Boldt > > To: issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org > > Date: Wed, Jul-28-2004 1:13 PM > > Subject: issue 7597 -- Lexicon Query Service RTF issue (RTF to be > re-chartered??) > > > > I'll put the issue out there. The last RTF expired in 1999, the spec > > appears to be in use...so.... > > > > > > This is issue # 7597 > > > > LQS: parsing of QualifiedNameStrs > > > > According to the LQS specification (00-06-31), paragraph 2.1.4, the > > delimiter between a NamingEntity (NE) and a LocalName (LN) is the > > character '/', possibly excluding only the case of the 'OTHER' > > RegistrationAuthority. > > > > > > Reading this paragraph it is clear to me that in order to parse a > > QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's > > not 'IDL' or 'OTHER'), the *first* '/' is the delimiter between a NE > > and a LN, which also means that, in these cases, a '/' is not > > permitted inside a NE. If a QualifiedNameStr starts with "IDL" then > > the delimiter is the *last* occurence of '/'. > > > > > > The problem is that subsequent paragraphs in the specification (and > > also coding schemes and codes defined in the idls of LQS) DO NOT use > > these rules. For example the ICD-9-CM coding scheme should be > > represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which > > clearly is illegal because it uses the slash character inside the NE > > (which is the "hl7.omg.org/I9C"). There are numerous such cases > > throughout the spec. > > > > > > It is clear that if this kind of QualifiedNameStrs is acceptable then > > it is not feasible to have a "generic" implementation of the > > translation_library's str_to_qualified_code method: If I have a PIDS > > that supports a trait to represent the patient's spoken language and > > as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6) > > then according to 2.1.4 I should search LQS for the coding scheme > > "DNS:usmarc.omg.org" but I would probably find nothing because the > > ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). > Thus > > I should be aware that when I see such codes, the coding scheme is > the > > "DNS:usmarc.omg.org/041" and the rest is the concept code. But this > > forces me, as implementer of the translation library, to know all the > > possible coding schemes in order to parse them correctly. > > > > > > So my questions are: > > > > > > - Are the remarks mentioned above correct and well known? > > > > > > - If yes how the OMG is going to tackle this issue? > > > > > > - If the OMG considers it too costly to change all the examples in > > the spec. and the stringified coding schemes in the idls, what > is > > the proposed way to implement the translation_library interface? > > (One solution might be to have the LQS expose a > > translation_library > > interface through the TerminologyService interface and let the > LQS > > server do the "correct" transformation ...) > > > > > > [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it > > refers to "UniqueName" and "UniqueNameStr" which are unknown and it > > possibly means QualifiedName and QualifiedNameStr > > respectively. Secondly, it says that the character ':' should be the > > delimiter between NE and LN (!!).] > > > > > > > > > > > > ================================= > > Jürgen Boldt > > Director, Member Services > > > > Object Management Group > > 250 First Avenue, Suite 100 > > Needham, MA 02494 > > > > Tel. +1 781 444 0404 ext. 132 > > Fax: +1 781 444 0320 > > email: juergen@omg.org > > www www.omg.org > > > > ================================ > > > > > > From: "Solbrig, Harold R." To: Tim Brinson , David Forslund , Juergen Boldt , issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org, "Stelios G. Sfakianakis" Subject: RE: issue 7597 -- Lexicon Query Service RTF issue (RTF to bere-chartered??) Date: Fri, 30 Jul 2004 15:49:07 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) All, The confusion centers around the definition of "localName". When talking about a code system, the code system identifier is the localName, but when talking about a concept code, the code itself is the "localName" and the code system becomes the "naming authority". As observed in the issue report below, this results in a conflict - do you go from: DNS:umls.hl7.omg.org/041 for the code system to: a) DNS:041.umls.hl7.omg.org/SPA for Spanish or b) DNS:umls.hl7.omg.org/041/SPA ? The latter (sort of) makes more sense, but, as pointed out in the issue report, violates the stated syntax. The former requires some unstated and possibly incorrect transformation rules. The LQS spec used the latter form in the examples even though it wasn't strictly correct. Since the LQS specification was published, HL7 has decided to use ISO OID's for all of their Version 3 objects. This has resulted in a similar set of issues. The root HL7 OID is "2.16.840.1.113883". They have chosen to partition their namespace for management purposes, so node "6.2" represents ICD9-CM and "6.10" the IETF Mime Types, etc. ISO has begun to deprecate the NameForm, so we have switched to the Number form, but the issue is fundamentally the same. Do we represent ICD9 as ISO:2.16.840.1.113883/6.2 Or ISO:2.16.840.1.113883.6/2 Furthermore, should "text/plain" be represented as ISO:2.16.840.1.113883/6.10/text/plain Or ISO:2.16.840.1.113883.6.10/text/plain --------------------------------------------------------- The standing resolution at the moment is that we need these things to act like well-behaved URI's that can be used in RDF and other XML documents, so we've modified the local rules as follows: RA: ISO, NE: 2.16.840.1.113883, LocalName: 6.2 Stringifies as URI:ISO:2.16.840.1.113883.6.2# And ICD9-CM code 490.92 (Hypertensive heart and renal disease, unspecified, with renal failure) codes as URI:ISO:2.16.840.1.113883.6.2#490.92 And the Mime type of text/plain stringifies as URI:ISO:2.16.840.1.113883.6.10#text%2Fplain This doesn't do much to address the DNS branch. ------------------------------------------------------ Another issue that has recently been introduced in the medical domain is the notion of "sub name spaces". The CAP (keepers of SNOMED-CT) can issue local namespaces that allow organizations to augment the basic content. While these local spaces are disjoint from the SNOMED namespace, the content isn't part of the SNOMED-CT code system, yet it doesn't stand alone as well. No solutions here - just thought I'd throw it on the table... :-{ ------------------------------------------------------- Recently, the LSID has appeared on the horizon. While LSID is designed primarly to represent "a piece of data", but syntax of the LSID may work to resolve this issue: URN:LSID:::[:] LSID recommends, but doesn't mandate, that the authority identifier be a dns. The namespace id, object id and optional revision id are managed by the authority itself. One approach to the NamingAuthority to LSID might be: URN:LSID::: In this scenario, our friend IC9 would be: URN:LSID:ISO:2.16.840.1.113883:6.2 And hypertensive heart and renal disease: URN:LSID:ISO:2.16.840.1.113883.6.2:490.92 This approach doesn't do anything to address the naming authority / localname issues. Another, perhaps more useful approach would be: URN:LSID::: The Registration authority could be left out completely. Thus URI:LSID:org.hl7:2.16.840.1.113883.6.2:490.92 And URN:LSID:org.hl7:2.16.840.1.113883.6.10:text%2Fplain One would have to come up with a distinguished token to represent the code system itself. Elsewhere, we have used "@", but it would have to be escaped - thus ICD9 would be URN:LSID:org.hl7:2.16.840.1.113883.6.2:%00 There would still be some real advantages to be able to use the "#" delimiter between the code system and concept code, as it would allow automatic xml schema and other references. There is a real question, however, whether the semantics of the LSID are similar enough to justify this sort of mapping. In particular, how do the resulting service interfaces relate to LQS (or CTS) interfaces? Harold Solbrig > -----Original Message----- > From: Tim Brinson [mailto:tbrinson@2ab.com] > Sent: Friday, July 30, 2004 12:38 PM > To: David Forslund; Juergen Boldt; issues@omg.org; lqs-rtf@omg.org; > healthcare@omg.org; Stelios G. Sfakianakis; Harold Solbrig > Subject: Re: issue 7597 -- Lexicon Query Service RTF issue (RTF to bere- > chartered??) > > All, > > Dave, good to see you are still at LANL. Hope all is going well. > > I responded to Stelios, the guy submitting the issue (See attached). As > I > was responding to Stefios it took me a few iterations before I zeroed in > on > my final understanding of the issue. > > As one of the submitters on the LQS I don't recall meaning to break the > rules of the NamingAuthority. I think there may have already been an > issue > entered for this, a long time ago. I think we didn't have anyone > interested > in leading a RTF. > > When using the DNS registration authority, I think hierarchical coding > schemes were intended to be created via the dns rules. So the two coding > schemes Stefios pointed out should have been changed in the spec like > this: > > DNS:hl7.omg.org/I9C -> DNS:i9c.hl7.omg.org/ > DNS:usmarc.omg.org/041 -> DNS:041.usmarc.omg.org/ > > I worked on a project that had on the order of 100 coding schemes. There > was an extensive hierarchy to them. We used DNS as the registration > authority and we used the dns rules for the hierarchy. That is, we > followed > the NamingAuthority spec and we did not have any problems with it. > > However, in a particular environement one could define what ever rules > they > want to use for a stringified qualified code and provide their own parsing > for it. As Dave points implies, you could do it in a way where the rules > are consistent enough that you don't need to know the coding schemes in > the > translation library implementation. > > Tim > > > ----- Original Message ----- > From: "David Forslund" > To: "Juergen Boldt" ; ; rtf@omg.org>; > > Sent: Thursday, July 29, 2004 3:19 PM > Subject: Re: issue 7597 -- Lexicon Query Service RTF issue (RTF to > bere-chartered??) > > > > I think I agree in principle with the ambiguity pointed out by the author > of > this question. > The LQS specification seems to consider in practice the boundary between > the > CodingSchemeId > and the LocalName to be arbitrary rather than in accordance with the > NamingAuthority specification. > Perhaps this is intentional in the implementation of the specification. > I'm interested in > other interpretations particularly from those who have implemented LQS. > I'm > not sure it requires > knowing all CodingSchemes to implement it. It may be more akin to > understanding a hierarchical > coding scheme strategy, which is actually pretty reasonable. > > Dave > > > ------------Original Message------------ > > From: Juergen Boldt > > To: issues@omg.org, lqs-rtf@omg.org, healthcare@omg.org > > Date: Wed, Jul-28-2004 1:13 PM > > Subject: issue 7597 -- Lexicon Query Service RTF issue (RTF to be > re-chartered??) > > > > I'll put the issue out there. The last RTF expired in 1999, the spec > > appears to be in use...so.... > > > > > > This is issue # 7597 > > > > LQS: parsing of QualifiedNameStrs > > > > According to the LQS specification (00-06-31), paragraph 2.1.4, the > > delimiter between a NamingEntity (NE) and a LocalName (LN) is the > > character '/', possibly excluding only the case of the 'OTHER' > > RegistrationAuthority. > > > > > > Reading this paragraph it is clear to me that in order to parse a > > QualifiedNameStr that starts with "DNS", "ISO", "DCE" (so that it's > > not 'IDL' or 'OTHER'), the *first* '/' is the delimiter between a NE > > and a LN, which also means that, in these cases, a '/' is not > > permitted inside a NE. If a QualifiedNameStr starts with "IDL" then > > the delimiter is the *last* occurence of '/'. > > > > > > The problem is that subsequent paragraphs in the specification (and > > also coding schemes and codes defined in the idls of LQS) DO NOT use > > these rules. For example the ICD-9-CM coding scheme should be > > represented as "DNS:hl7.omg.org/I9C" according to par. 3.5, which > > clearly is illegal because it uses the slash character inside the NE > > (which is the "hl7.omg.org/I9C"). There are numerous such cases > > throughout the spec. > > > > > > It is clear that if this kind of QualifiedNameStrs is acceptable then > > it is not feasible to have a "generic" implementation of the > > translation_library's str_to_qualified_code method: If I have a PIDS > > that supports a trait to represent the patient's spoken language and > > as a value I get the string "DNS:usmarc.omg.org/041/ENG" (par. 3.6) > > then according to 2.1.4 I should search LQS for the coding scheme > > "DNS:usmarc.omg.org" but I would probably find nothing because the > > ''correct'' coding scheme is "DNS:usmarc.omg.org/041" (par. 3.5). Thus > > I should be aware that when I see such codes, the coding scheme is the > > "DNS:usmarc.omg.org/041" and the rest is the concept code. But this > > forces me, as implementer of the translation library, to know all the > > possible coding schemes in order to parse them correctly. > > > > > > So my questions are: > > > > > > - Are the remarks mentioned above correct and well known? > > > > > > - If yes how the OMG is going to tackle this issue? > > > > > > - If the OMG considers it too costly to change all the examples in > > the spec. and the stringified coding schemes in the idls, what is > > the proposed way to implement the translation_library interface? > > (One solution might be to have the LQS expose a > > translation_library > > interface through the TerminologyService interface and let the LQS > > server do the "correct" transformation ...) > > > > > > [BTW, the paragraph 1.5.2.4 does not agree with 2.1.4: Firstly, it > > refers to "UniqueName" and "UniqueNameStr" which are unknown and it > > possibly means QualifiedName and QualifiedNameStr > > respectively. Secondly, it says that the character ':' should be the > > delimiter between NE and LN (!!).] > > > > > > > > > > > > ================================= > > Jürgen Boldt > > Director, Member Services > > > > Object Management Group > > 250 First Avenue, Suite 100 > > Needham, MA 02494 > > > > Tel. +1 781 444 0404 ext. 132 > > Fax: +1 781 444 0320 > > email: juergen@omg.org > > www www.omg.org > > > > ================================ > > PGP Key ID: 0x5F30AAC2 | FORTH, http://www.forth.gr