Archetype-editors

Implementers (archive)
21

2006/9/19, Bert Verhees <bert.verhees@rosa.nl>:

Mattias Forss schreef:

2006/9/18, Bert Verhees <bert.verhees@rosa.nl >:

Bert Verhees schreef:

Bert Verhees schreef:

It’s because it’s not a vaild openEHR data type, i.e. not a vaild
openEHR archetype. If u want to add support for other reference
model you can do that when the source is released.
I am sorry, but I don’t understand. I created these archetypes with the
java-archetype-editor, and also once with the Ocean archetype editor,
and even the ADL-workbench parses it, and shows a nice trtee, with all
tree elements correctly described

I tried it again, it was not the java-editor which created it, it is
because I diod so many things, that I forgot.
It was the ADL documentation, which, in my opinion, explained that
this was legal.

See the latest version, chapter MailScanner has detected a possible fraud attempt from “4.4.2.2” claiming to be MailScanner warning: numerical links are often malicious: 4.4.2.2
But still there is a problem with this construct

ELEMENT[at0016] matches { – Aantal herhalingen
value matches {|>= 0|}
}

Bert,

You can not expect that the archetype editor will recognize an archetype anymore once you’ve been editing it manually. In order to create archetypes that conform to the openEHR reference model, they are supposed to be created with the widgets in the user interface… Every time you have an ADL-file which has openEHR in the archetype identifier, that

That is too bad, it is on my wish list, it should be like opening an ADL-file.
But I know what the weak point is, you have written your ADL-parser yourself, to overcome the immutable lists Rong did program. That was not necessary. Because the parser from Rong, is very good, and searches the text for pattern, so it can create objects from the ADL, even if it did not write it itself. The ADLparser from Rong also has detailed error messages, could improve but already very good.
That is how a archetype editor can work two ways, making it possible to edit in text and to edit in GUI.

No, I haven’t written my own ADL-parser, I use the one provided by Rong Chen. To overcome the immutable lists there is an internal model in the editor, but that’s a design decision (made on very limited time) but it will not affect the functionality of the program. If I want to, I can improve the internal model to be more general and allow more things but that concerns your archetypes, which follow another reference model. These archetypes must also replace the openEHR in the archetype identifier so that the editor will know that it must treat the archetype in a more general way. That functioanlity however, is currently not provided in any of the archetype editors. Support for other (unknown) reference models could be implemented later.

We could also decide to use the AOM internally, but it would still be good to have simple facade classes to the AOM so that the logic for doing small changes in the GUI, e.g. setting run time name constraints, setting cardinality is easy to follow. The benefits of using the AOM will of course be that things not recognized in the GUI will stay the same and if the user wants to, the file could be checked for complete openEHR validity and then remove/convert illegal things.

At this moment however, I see that there is very much work in replacing the internal model with the AOM. I don’t think you fully understand how much effort it takes to map GUI widgets to the AOM since you haven’t implemented an archetype editor yourself. However, it’s a logical thing to do with the editor in the future, but God didn’t make the world in one day and I certainly will not manage to make these changes in one day :wink:

All these things are for free if you could overcome the immutable lists. I did overcome them, I create archetypes in code, while parsing HL7 XSD files. I stopped that project for other reasons, but the principle of code can be used in your archetype editor. If it is easy to exchange your ADL parser with that of Rong, you can win a lot of functionality without much programming. You even can support more versions of ADL simultaneous. But not many people will ever need that. But you will get automatically patched if there are errors and you can travel with Rong to ADL version 2, and surely there will be a 2.0.1.

You can also look at the ADL workbench which has a nice parser, a bit slow, I must admit, but produces a nice GUI after parsing, or does nice error messages if it does not succeed parsing.

Lots of opportunities.

reference model will be considered and things not recognized might disappear. Consequently, you must be very careful to make sure that the files you’re editing manually are conforming to the openEHR reference model.

It is possible to do checks, just ask the kernelobjects if they can handle what you deliver. it does not guarantee openehr model, but it guarantees valid ADL. Also this is an advantage if you can use the kernel inside your editor.
You, with your knowledge of what a valid OpenEHR model is, can than add the logic, that if ADL is valid, to check the model. You have to write that part anyway, and that part is not fully integrated in the kernel, but some checks are.

Yes, I know that but it requires some work, see above. I’m not sure if asking the kernel objects is the right thing if older archetypes are supposed to be supported in order to convert them to newer archetypes. We might need some other reference information than kernel objects when we convert archetypes based on older versions of the kernel, since older archetypes in many cases do not follow the reference model :wink:

Anyways, there should probably be some log about what was not recognized and what was converted, removed etc. For instance, in the newest version of the editor all leaf constrains on Integer under ELEMENTs will be converted to DV_COUNT. Other conversions are also made, but only a few are logged and they are only logged to the console at the moment. But as long as the file isn’t saved the user can always chose to quit without saving the file if the editor has converted or removed something that the user (for some reason) wants to keep.

That is true. But I didn’t know the editor had changed my ADL, which was valid as ADL, and I disovered accidently that it happened. Because, when I had saved my file, f.e. after issueing a small change. It can easily happen.

It should be possible to view a log if something changed…

Nice color Red, is it because of red loosing the elections in Sweden?
:wink: just joking

Nice one.

Regards,

Mattias

22

Another good thing for the editor would be the possibility to edit the KEY (identifier) in the definition, and do good checks that if they are changed manually, they are also changed in ontology

Why would one want to edit keys?

Sometimes it is very handy to have this possibility, f.e. because one wants to make items from a list too have a different key-system to make them recognizable.

Programmers often do that kind of things, giving local variables other names as globals, etc.

In my case, I had give list-items a number above 100 (at0100) and other items below, just for readability, and what happens, the Ocean editor starts giving numbers above 100. I do not like an archetype-editor to have an opinion about my numbering system.

The best thing that could happen to ADL-developers is the ADL workbench, it has a nice reward if loading succeeds, by showing a nice node-map, it has a good error-message system, and it is permissive as it comes to the openehr model, it accepts all valid ADL, which I see as a feature.

thanks
Bert

23

2006/9/19, Bert Verhees <bert.verhees@rosa.nl>:

Another good thing for the editor would be the possibility to edit the
KEY (identifier) in the definition, and do good checks that if they are
changed manually, they are also changed in ontology

Why would one want to edit keys?

Sometimes it is very handy to have this possibility, f.e. because one
wants to make items from a list too have a different key-system to make
them recognizable.

It is probably quite easy to add this functionality, but there should be some checks so it’s not possible to change to a nodeID that is already defined, because they are supposed to be unique.

/Mattias

24

Everyone,

there is a lot of work, fun, learning, and the occasional bit of angst here! Let’s try and channel some of this energy. My suggestion is that we build some organised wishlists, which can become formal change requests, but let’s not quite go there yet. My suggestion is that we as a group think about changes and enhancements for these things:

  • the Java parser
  • the Eiffel reference parser (what is inside the Workbench and the Ocean editor)
  • the Linköping archetype editor
  • the Ocean archetype editor
  • the ADL workbench
    can we document what we want on this basis? I think it will make things clearer…

I have already proposed to get an openEHR wiki up and running but it might take a while longer than I thought - there is a certain amount of sysadmin to do to make it happen, and we need to plan for disc space etc etc. So in the interim, let’s use posts on this list to keep a track of such things (e.g. under a “wishlist” thread) and we’ll move it to the wiki later.

  • thomas
25

2006/9/19, Thomas Beale <Thomas.Beale@oceaninformatics.biz>:

Everyone,

there is a lot of work, fun, learning, and the occasional bit of angst here! Let’s try and channel some of this energy. My suggestion is that we build some organised wishlists, which can become formal change requests, but let’s not quite go there yet. My suggestion is that we as a group think about changes and enhancements for these things:

  • the Java parser
  • the Eiffel reference parser (what is inside the Workbench and the Ocean editor)
  • the Linköping archetype editor
  • the Ocean archetype editor
  • the ADL workbench
    can we document what we want on this basis? I think it will make things clearer…

Hi Thomas,

I and Erik discussed this briefly. We think it’s a good idea.

/Mattias

26

>
>
> Everyone,
>
> there is a lot of work, fun, learning, and the occasional bit of angst
> here! Let's try and channel some of this energy. My suggestion is that we
> build some organised wishlists, which can become formal change requests, but
> let's not quite go there yet. My suggestion is that we as a group think
> about changes and enhancements for these things:
>
> - the Java parser
> - the Eiffel reference parser (what is inside the Workbench and the
> Ocean editor)
> - the Linköping archetype editor
> - the Ocean archetype editor
> - the ADL workbench
>
> can we document what we want on this basis? I think it will make things
> clearer...
>

Hi Thomas,

I and Erik discussed this briefly. We think it's a good idea.

I too think it's a great idea. First thing first - the interoperability between the openehr tools (java or eiffel or else) should be improved. We need to organize some set of minimal test archetypes used for testing parsers. I got some, and I am sure Thomas got some too. But we need to centralize these test archetypes. These are not the same as the clinical archetypes since they are just used for testing parsers - don't need to be meaningful at all. But they _must_ be complaint with the ADL specifications!

I am in the middle of re-organizing the java components (splitting them into even smaller pieces so they are more managable and reusable).

Cheers,
Rong

27

I must have missed the question, but it is "for all of us", so I better
answer it.

I have the humble opinion that the software, which will give the
concepts a home,
(it is not a house, it is a home)
need some improvement.

I will be happy to spend some time in that, best for me to do is
programming.
We'll see were I can help, and when I have some time (contrarily of some
others, I, my children, my wife and my cat live for a part from software
developing, so, working for money is important)

regards
Bert

Rong Chen schreef:

28

Bert
I think you have an older workbench - pre 1.4
Cheers, Sam

Bert Verhees wrote: