Heath, thanks much! I'd very much like to see the t_persistence_notes.htm, but that one cannot be reached at the moment. I hope to find it soon. I asked Chunlan for an example of your baddest archetype, one that involves some hierarchy and that would challenge a persistence layer. If one comes to mind, let me know.
Thanks again, Randolph On 11/6/07, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > > Randolph, > > As openEHR has no specification for a persistence model, there is no such > thing as a conformant DB schema. At Ocean we have developed a DB schema > that is still evolving but this is transparent to any application as the API > is based on the openEHR Information Model. We may explore alternate DB > schema's and even alternate data store technology, but again this will be > transparent to the application. > > > > The main article available on this topic was located at > http://www.openehr.org/FAQs/t_persistence_notes.htm but has not yet been > moved to the new web site. This is really just some suggestions about how a > persistence layer could be implemented, it is by no means a specification > for conformance. > > > > Regards > > > > Heath > > > > *From:* openehr-technical-bounces at openehr.org [mailto: > openehr-technical-bounces at openehr.org] *On Behalf Of *Randolph Neall > *Sent:* Tuesday, 6 November 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/965a00ea/attachment.html>
