The discussion Pablo has makes me think it could be good to have in an AQL-engine an entry to have external query languages executed like SNOMED expressions which can treat result data as hierarchies of data and so add an extra functionality layer
Bert
Maybe it is possible to generalize it in a way that it could be external calls that return a value or list of values. Maybe this is enough for SNOMED, CDSS, but also for queries to linked data such as drug-drug interaction and other services availabe in bioportal, etc.
Hi Diego, I don’t know what bioportal is, and how you want to find drug-drug interactions. In the Netherlands we have a large and well maintained data-vendor for this purpose, called Z-index. But I found that SNOMED itself also has drug-drug interactions, and it can, maybe, also become a national extension to SNOMED, because drugs often differ from country to country. Maybe this can be decided later, and that first the focus will be on the SNOMED part. I was thinking in your suggested way too (I think), that a special value-list-layer is added inside the AQL query-engine, which can do some comparison at the moment the AQL engine creates a result-set (internal) What is important to decide is that the AQL is using a SNOMED resultset, and not the other way, so the AQL has the deep magic layer. So the magic will happen at a deep internal level the AQL part using the SNOMED part cannot be at AQL-API-level, because that would be the same as doing the queries separately, and that would be very costly. Although, for a start, this is possible. For SNOMED, I found there are API’s defined or being defined, so that would be the stable part. What is very important, but maybe that is already taken care of, we need a formal way to include a SNOMED expression into an AQL query. If we are able to separate a SNOMED part from the AQL part, and define how it interacts with the AQL part, then we can parse that SNOMED part in a microservice and hand over the result to the database-specific AQL engine maintainers/developers. Bert
https://bioportal.bioontology.org/
It has tons of knowledge exposed as queriable web services. All services have an RDF output, so is perfect to demonstrate linked data
I agree with all your points BTW 
Thanks, very interesting
That is exactly the idea of “features” that I mentioned on the other post.
But besides defining syntax (AQL and how to express features in AQL-like form), I mean the declarative format, what is more valuable is to define each feature functionality. So features can be implemented in AQL and non-AQL environments (some of us have path-based queries, not AQL syntax processing).
A generic feature can be expressed as a definition (semantics) and a result schema (I think most will be lists of some kind of codes or ids). The evaluation of the definition to get a result instance that matches with the result schema is a service client, and the service is where features are really interpreted.
If services are well defined (API to resolve SNOMED expressions, API to resolve archetype hierarchies, etc.) it would be easier to create clients for many technologies and standardize querying features between different implementations, and each system can publish it’s conformance statement with the supported features.
This generates a kind of plug-n-play architecture for queries.
And on a sci-fi future, making query services discoverable based on the supported features and kinds of information contained in the repos that can be queried (publishing supported OPTs).
Just thinking out loud! But I’m working towards this with Diego
Best,
Pablo.
Ah, I didn't know that. I must read the mailing-lists more often.
Good luck with that. I am very interested to hear about proceedings and plans
Bert
Here you can find info about the firs proof of concept of openEHR+SNOMED for querying, it worked better than expected and the integration was easier than expected