This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Query Expression and Execution Technology"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) (New page: CATEGORY:RIMBAA Issue *Rik: I want to query in a RIM graph (memory or file) for pre-defined clinical criteria. Codes, values, ages, dates, AND, OR - the usual sort of things. *Ideally...) |
Rene spronk (talk | contribs) |
||
| Line 1: | Line 1: | ||
[[CATEGORY:RIMBAA Issue]] | [[CATEGORY:RIMBAA Issue]] | ||
| − | + | How does one query a RIM graph (memory or file) for pre-defined clinical criteria. Codes, values, ages, dates, AND, OR - the usual sort of things. There is a need for a query representation format, and then a tool to run those queries. | |
| − | |||
*Ideally it would be: | *Ideally it would be: | ||
| − | **Understandable by a non-developer or non-RIM expert | + | **Understandable by a non-developer or non-RIM expert. Some sort of query builder or parameter modifier may be needed that sits on top of one of the other query expression formats. |
**A standard of some sort | **A standard of some sort | ||
**Possible get it working quickly, days rather than weeks | **Possible get it working quickly, days rather than weeks | ||
| − | |||
| − | |||
| − | |||
| − | |||
==Options== | ==Options== | ||
===OCL=== | ===OCL=== | ||
| − | Grahame: | + | Grahame: OCL can be used directly. See |
| − | [http://www.hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm#rim_ocl] | + | [http://www.hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm#rim_ocl] for discussion. |
| − | for discussion | ||
| − | |||
| − | |||
| + | *Rik: Constraint and the selection part of a query seem to be allied but different to me - I know I already lumped these together in the question but now I'm trying to tease out the differences. I imagine a set of OCL constraints annotating a model, but they could be too fragmented to constitute a query. | ||
*Does anyone imagine firing off OCL queries and getting result sets/graphs back? | *Does anyone imagine firing off OCL queries and getting result sets/graphs back? | ||
**Grahame: yes, an invariant is only a query that must have type boolean and is required to evaluate to true. In our own use we define a different binding called "query" | **Grahame: yes, an invariant is only a query that must have type boolean and is required to evaluate to true. In our own use we define a different binding called "query" | ||
**so instead of ''context T inv: [expression which is of type boolean]'' it's ''context T query: [expression which returns OclAny]''. I have this working against CDA, but not in a general v3 context. | **so instead of ''context T inv: [expression which is of type boolean]'' it's ''context T query: [expression which returns OclAny]''. I have this working against CDA, but not in a general v3 context. | ||
| + | ===Gello=== | ||
| + | *Pros: on paper seems the ideal fit. A standard. Use cases shown recently on DSS list look similar to mine. | ||
| + | *Cons: hard to implement, no off the shelf tools I can integrate with my own code, not widely adopted. | ||
| − | + | Rik: Doesn’t add much over OCL, not that that is any easier, but we could just use that instead of the Gello subset. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Doesn’t add much over OCL, not that that is any easier, but we could just use that instead of the Gello subset. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
===XPath/XQuery=== | ===XPath/XQuery=== | ||
| + | *Pros: runs on anything, implemented already, if I serialize the data (or DOM it). | ||
| + | *Cons: Not RIM aware nor datatypes aware. Not ITS agnostic but that isn’t really an issue. | ||
| − | + | Rik: I see XQuery as a technology built mostly on XPath so would have some advantages if I was to | |
| − | + | make a lot of use of XPath but the same weaknesses (lack of model awareness, datatypes integration etc). Normally I tend to "query" using XSL and XPath so have not really looked into XQuery much. I expect it is a better way to do XPath-like queries properly. | |
| − | |||
| − | |||
| − | I see XQuery as a technology built mostly on XPath so would have some advantages if I was to | ||
| − | make a lot of use of XPath but the same weaknesses (lack of model awareness, datatypes integration etc). | ||
| − | |||
| − | Normally I tend to "query" using XSL and XPath so have not really looked into XQuery much. I expect it is a better way to do XPath-like queries properly. | ||
===HPath=== | ===HPath=== | ||
| − | + | *Pros: a better XPath for HL7, an implementation exists (JavaSIG). HPath is a better language (than XPath), since it shares the same intent but is properly tied to v3 semantics. | |
| − | Pros: a better XPath for HL7, an implementation exists (JavaSIG) | + | *Cons: not well documented, needs the JavaSIG code integrating, might be hard for a non-JavaSIG based project. The javasig implementation is not generally useable. No support for recent MIFs nor data types R2. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
===QBE=== | ===QBE=== | ||
| − | + | Query By example (QBE) - express queries as Acts etc with isCriterionInd set to true. | |
| − | + | *Pros: It’s HL7 | |
| − | Pros: It’s HL7 | + | *Cons: Complicated to express queries. No way to execute queries without writing your own engine. |
| − | |||
| − | Cons: Complicated to express | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Rene: Given the lack of constraint language tooling in SMD / Visio there is no way to predict what constraint language will prevail at some future point in time. My guess is that it'll be OCL. So right now the direction seems to be QBE + embedded OCL. | + | *NCI (Jean Duteau) are implementing QBE right now. |
| + | *Bob: Another I would throw into the consideration mix is HQMF [http://www.hl7.org/v3ballot/html/domains/uvqm/uvqm.htm], which makes heavy use of criteria (previously known as criterion mood). It kinda works like a Query By Example. One of the topics we're exploring with DSS in Cambridge is whether we should enable GELLO, ARDEN, etc in the <expression> field (e.g. where observation.value is data type EXPR_PQ). | ||
| + | *Rene: Given the lack of constraint language tooling in SMD / Visio there is no way to predict what constraint language will prevail at some future point in time. My guess is that it'll be OCL. So right now the direction seems to be QBE + embedded OCL. | ||
Revision as of 13:53, 4 October 2010
How does one query a RIM graph (memory or file) for pre-defined clinical criteria. Codes, values, ages, dates, AND, OR - the usual sort of things. There is a need for a query representation format, and then a tool to run those queries.
- Ideally it would be:
- Understandable by a non-developer or non-RIM expert. Some sort of query builder or parameter modifier may be needed that sits on top of one of the other query expression formats.
- A standard of some sort
- Possible get it working quickly, days rather than weeks
Options
OCL
Grahame: OCL can be used directly. See [1] for discussion.
- Rik: Constraint and the selection part of a query seem to be allied but different to me - I know I already lumped these together in the question but now I'm trying to tease out the differences. I imagine a set of OCL constraints annotating a model, but they could be too fragmented to constitute a query.
- Does anyone imagine firing off OCL queries and getting result sets/graphs back?
- Grahame: yes, an invariant is only a query that must have type boolean and is required to evaluate to true. In our own use we define a different binding called "query"
- so instead of context T inv: [expression which is of type boolean] it's context T query: [expression which returns OclAny]. I have this working against CDA, but not in a general v3 context.
Gello
- Pros: on paper seems the ideal fit. A standard. Use cases shown recently on DSS list look similar to mine.
- Cons: hard to implement, no off the shelf tools I can integrate with my own code, not widely adopted.
Rik: Doesn’t add much over OCL, not that that is any easier, but we could just use that instead of the Gello subset.
XPath/XQuery
- Pros: runs on anything, implemented already, if I serialize the data (or DOM it).
- Cons: Not RIM aware nor datatypes aware. Not ITS agnostic but that isn’t really an issue.
Rik: I see XQuery as a technology built mostly on XPath so would have some advantages if I was to make a lot of use of XPath but the same weaknesses (lack of model awareness, datatypes integration etc). Normally I tend to "query" using XSL and XPath so have not really looked into XQuery much. I expect it is a better way to do XPath-like queries properly.
HPath
- Pros: a better XPath for HL7, an implementation exists (JavaSIG). HPath is a better language (than XPath), since it shares the same intent but is properly tied to v3 semantics.
- Cons: not well documented, needs the JavaSIG code integrating, might be hard for a non-JavaSIG based project. The javasig implementation is not generally useable. No support for recent MIFs nor data types R2.
QBE
Query By example (QBE) - express queries as Acts etc with isCriterionInd set to true.
- Pros: It’s HL7
- Cons: Complicated to express queries. No way to execute queries without writing your own engine.
- NCI (Jean Duteau) are implementing QBE right now.
- Bob: Another I would throw into the consideration mix is HQMF [2], which makes heavy use of criteria (previously known as criterion mood). It kinda works like a Query By Example. One of the topics we're exploring with DSS in Cambridge is whether we should enable GELLO, ARDEN, etc in the <expression> field (e.g. where observation.value is data type EXPR_PQ).
- Rene: Given the lack of constraint language tooling in SMD / Visio there is no way to predict what constraint language will prevail at some future point in time. My guess is that it'll be OCL. So right now the direction seems to be QBE + embedded OCL.
