Op 11-9-2016 om 19:44 schreef pablo pazos:
IMHO the clearness of the query should not depend on the AQL code, but
the metadata associated with the query, like the ADL header and
ontology, the AQL would be the "definition" of the query. To share
queries between systems the AQL is not enough. We need a declaration
of intent, purpose, use, misuse, etc and description of the query in
natural language.
Formalization of AQL is also a good idea, but I am sure, AQL, like other
query languages, will occur ad-hoc in code. It takes specialists to code
and understand them, that has always been like that. But documentation
is good, especially if documentation is formalized and up to date, or
else, the documentation can have separate life of what it documents,
this is, the code moves away from the documentation.
Uncle Bob (Robert C. Martin) I listened a lot to him in the past (but he
started repeating himself last years) was the one who put my attention
to this problem. His answer was: Don't document. Write code so, that it
does not need documentation.
|// Dear maintainer: // // Once you are done trying to 'optimize' this
routine, // and have realized what a terrible mistake that was, //
please increment the following counter as a warning // to the next guy:
// // total_hours_wasted_here = 42|
See StackOverflow for more funny comments
http://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered
Also, to manage queries we need something like the CKM and an editor.
Good AQL should not rely only on clearness and readability, but on
specifying exactly what results we need.
I think both options are valid: SCT expressions and just codes in AQL,
but since I'm not an expert in SCT, I prefer someone else that knows
SCT defines the expressions and relationships in the terminology
server so I can create queries just using codes.
Sent from my LG Mobile
------ Original message------
*From: *Diego Boscá
*Date: *Sun, Sep 11, 2016 11:57
*To: *For openEHR technical discussions;
*Subject:*Re: SV: More generic reference model
I'm not a real fan of having just codes instead of expressions..
Expressions are far more readable and may help in the understanding of
the archetype. Just a single code representing the subset won't be as
clear.
El 11/9/2016 16:49, "pablo pazos" <[email protected]
<mailto:[email protected]>> escribió:
Hi Bert,
I was thinking about integrating SCT with path-based queries (I'm
not in AQL yet), but maintaining the complexity of the SCT
relationships and expressions on the terminology service (TS)
side, so on queries there are just simple codes (specific concept
ids, subsets or expressions identified just by one code). Then
when evaluating a query, with the TS we can get all the terms and
concept ids that match all the is_a relationships or subsets of
expressions. I talked with several TS providers and hopefully we
can build an integration next year to create and evaluate queries
with SCT.
What I'm saying is that I prefer to delegate the complexity of SCT
to the TS and create simpler queries in AQL or path-based queries,
but your idea is interesting. One problem though is that query
creators need to be experts in SCT.
What do you think?
Sent from my LG Mobile
------ Original message------
*From: *Bert Verhees
*Date: *Sat, Sep 10, 2016 13:14
*To: *For openEHR technical discussions;
*Subject:*Re: SV: More generic reference model
Hi Pablo, sorry I was bit slow with thinking through my plans. The
way I see it now, there is no change necessary in the reference
model to integrate the potential of SCT largely. Even you can keep
on using the semantic rich entry types like Observation, etc.
See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/
<http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/>
If you, however, limit yourself to the Generic entry type, which
even gives a better integration while keeping all OpenEhr
functinality alive.
http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/
<http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/>
I am interested in what you think about that.
Best regards
Bert Verhees
Op 10 sep. 2016 05:03 schreef "pablo pazos"
<[email protected] <mailto:[email protected]>>:
Hi all,
Regarding the genericity of the openEHR IM, from the
implementation point of view we have at least 3 models:
+ the implementation information model
+ the persistence information model
+ and the reference / canonic information model (the openEHR IM)
Others might have more than these 3 models on their openEHR
implementations.
I think some simplifications can still be done to the openEHR
IM without losing semantics, like removing ITEM_STRUCTURE and
using just CLUSTER/ELEMENT (we have a discussion about this on
the wiki started some years ago).
IMO we should not try to make the reference model simpler just
in sake of simplifying the implementation, since the other 2
models are for that. In my systems I have different
implementation models that are over simplified openEHR IM
implementations, and also very specific / optimized / generic
persistence information models compatible with the openEHR IM.
And I think the implementation / persistence models are the
ones we can simplify and adjust to our needs, but not the
reference model, since it's role is that: be the reference for
all implementations.
--
Kind regards,
Eng. Pablo Pazos Guti??rrez
http://cabolabs.com <http://cabolabs.com/es/home>
------------------------------------------------------------------------
*From:* openEHR-technical
<[email protected]
<mailto:[email protected]>> on
behalf of Mikael Nyström <[email protected]
<mailto:[email protected]>>
*Sent:* Friday, September 9, 2016 4:15:53 AM
*To:* For openEHR technical discussions
*Subject:* SV: SV: More generic reference model
Hi,
A related activity that might be useful to know is the “RFP
for LOINC - SNOMED CT Cooperation
Project”.http://www.ihtsdo..org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project
<http://www.ihtsdo.org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project>
.
Regards
Mikael
*Från:*openEHR-technical
[mailto:[email protected]
<mailto:[email protected]>]*För*Bert
Verhees
*Skickat:* den 9 september 2016 08:42
*Till:* [email protected]
<mailto:[email protected]>
*Ämne:* Re: SV: More generic reference model
Op 9-9-2016 om 8:37 schreef Bjørn Næss:
But in addition to that we need to map terms from
different other terminologies like SNOMED-CT, LOINC and
also Disease Ontologies.
There is a mapping effort by IHTSDO en Regenstrief, they
started that a few years ago, and it will be finished, next
year, I think.
http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc
<http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc>
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
<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
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
