Thank you, Chunlan. Your examples are clear. There are basically three choices for persistence types, as you and others have pointed out, XML, OODBMS, RDBMS, and XML. What is proving to be the most popular, most preferred, by the openEHR community? I am trying to find out, for instance, which of these three types Ocean adopted.
Also, one more thing: could you give me an example (web URL) of your biggest, baddest, nastiest archetype, or set of nested archetypes, that a system would should be capable of accommodating? Randolph On 11/6/07, Chunlan Ma <chunlan.ma at oceaninformatics.com> wrote: > > I am not sure I sent this email successfully or not. If you have got one, > please ignore this. > > > > Hi Randolph, > > > > What data query language you want to use for the underlying data model is > depend on what data store structure you want to use. If you want to use > relational db, then you need to derive sql queries from AQL. If you want to > use XML, you may need to generate XQuery statements or Xpath based on the > AQL to be able to get the appropriate data. Currently, SQL2005 also provides > the SQLXML features which is even handy to retrieve data from relational > table fields as well as XML blobs. > > > > Path-value persistence data model mentioned by Tom is one of the option > for openEHR based data instances. Relational data model with xml blobs is > another option as well. Object oriented persistence layer is another option. > It is absolutely vendors design decision on what sort of persistence layer > they prefer. > > > > You just asked What does it take for a DB schema to be conformant? > > > > In my understanding it is that the DB schema can be used to search and > retrieve the data that is required by the AQL. > > > > Let's use the AQL statement that I did for Greg: > > SELECT o > FROM EHR e[ehr_id/value='1234'] CONTAINS COMPOSITION CONTAINS OBSERVATION > o[openEHR-EHR-OBSERVATION.respiration.v1.adl] > WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnitude>n > > > > Imagine you are using a SQL server and you need to use sql query statement > to query your database. In the database, you have a table called EHR and you > have an id field which matches with the ehr_id/value. > > > > The AQL FROM clause requires all data must be from the EHR with id='1234', > so in your sql statements, there must be a criteria somewhere EHR.id= > '1234' > > > > The AQL statement (in the SELECT clause) also requires all respiration > observation instances, which have respiration rate is greater than n, been > returned. You have to somehow generate one or a set of sql queries to get > the qualified observation data. > > > > If your DB schema can support all these, then I see it is conformant. > > > > Regards, > > Chunlan > > > > > > *From:* openehr-technical-bounces at openehr.org [mailto: > openehr-technical-bounces at openehr.org] *On Behalf Of *Randolph Neall > *Sent:* Tuesday, November 06, 2007 2:03 PM > *To:* For openEHR technical discussions > *Subject:* Re: OpenEHR queries > > > > Thanks. Of course, as you say, the Sql parser will vary depending on the > structure of the underlying store, and underlying store designs can vary, > one of the strengths of openEHR. It would still seem, however, that whole > chunks of the AQL would have to end up in the Sql, and that, in turn, would > have implications--at least *some* implications--how the underlying > store would *have* to be designed. Only certain schemas would even work > with openEHR. Does the openEHR community offer any suggestions? At Ocean you > evidently felt that a certain design was best, not just any design, which > you imply when you refer to the need to be "conformant." What does it take > for a DB schema to be conformant? > > > > >The persistence model that Ocean uses is a trade off between completely > atomising objects and storing them as blobs. > > > > Have you disclosed any of the details regarding this tradeoff? > > > > > > Randolph > > > > > > On 11/5/07, *Hugh Leslie* <hugh.leslie at oceaninformatics.com > wrote: > > Hi Randolph, > > Currently, the only AQL query parser that I know of is one that is part of > the Ocean Informatics suite of products and runs against the Ocean EhrBank > openEHR repository. > > Converting AQL to SQL will depend entirely on what your underlying > persistence model is and also to some extent what relational database > flavour you are using. openEHR doesn't mandate any particular persistence > model and as has been already stated, the really nice thing about AQL is > that queries are independent of any underlying relational (or object) data > model. So an AQL query that is run against two separate and completely > independently developed openEHR repositories that probably use a completely > separate persistence model should return exactly the same data (as long as > they are both conformant). > > The persistence model that Ocean uses is a trade off between completely > atomising objects and storing them as blobs. This has been a process of > optimisation and we are really happy with the current performance of the > system. This is only one of many possible methods of openEHR persistence. > > regards Hugh > > Randolph Neall wrote: > > I think I understand. Thanks. What actually gets persisted, I suspect, are > the paths--and values pointed to by those paths--implicit in your archetype > object graph, correct? And to convert AQL query into an SQL query you > somehow extract that path from AQL and convert it into some sort of SQL, > right? Is there anything on your web site about this, about deriving a DB > query from an archtype query? > > > > >You can have whatever persistence layer as long as it can get expected > results back based on the AQL statement. > > > > --That's the question. How do you "get expected results back based on the > AQL Statement? > > > > Thanks, > > > > Randy Neall > > > > > > > > > > On 11/5/07, *Chunlan Ma* <chunlan.ma at oceaninformatics.com > wrote: > > > > > > *From:* openehr-technical-bounces at openehr.org [mailto: > openehr-technical-bounces at openehr.org] *On Behalf Of *Randolph Neall > *Sent:* Tuesday, November 06, 2007 3:35 AM > *To:* For openEHR technical discussions > *Subject:* Re: OpenEHR queries > > > > As a developer from the US who sometimes tries to follow discussions here, > I have a question probably well answered if I took more time myself to find > the answer. Against what do your archetype queries run? Against the DB > itself or some representation of the data in memory? I ask because a few > months ago, someone from openEHR said in one of the discussions that a DB > schema is not part of openEHR, that some private participant in openEHR had > one for sale, and Ocean, maybe, but that was it. So, again against what do > these queries (see example in Chunlan Ma's message below) run? > > > > That's good question. You've noticed that I didn't mention anything about > the data store here. In general, query languages are designed specifically > for a type of data store. For instance, SQL is run against relational > databases. XQuery is run against XML structured data. Object Oriented Query > Language need to be run against Object oriented database management systems > etc. These types of query language are data query languages, i.e. they > query at the data level. You have to know DB schema when you write a SQL > query statement. > > > > Archetype Query Language is different from the general query languages. > It's a semantic query language, i.e. it queries data at semantic level. > It's neutral to persistence layer and system design. We only need to use > archetype path and openEHR reference model to construct AQL statement. You > can have whatever persistence layer as long as it can get expected results > back based on the AQL statement. That's why AQL queries can be shared > across systems and enterprise boundaries. Sharing AQL is one of the key > solution to achieve semantic interoperability. > > > > Cheers, > > Chunlan > > > > > > Thanks, > > > > Randy Neall > > Veriqant, L.L.C. > > > > > > On 11/4/07, *Chunlan Ma* <chunlan.ma at oceaninformatics.com> wrote: > > Hi Greg, > > Rong has indicated there is a paper about archetype query language. Thanks > Rong. That paper introduced basic query syntax. It was written at the > beginning of this year. The query syntax has been enriched recently in > order > to support more complicated queries. I've already started to write the > specifications, but need to resolve some known issues before release. > > Anyway, I handcrafted the following queries for you (I cannot build my > query > builder at the moment because of some integration issues). > > The query statement below shows that all observation instances with > respiratory rate greater than n will be returned. > > SELECT o > FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION > o[openEHR-EHR-OBSERVATION.respiration.v1.adl] > WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnitude>n > AND > o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' > > If you want the respiratory quantity object been returned, the query would > look like: > > SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value > FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION > o[openEHR-EHR-OBSERVATION.respiration.v1.adl] > WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnitude>n > AND > o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' > > Just for your information, the single letter 'o' is the observation class > variable name, "/data/events[at0002]/data[at0003]/items[at0004]/value" is > the archetype path to respiratory quantity node. If you have the archetype > > workbench running, you can identify this path there. '$ehrId' is the > parameter name which can be substituted with real EHR ehr_id value at run > time. The query language supports parameterization. > > Some archetype query statements would be very long if the query criteria > are > complicated. In fact, we don't need to write the above queries by hand. > Ocean Informatics has implemented a tool - Archetype Query Builder, which > can be used to create/edit queries easily. Additionally, Ocean has also > implemented a query parser and query engine as well. > > The above query statements are consistent to the query syntax introduced > by > the MedInfo paper. The current query tools also support this query syntax. > However, as I have said that we have enriched the query syntax and all the > enhancements can be found from the query specifications. > > Hope this helps. > > Regards, > Chunlan > > -----Original Message----- > From: openehr-technical-bounces at openehr.org > [mailto: openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton > Sent: Monday, November 05, 2007 6:48 AM > To: openEHR-technical at openehr.org > Subject: OpenEHR queries > > Hi, > > Somewhere I recall reading that there was an OpenEHR query that > theoretically an OpenEHR compliant system could execute a return > results for. > > Is there a spec somewhere, preferably with a simple example. > > So if someone knew my patient and queried for all instances of > Respiratory Rate greater than n? > > openEHR-EHR-OBSERVATION.respiration.v1.adl > > Rate at0004 > n > Units /min (is that a default or are the units passed in the query) > > Or is this future functionality? > > thanks > > Greg > > http://www.patientos.org > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > ------------------------------ > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > > > __________ NOD32 2639 (20071105) Information __________ > > > > This message was checked by NOD32 antivirus system. > > http://www.eset.com > > > > > > -- > > ________________________________________________ > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > Clinical Director > Ocean Informatics Pty Ltd > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: > www.oceaninformatics.com > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071106/45b9fa84/attachment.html>
