I’m missing something as I don’t see any relationship between the ARCHETYPE_ONTOLOGY Class and the ARCHETYPE_TERM Class in the AOM content.
How are the two related? The ‘functions’ within the ARCHETYPE_ONTOLOGY Class make frequent reference to the terminology language yet this is not present in the class attributes (though is of course present in the ADL).
The ontology section (mis-named because we thought we were going to put ontology directly in there) in AOM1.4 was not fully specified. In AOM2 it is fully specified and you will see the relationship.
Nearly all the archetype tools today are ADL/AOM2 based internally, and they just treat ADL1.4 as a syntax; it is parsed and converted to AOM2 form internally. This is true for ADL Workbench, Better’s Archetype Designer, the Archie library, the Nedap tool, and (mostly) for LinkEHR. (Links to all these tools.)
I would suggest using the code in Archie, which does both ADL1.4 parsing and AOM2 representation and will save you a lot of work.
I had thought that I could leave AOM2 until a later phase in my development, but it appears not. I’ll pivot onto that model going forwards. It was always my plan to support it eventually but looks like it will be sooner rather than later. At least it replaces AOM1.4 and I don’t need to do both.
I am making reference to the Archie library, indeed the extension in Visual Studio is really helpful.
Although arguably creating ‘another parser’ might be a fruitless task, it does force me to get a deeper understanding of the underlying openEHR specification (including the versioning ).
For my ‘project’ it will be beneficial to have the parser in C# so I’m taking the time to try and do it properly. My first (partial) implementation of the parser is already in AWS as a microservice. There’s loads more to do, at the moment it’s creating a whole stack of test scripts for regression testing.
Well you might go further than I have on those openEHR-antlr4 grammars. They should (eventually) be better grammars than the current production ones (by virtue of being a cleaner design, modal etc) but they’ve only had a modicum of testing and have not yet been implemented. So it will be very interesting what you come up with, and doing it with another language (not Java) will surely surface some lessons.