Hi Georg, Please see comments inline On Fri, Feb 16, 2018 at 5:21 PM, Georg Fette <[email protected]> wrote:
> Hi Seref, > Quite some discussion you already had on this topic last year. The > examples are a bit hard to grasp because of their complexity in size. > Although they are not really that extremely complex but perhaps the > problems should be discussed with the least complex examples as possible. > I'd strongly suggest that you take an Xquery example from the repository I created and simplify the query I've written. Focus on a small section of the example data. Then extend the scope. I admit there is a learning curve but both XQuery and Sparql examples would help you get the logic of AQL query execution to a sufficient extend since they are mostly aligned with AQL, at least in the context of examples in that repo > > I would think it more understandable if it were explicitely described in > the API documentation that all result data is generally encoded in JSON > (with a link/reference to the corresponding reference model page). But that > wouldn't be sufficient. The description of the encoding concerns not only > how a single element is encoded but even more how collections are encoded. > Those collections are not ITEM_LISTs or any other part of the reference > model of openEHR because they are formed at the moment the query is > executed. When in the example from the API the "uid"-member of "c" is > assumed to be of the type ITEM_LIST (or any other collection type) and the > member "value" of "uid" were a primitive, the requested column > "c/uid/value" represents a collections although the "value"s themselves are > primitves. This can't be handled with a generic object-serialization > mechanism. The only object containing all desired "value"s is the parent > "c" object. This could be generically serialized, but it isn't requested in > the query. So there has to be an iteration over all "value"s,which can > themselves be serialized, but all their resulting JSON-Strings would have > to be concatenated (externally from the serializing mechanisms) and written > to the same result cell. Or, when no concatenation is desired, some > solution with something like a Cartesian product would be needed. > Please correct me if I'm wrong but it sounds like you're speculating above as to how AQL execution works. I'd say you mostly have it right but allow me to clarify it a bit: there are not collections that are created during query execution; you should not think about a single variable unless the aql SELECT clause includes only one variable. The SELECT clause identifies a number of elements from an object structure (assume that this is a COMPOSITION instance). If any of the identified elements of SELECT a,b,c match more than one data item in the composition instance then the result set has to include all combinations of matches. Assume that the composition has a1,b1,c1 AND c2. In this case, the SELECT clause is describing a pattern like this <a>,<b>,<c> and we have a1,b1 and c1 and c2 which we can use define matches for this pattern. So our result set would be: a1,b1,c1 a1,b1,c2 Which is the latter case you're describing. It would not be a1,b1,[c1,c2] where c1 and c2 are concatenated because *each row of the result set has to express a match for the SELECT clause contents*. If you concatenate c1 and c2 and return one row as the result set your result set would no longer correctly represent a match for the structural and value constraints expressed by the AQL query. Let me give you an example. Imagine you want to get a list of allergies for patients using AQL *For each patient there is only one instance of a COMPOSITION based on an archetype and all allergies are added to this single instance*. So if you want to select the composition uid and the allergy name data items you'd use a SELECT statement like SELECT c/uid/value, alg/value . In this select clause, alg is some ELEMENT with DV_TEXT value. Your result set would then be something like: uid| allergy_value| 1 | nut allergy| 1 | penicillin | 2 | shellfish | In the result set above, the composition with uid 1 belongs to patient A and she/he has nut allergy and penicillin allergy. Patient B is allergic to shellfish and her/his composition instance gives us this information. Can you concatenate the allergy_value column values above? No! because then you'd lose the relationshp between uid and allergy-value, or in more pragmatic terms, you'd have no clue who has which allergy. This is annoying, but necessary because it preserves query semantics and data integrity for result sets. So it is the application developer's task to take that result set and process it so that the fact that nut allergy and penicillin are under the same composition is somehow used. *Most users of AQL are actually (implicitly) asking for a feature that allows them to retrieve the above result set as follows:* uid| allergy_value| 1 | nut allergy, penicillin| 2 | shellfish | Currently this is only possible if you select the first common parent of allergy_value data item and this is what you're describing when you talk about c being the parent. Unfortunately, current AQL semantics would mean that all of the parent object would be serialised, so you'd then have to dig into that object just to get nut allergy and penicillin values. In summary, AQL semantics does not support defining a result set like above at the moment. Our AQL implementation follows the logic I explained above and I'm pretty sure Marand and Dips implementations do the same and so does the XQuery and Sparql examples I've given. I hope this clarifies things a bit. Let me know if it makes sense or not. Ps: Your points re selecting a LIST_ITEM node are very interesting, I intentionally did not touch that above :) Once the above makes sense, that point deserves a dedicated question. > How do the commercial implementations of AQL like the software from Marand > handle this stuff ? > > Greetings > Georg > > -- > --------------------------------------------------------------------- > Dipl.-Inf. Georg Fette Raum: B009 > > 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
