New ADL/AOM proposals to solve some old problems

On 29/04/2013 09:01, Mikael Nystr?m wrote: > > Hi Tom, > > Is the intention that the new data type TERMINOLOGY_CODE also can > contain a post-coordinated code so it, for example, can contain a > expression in SNOMED CT compositional grammar? (See > www.snomed.org/tig?t=rfg_expression_scg >

New ADL/AOM proposals to solve some old problems

: New ADL/AOM proposals to solve some old problems On 29/04/2013 09:01, Mikael Nystr?m wrote: Hi Tom, Is the intention that the new data type TERMINOLOGY_CODE also can contain a post-coordinated code so it, for example, can contain a expression in SNOMED CT compositional grammar? (See

New ADL/AOM proposals to solve some old problems

DL/AOM proposals to solve some old problems In openEHR we use custom syntax in archetypes to express ordinal constraints, quantity constraints and coded text constraints - i..e constraints on what are probably the most ubiquitous data types in health. I have been mulling over feedback from pr

New ADL/AOM proposals to solve some old problems

2013/4/25 Thomas Beale : > On 25/04/2013 18:44, Diego Bosc? wrote: >> >> 2013/4/25 Thomas Beale : >> >>> Consider these dichotomies: >>> >>> OWL (readable) v RDF (hideous) >>> JSON (simplistic, but readable) v XML (hard to read, tricky inheritance >>> model, tricky containment semantics, ...) >>> R

New ADL/AOM proposals to solve some old problems

2013/4/25 Thomas Beale : > On 25/04/2013 18:52, Diego Bosc? wrote: >> >> You can generate operations to deal with domain types, but then AQL >> would be openEHR specific (you can call it OQL then). What I say is > > > Diego, > > there is nothing openEHR-specific today in AQL, and allowing more comp

New ADL/AOM proposals to solve some old problems

On 25/04/2013 18:44, Diego Bosc? wrote: > 2013/4/25 Thomas Beale : >> Consider these dichotomies: >> >> OWL (readable) v RDF (hideous) >> JSON (simplistic, but readable) v XML (hard to read, tricky inheritance >> model, tricky containment semantics, ...) >> Ruby / Python (readable, according the yo

New ADL/AOM proposals to solve some old problems

You can generate operations to deal with domain types, but then AQL would be openEHR specific (you can call it OQL then). What I say is that generating a path to specify a filter (and accessing it) is direct when the domain type has been expanded, and not so easy if you take it as it is. If you get

New ADL/AOM proposals to solve some old problems

2013/4/25 Thomas Beale : > On 25/04/2013 11:47, Diego Bosc? wrote: > > As you know, I'm not a big fan of domain types, so take my comments > with a grain of salt ;) > I understand that back in the day when archetypes were hand crafted > domain types could serve a purpose. But in my opinion ADL shou

New ADL/AOM proposals to solve some old problems

On 25/04/2013 18:52, Diego Bosc? wrote: > You can generate operations to deal with domain types, but then AQL > would be openEHR specific (you can call it OQL then). What I say is Diego, there is nothing openEHR-specific today in AQL, and allowing more complex primitive types like dates or codes

New ADL/AOM proposals to solve some old problems

On 25/04/2013 12:21, Diego Bosc? wrote: > PPPS: How you define an AQL filter over a domain type? > > How do you define an AQL filter over a date time? Well, ok, it's not quite as simple as that. With a coded term type (in particular) you want operators like 'in set', 'in subsumption', and 'in su

New ADL/AOM proposals to solve some old problems

On 25/04/2013 11:47, Diego Bosc? wrote: > As you know, I'm not a big fan of domain types, so take my comments > with a grain of salt ;) > I understand that back in the day when archetypes were hand crafted > domain types could serve a purpose. But in my opinion ADL should not > be written by hand n

New ADL/AOM proposals to solve some old problems

PPPS: How you define an AQL filter over a domain type? 2013/4/25 Diego Bosc? : > As you know, I'm not a big fan of domain types, so take my comments > with a grain of salt ;) > I understand that back in the day when archetypes were hand crafted > domain types could serve a purpose. But in my opini

New ADL/AOM proposals to solve some old problems

As you know, I'm not a big fan of domain types, so take my comments with a grain of salt ;) I understand that back in the day when archetypes were hand crafted domain types could serve a purpose. But in my opinion ADL should not be written by hand nowadays. Tools should be the ones that 'hide' the

New ADL/AOM proposals to solve some old problems

Very interesting thoughts Tom! My initial impression of the proposal is very positive. If I understand things correctly this will enable shorter and more readable serializations not only in ADL but also in other formalisms. If we consider ADL being a DSL

New ADL/AOM proposals to solve some old problems

On 25/04/2013 10:20, Erik Sundvall wrote: > Very interesting thoughts Tom! > > My initial impression of the proposal is very positive. If I > understand things correctly this will enable shorter and more > readable serializations not only in ADL but also in other formalisms. > > If we consider AD

New ADL/AOM proposals to solve some old problems

In openEHR we use custom syntax in archetypes to express ordinal constraints, quantity constraints and coded text constraints - i..e constraints on what are probably the most ubiquitous data types in health. I have been mulling over feedback from previous debates here and in CIMI about the 'un