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
----- Original Message ----- From: "Ergin Soysal" <[email protected]> To: "Openehr-Technical" <openehr-technical at openehr.org> Sent: Sunday, May 09, 2004 10:04 AM Subject: Re: ADL 1.2 proposal > 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=viewd ownload&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 > > > 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): > > ----------------------------------------------------------- > > > > <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> > > > > <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. Now, go and compare a UML model with its XMI equivalent. You > > have no hope of reading the latter, because not only are the XML tags > > against you, but the classes and attributes are in different sections of > > the text - good for machines, no use to humans. > > > > 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 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. > > > >> 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. > > > > well, when the ADL XML-schema is published, all the XML-schema parsers > > will be able to read it, and that's certainly an intended outcome. But > > we couldn't have easily defined the semantics of ADL if we were limited > > to something like XML-schema to do it - at least we would want UML. 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. 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). > > > > 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. > > > >> > >> 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? > > > > well, there is a need for an interoperable, lossless representation of > > archetypes. ADL is one possibility - it's text, which also happens to be > > readable by (some) humans. If it turns out that the community prefers > > another serialisation, e.g. XML-schema instance, OWL or YAML, for all I > > care, then I have no problem whatsoever - ADL will then become a > > primarily explanatory tool. But two things are worth pointing out: many > > people do like to use abstract syntaxes (it's why math and music > > notation exist...), and secondly, 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. But that's probably a detail. I have no personal > > preference for what interoperable concrete syntax is chosen by industry, > > or the community, only that it be able to represent the required > > semantics properly. > > > >> 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"? > > > > I hadn't really thought about it in those terms I have to say. I have > > received emails from people saying that they love using ADL, including > > in fields outside of health; other people prefer to think in XML, or > > UML, or functional interfaces - clearly the world is a diverse place. > > The only claim I would make for ADL is that it precisely embodies a > > conceptualisation of the problem and solution so that the problem can be > > further thought about; I think some people and tools will continue to > > use it, others won't. > > > >> 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? > > > > well, we need an archetype library (for collaborative authoring), > > archetype servers (for runtime access in interoperable format) and in > > some sites, local archetype repositories (for access to archetypes > > converted to an efficient local form). > > > > 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. > > > > > > - thomas > > > > > > > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
