Mentioned that in general, don't see the point of arguing about readability of things that are meant to be generated and processed by machines. not read or processed by a person.
If modeling tools work as expected, no clinical modeler or terminologist should deal with "source code". But I get that we don't live in a perfect world and tools are not ideal, that is why I think is better to focus on improving tools than have an ideal syntax. On Tue, May 16, 2017 at 11:44 AM, Thomas Beale <[email protected]> wrote: > Hi Pablo, > > if you were talking XML or other such unreadable stuff I agree. But the > whole point of context free grammars like programming languages, ADL, OWL, > and also these SNOMED mini-languages is to be formal and human readable. It > is via languages that humans learn the semantics of the formalism in a > native way. The problem with GUIs is that everyone's is different, whereas > everyone knows what this means (using standard logic as an example): > > ∃p:P | F(p) = blue > > I think that the SNOMED compositional and constraint grammars have a very > readable and concise native syntax, and the fact is that people edit > archetypes and related artefacts all the time, so we need to be able to see > this kind of syntax in plain text. > > I now think that putting these expressions into URIs is not the way to go. > We could probably handle the constraint in a separate ODIN attribute, in > the way that Bert is probably thinking about. I'll try to work on a design > for this as soon as possible, but others are always welcome to come up with > something. > > - thomas > > On 16/05/2017 11:06, Pablo Pazos wrote: > > 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. >>> >> > > _______________________________________________ > 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
