Hi Roger, I'd really like the kind of functionality you describe and it is definitely desirable...I was little concerned about the workload implications to already supersaturated core members. And I must say worried about the wording in subject of the thread - the content and quality of openEHR documents look pretty satisfactory to me at the moment. Sorry if my message has been little "reactive" - but I can not help but become emotional when it comes to openEHR ;)
BTW I'd be very interested to know if anyone prefers to use a "text editor" when creating/updating archetypes? It'd be very cool to have an "ADL" aware editor and have kind of "intellisense" functionality for writing ADL expressions for advanced users. Cheers, -koray Roger Erens wrote: > Hi Koray, > > If you imagine some sort of workbench or platform that can be used to > create openEHR-based applications, wouldn't it be nice if the > workbench would offer the creator/developer some sort of help along > the way? Not with tooltips saying something like "See the reference > documentation" but more like tooltips containing snippets of the > reference documentation, e.g. "Insert here an object of type DV_TEXT: > <snippet of Data Types IM inserted>". If you envisage this workbench > or platform in a web-centric setting, it's not too hard to see that a > translation service (Yahoo's or Google's) could machine-translate > those snippets. Of course it should be very clear that the originally > published (English) specification on openEHR.org is authorative. > > I think the OP was pointing into this direction, and not a > multi-million resource-intensive translation process. > > From-the-pitfalls-yours, > > Roger > > On Sat, Sep 26, 2009 at 03:23, Koray Atalag <koray at cs.auckland.ac.nz > <mailto:koray at cs.auckland.ac.nz>> wrote: > > Hi All, > > I really appreciate the "mental" exercise to achieve a better > documentation; however I must say I am really surprised to watch > the recent discussions like this one because I wonder if we, as a > community yet to solve many fundamental problems and overcome the > many challenges, have enough resources to deal with this at the > moment. Frankly I disagree with the need to translate all the > specs and documentation into other languages at the moment - not > to say that this is trivial but I don't think we are at that stage > at the moment. And when we become (if ever!) a multi-million $$$ > foundation then I suggest looking at how ISO or national bodies > approach the multi-lingual documentation problem. > > While I believe in and most importantly own a couple open source > projects myself, I see many from FOSS rounds getting into the > pitfall of seeing software as either evil or good or having the > illusion of open source as a merit by itself. That is not true...I > hope we don't end up trying to FOSS everything "just for the sake > of" the "open" in our prefix ;) > > And ?eref I don't think much people left in Turkey to bother with > openEHR anyways! > > Cheers, > > -koray > > Seref Arikan wrote: >> Tom, >> I'd be happy to help you out, just let me know what you need me >> to do. I'll be putting all of the documentation into Eclipse >> plugins of Opereffa anyway. We can turn that task into an >> experiment to lay out some sort of method for transformation of >> documentation to other formats. >> >> Cheers >> >> >> On Fri, Sep 25, 2009 at 6:08 PM, Thomas Beale >> <thomas.beale at oceaninformatics.com >> <mailto:thomas.beale at oceaninformatics.com>> wrote: >> >> >> Unfortunately I can't make any conversion mission a top >> priority, but let's commit at least to an experiment which I >> can initiate - I will generate the 'standard as-is' XML >> output from one specification (say the data types) and make >> that available - Seref or someone else may be able to >> determine what rules it is following; in the meantime I can >> do a bit of research on what needs to be done to a FM >> document to make its XML output DITA based. >> >> - thomas >> >> >> Tim Cook wrote: >>> Hi Seref, >>> >>> Thanks for your concerns and well thought out points. >>> >>> If you read my original posting, I didn't ask Tom to stop using >>> Framemaker. I ask for some output in place of (or in addition to) >>> the >>> PDF and Framemaker formats. I'll happily accept .doc files at this >>> point. >>> >>> It seems that we have a different perspective on what the sense of >>> trust >>> in the community is also. But that is an entirely other subject. >>> :-) >>> >>> --Tim >>> >>> >>> On Fri, 2009-09-25 at 11:08 +0100, Seref Arikan wrote: >>> >>>> Dear all, >>>> I'd like to express my concerns about practical outcomes of >>>> suggested >>>> changes, changes based on potential benefits. I'd appreciate your >>>> input about the use cases we are discussing just to make sure that >>>> I >>>> get this right. >>>> First of all, translation of openEHR documentation to other >>>> languages >>>> is a very critical task, which would be quite a challenge, because >>>> we >>>> are talking about very high quality documentation, to which I keep >>>> going back quite often, mostly to find out that a point that I was >>>> missing has already been there, expressed carefully. At one point >>>> I've >>>> thought about translating the docs to Turkish, my mother tongue, >>>> and >>>> realized that not having a Framemaker licence was the least of my >>>> problems. Reflecting the same quality, and more important than >>>> that, >>>> the same semantics consistenty in other languages is a huge >>>> challange. >>>> It requires understanding of the domain, the standard, and >>>> possesion >>>> of more than ordinary control over two languages, one being >>>> English. >>>> Also, as a member of openEHR community I would not like to see >>>> translations of the specs in the wild, with no official approval or >>>> inclusion from openEHR foundation, since this can easily lead to >>>> confusing documentation on an already confusing topic, which is >>>> challanging enough to master with really good docs. >>>> I would like to know if there are efforts, or even intentions of >>>> translating this documentation to other languages, and the owners >>>> of >>>> these intentions. How many translations of the documentation will >>>> be >>>> for Spanish for example? If a person would give this task a try, >>>> due >>>> to reasons expressed above, he/she would have to possess quite a >>>> lot >>>> of time, skills and he/she would have to communicate with openEHR >>>> to >>>> make sure that the outcomes do not do harm instead of doing good. >>>> My >>>> opinion is, this would be an effort linked to an institutuion like >>>> a >>>> university, or a government agency, working with openEHR. I can't >>>> see >>>> people working in their homes/offices on their own, doing this >>>> whole >>>> work, and if there are people like this, I really want to know >>>> them. >>>> The point? Well, the translation would mostly likely be performed >>>> by >>>> people with resources. A framemaker 9 licence would be the least of >>>> their problems. Again, please let us know if there is a person out >>>> there, comminting to translation, committing to ensure its quality, >>>> and committing to its maintanance, and is not able to move forward, >>>> just because he/she can't afford a licence for Framemaker. >>>> I appreciate the effort for preserving the idea of openness in all >>>> aspects of openEHR, but I want to see Tom producing documentation >>>> efficiently. This is his time spend in front of a computer, and I >>>> do >>>> not want him working slower, or producing inferior quality output, >>>> which is what will obviously happen if he does not use Framemaker. >>>> I >>>> have to confess that I am failing to see the fairness of asking >>>> Tom to >>>> commit more of his time today, for potential future benefits, which >>>> have significant prerequisites that must be covered, before they >>>> can >>>> be realized. >>>> Having used Framemaker html, xml outputs to produce documentation >>>> for >>>> Eclipse plugins, I'm fine with the idea of documentation being >>>> exported to these formats from framemaker. PDF outputs are simply >>>> read >>>> only docs, doing exactly what they are created for, providing cross >>>> platform access to documentation. So I don't see the point of >>>> critisizing them for not being appropriate for translation either, >>>> since they are not produced to be edited at all. >>>> Conclusion: please let us see concrete use cases,that justifies >>>> making >>>> the suggested changes, build on not only on idealism but also >>>> actual >>>> cost benefit analysis, and we can build a solution, or a roadmap >>>> from >>>> there. I'd rather see this wonderful community move forward, >>>> trying to >>>> stay close to its principles as much as it can, with its available >>>> resources, than see it watch others progress while we fail to do so >>>> just because we're getting ready for a better future all the time. >>>> >>>> Best Regards >>>> Seref >>>> >>>> >>>> On Fri, Sep 25, 2009 at 9:18 AM, Tim Cook >>>> <timothywayne.cook at gmail.com> <mailto:timothywayne.cook at >>>> gmail.com> wrote: >>>> On Fri, 2009-09-25 at 10:08 +0200, Erik Sundvall wrote: >>>> >>>> > In a previous license discussion I suggested the much >>>> more >>>> commonly >>>> > understood and more open CC-BY licence >>>> > (http://creativecommons.org/licenses/by/3.0/) to be used >>>> for >>>> the >>>> > specification documents, but I believe the discussion >>>> then >>>> slipped >>>> > over to just licensing for archetypes. Can we solve this >>>> while we are >>>> > at it? >>>> >>>> >>>> Well, I'm still waiting to hear from the openEHR Foundation >>>> Board >>>> (officially) on this issue since they are the only >>>> governing >>>> body we >>>> have. >>>> >>>> I'm not personally concerned with the notice you pointed >>>> out >>>> because my >>>> re-use strictly adheres to items 2&3. However, commercial >>>> users/developers such as Ocean Informatics may or may not >>>> be >>>> in breach >>>> of that license. That is for the Foundation Board to >>>> decide. >>>> There >>>> does seem to be some conflict with some of the content >>>> notices >>>> and >>>> licenses regarding commercial use though. It basically >>>> depends on where >>>> you look on the website. >>>> >>>> The openEHR Foundation, as a legal entity in the UK (and >>>> the >>>> web site >>>> claims globally), supported by CHIME/UCL and Ocean >>>> Informatics >>>> I assume >>>> have sought proper legal counsel? >>>> >>>> --Tim >>>> >>>> >>>> >>>> _______________________________________________ >>>> openEHR-clinical mailing list >>>> openEHR-clinical at openehr.org <mailto:openEHR-clinical >>>> at openehr.org> >>>> >>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> openEHR-implementers mailing list >>>> openEHR-implementers at openehr.org <mailto:openEHR-implementers >>>> at openehr.org> >>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-implementers >> >> >> -- >> *Thomas Beale >> Chief Technology Officer, Ocean Informatics >> <http://www.oceaninformatics.com/>* >> >> Chair Architectural Review Board, /open/EHR Foundation >> <http://www.openehr.org/> >> Honorary Research Fellow, University College London >> <http://www.chime.ucl.ac.uk/> >> Chartered IT Professional Fellow, BCS, British Computer >> Society <http://www.bcs.org.uk/> >> >> >> * >> * >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> <mailto:openEHR-technical at openehr.org> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ openEHR-technical >> mailing list openEHR-technical at openehr.org >> <mailto:openEHR-technical at openehr.org> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090928/e61f341b/attachment.html>
