Hi Tom, On Thu, Mar 1, 2018 at 2:33 PM, Thomas Beale <[email protected]> wrote:
> > On 01/03/2018 11:05, Seref Arikan wrote: > >> Hi Diego, >> >> I'd like to hear how you'd address the requirement via a call to an >> external service. >> >> > I don't think it should be that complicated - after all, a call out to a > terminology service is already a call out to a service; terminology is just > one kind of reference knowledge that a query language / engine needs to get > at; we can assume that a units service (as Bert and others were discussing > earlier), lab results reference ranges, drug DB and so on may all be needed > by the query service. > In case I gave the wrong impression: my question above was not meant to sound like I thought this would be a difficult thing. Reading it again, I can see that it may be interpreted as 'I'd like to see you try', which was not the intention. I genuinely wanted to know how Diego would like to use AQL to address this specific requirement. > > So I think it mainly comes down to the syntax and programming model of > talking out to such interfaces. We might potentially assume that they are > all based on a common ontology meta-model of some kind (e.g. based on BFO, > RO, IAO etc) in which case a common underlying style could be established. The way I see it, your suggestion may pave the way to the can of worms I mentioned earlier, so I'll give up on my efforts to not to hijack this thread :) Re extending AQL for calls to external services: I'd be inclined to keep the syntax in the scope of the AQL specification and leave the programming model out of scope. I think AQL needs to support procedural extensions as an umbrella concept, which, then, can be used for a number of things, some of which may be calls to external knowledge services. There is a lot more than calling out to external terminology services that can be accomplished with procedural extensions: they could turn AQL into the ultimate clinical data query language, which is the upside. But there is a downside as well: things may get complicated from a standardisation point of view. Once calls to external services become part of syntax, AQL's vendor/implementation independent nature will be harder to preserve, as vendors start doing useful and no doubt clever things with calls to external services. Aql's behaviour is already slightly different across vendors, so if vendor X implements a smart feature using an external service and that service is available only in my vendor X's implementation, behaviour interoperability provided by AQL would be damaged. I think the upsides are worth adding this support but downsides will need careful management, probably based on profiles/levels etc. > > > - thomas > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_ > lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
