Hi Georg, Please see comments inline On Thu, Feb 15, 2018 at 9:43 AM, Georg Fette <[email protected]> wrote:
> Hello, > I have some questions on the explicit definition on how the result rows > are returned in the query API: > 1. In the example at https://www.openehr.org/releas > es/ITS/Release-0.9.0/docs/query.html#header-resultset-example there is > one result row with one fact for each of the columns that were requested. > Three of the columns contain primitves (i.e. Strings) but one column > contains a JSON representation of an object. It is difficult to grasp from > the example why some facts are returned as primitves and some as serialized > JSON objects. It would be beneficial to see the corresponding archetype > definitions in order to understand how different columns containing > different parts of the archetypes are encoded. > the columns contain data instances that are found at the given path. If the data (item) instance has type String, then its serialisation is just a simple string. If you provide a path to an Object (such as the name with type DV_TEXT) then its serialisation has to represent the object and this is why you'd get a json payload for that column. Are you suggesting that this explanation is included in the documentation? 2. When one of the columns contains a list of items in each cell (because > the denoted data type is an ITEM_LIST), will the content of that cell be > JSON serialized ? When a user requests all laboratory values (e.g. calcium > measurements) for a specific patient, then a table would be returned. But > instead of receiving the individual measurements in seperate columns so the > result could be immediately processed in tools like Excel or SPSS, the data > would have to be again crunched by another tool that makes a real table out > of the table-JSON-compound. > This is a sensible expectation and something that gets everyone when they are first introduced to AQL. AQL is doing what it should do here, *if you assume that it has a particular semantics to express query patterns. *Unfortunately, that particular semantics is not officially described in the specifications but is inferred via common sense. I drop by and make this point every couple of months when questions similar to yours arise :) I'll stop here for reasons to be revealed a few lines below. Read on please ... > 2b. What happens when multiple columns can contain multiple values as > their values. When every column containing multiple values (ITEM_LISTs) > will be encoded with JSON and written to the same cell this will not be an > issue. But when the multiple values are instead distributed over multiple > cells (or rows) some mechanism has to be defined how to cope with the > combination of two columns containing multiple values for one record. In > SQL-JOINs this is handled with the Cartesian product of the sets of facts. > But this bears the risk of combinatorial explosions when defining queries > with too many columns containing too many values for each record. > Yep, you got it. I don't think you'd get json serialisations of ITEM_LISTs, because implementations usually omit LIST types as standalone instances and expand their children as a group of items sitting under the LIST's parent. I'm happy to be corrected if my memory is failing me here. It is not only LISTs that give you this behaviour, if you have a CLUSTER with multiple ELEMENTs under it, and if you use a SELECT path in AQL that points at the cluster, then you *may* end up with the cartesian product, which is the *right result.* About 10 months ago, this question came from Bjorn in a slightly different worded way and I tried to clarify it. Unfortunately, my responses, which included images (or even the ones that did not) are not visible in the mail archives. So I copied the contents of the thread here: https://serefarikan.com/2018/02/15/a-rough-and-inaccurate-guide-to-archetype-query-language-semantics/ I created a git repo with examples and I think Bjorn has one that he created when he asked his question. If you look at my responses, you can see why AQL implementations are behaving in the way they're doing. The formalism I'm using to explain things is my view of AQL but as the git repo I created shows, both SPARQL and XQUERY queries that express the same semantics deliver the same results. I'd suggest you read that discussion (sorry for the bad formatting of some contents, wordpress is a nightmare when formatting code) *Can we have a more convenient result set structure then what we have now?* => This is an entirely different discussion and quite a deep one too. But I think clearly explaining and clarifying the result set we have now is a key task at the moment. > Greetings > Georg > > -- > --------------------------------------------------------------------- > Dipl.-Inf. Georg Fette Raum: B001 > Universität Würzburg Tel.: +49-(0)931-31-85516 > Am Hubland Fax.: +49-(0)931-31-86732 > 97074 Würzburg mail: [email protected] > --------------------------------------------------------------------- > > > _______________________________________________ > 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
