On 11/22/2013 08:07 PM, Thomas Beale wrote:
>
> I spent a bit of time trawling back through that last discussion on
> C_OBJECT.node_id (the property that carries at-codes) and whether it
> should be mandatory or optional, and also whether empty is valid.
>
> Currently it is mandatory, and can't be empty.
>
> We need to make the spec work for 2 distinct styles of modelling:
>
> * 13606 style - requires an at-code on every node, but only some
> have to be defined in the ontology section
> o in this case, the node codes really are like identifiers only,
> some of which happen to have a 'meaning' define for them
> o the result of this is the ability to do more mechanical
> processing of structures, since absolutely every node has an id.
> * openEHR / CIMI style - at-codes required according to rules needed
> to ensure uniqueness; if present, always defined in ontology
> section; they are optional on any other node;
> o in this case, the node codes (where they exist) really are
> codes, and are always defined as terms
> o the result of this, especially in larger archetypes is far
> fewer node ids (since very few at leaves), and shorter paths.
>
Let me split a bit this email, to not get confusing
------------------------------------------------------
Hi Thomas, as you probably know, by now, my kernel works with both
Reference Models, and has AOM as base-definition, every constraint a RM
puts above that is for the particular Reference Model. The AOM only
needs to support it, in fact it is the other way around:
A Reference Model which wants to work with ADL-archetypes, must be able
to fit in the AOM.
------------------------------------------------------
I have a question about the mandatory of the node_id. I can read it in
the specs, you are right, it is there.
It may sound stupid, but that is not how I ever understood this
requirement. Because C_PRIMITIVE_OBJECT is also derived from C_OBJECT,
and mostly I see them in OpenEHR-archetypes without node_id.
I checked a few examples and the ADL-parser accepts them with no
node_id, and returns null for nodeid if there is no nodeid.
In the AOM Java code I find following rule in CObject-constructor
if (nodeID != null && StringUtils.isEmpty(nodeID)) {
throw new IllegalArgumentException("empty nodeID");
}
In my feeling, this contradicts with the specs. Or am I wrong? Must be
something stupid I overlook.
Please put me on the right track!
------------------------------------------------------
> In theory, in both approaches the ontology section comes out about the
> same, since the LinkEHR-style ontology only contains at-codes with
> some 'interesting' or meaningful definition.
>
> I would think our goal would be that archetypes written by anyone
> should work in anyone else's tool. At the moment this probably isn't
> the case:
>
I think this is because of purpose.
The developers only have their specific purpose in mind, and do not want
to create an archetype-editor which serves purely the AOM-specs.
At this moment there are only two Reference Models, but it could well be
possible there are new to come.
Because the AOM concept is very powerful. It can have a life of its own,
for beyond the purpose of OpenEHR and 13606. Reference models should be,
as I said, just constraints on the AOM. And if they receive recognition
in major software-development, then that is a good thing, but it has
nothing to do with the AOM.
The AOM is (only) a modeling-environment, it must be as wide open as
possible. So, discussion must not target the internals of the AOM, but
the reference model.
------------------------------------------------------
> * the AE and ADL workbench would both complain about archetypes with
> at-codes with no definition in the ontology section
> * LinkEHR would complain about archetypes that had some nodes with
> no at-codes
>
> As Pablo Pazos said in that previous discussion, we should make this work.
>
Ah, Pablo said so too? Thanks Pablo!!! It is the first time in years
someone else except me brings this under attention. (as far as I know,
maybe I missed some)
I had this discussion a few times on this list, let's say, once every
two years, and it always brought up a mist of arguments, and in the end
nothing changed.
That was a bit tiresome, so I left it as it is and did my own thing, and
that was following the AOM as written by Rong.
Which now seems conflicting against the specs? (please enlighten me)
I think it is important, having good tooling is essentially for the
acceptance of a standard (AOM is part of an ISO standard, as I believe).
It is really a pity this fact is not well recognized.
The answer does not look to complicated. But maybe, again?, I am
overlooking complexities.
Talking about ArchetypeEditor GUI, make the in creation of an
C_PRIMITIVE_OBJECT the addition of a node_id optional. Create an
archetype-editor so, that it works conform the AOM. And make support of
the AP optionally.
Shouldn't be that hard. In fact, in my spare hours, I am working on one,
purely AOM-archetype-editor (but I do not have many spare-hours)
Bert
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131128/e0db78cd/attachment.html>
