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> 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> 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> >> <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 >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >> >> ------------------------------ >> >> _______________________________________________ >> openEHR-implementers mailing listopenEHR-implementers at >> openehr.orghttp://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 >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> > ------------------------------ > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > openehr.orghttp://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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090927/39875621/attachment.html>
