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 S,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 > 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/20090926/5de478fb/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 4972 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090926/5de478fb/attachment.png>
