Not sure why readability is a requirement here. Shouldn't those expressions be generated and consumed by systems?
We should create simple to use GUIs not simple to read code :) On Wed, May 3, 2017 at 9:31 AM, Diego Boscá <[email protected]> wrote: > Or just use the "Long syntax" as described in point 5.2 from Expression > Constraint Language, which keeps things readable enough > http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus| > > 2017-05-03 14:20 GMT+02:00 Thomas Beale <[email protected]>: > >> Daniel, >> >> my fault - didn't read the front page properly - the things we need are >> mooted for next release. But now I agree with Diego... >> >> The expression constraint "< 404684003 |Clinical finding|: < 47429007 >> <4742%209007> |Associated with| = < 79654002 |Edema|" >> >> - http >> <http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002> >> ://snomed.info/ecl/% >> <http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002> >> 3C404684003%3A%3C%3C47429007%3D%3C%3C79654002 >> <http://snomed.info/ecl/%3c404684003:%3c%3c47429007=%3c%3c79654002> >> >> >> that is seriously unreadable. In a different universe, we would have >> hoped for something like: >> >> http://snomed.info/ecl/<404684003:<47429007 <4742%209007>=<79654002 >> >> but of course that is illegal in URI syntax. >> >> In terms of what we put in archetype bindings, I start to wonder. Could >> it make sense to allow: >> >> - proper URIs for single terms, value set refs, module refs etc (all >> the URIs that only include a single SCT code) >> - post-coordinated expressions in their syntax form >> - constraint expressions in their syntax form >> >> where the latter two would be understood as standing for their equivalent >> URIs? That's an awful hack though. >> >> A more consistent argument would be to revert to not using URIs in >> bindings, and use just codes and expressions. >> >> The problem with doing that is that the ID concept URIs include useful >> things like /id, /module, /field, etc. >> >> If we just go with the kind of URIs like the above, archetype bindings >> will cease to be self-documenting. I am starting to think we need an >> expression syntax that covers all of: >> >> - single term references, including to SNOMED codes, modules, >> versions, .... >> - SNOMED post-coordinated expressions >> - SNOMED constraint expressions >> - and... the equivalent for non-SNOMED codes, e.g. LOINC, ICDx, ICF, >> etc etc >> >> We still don't have a universal terminology referencing mechanism, but >> it's what I think we need. It could in theory be achieved with the use of a >> new 'terminology' scheme space, thus: >> >> < 19829001 |Disorder of lung| <http://snomed.info/id/19829001> >> and < 301867009 |Edema of trunk| <http://snomed.info/id/301867009> >> >> becomes >> >> terminology:/snomed-ct/ecf/value="< 19829001 |Disorder of lung| >> <http://snomed.info/id/19829001> and < 301867009 |Edema of trunk|" >> <http://snomed.info/id/301867009> >> >> (I won't try to work out the nicest syntax, let's just say we agree that >> we could find one) >> >> This would allow URIs of the form >> >> terminology:/loinc/xyz/something-loinc-ish >> >> and so on. >> >> The sole purpose of a terminology scheme space might just be to establish >> a universal id space whose ids are readable, structured strings, that can >> be machine-converted to real URIs for SNOMED, but also LOINC, ICDx, HL7, >> and all the other terminologies. >> >> - thomas >> >> On 03/05/2017 12:09, Daniel Karlsson wrote: >> >> See this page: >> https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard >> Please consider the language used when posting. >> /Daniel >> >> On May 3, 2017 13:03, Bert Verhees <[email protected]> >> <[email protected]> wrote: >> >> On 03-05-17 12:53, Thomas Beale wrote: >> >> On 03/05/2017 11:40, Bert Verhees wrote: >> >> On 03-05-17 12:36, Thomas Beale wrote: >> >> The only missing part, now that I look at the SNOMED Compositional >> Grammar <https://confluence.ihtsdotools.org/display/DOCSCG> and Expression >> Constraint Language <https://confluence.ihtsdotools.org/display/DOCECL> >> specs, is how to create a URI (which is the type of a term binding in >> ADL2 >> <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>) >> from a post-coordinated expression or constraint expression. This should be >> trivial, but I don't see where SNOMED has specified it. >> >> >> True, I was looking for that also, a few days ago. I don't have time to >> read much now, but there is a document on the SNOMED site on URI's, maybe >> it is in there? >> I can take a look later or look in my documentation, I have course >> materials. I come back to this tomorrow if not someone else already has. >> >> >> The URI spec is here >> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard>, >> but it doesn't address URIs for expressions either. >> >> (All the SNOMED language specs appear to be here >> <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+Computable+Languages> >> these days - nice and convenient, and also nicely published. We probably >> should go back to linking to them somewhere on the openEHR site). >> >> >> I checked my course materials from last year, lucky I found it quickly, >> there is not any mentioning of URI's for expressions, so I guess it does >> not yet exist. >> >> Stupid. >> >> Bert >> >> >> >> >> _______________________________________________ >> openEHR-technical mailing >> [email protected]http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> -- >> Thomas Beale >> Principal, Ars Semantica <http://www.arssemantica.com> >> Consultant, ABD Team, Intermountain Healthcare >> <https://intermountainhealthcare.org/> >> Management Board, Specifications Program Lead, openEHR Foundation >> <http://www.openehr.org> >> Chartered IT Professional Fellow, BCS, British Computer Society >> <http://www.bcs.org/category/6044> >> Health IT blog <http://wolandscat.net/> | Culture blog >> <http://wolandsothercat.net/> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org >> > > > > -- > > [image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ> > > [image: Twitter] <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn] > <https://htmlsig.com/t/000001C4DPJG> [image: Maps] > <https://htmlsig.com/t/000001BZTWS7> > > Diego Boscá Tomás / Senior developer > [email protected] > [email protected] > > VeraTech for Health SL > +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023 > <+34%20627%2001%2050%2023> > www.veratech.es > > Su dirección de correo electrónico junto a sus datos personales forman > parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511) > cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley > Orgánica 15/1999, usted puede ejercitar sus derechos de acceso, > rectificación, cancelación y, en su caso oposición, enviando una solicitud > por escrito a [email protected]. > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com [email protected] Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
