# ADL 1.2 proposal **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2004-05-06 11:51 UTC **Views:** 2 **Replies:** 11 **URL:** https://discourse.openehr.org/t/adl-1-2-proposal/15681 --- ## Post #1 by @thomas.beale Dear colleagues, there is a proposed revision of the Archetype Definition Language \(ADL\) v 1\.2 available at http://www.openehr.org/tmp/adl-1_2_draft_d.pdf. Only small changes to ADL itself are proposed, but the explanations have been improved, and complete grammars have been included in the document\. The main change is a complete redesign of the object models corresponding to ADL, informed by previous work in GEHR, ongoing archetype development, and the DSTC team engaged on the HealthConnect project in Brisbane, Australia\. This proposal will be reviewed in the proper fashion by the openEHR ARB, but of course we welcome community review and input on this discussion list\. The software \(sorry, only on Windows so far\) which implements this specification is at http://www.openehr.org/repositories/implem/latest/publishing/tools/windows/index.html. Please read the READMEs first if you intend using it\. We are still working on the packaging and use instructions, so please be patient, and of course post any complaints about difficulties you encounter\. As I'm sure many of you appreciate, perfect packaging takes time and effort, and requires user feedback\. regards, \- thomas beale --- ## Post #2 by @Vincenzo_Della_Mea Dear Thomas, as I already wrote some day ago, inside the package there are no ADL archetype files, or at least I'm not able to find them at all\. I tried to test the HTML examples, by saving them as text, but without success\. Thanks, Vincenzo --- ## Post #3 by @Ergin_Soysal Dear Thomas, Not sure if this is discussed here before, but I wonder why you don't use XML for ADL\. So that, it will be possible to use tens of ready made parsers and validators against a DTD for a number of programming language; visualize using a xslt etc\. Here a quick example: <?xml version="1\.0" encoding="UTF\-8"?> <\!DOCTYPE archetype      PUBLIC "\-//openEHR Foundation//DTD Archetype 1\.2//EN"     "http://www.openehr.org/dtds/achetype-12.dtd"> <archetype id="achetype\_id" specialize="parent\_archetype\_id">   <concept>at0010 <\!\-\- haematology result \-\->   </concept>   <description>     <\!\-\-dADL meta\-data section \-\->     <author>Sam Heard &lt;s\.heard@littlerock\.con></author>     <submission>       <organisation>openEHR Foundation</organisation>       <date>2003\-06\-10</date>     </submission>     <revision identifier="1\.2">       <author>Thomas Beale &lt;t\.beale@home\.net></author>       <date>2003\-12\-11</date>     </revision>     <status>draft</status>     <purpose>       <items lang="en">general model of haematology lab results</items>       <items lang="de">Allgemeines Modell fuer Haematologie Laborwerte</items>     </purpose>     <use>       <items lang="en">can be used directly or specialised for particular result types</items>       <items lang="de">kann entweder direkt benutzt werden, oder speziell fuer besondere Ergebnissarten</items>     </use>     <misuse/>   </description>   <definition>     <\!\-\- cADL structural section \-\->   </definition>   <ontology>     <\!\-\- dADL definitions section \-\->   </ontology> </archetype> Ergin Soysal, MD > Dear colleagues, > > there is a proposed revision of the Archetype Definition Language \(ADL\) > v 1\.2 available at http://www.openehr.org/tmp/adl-1_2_draft_d.pdf. Only > small changes to ADL itself are proposed, but the explanations have been > improved, and complete grammars have been included in the document\. The > main change is a complete redesign of the object models corresponding to > ADL, informed by previous work in GEHR, ongoing archetype development, > and the DSTC team engaged on the HealthConnect project in Brisbane, > Australia\. > > This proposal will be reviewed in the proper fashion by the openEHR ARB, > but of course we welcome community review and input on this discussion > list\. The software \(sorry, only on Windows so far\) which implements this > specification is at > http://www.openehr.org/repositories/implem/latest/publishing/tools/windows/index.html. > Please read the READMEs first if you intend using it\. > > We are still working on the packaging and use instructions, so please be > patient, and of course post any complaints about difficulties you > encounter\. As I'm sure many of you appreciate, perfect packaging takes > time and effort, and requires user feedback\. > > regards, > > \- thomas beale > > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org > Pleksus Biliþim Teknolojileri http://www.pleksus.com.tr Tel: \+90 \(312\) 435 5343 Fax: \+90 \(312\) 435 4006 --- ## Post #4 by @thomas.beale Ergin Soysal wrote: > ``` > Dear Thomas, > Not sure if this is discussed here before, but I wonder why you don't use > XML for ADL. So that, it will be possible to use tens of ready made > parsers and validators against a DTD for a number of programming language; > visualize using a xslt etc. Here a quick example: > > ``` XML will be one of the formats we can save to, but it is nearly useless when writing new syntaxes which you want to compute with. What XML is good at is only one thing really: platform independent machine representation and machine-to-machine communication. But if you want to define a language for e.g. representing constraints, such as ADL, it causes problems to try and do it "in XML". If we were to do it in XML, then we have to deal with 2 syntaxes at once; often you end up fighting the inbuilt restrictions of the XML sytnax. ADL is what is known as an "abstract" syntax, and allows us to define and deal with just one syntax. The same approach is usually followed by projects which need to define a new syntax. For example, OWL has an abstract syntax - see [http://www.w3.org/TR/owl-semantics/syntax.html](http://www.w3.org/TR/owl-semantics/syntax.html) - you might notice that raw RDF is nearly impossible for humans to read or think with. THere are also other human readable syntaxes, such as OMG HUTN, YAML, and so on - all of these are computable and human readable. And consider the fact that all programming languages come with their own syntaxes - we don't write in XML when writing in Java for example. There is an interoperability syntax for representing models called XMI, but we don't use it to think or compute with models - we use UML, or else one of the programming languages syntaxes. In sum: syntax is very important in forming and guiding the way we understand and solve problems. Gerard Freriks just sent me an extract from an account of the XML 2004 Europe conference: --- ## Post #5 by @Tony_Austin Tom, >> Not sure if this is discussed here before, but I wonder why you don't use >> XML for ADL\. So that, it will be possible to use tens of ready made >> parsers and validators against a DTD for a number of programming language; >> visualize using a xslt etc\. Here a quick example: > > XML will be one of the formats we can save to, but it is nearly useless when writing new syntaxes which you want to compute with\. What XML is good at is only one thing really: platform independent machine representation and machine\-to\-machine communication\. That's two\! > For example, OWL has an abstract syntax \- see http://www.w3.org/TR/owl-semantics/syntax.html \- you might notice that raw RDF is nearly impossible for humans to read or think with\. From http://www.w3.org/TR/owl-semantics/ it seems that the abstract syntaxes are used to restrict the possible expressions of OWL into smaller subsets\. Full OWL has the same syntax as RDF: >> First, Section 2 contains a high\-level, abstract syntax for both OWL Lite, a subset of OWL, and OWL DL, a fuller style of using OWL but one that still places some limitations on how OWL ontologies are constructed\. Eliminating these limitations results in the full OWL language, called OWL Full, which has the same syntax as RDF\. It's interesting that from the adl\-1\_2\_draft\_d\.pdf page 13, we're offered the following: <owl:Class rdf:about="\#Opera">    <rdfs:subClassOf>       <owl:Restriction>         <owl:onProperty rdf:resource="\#hasLibrettist" />         <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>       </owl:Restriction>     </rdfs:subClassOf>   </owl:Class> vs\. DOCUMENT ∈ \{    class ∈ \{\[ac0001\]\}    type ∈ \{\[ac0002\]\}    attributes cardinality ∈ \{0\.\.\*\} ∈ \{     DOC\_ATTR occurrences ∈ \{1\.\.\*\} ∈ \{       name ∈ \{ac0003\}       value ∈ \{\*\}     \}    \}   \} and: OPERA ∈ \{    A ∈ \{ librettist cardinality ∈ \{1\.\.\*\} ∈ \{\*\} \} I've removed the comments in the second extract\. Now I'm not sure about anyone else, and it may have a lot to do with my not being especially mathematically minded, but I don't regard myself as a "tortured soul" \(page 12 para 2\) for having relatively less difficulty with the first than the second\. And I think it could be parsed by a schema\-reading XML parser? > We don't write in XML when writing in Java for example\. I won't unduly labour the point but that is probably more to do with the compactness of the latter than the lack of human readability of the former: <package>org\.openehr\.a\_package</package> <public><class>A\_class<implements>Another\_class</implements> vs\. package org\.openehr\.a\_package; public class A\_class implements Another\_class \{ \.\.\. for example\. I think most would still be able to "read" the former without difficulty\. The compiled versions of either of these would not be human\-readable \(being binary\) and that of course is what "human\-readability" typically means\. >> After all, parsing is easy, I'm not sure that this is justified\. Parsing is difficult\. As you well know, I still can't use your ADL parser and that is presently the only entrée into the use of the language you have defined\. Contrast this with the many parsers that Ergin Soysal alluded to\. Writing a syntax is "easy" in the sense that you can sit down one day and dream one up, but that doesn't give it market credibility or widespread support\. > Saving ADL as XML is easy, but then of course it is no longer readable in any meaningful way by humans, just by machines\. In the version of the document I cited above there are a number of object models given \(which I haven't had a chance to unpick yet\)\. It might be contended that ADL is also only really readable by machines, given the highly mathematical nature of its format and at the least the enormity of a likely script\. Now, given the object model, is there any longer a special need for ADL? Am I right that the stated purpose was to enable archetype development unencumbered by issues associated with additional syntax? Is not the object model now the necessary and sufficient condition to call that process "done"? Put another way, do you see an archetype repository as a persistence engine for objects of the sort given in the document, with ADL just one of a range of languages for inserting and retrieving archetypes? > In terms of validation, we wouldn't use DTD in any case, we would use one of the XML schema languages, since these have typing and better ability to represent higher\-level concepts like constraints\. Agreed\.     Very best wishes as always, and see you soon,               Tony\. --- ## Post #6 by @thomas.beale Tony Austin wrote: >     XML will be one of the formats we can save to, but it is nearly >     useless when writing new syntaxes which you want to compute with\. >     What XML is good at is only one thing really: platform independent >     machine representation and machine\-to\-machine communication\. > > That's two\! we have a different counting system in the antipodes;\-\) > For example, OWL has an abstract syntax \- see http://www.w3.org/TR/owl-semantics/syntax.html \- you might notice that raw RDF is nearly impossible for humans to read or think with\. > > From http://www.w3.org/TR/owl-semantics/ it seems that the abstract syntaxes are used to restrict the possible expressions of OWL into smaller subsets\. Full OWL has the same syntax as RDF: > >         First, Section 2 contains a high\-level, abstract syntax for >         both OWL Lite, a subset of OWL, and OWL DL, a fuller style of >         using OWL but one that still places some limitations on how >         OWL ontologies are constructed\. Eliminating these limitations >         results in the full OWL language, called OWL Full, which has >         the same syntax as RDF\. > not quite \- have a look at for example some of the test cases: http://www.w3.org/TR/owl-test/byFunction#function-FunctionalProperty \- this is raw RDF\. I don't know how many people, if they're being honest would say this is a readable syntax\. There are some small examples of the mapping of the abstract syntax to the concrete at http://www.w3.org/TR/2002/WD-owl-semantics-20021108/examples.html. > I've removed the comments in the second extract\. Now I'm not sure about anyone else, and it may have a lot to do with my not being especially mathematically minded, but I don't regard myself as a "tortured soul" \(page 12 para 2\) for having relatively less difficulty with the first than the second\. And I think it could be parsed by a schema\-reading XML parser? all I would say there is that XML tags aren't there for humans to read \- I have talked about this with a lot of people, and interestingly, at an XML conference in Sydney last year heard a couple of the W3C core people say more or less the same thing\. Prof\. Joachim Dudeck from Geissen university in Germany always precedes the main part of any talk by a statement to the effect "XML is not meant for humans \- no\-one should ever read it, only machines"\. What I meant by 'tortured souls' was simply that there is a widespread misunderstanding about XML in the IT world \- which is that, because you can open an XML file with a text editor, it is somehow intended to be directly worked upon by humans; on any non\-trivial piece of XML, you do \(in my opinion\) have to be fairly tortured to try and read it, rather than find a human\-oriented equivalent \(which almost always exists\)\. But I take your point, I hadn't actually realised that anyone might compare the two syntax fragments in the light of this statement\. In any case, the OWL fragment should be replaced by a piece of abstract OWL\. >     We don't write in XML when writing in Java for example\. > > I won't unduly labour the point but that is probably more to do with the compactness of the latter than the lack of human readability of the former: > > <package>org\.openehr\.a\_package</package> > <public><class>A\_class<implements>Another\_class</implements> > > vs\. > > package org\.openehr\.a\_package; > public class A\_class implements Another\_class \{ \.\.\. well, that's one example where the syntaxes are somewhat close, but try reading this \(fragment of physical exam from CDA document\): --- ## Post #7 by @Ergin_Soysal While playing with ADL, I found myself collecting language rules in an app\. I converted it to an editor\. I hope you like: http://soysal.com/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=2 Please test it\. I can continue development on interest\. And back to ADL discussion\. First question here, who will use \(e\.i\. learn\) this language in a clinic requiring an additional archetype or modification? Next question, what will be the frequency of definition of a new archetype or modification in an health service? I believe, in majority of the cases, it may be impractical to expect some stuff to learn and remember this language\. xml may have an advantage with html\-like syntax\. But the fact that, instead of manual coding these scripts, soon, there will be a heavy demand for a visual designer, string/term translator, and/or script generator wizards etc\. In this case, you'll need to reverse engineer the ADL code back to load into the IDE :\), sorry\. So, a well defined, easily parsable format would be very beneficial in near future\. Ergin --- ## Post #8 by @Tony_Austin Tom, >>    That's two\! > > we have a different counting system in the antipodes;\-\) So if I say you owe me 20 quid, does that mean you owe me 10, or owe me 30? :\) > all I would say there is that XML tags aren't there for humans to read\. What I meant by 'tortured souls' was simply that there is a widespread misunderstanding about XML in the IT world \- which is that, because you can open an XML file with a text editor, it is somehow intended to be directly worked upon by humans; on any non\-trivial piece of XML, you do \(in my opinion\) have to be fairly tortured to try and read it, rather than find a human\-oriented equivalent \(which almost always exists\)\. The point that XML can be unreadable is quite reasonable, but obviously you can more\-or\-less obfuscate any chosen piece of syntax\. The point of my Java code example was to show that XML can be quite concise if you don't start adding in namespaces and other clutter\. Conversely, the extract from the spec document that I included was to show that without the comments, even the ADL examples in the document can be difficult to follow\. In any case while the opinion is fair enough, the claim that my soul is tortured might not be a matter of formal openEHR policy in a specification document\! >                <table> >                  <tr> >                    <th>\*Date / Time\*</th> >                    <th>\*April 7, 2000 14:30\*</th> >                    <th>\*April 7, 2000 15:30\*</th> >                  </tr> >                  <tr><th>\*Height\*</th><td>\*177 cm \(69\.7 in\)\*</td></tr> >                  <tr><th>\*Weight\*</th><td>\*194\.0 lbs \(88\.0 kg\)\*</td></tr> >                  <tr><th>\*BMI\*</th><td>\*28\.1 kg/m2\*</td></tr> >                  <tr><th>\*BSA\*</th><td>\*2\.05 m2\*</td></tr> >                  <tr> >                    <th>\*Temperature\*</th> >                    <td>\*36\.9 C \(98\.5 F\)\*</td> >                  </tr> >                  <tr><th>\*Pulse\*</th><td>\*86 / minute\*</td><td>\*84 / minute\*</td></tr> >                  <tr><th>\*Rhythm\*</th><td>\*Regular\*</td><td>\*Regular\*</td></tr> >                  <tr> >                    <th>\*Respirations\*</th> >                    <td>\*16 / minute, unlabored\*</td> >                    <td>\*14 / minute\*</td> >                  </tr> >                  <tr><th>\*Systolic\*</th><td>\*132 mmHg\*</td><td>\*135 mmHg\*</td></tr> >                  <tr><th>\*Diastolic\*</th><td>\*86 mmHg\*</td><td>\*88 mmHg\*</td></tr> >                  <tr><th>\*Position / Cuff\*</th><td>\*Left Arm\*</td><td>\*Left Arm\*</td></tr> >                </table> >              </text> >              <component1> >                <typeCode code="\*COMP\*"/> >                <contextConductionInd value="\*TRUE\*"/> >                <cdaEntryObservation> >                  <classCode code=”\*OBS\*”/> >                  <moodCode code=”\*EVN\*”/> >                  <code code=”\*F\-01851\*” codeSystem=”\*SNOMED\*” >                    displayName=”\*Body height measure\*”/> >                  <effectiveTime value=”\*200004071430\*”/> >                  <value xsi:type=”\*PQ\*” value=”\*1\.77\*” unit=”\*m\*”> >                    <translation value=”\*69\.7\*” code=”\*\[in\_I\]\*” codeSystem=”\*UCUM\*”/> >                  </value> >                </cdaEntryObservation> >              </component1> >              <component1> > > now, you can read it, sort of \(it's a table\), but it isn't at all obvious what it means until you convert to a human consumable form, which is of course what an XML browser will do to display it on the screen\. Hmm, well I can clearly pick out things like what the Systolic values are\. But in any case this only proves that an HTML table isn't the best native representation for a sequence of readings\. In the second part of the data structure I can see what the value of the "contextConductionInd" is quite easily\. It might be argued that I have no idea what the contextConductionInd actually represents, and that's true, but that's an issue of meaning, not of syntax\. > I would also say that if you go back to the programming language example, you will find that almost all programming languages have a\) stronger semantics \(e\.g\. ability to express functions, proper inheritance\), b\) use of visual real\-estate in the displayed text more or less obeys the rule that visual area used corresponds to importance \(it never does in XML \- it's mostly repeated tags you don't need to see\), c\) the style of syntax is tailored to the kind of problem the language was designed for\. I'm not sure about \(a\), but certainly \(b\) and \(c\) are completely valid observations\. > I have nothing against XML, for its intended purpose, but I do have a big problem with the idea that humans should use it as a syntax for thinking or reading\. > >>         After all, parsing is easy, >> >> I'm not sure that this is justified\. Parsing is difficult\. > > I would have to disagree there \- it takes me about a day or two to build a basic parser for any published language, given yacc/lex programming tools & libraries\. Yacc and Lex provide only the tools to read a sequence of tokens from a stream and form a parse tree\. They do nothing to interpret that into the meaning given by the information model that should underpin it \(they don't tell me what the contextConductionInd really was and why it was important\)\. > And you still wouldn't be able to show someone a text of an archetype that they could understand, where as an abstract syntax does have the property of being explainable\. Well as I suggested in my last mail, all things are relative\. A piece of Greek text is obviously human\-readable, but it won't help me in the slightest\. I found ADL to be quite mathematical\. Perhaps I simply always need the visual tools\. > But don't get me wrong \- the XML stuff is coming, it just takes a bit of time to get it all done\. Also, don't forget, the XML view of the world only gives you the data view; but there is an API based on the functional part of the model behind ADL \- for this purpose, we still need to use programming languages \(and/or WSDL equivalents\)\. Absolutely\. This is true of any information model\. > I would like to defend the parser a bit \- it's not totally useless: once it has a Java interface, we will have covered the \.Net and Java flavours of the world, and for a lot of people, it is very useful to just re\-use such a component, benefitting from a growing, maintained, and widely tested code base, just as for e\.g\. James Clark's original XML parser, which gets wrapped into every language\. The parser by the way will grow to handle all the main XML formats\. I certainly don't mean to imply that it is globally useless\! But in fairness, if I can't use it, it's useless to me, by definition\. And if parsing was easy, it would be easy to fix, correct? > the experience so far with converting archetypes to XML has had its problems \- the DSTC has been doing it for some years now, and you do get problems, mainly because XML\-schema cannot adequately represent everything in UML \(its inheritance model is broken, for a start\), and you end up having to embed annotations to avoid being lossy\. This is also a very important and worthwhile observation\. Perhaps the use of ADL is mandated because the other formalisms are deficient? That would certainly be a compelling reason to pursue ADL\. It would be interesting to see what all the deficiencies are\. > In sum, ADL represents one entry point into the world of archetypes, allowing its authors to develop other representations etc, which may be more interesting than the original; I see this as a natural evolution that occurs with any attempt to formalise an idea into computable form\. Fair enough\.           All the best,                 Tony\. --- ## Post #9 by @Isabel_Roman Sorry for my intrusion and my english\. I think all of you are agree in some aspects\. But I think that high level ontology languages as owl have enought potential to represent archetypes and you have tools to write in this language or parse owl files and the devolopment of new tools is easy thanks to apis as jena or protege\. So why reinventing the wheel with another language? you can save steps writing directly in owl and you can benefit of semantic web techniques \(for example\)\. In http://trajano.us.es/~isabel/EHR/ I have publish the RM in owl language, now I´m working with Archetype models\. Thakns to all and sorry again\. Isabel Román --- ## Post #10 by @thomas.beale Ergin Soysal wrote: > While playing with ADL, I found myself collecting language rules in an > app\. I converted it to an editor\. I hope you like: > http://soysal.com/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=2 > Please test it\. I can continue development on interest\. > Hi Ergin, very nice\. I thought I had started up gvim when I started this app\! In case you didn't know, there is a syntax mode for gvim, which does the same colourisation etc, and works in either vi or mouse mode; see http://www.openehr.org/repositories/implem/latest/publishing/tools/windows/index.html, or I can post just the gvim files on this group if anyone wants them \- they're very small\. Gvim you can get from http://www.vim.org/, it's a very nice editor, free, and works on all platforms\. The gvim mode I developed \- could be better, so anyone who wants to improve it is welcome\. > And back to ADL discussion\. First question here, who will use \(e\.i\. learn\) > this language in a clinic requiring an additional archetype or > modification? > I should point out that just because we have defined a formal language for archetypes, does not mean we think that this is the way people will generall write archetypes\. There is an open source GUI editor nearing completion which will be available in a few weeks, designed for clinicians\. It has already been tested in turkish by Koray Atalag as a matter of fact, and also demostrated to CEN and HL7 audiences\. > Next question, what will be the frequency of definition of a > new archetype or modification in an health service? > Well, that is very dependent on how people apply it, but I would expect that after an initial phase of a lot of creation, the creation of completely new archetypes will probably not occur that often \- but the modification of existing ones, and creation of archetypes which are specialisations of existing ones will be quite common\. That is only a guess, however\.\.\. > I believe, in majority > of the cases, it may be impractical to expect some stuff to learn and > remember this language\. > I agree totally \- the main audience of such languages is technical people and tool\-builders, not actual archetype authors\. > xml may have an advantage with html\-like syntax\. > I can't say I know many people who think raw xml or html are nice to edit in \- I think they're awful \(but it's obviously a matter of personal taste\!\); ADL was designed to be something like a programming language \- so technical people might write in it, but as I say above, the real aim is GUI tools\. > But the fact that, instead of manual coding these scripts, soon, there > will be a heavy demand for a visual designer, string/term translator, > and/or script generator wizards etc\. In this case, you'll need to reverse > engineer the ADL code back to load into the IDE :\), sorry\. > which is what the GUI editor does: it uses the parser back\-end, which is already on the web, with its own technical viewer GUI\. Exactly the same parser is used by the clinician's editor tool, guaranteeing that the editor must conform to the exact semantics of ADL\. Since the parser is able to save in ADL, and HTML, and in the near future, in XML and OWL/RDF, the editor will be able to do this as well\. Of these formats, ADL, and probably XML\-schema\-based XML will also be able to be read in \(for the XML, we have to see yet whether it is semantically lossy or not\)\. But at least we know that ADL works properly as a lossless format for saving and reading archetypes in\. hope this helps\. \- thomas --- ## Post #11 by @thomas.beale Isabel Román Martínez wrote: > Sorry for my intrusion and my english\. > I think all of you are agree in some aspects\. > But I think that high level ontology languages as owl have enought potential > to represent archetypes and you have tools to write in this language or > parse owl files and the devolopment of new tools is easy thanks to apis as > jena or protege\. So why reinventing the wheel with another language? > you can save steps writing directly in owl and you can benefit of semantic > web techniques \(for example\)\. > In http://trajano.us.es/~isabel/EHR/ I have publish the RM in owl language, > now I´m working with Archetype models\. > Thakns to all and sorry again\. > Isabel Román > Hi Isabel, we have been looking at OWL for some time actually, and are working with people at the University of Manchester and also Mayo Clinic to determine if OWL can cover the semantics of archetypes or not\. So far we know that OWL does not have the required data types, and it seems likely that there will be other differences\. However, we intend to continue the work on this, and develop an ADL \-> OWL/RDF serialiser \(in fact a rough XML serialiser for OWL was already done recently\)\. However, at this stage, it does not look as though it will be possible to save an ADL archetype as OWL without losing information, even if we solve the data types problem\. For one thing, how do you save archetype invariants \(a subset of OCL\) as OWL statements? This work will continue, and we will know more soon\. \- thomas --- ## Post #12 by @Ergin_Soysal Hi all, I've updated ADLED for the last time, and it's abondened :\)\. Changes: \+Search/Replace \+Code collapse: somehow incomplete \*Some Syntax highlighter improvements\. http://soysal.com/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=2 Ergin Soysal --- **Canonical:** https://discourse.openehr.org/t/adl-1-2-proposal/15681 **Original content:** https://discourse.openehr.org/t/adl-1-2-proposal/15681