openEHR Transition: two procedural and one licensing question
Hi Eric, Good that you bring up the SA + or - discussion again. In order to make the best decision can you please provide us with these arguments and, if possible, with the names of those companies/organisations. Cheers, Stef Op 6 sep 2011, om 16:51 heeft Erik Sundvall het volgende geschreven: > I have heard serious arguments in more than > one country where companies/organisations are not wanting to use > openEHR archetypes partly because of the SA licencing issue. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/0753a42b/attachment.html>
openEHR Transition Announcement (about regional/national openehr organizations)
enEHR-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/20110906/5e0ceee9/attachment.html>
openEHR Transition: two procedural and one licensing question
Hi All, I have been suffered by sever jet lag after long trip, while I have been thinking about this new white paper and our local activity. I could not find such localisation activity in this white paper, but please consider and mention about such local activity. I would like to show these two proposals. 1) Local activity support. As a global standard, localisation to each country or area is necessary. My three years experience to implementation of the Ruby codes, archetypes and template, we need lots of localisation efforts for Japanese use. I think this experience may be available to localise for other countries. East Asian countries people is keen in openEHR development and their engagements are promising for their health care. 2) Premature artefact repository CKM provides us well-considered archetypes and templates. This is a great knowledge resource for mankind. However, to incubate archetype as a common concept takes long time like vintage wine. On the other hand, I need more agile movement for daily development. I have developed about 50 archetypes and 6 templates. These artefacts are still premature to evaluate on CKM, but I would like to discuss about my artefacts on line with many people. Yes, it will be a 99% junk repository, but 1% diamond would be a precious for our community. As Major league cannot exist without minor leagues, I think CKM needs such minor artefacts groups. I am preparing to share them on GitHub, because anyone can use repository for each use by fork and merge request is useful. I think the licence of this repository would adopt CC-BY-SA, is this OK, Erik and Ian? Cheers, Shinji KOBAYASHI(in Japan, a path of typhoon.) 2011/9/6 Erik Sundvall : > Thanks for replying Sam! > > Erik Wrote (to openEHR-technical at openehr.org): >>> Was that whitepaper formally ratified by the new board, or by the old board, >>> or is it's current state just a suggestion by Sam? > > On Mon, Sep 5, 2011 at 17:58, Sam Heard > wrote: >> [Sam Heard] The whitepaper was ratified by the participants in the planning >> process, the current Board (Profs. Kalra, Ingram and myself) and the new >> Transitional Board. > > This is a bit worrying for the period until a broader board can be > elected. I was hoping that somebody within the new board would be > interested enough and have time to take licensing issues and community > feedback seriously, let's hope that the board does a bit more research > and community dialogue before ratifying a new version of this > whitepaper. Could somebody from the board please confirm that you'll > take a serious look at this in the near future? > > Erik wrote: >> What is the mandate period of the transitional board? When will the >> suggested new structure with an elected board start? > > On Mon, Sep 5, 2011 at 17:58, Sam Heard > wrote: >> [Sam Heard] I for one am very happy to express a date for elections if >> organisations embrace these arrangements. Clearly if there is no interest in >> participating from industry or organisations then we would have to think >> again. I suspect we will then move to election of the Board by Members but >> it is our wish to provide a means of determining the governance for >> openEHR?s key sponsors. The aim is to balance the Members with governance >> from the funders and sponsors. Some may prefer a democratic organisation top >> to bottom; we do not think this will achieve the best results. > > So there is no absolute end date set. :-( > > The "if organisations embrace these arrangements" part is worrying, > especially since we already have seen failed attempts at getting > buy-in from "organisations". > > Can't you set an absolute latest date (e.g. at the very latest > December 31, 2012) when the new arrangements will start no matter if > big organisations have made use of the introductory offer of buying a > position in the board? If not, we risk having an interim board > forever, and we really don't need any more delays in the journey > towards community-driven governance. If you get buy-in from the number > of big players you want before that absolute end date then there would > be nothing stopping you from doing the transition earlier than the > "latest date". > > Erik wrote: >> The thoughts behind the third point in the "Principles of licencing" are >> understandable, but as stated over and over again, e.g. at... >> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 >> ...the SA part of CC-BY-SA won't help against copyright and patent abuse. >> Only fighting possible upcoming bad patents in particular and bad patent >> laws in general might save the openEHR community form patent abuse. > > On Mon, Sep 5, 2011 at 17:58, Sam Heard > wrote: >> [Sam Heard] If this is true then the SA part of the license has no value. If >> this is true then I have not heard this before. > > I am very glad if you might have started to see the lack of value in > SA for archety
Bosphorus Web Services and an open source communication layer for openEHR implementers
Dear members of the openEHR community, We announced Project Bosphorus from UCL, CHIME at the end of 2010 and have been preparing an update on progress, including access to source code and a web services implementation, for testing purposes . Recent questions on the openEHR lists are relevant to the progress made and the following is therefore posted as an interim update, indicating the open source materials that we expect to release shortly, as a further component of the Opereffa platform, that has been under development here since 2008. The Bosphorus project was initiated in order to improve Java implementations of openEHR, by providing direct access to the Eiffel code base, which has been made available as open source software by Ocean Informatics. Over the past year, we have been working on a new method for connecting Java technology to the Eiffel code base. For simple applications, and in a technically simple scenario, such connectivity is not hard to construct. However, we have realized that the outcomes we wish to achieve must address more complex and demanding requirements. It is quite hard to imagine a successful openEHR implementation today which does not have a service-based design. Web-based approaches are strongly dominating everything else, and realizing their advantages in openEHR has required detailed exploration of a number of architectural and technological design choices. Scalability, performance and technology neutral access to underlying functionality are key considerations for any modern architecture. This study led us to develop a software layer which would go beyond out of the box integration options for Java and Eiffel. Especially in relation to scalability and stability requirements, it proved extremely hard to develop a satisfactory solution with available out of the box options for these two technologies. Therefore, we went on to develop a custom communication channel, using two high performance, open source frameworks: ZeroMQ from iMatix Corporation and Protocol Buffers from Google. We had earlier adopted a service-focused design for our related research on a new openEHR-based data analysis framework, and for this the new Bosphorus connectivity layer needed to be exposed to other software components, as a web service. We are excited by the potential of the evolving Bosphorus architecture, since it allows us to expose the very mature and capable open source Eiffel code base as a Java web service, with excellent characteristics in terms of scalability and performance. We believe the design will prove an important new approach to system implementation, as we start to pull key low level openEHR functionality into web services. Components, such as archetype parsers and new functionality required to exploit ADL 1.5, have proven to be good early candidates for such web services. By slowly moving to provide key openEHR functionalities as web services, we are aiming to lower current barriers to openEHR implementation, very significantly. To demonstrate the outcomes achieved to date, using this approach, we will be deploying a test web service under the Opereffa Studio Project, using Bosphorus, as previously announced. This test web-service,will provide the functionality of an archetype parser, with outputs in the form of openEHR XML schema compatible XML, and JSON. We are currently finalising our first full implementation and will be providing further details and access to the web service, shortly. We would appreciate feedback regarding the approach and, later on, regarding the use of the test web service. This is an open source project, and source code will be available with the release. We would like to thank Thomas Beale for his excellent open source Eiffel code, and his support and feedback during the development of Bosphorus. Seref Arikan and David Ingram UCL, CHIME
openEHR Transition: two procedural and one licensing question
Good to hear about you! I hope everything is ok in Japan. I would encourage you to put the archetypes on the CKM anyway, as I would say that most of the available archetypes on the repository are in the same situation as your archetypes (the implicit 'use under your own responsibility') 2011/9/6 Shinji KOBAYASHI : > Hi All, > > I have been suffered by sever jet lag after long trip, while I have > been thinking about this new white > paper and our local activity. I could not find such localisation > activity in this white paper, but please > consider and mention about such local activity. > I would like to show these two proposals. > 1) Local activity support. > As a global standard, localisation to each country or area is > necessary. ?My three years experience > to implementation of the Ruby codes, archetypes and template, we need > lots of localisation efforts > for Japanese use. I think this experience may be available to localise > for other countries. East Asian > countries people is keen in openEHR development and their engagements > are promising for their > health care. > > 2) ?Premature artefact repository > CKM provides us well-considered archetypes and templates. This is a > great knowledge resource > for mankind. However, to incubate archetype as a common concept takes > long time like vintage wine. > On the other hand, I need more agile movement for daily development. I > have developed about 50 > archetypes and 6 templates. These artefacts are still premature to > evaluate on CKM, but I would > like to discuss about my artefacts on line with many people. Yes, it > will be a 99% junk repository, > but 1% diamond would be a precious for our community. As Major league > cannot exist without > minor leagues, I think CKM needs such minor artefacts groups. > I am preparing to share them on GitHub, because anyone can use > repository for each use by fork > and merge request is useful. > I think the licence of this repository would adopt CC-BY-SA, is this > OK, Erik and Ian? > > Cheers, > Shinji KOBAYASHI(in Japan, a path of typhoon.) > > 2011/9/6 Erik Sundvall : >> Thanks for replying Sam! >> >> Erik Wrote (to openEHR-technical at openehr.org): Was that whitepaper formally ratified by the new board, or by the old board, or is it's current state just a suggestion by Sam? >> >> On Mon, Sep 5, 2011 at 17:58, Sam Heard >> wrote: >>> [Sam Heard] The whitepaper was ratified by the participants in the planning >>> process, the current Board (Profs. Kalra, Ingram and myself) and the new >>> Transitional Board. >> >> This is a bit worrying for the period until a broader board can be >> elected. I was hoping that somebody within the new board would be >> interested enough and have time to take licensing issues and community >> feedback seriously, let's hope that the board does a bit more research >> and community dialogue before ratifying a new version of this >> whitepaper. Could somebody from the board please confirm that you'll >> take a serious look at this in the near future? >> >> Erik wrote: >>> What is the mandate period of the transitional board? When will the >>> suggested new structure with an elected board start? >> >> On Mon, Sep 5, 2011 at 17:58, Sam Heard >> wrote: >>> [Sam Heard] I for one am very happy to express a date for elections if >>> organisations embrace these arrangements. Clearly if there is no interest in >>> participating from industry or organisations then we would have to think >>> again. I suspect we will then move to election of the Board by Members but >>> it is our wish to provide a means of determining the governance for >>> openEHR?s key sponsors. The aim is to balance the Members with governance >>> from the funders and sponsors. Some may prefer a democratic organisation top >>> to bottom; we do not think this will achieve the best results. >> >> So there is no absolute end date set. :-( >> >> The "if organisations embrace these arrangements" part is worrying, >> especially since we already have seen failed attempts at getting >> buy-in from "organisations". >> >> Can't you set an absolute latest date (e.g. at the very latest >> December 31, 2012) when the new arrangements will start no matter if >> big organisations have made use of the introductory offer of buying a >> position in the board? If not, we risk having an interim board >> forever, and we really don't need any more delays in the journey >> towards community-driven governance. If you get buy-in from the number >> of big players you want before that absolute end date then there would >> be nothing stopping you from doing the transition earlier than the >> "latest date". >> >> Erik wrote: >>> The thoughts behind the third point in the "Principles of licencing" are >>> understandable, but as stated over and over again, e.g. at... >>> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 >>> ...the SA part of CC-BY-SA won't he
Fwd: [openEHR-announce] openEHR Transition Announcement
ble, to > author archetypes, templates and terminology reference sets directly > interacting with the Clinical Knowledge Manager and equivalent repository and > review tools; and > Establish a mechanism for Associates to formally endorse archetypes (and > possibly in the longer term templates) for international use. > The Board has been changed to manage the transition until we are in a > position to take nominations from Associates. Prof. David Ingram will become > President and remain on the Board. Dr Bill Aylward from Moorfield?s Eye > Hospital (the Open Eyes Project) will join Dr Ian McNicoll with his long > advocacy of health care computing (British Computer Society) and Dr Jussara > Rotzsch who has been involved in establishing openEHR as the Brazilian > national EHR model. Professor Dipak Kalra and I will remain and I become > Chair of the Board initially. The new Board will now actively seek Associates > to engage in this important work and to provide secure governance into the > future. > > At present many of our key participants are being drawn into national > programmes. Whilst this is encouraging, we need to bring this work, where > appropriate, back to the international community as quickly as possible. It > is clear that governance that is acceptable to these national programs and > industry is a very important step. It is also our belief that standard SDO > processes are not suitable for our work and we have instead modelled our > future on collaborative engineering efforts. Our products must be fit for > purpose, stable and have an update cycle that is in tune with our domain. > > Free membership for participants and free access to the assets of the > Foundation remains a fundamental principle going forward. Our commitment to > open specifications, open software and open clinical models, unrestrictive to > commercial use, remains unchanged. > > We hope you will join with us enthusiastically in the next phase of > development of the Foundation and comment freely on the attached paper. There > will be many views on what we need to do and how we might best achieve it. > The Board is very interested in alternative ways to balance the needs of > industry and governments with those of the developers and users of the system. > > Let?s make the future of eHealth work efficiently for all. > > Yours sincerely, Sam Heard > > Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale, > Martin van der Meer and Tony Shannon for assisting in the planning. > > openEHR Transition White Paper > ___ > openEHR-announce mailing list > openEHR-announce at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/1b009098/attachment.html>
openEHR Transition: two procedural and one licensing question
Hi Ian! Nice to have more than one single board member to actually discuss with on the lists, this is already a great openEHR improvement! On Tue, Sep 6, 2011 at 15:07, Ian McNicoll wrote: > The issue of CC-BY vs. CC-BY-SA has, of course, been extensively > discussed and although the previous board took a decision to adopt SA, > this is very much up for further discussion. Good. Don't wait too long, there are several more interesting and fun things to discuss and work with once the licensing stupidity is solved. >?Like many others, I did > not get particularly involved in these discussions as it felt to me > (perhaps incorrectly) to be a somewhat arcane and legalistic debate > over a pretty fine point. How can this be explained to clinicians of the board if what is already on the wiki... http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal ...is not enough? Just read through that page and follow the links to the messages in the cited mail debate dating years back, then ask again if any points are still unclear. Analogies can be misleading, but I'll try: What danger is "a pretty fine point" of a malign cancer cell cluster in a human body, why so much fuzz when you detect that? Whenever I talk to software people they seem to immediately understand the issue and importance of not having licence-contagious (GPL/SA-like) code getting into the wrong parts of closed source systems (if you want to allow closed source business models in your ecosystem). Software people also understand that you simply can't claim to publish something as CC-BY at the same time as you say that some derivative works based on it should be CC-BY-SA, that's just incredibly misguided and any governance body letting that slip through is not to be completely trusted regarding license competence until further educated... If you don't have people on the board understanding software industry basics, then the board is missing some vital competence and you should make sure to either get that competence into the board or take the advice of people like Tom Beale in these questions. Just as much as you'd probably consider it wise to consult a clinician rather than a software specialist regarding medical issues. The "fine point" of licensing is fundamental for most companies before deciding if they want to commit commercial resources into any software-related project. I have heard serious arguments in more than one country where companies/organisations are not wanting to use openEHR archetypes partly because of the SA licencing issue. They may have adopted the technical framework (RM etc) but are using their own set of archetypes, and as long as they don't exchange data outside their own systems then there is no perceived interoperability problem... *sigh* > What might be helpful to me and others would be some clear practical > examples of the kind of scenario for which CC-BY-SA is thought to be > required (rightly or wrongly). Read that wikipage and the mail links again, there are several examples in those texts where CC-BY-SA would likely reduce trust in openEHR as a viable business option. One major short term risk I see currently is that the foundation will continue to be slow in response to licensing concerns and that as a result competitors to the openEHR-hosted CKM will pop up using better licenses (like pure CC-BY) for their non-openEHR-derived archetypes and that the archetyping community gets fragmented and semantic interoperability thus is reduced. Another short term risk is that fewer commercial entities might be interested in openEHR if there is a perceived lack of understanding of software industry needs in the board. But I think you find most of these arguments already on that wikipage and in it's linked mail discussion. http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal Do read it. And the links. Please. // Erik
CKM Archetypes in XML don't seem to validate properly against available XSDs
Thanks, Sebastian! yes, I also look forward to the new AOM/XML binding component. Cheers, Rong On 6 September 2011 15:45, Sebastian Garde < sebastian.garde at oceaninformatics.com> wrote: > Hi, > > I have modified the XMLSerialiser code and checked it in, you can compile > it from there if you like. > This will become part of the next minor release for ckm. > > Seref: looking forward to the binding! > > Cheers > Sebastian > > Am 06.09.2011 11:44, schrieb Seref Arikan: > > Hi Rong, > I'm working on this; an AOM to JAXB binding. I'm hoping that I'll be > able to give more details in a couple of weeks. > > Regards > Seref > > > On Tue, Sep 6, 2011 at 10:34 AM, Rong Chen > wrote: > > Hi Sebastian, > To my knowledge, no one is maintaining the AOM xml-serialiser from the Java > Reference Project at the moment. So I would appreciate if you could fix it > this time. > Actually the larger issue about xml-serialiser is that it's not relying on a > java XML binding API. This makes it vulnarable to changes in the archetype > XML schema. > There is already a xml-binding component that provides XML parsing and > serialising based on RM XML schema. One just needs to implement a mapping > between the classes from openehr-aom component and the generated XML > binding classes in order to have XML schema based parsing and serialising. > This is probably the best way to go. > Cheers, > Rong > On 6 September 2011 10:53, Sebastian Garde oceaninformatics.com> wrote: > > Hi > > CKM is using the XML serialiser of the openEHR Java Reference > implementation. > > It seems that the serialiser applies a different order to some elements > than required by the schema. > > Not sure if these were turned around in the xsd at some stage maybe? > While I don't really understand why these elements need to have an > order, I believe the problem in the XML serialiser is quite easy to fix. > > Is anybody maintaining this code at present? Otherwise I can have a go. > > Regards > Sebastian > > > Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: > > Hello everyone > > Maybe there has been some intermediate change that i am missing here but > i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" > (downloaded as XML from the CKM editor today) through the available XSDs > from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and > i am getting a very large number of errors. > > Just as an indication, all the errors are "Invalid content was found" > mostly for the elements "existence" and "lower_included" (expecting > "rm_attribute_name" and "lower_unbounded" respectively) > > Are there different XSDs for the structure of the CKM XML files? And if > yes, are they available? > > Looking forward to hearing from you > Athanasios Anastasiou > > P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead > of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was > "BaseTypes.xsd" in version 1.0). It seems that the intention is to > preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" > reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it makes > a difference for case sensitive file systems :-) > > > > ___ > openEHR-technical mailing listopenEHR-technical at > openehr.orghttp://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 listopenEHR-technical at > openehr.orghttp://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 > > > -- > >[image: Ocean Informatics] > Dr Sebastian Garde > Senior Developer > Ocean Informatics >*Dr. sc. hum., Dipl.-Inform. Med, FACHI* > > Skype: gardeseb > > ___ > 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/20110906/89cd6c41/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: oceanlogo.png Type: image/png Size: 5677 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/89cd6c41/attachment.png>
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hi, I have modified the XMLSerialiser code and checked it in, you can compile it from there if you like. This will become part of the next minor release for ckm. Seref: looking forward to the binding! Cheers Sebastian Am 06.09.2011 11:44, schrieb Seref Arikan: > Hi Rong, > I'm working on this; an AOM to JAXB binding. I'm hoping that I'll be > able to give more details in a couple of weeks. > > Regards > Seref > > > On Tue, Sep 6, 2011 at 10:34 AM, Rong Chen wrote: >> Hi Sebastian, >> To my knowledge, no one is maintaining the AOM xml-serialiser from the Java >> Reference Project at the moment. So I would appreciate if you could fix it >> this time. >> Actually the larger issue about xml-serialiser is that it's not relying on a >> java XML binding API. This makes it vulnarable to changes in the archetype >> XML schema. >> There is already a xml-binding component that provides XML parsing and >> serialising based on RM XML schema. One just needs to implement a mapping >> between the classes from openehr-aom component and the generated XML >> binding classes in order to have XML schema based parsing and serialising. >> This is probably the best way to go. >> Cheers, >> Rong >> On 6 September 2011 10:53, Sebastian Garde >> wrote: >>> Hi >>> >>> CKM is using the XML serialiser of the openEHR Java Reference >>> implementation. >>> >>> It seems that the serialiser applies a different order to some elements >>> than required by the schema. >>> >>> Not sure if these were turned around in the xsd at some stage maybe? >>> While I don't really understand why these elements need to have an >>> order, I believe the problem in the XML serialiser is quite easy to fix. >>> >>> Is anybody maintaining this code at present? Otherwise I can have a go. >>> >>> Regards >>> Sebastian >>> >>> >>> Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: >>>> Hello everyone >>>> >>>> Maybe there has been some intermediate change that i am missing here but >>>> i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" >>>> (downloaded as XML from the CKM editor today) through the available XSDs >>>> from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and >>>> i am getting a very large number of errors. >>>> >>>> Just as an indication, all the errors are "Invalid content was found" >>>> mostly for the elements "existence" and "lower_included" (expecting >>>> "rm_attribute_name" and "lower_unbounded" respectively) >>>> >>>> Are there different XSDs for the structure of the CKM XML files? And if >>>> yes, are they available? >>>> >>>> Looking forward to hearing from you >>>> Athanasios Anastasiou >>>> >>>> P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead >>>> of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was >>>> "BaseTypes.xsd" in version 1.0). It seems that the intention is to >>>> preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" >>>> reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it makes >>>> a difference for case sensitive file systems :-) >>>> >>>> >>>> >>>> ___ >>>> 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 > -- Ocean Informatics Dr Sebastian Garde Senior Developer Ocean Informatics /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/d82fc4f5/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: oceanlogo.png Type: image/png Size: 5677 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/d82fc4f5/attachment.png>
openEHR Transition: two procedural and one licensing question
Hi Erik, As one of the new transitional board members I would like to thank you for your comments and suggestions. I don't think any of us would consider the White Paper as near to being a finished article but there was consensus that, given the long wait, it was good enough to go to the openEHR community for what I hope will be robust discussion and criticism. As you say, there are a number of issues which lack clarity and need further discussion. The issue of CC-BY vs. CC-BY-SA has, of course, been extensively discussed and although the previous board took a decision to adopt SA, this is very much up for further discussion. Like many others, I did not get particularly involved in these discussions as it felt to me (perhaps incorrectly) to be a somewhat arcane and legalistic debate over a pretty fine point. What might be helpful to me and others would be some clear practical examples of the kind of scenario for which CC-BY-SA is thought to be required (rightly or wrongly). As I understand it the debate centres around whether this particular kind of 'misuse' can really be controlled by CC-BY-SA without imposing inappropriate restrictions on the corpus of work as a whole and sending the wrong message to interested parties. I did enjoy your reference to ''transitional arrangements' in North Africa and the Miiddle East :-) Much as I am attracted to the idea of participating in an 'interim' 25 year reign of terror, I am absolutely clear that the role of this board is to manage the transitional period as rapidly as possible. I think setting an end date is correct in principle but might be difficult to judge in practice. Having said that, Dec 2012 feels to me like a reasonable start point for discussion. I think the White Paper correctly identifies the need to engage institutional and commercial organisations directly in any new governance arrangements. openEHR benefits in many ways from not being an 'official' standards body,but the lack of organisational governance has been a significant barrier to engagement of potential institutional stakeholders. Whilst the core of openEHR activities should, I think, definitely draw heavily on an Apache Foundation-like approach, I am not convinced that this will be sufficient. Balancing this requirement against the legitimate needs of ordinary members will be challenging and I am sure you and others will have a number of ideas in this area. I expect there may well be some robust exchanges of opinion over the coming weeks and months but I am very confident that as a community we have a pretty coherent and unified sense of the end goal : An open specification, backed up by open source software, and open clinical knowledge artifacts, with as little encumbrance on further use as possible, commercial or otherwise, and community-led development very much in the mode of open-source software projects. This does need to be anchored by much more inclusive governance arrangements which blend the needs of community members and the 'open ethos' above, with the organisational checks and balances that institutional stakeholders will expect from a body which produces 'standard models'. After a period where we have moved from specification to development and now into real implementation, I am increasingly confident that openEHR has a solid and exciting future. I am looking forward to the challenge of helping get us into the right shape to support this future. Regards, Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 6 September 2011 10:05, Erik Sundvall wrote: > Thanks for replying Sam! > > Erik Wrote (to openEHR-technical at openehr.org): >>> Was that whitepaper formally ratified by the new board, or by the old board, >>> or is it's current state just a suggestion by Sam? > > On Mon, Sep 5, 2011 at 17:58, Sam Heard > wrote: >> [Sam Heard] The whitepaper was ratified by the participants in the planning >> process, the current Board (Profs. Kalra, Ingram and myself) and the new >> Transitional Board. > > This is a bit worrying for the period until a broader board can be > elected. I was hoping that somebody within the new board would be > interested enough and have time to take licensing issues and community > feedback seriously, let's hope that the board does a bit more research > and community dialogue before ratifying a new version of this > whitepaper. Could somebody from the board please confirm that you'll > take a serious look at this in the near future? > > Erik wrote: >> What is the mandate period of the transitional board? When will the >> suggested new structure with an elected board start? > > On Mon, Sep 5, 2011 at 17:58, Sam Heard > wrote: >> [Sam Heard
openEHR Transition: two procedural and one licensing question
t > > December 31, 2012) when the new arrangements will start no matter if > > big organisations have made use of the introductory offer of buying a > > position in the board? If not, we risk having an interim board > > forever, and we really don't need any more delays in the journey > > towards community-driven governance. If you get buy-in from the number > > of big players you want before that absolute end date then there would > > be nothing stopping you from doing the transition earlier than the > > "latest date". > > > > Erik wrote: > >> The thoughts behind the third point in the "Principles of licencing" are > >> understandable, but as stated over and over again, e.g. at... > >> http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 > >> ...the SA part of CC-BY-SA won't help against copyright and patent abuse. > >> Only fighting possible upcoming bad patents in particular and bad patent > >> laws in general might save the openEHR community form patent abuse. > > > > On Mon, Sep 5, 2011 at 17:58, Sam Heard > > wrote: > >> [Sam Heard] If this is true then the SA part of the license has no value. > >> If > >> this is true then I have not heard this before. > > > > I am very glad if you might have started to see the lack of value in > > SA for archetypes. Using pure CC-BY (for both archetypes AND > > specifications) would make the first six points under "Principles of > > licensing" unnecessary and reduce confusion. > > > > At the same time I am very worried about the totally amazing > > information blocking filter you must have built in if you have "not > > heard" this argument before. Several people have been questioning your > > reasoning on this very point for years! > > > > On the official openEHR-wikipage set up for this particular question > > when community feedback was requested... > > http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal > > ...you have several people (including Tom Beale) in clear text saying > > that CC-BY-SA will NOT protect against patent attacks. (Scroll down to > > the heading "Discussion summaries regarding CC-BY versus CC-BY-SA for > > content models".) > > > > How on earth could you and the entire board miss that when writing up > > the draft for the transition whitepaper and when making earlier > > license decisions? > > > > One thing that however is very efficient in fighting patent trolls is > > "prior art". Thus one of the best protections regarding archetypes > > etc. is to have as much as possible of development completely public, > > indexed and archived by trusted sites (like http://www.archive.org/). > > This means always making sure to allow enough search engines and not > > requiring login in order to read archetype discussions and thoughts in > > development repositories (things like the CKM). The earlier date the > > mention of an idea can be traced back to, the more patent claims it > > will protect against. > > > > Best Regards, > > Erik Sundvall > > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > > > P.s. I agree with Pablo & Diego that we need to talk about > > communication between several repositories, not just discuss the > > current openEHR-hosted CKM. > > > > ___ > > 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/20110906/c713f558/attachment.html>
CKM Archetypes in XML don't seem to validate properly against available XSDs
I believe it would be a very limited number of changes. If this helps you temporarily, I'd go for it. Sebastian Am 06.09.2011 11:49, schrieb Athanasios Anastasiou: > Hello > > Thank you for your response Sebastian. > > Is it a small number of changes that i could perhaps apply to the XSDs > temporarily or better wait for you to modify the serialiser and try to > re-download the archetypes from the CKM? > > All the best > Athanasios Anastasiou > > > > > On 06/09/2011 09:53, Sebastian Garde wrote: >> Hi >> >> CKM is using the XML serialiser of the openEHR Java Reference >> implementation. >> >> It seems that the serialiser applies a different order to some elements >> than required by the schema. >> >> Not sure if these were turned around in the xsd at some stage maybe? >> While I don't really understand why these elements need to have an >> order, I believe the problem in the XML serialiser is quite easy to fix. >> >> Is anybody maintaining this code at present? Otherwise I can have a go. >> >> Regards >> Sebastian >> >> >> Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: >>> Hello everyone >>> >>> Maybe there has been some intermediate change that i am missing here >>> but >>> i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" >>> (downloaded as XML from the CKM editor today) through the available >>> XSDs >>> from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html >>> and >>> i am getting a very large number of errors. >>> >>> Just as an indication, all the errors are "Invalid content was found" >>> mostly for the elements "existence" and "lower_included" (expecting >>> "rm_attribute_name" and "lower_unbounded" respectively) >>> >>> Are there different XSDs for the structure of the CKM XML files? And if >>> yes, are they available? >>> >>> Looking forward to hearing from you >>> Athanasios Anastasiou >>> >>> P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead >>> of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was >>> "BaseTypes.xsd" in version 1.0). It seems that the intention is to >>> preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" >>> reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it >>> makes >>> a difference for case sensitive file systems :-) >>> >>> >>> >>> ___ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > -- Ocean Informatics Dr Sebastian Garde Senior Developer Ocean Informatics /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/ac205189/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: oceanlogo.png Type: image/png Size: 5677 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/ac205189/attachment.png>
openEHR Transition Announcement (about regional/national openehr organizations)
ional requirements, and templates that allow tailoring for actual use in specific settings. The result is ADL/AOM 1.5. He has, as usual, been totally committed to this work and it is probably very important for me to say, it is ?no mean feat?. There is a lot to do. Most important are: Begin to showcase development teams and software using openEHR successfully in clinical settings; Finalise ADL/AOM 1.5, including its succinct XML expression, and integrate it into existing and emerging tools; Update the openEHR reference model to version 1.1 bringing our collective knowledge to bear on the new features and changes while ensuring backward compatibility; Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools; and Establish a mechanism for Associates to formally endorse archetypes (and possibly in the longer term templates) for international use. The Board has been changed to manage the transition until we are in a position to take nominations from Associates. Prof. David Ingram will become President and remain on the Board. Dr Bill Aylward from Moorfield?s Eye Hospital (the Open Eyes Project) will join Dr Ian McNicoll with his long advocacy of health care computing (British Computer Society) and Dr Jussara Rotzsch who has been involved in establishing openEHR as the Brazilian national EHR model. Professor Dipak Kalra and I will remain and I become Chair of the Board initially. The new Board will now actively seek Associates to engage in this important work and to provide secure governance into the future. At present many of our key participants are being drawn into national programmes. Whilst this is encouraging, we need to bring this work, where appropriate, back to the international community as quickly as possible. It is clear that governance that is acceptable to these national programs and industry is a very important step. It is also our belief that standard SDO processes are not suitable for our work and we have instead modelled our future on collaborative engineering efforts. Our products must be fit for purpose, stable and have an update cycle that is in tune with our domain. Free membership for participants and free access to the assets of the Foundation remains a fundamental principle going forward. Our commitment to open specifications, open software and open clinical models, unrestrictive to commercial use, remains unchanged. We hope you will join with us enthusiastically in the next phase of development of the Foundation and comment freely on the attached paper. There will be many views on what we need to do and how we might best achieve it. The Board is very interested in alternative ways to balance the needs of industry and governments with those of the developers and users of the system. Let?s make the future of eHealth work efficiently for all. Yours sincerely, Sam Heard Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale, Martin van der Meer and Tony Shannon for assisting in the planning. openEHR Transition White Paper ___ openEHR-announce mailing list openEHR-announce at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/ec4bc41c/attachment.html> -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ATT1 URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/ec4bc41c/attachment.pl>
openEHR Transition: two procedural and one licensing question
Thanks Pablo ? this is very helpful. Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Tuesday, 6 September 2011 8:42 AM To: openehr technical Subject: RE: openEHR Transition: two procedural and one licensing question Hi, I think Diego's point is to change this "... directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools"to something like "... to interact with any Clinical Knowledge Manager through a standard API (to be defined)". -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos _ Date: Mon, 5 Sep 2011 21:49:01 +0100 Subject: Re: openEHR Transition: two procedural and one licensing question From: ian.mcnic...@oceaninformatics.com To: openehr-technical at openehr.org Hi Diego, I understand from Sebastian that you have been exploring the current CKM web services. Do you think these might form the basis for an open repository API or do you have any other comments or alternative suggestions? Ian On Monday, 5 September 2011, Sam Heard wrote: > Thanks Diego > > [Sam Heard] This would be a step forward and would allow for slim and fat > systems to offer the same basic calls. > >> > My suggestion is for the this point >> "Begin an open source software project for tools, web-based if >> possible, to author archetypes, templates and terminology reference >> sets directly interacting with the Clinical Knowledge Manager and >> equivalent repository and review tools" >> >> I agree with the first part (create web-based open source tools), but >> I think that the second part should be clarified. We should define a >> basic API to access repositories, to avoid doing ad-hoc >> implementations for each one of the possible repositories > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org ___ 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/20110906/0d940784/attachment.html>
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hi Sebastian, To my knowledge, no one is maintaining the AOM xml-serialiser from the Java Reference Project at the moment. So I would appreciate if you could fix it this time. Actually the larger issue about xml-serialiser is that it's not relying on a java XML binding API. This makes it vulnarable to changes in the archetype XML schema. There is already a xml-binding component that provides XML parsing and serialising based on RM XML schema. One just needs to implement a mapping between the classes from openehr-aom component and the generated XML binding classes in order to have XML schema based parsing and serialising. This is probably the best way to go. Cheers, Rong On 6 September 2011 10:53, Sebastian Garde < sebastian.garde at oceaninformatics.com> wrote: > Hi > > CKM is using the XML serialiser of the openEHR Java Reference > implementation. > > It seems that the serialiser applies a different order to some elements > than required by the schema. > > Not sure if these were turned around in the xsd at some stage maybe? > While I don't really understand why these elements need to have an > order, I believe the problem in the XML serialiser is quite easy to fix. > > Is anybody maintaining this code at present? Otherwise I can have a go. > > Regards > Sebastian > > > Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: > > Hello everyone > > > > Maybe there has been some intermediate change that i am missing here but > > i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" > > (downloaded as XML from the CKM editor today) through the available XSDs > > from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and > > i am getting a very large number of errors. > > > > Just as an indication, all the errors are "Invalid content was found" > > mostly for the elements "existence" and "lower_included" (expecting > > "rm_attribute_name" and "lower_unbounded" respectively) > > > > Are there different XSDs for the structure of the CKM XML files? And if > > yes, are they available? > > > > Looking forward to hearing from you > > Athanasios Anastasiou > > > > P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead > > of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was > > "BaseTypes.xsd" in version 1.0). It seems that the intention is to > > preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" > > reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it makes > > a difference for case sensitive file systems :-) > > > > > > > > ___ > > 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/20110906/07084cc8/attachment.html>
openEHR Transition: two procedural and one licensing question
Thanks for replying Sam! Erik Wrote (to openEHR-technical at openehr.org): >> Was that whitepaper formally ratified by the new board, or by the old board, >> or is it's current state just a suggestion by Sam? On Mon, Sep 5, 2011 at 17:58, Sam Heard wrote: > [Sam Heard] The whitepaper was ratified by the participants in the planning > process, the current Board (Profs. Kalra, Ingram and myself) and the new > Transitional Board. This is a bit worrying for the period until a broader board can be elected. I was hoping that somebody within the new board would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: > What is the mandate period of the transitional board? When will the > suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard wrote: > [Sam Heard] I for one am very happy to express a date for elections if > organisations embrace these arrangements. Clearly if there is no interest in > participating from industry or organisations then we would have to think > again. I suspect we will then move to election of the Board by Members but > it is our wish to provide a means of determining the governance for > openEHR?s key sponsors. The aim is to balance the Members with governance > from the funders and sponsors. Some may prefer a democratic organisation top > to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The "if organisations embrace these arrangements" part is worrying, especially since we already have seen failed attempts at getting buy-in from "organisations". Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start no matter if big organisations have made use of the introductory offer of buying a position in the board? If not, we risk having an interim board forever, and we really don't need any more delays in the journey towards community-driven governance. If you get buy-in from the number of big players you want before that absolute end date then there would be nothing stopping you from doing the transition earlier than the "latest date". Erik wrote: > The thoughts behind the third point in the "Principles of licencing" are > understandable, but as stated over and over again, e.g. at... > http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 > ...the SA part of CC-BY-SA won't help against copyright and patent abuse. > Only fighting possible upcoming bad patents in particular and bad patent > laws in general might save the openEHR community form patent abuse. On Mon, Sep 5, 2011 at 17:58, Sam Heard wrote: > [Sam Heard] If this is true then the SA part of the license has no value. If > this is true then I have not heard this before. I am very glad if you might have started to see the lack of value in SA for archetypes. Using pure CC-BY (for both archetypes AND specifications) would make the first six points under "Principles of licensing" unnecessary and reduce confusion. At the same time I am very worried about the totally amazing information blocking filter you must have built in if you have "not heard" this argument before. Several people have been questioning your reasoning on this very point for years! On the official openEHR-wikipage set up for this particular question when community feedback was requested... http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal ...you have several people (including Tom Beale) in clear text saying that CC-BY-SA will NOT protect against patent attacks. (Scroll down to the heading "Discussion summaries regarding CC-BY versus CC-BY-SA for content models".) How on earth could you and the entire board miss that when writing up the draft for the transition whitepaper and when making earlier license decisions? One thing that however is very efficient in fighting patent trolls is "prior art". Thus one of the best protections regarding archetypes etc. is to have as much as possible of development completely public, indexed and archived by trusted sites (like http://www.archive.org/). This means always making sure to allow enough search engines and not requiring login in order to read archetype discussions and thoughts in development repositories (things like the CKM). The earlier date the mention of an idea can be traced back to, the more patent claims it will protect against. Best Regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 P.s. I agree with Pablo & Diego that we need to talk about communication between several repositories, not just discuss the current openEHR-hosted CKM
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hi CKM is using the XML serialiser of the openEHR Java Reference implementation. It seems that the serialiser applies a different order to some elements than required by the schema. Not sure if these were turned around in the xsd at some stage maybe? While I don't really understand why these elements need to have an order, I believe the problem in the XML serialiser is quite easy to fix. Is anybody maintaining this code at present? Otherwise I can have a go. Regards Sebastian Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: > Hello everyone > > Maybe there has been some intermediate change that i am missing here but > i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" > (downloaded as XML from the CKM editor today) through the available XSDs > from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and > i am getting a very large number of errors. > > Just as an indication, all the errors are "Invalid content was found" > mostly for the elements "existence" and "lower_included" (expecting > "rm_attribute_name" and "lower_unbounded" respectively) > > Are there different XSDs for the structure of the CKM XML files? And if > yes, are they available? > > Looking forward to hearing from you > Athanasios Anastasiou > > P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead > of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was > "BaseTypes.xsd" in version 1.0). It seems that the intention is to > preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" > reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it makes > a difference for case sensitive file systems :-) > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hello Thank you for your response Sebastian. Is it a small number of changes that i could perhaps apply to the XSDs temporarily or better wait for you to modify the serialiser and try to re-download the archetypes from the CKM? All the best Athanasios Anastasiou On 06/09/2011 09:53, Sebastian Garde wrote: > Hi > > CKM is using the XML serialiser of the openEHR Java Reference > implementation. > > It seems that the serialiser applies a different order to some elements > than required by the schema. > > Not sure if these were turned around in the xsd at some stage maybe? > While I don't really understand why these elements need to have an > order, I believe the problem in the XML serialiser is quite easy to fix. > > Is anybody maintaining this code at present? Otherwise I can have a go. > > Regards > Sebastian > > > Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: >> Hello everyone >> >> Maybe there has been some intermediate change that i am missing here but >> i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" >> (downloaded as XML from the CKM editor today) through the available XSDs >> from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and >> i am getting a very large number of errors. >> >> Just as an indication, all the errors are "Invalid content was found" >> mostly for the elements "existence" and "lower_included" (expecting >> "rm_attribute_name" and "lower_unbounded" respectively) >> >> Are there different XSDs for the structure of the CKM XML files? And if >> yes, are they available? >> >> Looking forward to hearing from you >> Athanasios Anastasiou >> >> P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead >> of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was >> "BaseTypes.xsd" in version 1.0). It seems that the intention is to >> preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" >> reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it makes >> a difference for case sensitive file systems :-) >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hi Rong, I'm working on this; an AOM to JAXB binding. I'm hoping that I'll be able to give more details in a couple of weeks. Regards Seref On Tue, Sep 6, 2011 at 10:34 AM, Rong Chen wrote: > Hi Sebastian, > To my knowledge, no one is maintaining the AOM xml-serialiser from the Java > Reference Project at the moment. So I would appreciate if you could fix it > this time. > Actually the larger issue about xml-serialiser is that it's not relying on a > java XML binding API. This makes it vulnarable to changes in the archetype > XML schema. > There is already a xml-binding component that provides XML parsing and > serialising based on RM XML schema. One just needs to implement a mapping > between the classes from ?openehr-aom component and the generated XML > binding classes in order to have XML schema based parsing and serialising. > This is probably the best way to go. > Cheers, > Rong > On 6 September 2011 10:53, Sebastian Garde > wrote: >> >> Hi >> >> CKM is using the XML serialiser of the openEHR Java Reference >> implementation. >> >> It seems that the serialiser applies a different order to some elements >> than required by the schema. >> >> Not sure if these were turned around in the xsd at some stage maybe? >> While I don't really understand why these elements need to have an >> order, I believe the problem in the XML serialiser is quite easy to fix. >> >> Is anybody maintaining this code at present? Otherwise I can have a go. >> >> Regards >> Sebastian >> >> >> Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: >> > Hello everyone >> > >> > Maybe there has been some intermediate change that i am missing here but >> > i am trying to validate "openEHR-EHR-OBSERVATION.blood_pressure.v1.xml" >> > (downloaded as XML from the CKM editor today) through the available XSDs >> > from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and >> > i am getting a very large number of errors. >> > >> > Just as an indication, all the errors are "Invalid content was found" >> > mostly for the elements "existence" and "lower_included" (expecting >> > "rm_attribute_name" and "lower_unbounded" respectively) >> > >> > Are there different XSDs for the structure of the CKM XML files? And if >> > yes, are they available? >> > >> > Looking forward to hearing from you >> > Athanasios Anastasiou >> > >> > P.S. Just as a note, "Resource.xsd" references "basetypes.xsd" instead >> > of "BaseTypes.xsd" in both 1.0.1 and 1.0.2 versions (while it was >> > "BaseTypes.xsd" in version 1.0). It seems that the intention is to >> > preserve the letter case (e.g. the "Resource.xsd" and "Structure.xsd" >> > reference "BaseTypes.xsd"). It's a tiny thing but, as you know, it makes >> > a difference for case sensitive file systems :-) >> > >> > >> > >> > ___ >> > 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 Transition: two procedural and one licensing question
Hi Pablo, I agree with your and Diego's suggested change. That was the intended meaning of the original statement but yours expresses this more clearly. I was just interested in Diego's actual experience with the CKM web-services as the basis for a generic API. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 6 September 2011 00:11, pablo pazos wrote: > Hi, > > I think Diego's point is to change this "... directly interacting with the > Clinical Knowledge Manager and equivalent repository and review tools"to > something like "... to interact with any Clinical Knowledge Manager through > a standard API (to be defined)". > > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez > Blog: http://informatica-medica.blogspot.com/ > Twitter: http://twitter.com/ppazos > > > Date: Mon, 5 Sep 2011 21:49:01 +0100 > Subject: Re: openEHR Transition: two procedural and one licensing question > From: Ian.McNicoll at oceaninformatics.com > To: openehr-technical at openehr.org > > Hi Diego, > > I understand from Sebastian that you have been exploring the current CKM web > services. ?Do you think these might form the basis for an open repository > API or do you have any other comments or alternative suggestions? > > Ian > > On Monday, 5 September 2011, Sam Heard > wrote: >> Thanks Diego >> >> [Sam Heard] ?This would be a step forward and would allow for slim and fat >> systems to offer the same basic calls. >> >>> > My suggestion is for the this point >>> "Begin an open source software project for tools, web-based if >>> possible, to author archetypes, templates and terminology reference >>> sets directly interacting with the Clinical Knowledge Manager and >>> equivalent repository and review tools" >>> >>> I agree with the first part (create web-based open source tools), but >>> I think that the second part should be clarified. We should define a >>> basic API to access repositories, to avoid doing ad-hoc >>> implementations for each one of the possible repositories >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant,?Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care ?www.phcsg.org > > > ___ 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 Transition: two procedural and one licensing question
Thanks Diego [Sam Heard] This would be a step forward and would allow for slim and fat systems to offer the same basic calls. > > My suggestion is for the this point > "Begin an open source software project for tools, web-based if > possible, to author archetypes, templates and terminology reference > sets directly interacting with the Clinical Knowledge Manager and > equivalent repository and review tools" > > I agree with the first part (create web-based open source tools), but > I think that the second part should be clarified. We should define a > basic API to access repositories, to avoid doing ad-hoc > implementations for each one of the possible repositories
openEHR Transition: two procedural and one licensing question
ng things to discuss and clarify in the white paper, but let's start here :-) Again, thanks for working towards a more understandable openEHR foundation. [Sam Heard] Thank you Eric Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/34910c4f/attachment.html>
openEHR Transition: two procedural and one licensing question
In my experience. you only need 2 or 3 CKM web services: search (with different kinds of search) & download. I think those two are really basic, and are also the ones that every repository must have (and depending on the application, those are enough). Some of the other web services (like freemind generation) are useful, but I wouldn't put them in a generic API. 2011/9/5 Ian McNicoll : > Hi Diego, > > I understand from Sebastian that you have been exploring the current CKM web > services. ?Do you think these might form the basis for an open repository > API or do you have any other comments or alternative suggestions? > > Ian > > On Monday, 5 September 2011, Sam Heard > wrote: >> Thanks Diego >> >> [Sam Heard] ?This would be a step forward and would allow for slim and fat >> systems to offer the same basic calls. >> >>> > My suggestion is for the this point >>> "Begin an open source software project for tools, web-based if >>> possible, to author archetypes, templates and terminology reference >>> sets directly interacting with the Clinical Knowledge Manager and >>> equivalent repository and review tools" >>> >>> I agree with the first part (create web-based open source tools), but >>> I think that the second part should be clarified. We should define a >>> basic API to access repositories, to avoid doing ad-hoc >>> implementations for each one of the possible repositories >> >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant,?Ocean Informatics, UK > openEHR Clinical Knowledge Editor www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care ?www.phcsg.org > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
