+2 Stef
Op 26 sep 2009, om 08:13 heeft Grahame Grieve het volgende geschreven: > +1 > > Grahame > > Sent from my iPhone > > On Sep 25, 2009, at 6:23 PM, 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> 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 list >>>>> openEHR-implementers at openehr.org >>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-implementers >>> >>> >>> -- >>> <mime-attachment.png> Thomas Beale >>> Chief Technology Officer, Ocean Informatics >>> >>> Chair Architectural Review Board, openEHR Foundation >>> Honorary Research Fellow, University College London >>> Chartered IT Professional Fellow, BCS, British Computer Society >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> 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 >>> >> _______________________________________________ >> openEHR-technical mailing list >> 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/339f53cc/attachment.html>
