On 02/05/2012 16:19, pablo pazos wrote: > Hi Thomas, > > This example is very helpful, thanks. > > About Diego's questions and your answers on other emails, as I > understand I have to "merge/resolve" the ontology section too, so all > needed codes are there without ambiguity. > Is the " component_ontologies" a constructor from ADL1.5?
that operation is pretty simple. For each specialised archetype, you flatten the terminology simply by adding the terms - technically you can just do a Hash table merge. In the Eiffel code of the flattener <http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/libraries/openehr/src/am/archetype/comparator/archetype_flattener.e>, search for 'flatten_ontology', you will see it is a single statement, which I imagine will be nearly the same in Java. When you do a template flatten, you have to construct the component_ontologies, which is a bit more work, but really it is just the addition of already flattened ontology sections into a container data structure. See the last routine in the above file and the routine 'add_component_ontology' here <http://www.openehr.org/svn/ref_impl_eiffel/BRANCHES/adl1.5/libraries/openehr/src/am/archetype/operational_template.e>. > > About the new nodeId codes with archetype ids, this should be > transparent to software applications or at some point do I have to > differentiate between normal at codes and archid codes? the software does need to know that it will encounter 'codes' in real data built from templates that will in fact be Archetype Ids. > E.g. I see descriptions for normal at codes in termDefinitions but for > those nodeIds with archetype id the codes are defined in > component_ontologies section. Maybe there are other cases where those > codes should be treated differently. It would be nicer to don't > interpret the internal structure of nodeID for implementation simplicity. actually, you can treat the archetype ids that you hit in the archetyped data simply as strings. It may seem strange at first, but in fact, it is just an efficient method of storing 'code name spaces' (the archetype ids and codes within each namespace. People sometimes ask: why aren't we using OIDs or GUIDs for this? I originally thought we would. But apart from the fact that functionally they don't add any particular value (they are just strings as well), there are advantages with the current method: * at-codes are generally 4-10 byte strings (the vast majority are 6). Oids are variable (but usually long due to the leader part) and GUIDs are stored as a 36-byte string or a 16-byte integer. Let's say the median difference is 30 bytes if the GUID is stored in its most common String form. For an average archetype with 20 data points, this means 19 x 30 = 570 bytes extra if GUIDs are used. In a realistic COMPOSITION with average 3 archetypes, this is 1,710 extra bytes. This could easily be a significant proportion of the total COMPOSITION size, which means it can affect the persistence provisioning requirement. On its own, possibly not such a big problem, but if no effort is made to keep data space-efficient, all the inefficiencies can change the final deployment costs and performance significantly. * at-codes have the structure where child codes ('child' in the IS-A subsumption sense) have the same code as the parent but with '.' sections appended, e.g. at0002.2.17, enabling very efficient query processing. GUIDs and OIDs don't have this property, so your query processor has to do extra work to figure out if a code is a) specialised and b) a child of some other code. * the path processing of the data is simplified, and also the paths themselves are relatively short. Paths with OIDs or GUIds would be far longer. That said, in the future it may be that the archetype_ids (not the at-codes) might be replace by archetype GUIds (or both might be used), for the purposes of some kinds of fast GUID-based indexing. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120502/7fcbe340/attachment.html>
