Archetype Naming proposals - do we need V0?
Hi Ian, I would prefer https://github.com/flazz/semver/ , but not explain :) CKM shows archetype revision history tree, but the version is not changed. For example, openEHR-EHR-OBSERVATION.blood_pressure version has been kept 1 in these years, but it has 26 revision up. I think it is non-sense to change version by each revision commit, but meaningful change should be reflected to the version number, such as adding item, fixed typo, translation to other language completed. Shinji 2014-10-01 23:05 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, Github is your friend - see https://github.com/npm/node-semver but I agree, it is tricky. However it is simply not possible to manage the transition between stable and published archetypes safely by just using numbering alone. We need to very explicitly flag that unstable state so that it can be parsed safely - this is what the '-' gives us. We did look at all sort of numbering schemes and alternatives to Semver but eventually came back to the view that this is pretty well how it has to work. One big advantage of sticking with Semver is that we can take advantage of work like the NPM parser, apart from the The 'exclusive revision history' (if I understand you correctly) comes from the Build identifier, identified by a '+' So an unstable archetype may be v1.0.1-unstable+145567345 and after some internal authoring or reviewing goes to v1.0.1-unstable+35634512 The build identifier is not guaranteed to be sequential and there may well be breaking changes between the first and second iteration. From the developer perspective I can know exactly which build of the archetype I am using in my system, and that it is unstable. I would be very unwise to use this in any production system but may of course need it in a testing phase, or need to support its use within tooling. I am not wedded to -unstable , but I think you will find that if you try to work with some other number=based system, you always hit a problem ,and that some kind of pre-release signifier is required. If we agreed that openEHR would only officially support -unstable (or -alpha) and -rc, that would greatly simplify the parsing. Ian Ian Implementers do not have to parse what comes next On 1 October 2014 14:34, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Ian. I have read once SemVer, but it is still confusing about suffix. especially alpha.11 alpha.beta beta.1 sequence. This needs tricky grammar rule to parse. Hi Sebastian, I think revision history should be exclusive, even it is unstable version. Regards, Shinji 2014-10-01 21:26 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, Can I suggest you read the semver.org specifications? Semver is now used pretty widely in systems and tooling (including the nodeJS Package Manager NPM). We have taken the - suffix directly from those specifications and in other respcts we are now following semver exactly so there should be open source parsers out there that can be used. Semver exists because we have to treat semantic specifications differently from normal software builds. In normal software alpha, beta, pre-release and indeed the numbering chosen do not need to have any computable significance. Windows 9 is only called Windows 9 for marketing reasons ,not because it represents a breaking change. My recent Yosemite Beta 3- Beta 4 update may make all sorts of breaking changes but is still a Beta and appears to be only a build different from the Developer Pre-release Yosemite candidate. When we are dealing with Semantic artefacts such as APIs or archetypes, the numbering scheme and suffixes have very specific meanings and rules, to do with backward compatibility. The -suffix is necessary to make it very clear that this is a pre-release artefact and that the normal versioning rules do not apply. What comes after the suffix does not really matter and The prime responsibility we have as archetype authors is to make sure that developers know whether they are working with a stable, published archetype which has followed the versioning rules, or an unstable archetype where those rules are temporarily suspended. It is impossible to do this clearly with a numbering schema alone which is why the - suffix is well-established in SemVer and the tools which use it. In normal circumstances unstable archetypes would never be used in production systems. Ian On 1 October 2014 13:04, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Ian, I prefer V0, because it would be easier to adopt for other developers who do not know openEHR well. For parser implementation, 1.0.0-unstable is not a good design, because it is not clear that which is the later release amongs, unstable, testing, pre-release, release-candidate, draft, etc... I would suggest 0.9.9 instead of 1.0.0-unstable. We can
Archetype Naming proposals - do we need V0?
Sorry, I have misused exclusive to explicit. It is explicit mistake. much sorry to confusing you. Shinji ashamed. 2014-10-02 0:02 GMT+09:00 Shinji KOBAYASHI skoba at moss.gr.jp: Hi Ian, I would prefer https://github.com/flazz/semver/ , but not explain :) CKM shows archetype revision history tree, but the version is not changed. For example, openEHR-EHR-OBSERVATION.blood_pressure version has been kept 1 in these years, but it has 26 revision up. I think it is non-sense to change version by each revision commit, but meaningful change should be reflected to the version number, such as adding item, fixed typo, translation to other language completed. Shinji 2014-10-01 23:05 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, Github is your friend - see https://github.com/npm/node-semver but I agree, it is tricky. However it is simply not possible to manage the transition between stable and published archetypes safely by just using numbering alone. We need to very explicitly flag that unstable state so that it can be parsed safely - this is what the '-' gives us. We did look at all sort of numbering schemes and alternatives to Semver but eventually came back to the view that this is pretty well how it has to work. One big advantage of sticking with Semver is that we can take advantage of work like the NPM parser, apart from the The 'exclusive revision history' (if I understand you correctly) comes from the Build identifier, identified by a '+' So an unstable archetype may be v1.0.1-unstable+145567345 and after some internal authoring or reviewing goes to v1.0.1-unstable+35634512 The build identifier is not guaranteed to be sequential and there may well be breaking changes between the first and second iteration. From the developer perspective I can know exactly which build of the archetype I am using in my system, and that it is unstable. I would be very unwise to use this in any production system but may of course need it in a testing phase, or need to support its use within tooling. I am not wedded to -unstable , but I think you will find that if you try to work with some other number=based system, you always hit a problem ,and that some kind of pre-release signifier is required. If we agreed that openEHR would only officially support -unstable (or -alpha) and -rc, that would greatly simplify the parsing. Ian Ian Implementers do not have to parse what comes next On 1 October 2014 14:34, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Ian. I have read once SemVer, but it is still confusing about suffix. especially alpha.11 alpha.beta beta.1 sequence. This needs tricky grammar rule to parse. Hi Sebastian, I think revision history should be exclusive, even it is unstable version. Regards, Shinji 2014-10-01 21:26 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, Can I suggest you read the semver.org specifications? Semver is now used pretty widely in systems and tooling (including the nodeJS Package Manager NPM). We have taken the - suffix directly from those specifications and in other respcts we are now following semver exactly so there should be open source parsers out there that can be used. Semver exists because we have to treat semantic specifications differently from normal software builds. In normal software alpha, beta, pre-release and indeed the numbering chosen do not need to have any computable significance. Windows 9 is only called Windows 9 for marketing reasons ,not because it represents a breaking change. My recent Yosemite Beta 3- Beta 4 update may make all sorts of breaking changes but is still a Beta and appears to be only a build different from the Developer Pre-release Yosemite candidate. When we are dealing with Semantic artefacts such as APIs or archetypes, the numbering scheme and suffixes have very specific meanings and rules, to do with backward compatibility. The -suffix is necessary to make it very clear that this is a pre-release artefact and that the normal versioning rules do not apply. What comes after the suffix does not really matter and The prime responsibility we have as archetype authors is to make sure that developers know whether they are working with a stable, published archetype which has followed the versioning rules, or an unstable archetype where those rules are temporarily suspended. It is impossible to do this clearly with a numbering schema alone which is why the - suffix is well-established in SemVer and the tools which use it. In normal circumstances unstable archetypes would never be used in production systems. Ian On 1 October 2014 13:04, Shinji KOBAYASHI skoba at moss.gr.jp wrote: Hi Ian, I prefer V0, because it would be easier to adopt for other developers who do not know openEHR well. For parser implementation, 1.0.0-unstable is not a good design,
Archetype Naming proposals - do we need V0?
Hi Ian and Sebastian, The rule figured by Sebastian and the explanation by Ian looks very clear, thank you. But we will need to additional rule/guide to make it clear what is 'major' or 'minor', in the next step. For example, if the archetype was converted from ADL 1.4 to 1.5(or later), is this minor change or major change? ADL conversion may break compatibility for machine readability, but not change in clinical semantics. If an archetype was changed to be semantically incompatible, I think they should not be assigned for same archetype id. regards, Shinji 2014-10-02 1:16 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, For clarity ... CKM 'revisions' have nothing to do with the official openEHR major.minor.path numbers. They are an internal format to do with the local workflows inherit in openEHR. We have discussed changing CKM 'revision' to something else to make this clearer. The official major.minor.patch number proposals are intended to be neutral to the use of CKM or any other repository tool, even the use of a simple Git repo, and make no assumptions about how the assets are organised within that repo e.g a git-based repo may have a quite different Trunk/branching method and use branch names/ tags to handle internal workflow. The aim of the openEHR major.minor.patch scheme is to ensure that where an archetype is used outside of a repo, in tooling or in applications, that the consumer can be very confident about the exact provenance of the archetype and especially its stability. So ignore what CKM does internally, that is not important in this context. In the future each archetype in CKM (and we hope other controlled repos) will also label every asset and version of the asset using major.minor.patch -XX + build, alongside what ever local internal versioning scheme they require. Ian On 1 October 2014 17:00, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: On 01.10.2014 17:02, Shinji KOBAYASHI wrote: Hi Ian, I would prefer https://github.com/flazz/semver/ , but not explain :) CKM shows archetype revision history tree, but the version is not changed. For example, openEHR-EHR-OBSERVATION.blood_pressure version has been kept 1 in these years, but it has 26 revision up. I think it is non-sense to change version by each revision commit, but meaningful change should be reflected to the version number, such as adding item, fixed typo, translation to other language completed. Hi Shinji, With the new revision rules a la SemVer we now have: The major version would change with an incompatible change (=the current v1, v2, etc identifier) The minor version for a compatible change which could change the meaning even if only slightly The patch version for e.g. fixing a typo in a translation. There are some grey areas, but the intention is clear I think. In CKM, you can do this with the new revision rules. CKM will suggest a new revision number based on this general idea. In any case you can always go higher - if you think a patch change is so significant because of the wording that has changed, it can also be a minor (or even major) version increase, i.e. instead of going from v1.0.0 to v1.0.1, you go to v1.1.0 To take the example of the BP archetype that you mention: The archetype was published in Rev 16 in 2009. Since then it has encountered several more changes to it like adding a couple of translations. None of these would be a breaking change to my knowledge. So, in the old rules it just remains v1. With the new revision rules, the archetype would have been published as v1.0.0 in 2009 and would now maybe be v1.2.4 (or whatever) - which means it had a number of patches and 2 minor version changes in total, none of them backwardly incompatible. Is this the kind of stuff you are missing? If so, this is exactly what the revisioning rules are there for. Cheers Sebastian Shinji 2014-10-01 23:05 GMT+09:00 Ian McNicoll ian at mcmi.co.uk: Hi Shinji, Github is your friend - see https://github.com/npm/node-semver but I agree, it is tricky. However it is simply not possible to manage the transition between stable and published archetypes safely by just using numbering alone. We need to very explicitly flag that unstable state so that it can be parsed safely - this is what the '-' gives us. We did look at all sort of numbering schemes and alternatives to Semver but eventually came back to the view that this is pretty well how it has to work. One big advantage of sticking with Semver is that we can take advantage of work like the NPM parser, apart from the The 'exclusive revision history' (if I understand you correctly) comes from the Build identifier, identified by a '+' So an unstable archetype may be v1.0.1-unstable+145567345 and after some internal authoring or reviewing goes to v1.0.1-unstable+35634512 The build identifier is not guaranteed to be sequential and there may well be
Archetype Naming proposals - do we need V0?
On 01/10/2014 16:44, Sebastian Garde wrote: Hi Sebastian, I realise you are physically not too far away from me in Germany and we even share the same name, so I hope you won't shoot the messenger here, but I have to say the following... The consequence of what you are saying would be that we cannot publish any v1 archetype if it is already on CKM without an analysis if there have been any breaking changes anywhere during the development and review process (which would be the case in most cases I suspect). However, this is the case with or without any of the changes being discussed here: It doesn't matter if draft archetypes become v0 for a while: once they are published they'd be v1 again anyway - and likely incompatible with the previous v1. but none of the existing CKM archetype ids has a namespace, so the new ids will be distinguishable from the old. It would be useful to have some real data on who has used any CKM draft (i.e. 'old') archetypes in real systems to know is there is in fact a problem here or not. Anyway, the renaming should follow the model: openEHR-EHR-ADMIN_ENTRY.encounter.v1 = *org.openEHR::*openEHR-EHR-ADMIN_ENTRY.encounter.*v0.0.1* = review changes = *org.openEHR::*openEHR-EHR-ADMIN_ENTRY.encounter.*v1.0.0* so there is no way for the first and last versions to get mixed up that I can see. If on the other hand, you leave the CKM draft archetypes as v1 and they are published subsequently, there is also no guarantee whatsoever that the published version is compatible with any draft revision (or any of the draft revisions with each other). Either way, if you use them now, no, you cannot just replace a draft archetype with the next revision of the draft archetype or its subsequently published revision. You cannot do it now, because there is no guarantee that they'd be compatible and you cannot do it with or without v0. So, while I certainly acknowledge the problem (more below), it is not a problem that is caused or increased by migrating draft archetypes to v0. And in fact solving this problem is one of the core reasons for the proposed revisioning rules. You will know exactly where you are at and how compatible two archetypes are. So, if you as a company use draft archetypes, this is the risk you have taken - draft archetypes just cannot be assumed stable or backwardly compatible just because they happen to be expressed in (more or less) correct ADL. The impression that draft archetypes are stable has of course been given by the lack of activity in getting draft archetypes published on the international CKM. The industry sprint will hopefully change the momentum of this considerably. The problem you describe is more or less the same for every vendor that uses unstable archetypes, which for lack of alternatives, will most likely be about every vendor. However, I can see some ideas for a solution to this problem, because you can clearly identify all archetypes under the new revisioning rules vs those that are not. Most importantly, archetypes under the proposed revisioning scheme will have a namespace whereas the old ones don't. ah, you got there before me ;-) - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/4878baf3/attachment.html
Licensing of specs and artifacts
Thanks Silje, that you bring this very important subject under attention. It was already under attention recently on a LinkedIn discussion, but I am afraid it did not reach the right people. I do agree with your point of view, so there is not much discussion, there is only one small remark. I don't see any point in retaining the CC-BY-SA license, with extra clause. First, CC-BY-SA prevents the secret proprietary use of OpenEHR-archetypes, in industry this can be a reason not to use OpenEHR. Except from that, CC-BY-SA is not by everyone understood and is a source of FUD (Fear, Uncertainty, Doubt), even with extra clause, it will remain a source of FUD. For information the link to the LinkedEhr discussion, I hope it works https://www.linkedin.com/groups/Membership-144276%2ES%2E5909661200660054019?trk=groups_most_popular-0-b-ttlgoback=%2Egde_144276_member_5909661200660054019%2Egmp_144276 Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: Hi everyone, In light of the recent re-licensing of FHIR http://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meeting http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I?d like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivatives http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alike http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I?m bound to have forgot some issues: CC-BY-ND (for specs): ?Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as ?openEHR?. CC-BY-SA (for artefacts): ?Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any /published/ modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can?t rely 100% on. The way I see it, this problem could be solved in one of two ways: oUse the CC-BY license, which retains the attribution clause, but doesn?t require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. oRetain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it?d send them a strong signal. Kind regards, *Silje Ljosland Bakke* Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/98dfc483/attachment.html
Licensing of specs and artifacts
For information the link to the LinkedEhr discussion, I hope it works Of course, this should be: LinkedIN ;-) (sorry David) Best regards Bert Verhees On 01-10-14 17:02, Bakke, Silje Ljosland wrote: Hi everyone, In light of the recent re-licensing of FHIR http://www.healthintersections.com.au/?p=2248 using the Creative Commons CC0 Public Domain Dedication as well as the discussion about licensing at the 2014 openEHR Roadmap Meeting http://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting in Lillestr?m on September 16 and 17, I?d like to restart the discussion on licensing of openEHR specifications and artefacts (mainly archetypes, but also potentially templates and terminology sets). As of now, the specifications are licensed using the Creative Commons Attribution No-Derivatives http://creativecommons.org/licenses/by-nd/3.0/ (CC-B-ND) license, while the Creative Commons Attribution Share-Alike http://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used for artefacts. Several issues have been raised about this choice of licences. Feel free to add to this list, I?m bound to have forgot some issues: CC-BY-ND (for specs): ?Theoretically, a hostile takeover of the openEHR Foundation might leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder (the Foundation) has the rights to modify them. A forkable license like for instance CC-BY-SA would solve this issue. Global registering of the openEHR trademark would keep any derivates to be branded as ?openEHR?. CC-BY-SA (for artefacts): ?Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any /published/ modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can?t rely 100% on. The way I see it, this problem could be solved in one of two ways: oUse the CC-BY license, which retains the attribution clause, but doesn?t require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. oRetain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the CC+ https://wiki.creativecommons.org/CCPlus protocol. I realise these issues will ultimately be decided by the board of the openEHR Foundation, but if the community can come to some kind of consensus on this issue I would hope it?d send them a strong signal. Kind regards, *Silje Ljosland Bakke* Coordinator, National Editorial Board for Archetypes, National ICT Norway Adviser, RD dept, E-health section, Bergen Hospital Trust Tel. +47 40203298 ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/26c7bb0b/attachment-0001.html
Licensing of specs and artifacts
40203298 ___ openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/0b423b40/attachment.html
Archetype Naming proposals - do we need V0?
(as they are right now in fact ;-) * I don't see the problem with v0 references in templates, since it's the same problem between any major version. An archetype .v0.x can't be assumed to be compatible with .v1.y - as for other major versions, we treat them technically as different archetypes. So either the template reference is v* (any major version you like) or it isn't, in which case it points to a known major version - v0, v1, v2 or other. o we should assume that future tools will make it easy to change these template references - it won't be difficult to do. Sure, looking forward to tooling support on it, but realistically at the moment it is a pain that is not needed for the first publication if you go with v1 as a the initial major version. well I think its a bigger danger, given the level of reuse of CKM archetypes, that the version ids wouldn't correct reflect the state of the archetypes. We could in theory revert everything that is not published to v0 right now, and i guess that is breaking the rules for less time. But there are still some dozens of fully reviewed and published archetypes that have to retain their v1.x version anyway. So I think the only question is to do with the industry sprint archetypes. How about doing this: * mark archetypes that have never been 'published' and are not in the industry sprint as v0.5.0 * mark the industry sprint archetypes as v1.0.0-unstable * leave currently published archetypes on v1.x, i.e. where they are today. If I receive a copy of archetypes marked like that in say the GitHub mirror, or through a different CKM, I don't need any further education, it's obvious what's going on. - thomas ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/133763c7/attachment-0001.html
Archetype Naming proposals - do we need V0?
I agree with your points. I would say that some of your points are the reasons people is reluctant in adopting openEHR more. It's not all about licenses. It has always puzzled me why there is not a single v2 archetype in CKM after 7 years. 2014-10-02 9:17 GMT+02:00 Sebastian Iancu sebastian at code24.nl: Hi Sebastian G, David M, Thank you for your elaborate answers. I can proudly say, years ago, we were one of the early adopters of openEHR. We've been there (in fact actively participating) when the CAM-hash was introduced, or when .v1draft was replaced with .v1, or when the archetype_id versioning policy was polished, or when Thomas started to work on distributed knowledge management and artefact identification. I'm not a stranger to the fact that CKM archetypes are changing without having their version updated, sometimes breaking existing specifications. I also acknowledge the benefits of the industry-sprint, and that we need clearing things out in CKM content for that. Finally, as technician, I'm aware of the impact of using 'draft'-like artefacts in own software. But, I cannot agree with a mass regression to v0: What's the point of having this boolean logic where draft=0, stable=1? Are we never going to have v2? And if yes, would that mean something (published-on-Mars-aswell, or sprint-2)? The version itself should not be important (we can have v1 or v87), it matters only in relation with other versions and a timeline. There are already released specification about versioning, so why violate them doing odd regression? There is no guaranty that all current drafts will be published some day - in which case we might be stuck with v0, while v1 was already available up to 2014. Why should we destroy something that already exists and it works? We know CKM content is not perfect, archetype changes are not fully considered in their version - why should we create even more mess? Furthermore, for my point of view: you hardly get early adopters if you discourage them to use 'draft' archetypes an archetype uploaded on CKM is in fact sort-of technically published, although not domain-published. Breaking it constantly makes it unusable and lowers the adoption or real-life testing chances. encouraging vendors or consumers to use their own archetype repositories (own namespaces) as opposed to a global own (CKM) is a threat to interoperability, and defies some of the openEHR principles. In conclusion, I'm not at all against the new versioning identification, discussed these days (i.e v1.2.3, etc), as long as it is introduced only in/for upcoming specifications (ADL 1.5, 2.0 whatever) and it is not breaking existing systems based on RM 1.0.2 and ADL 1.4 archetypes. Keep things simpler and don't focus too much on only syncing with semver, while you forget the big picture where these archetypes are actually used for (namely to describe data). Sebastian Code24 On 10/1/2014 5:44 PM, Sebastian Garde wrote: Hi Sebastian, I realise you are physically not too far away from me in Germany and we even share the same name, so I hope you won't shoot the messenger here, but I have to say the following... The consequence of what you are saying would be that we cannot publish any v1 archetype if it is already on CKM without an analysis if there have been any breaking changes anywhere during the development and review process (which would be the case in most cases I suspect). However, this is the case with or without any of the changes being discussed here: It doesn't matter if draft archetypes become v0 for a while: once they are published they'd be v1 again anyway - and likely incompatible with the previous v1. If on the other hand, you leave the CKM draft archetypes as v1 and they are published subsequently, there is also no guarantee whatsoever that the published version is compatible with any draft revision (or any of the draft revisions with each other). Either way, if you use them now, no, you cannot just replace a draft archetype with the next revision of the draft archetype or its subsequently published revision. You cannot do it now, because there is no guarantee that they'd be compatible and you cannot do it with or without v0. So, while I certainly acknowledge the problem (more below), it is not a problem that is caused or increased by migrating draft archetypes to v0. And in fact solving this problem is one of the core reasons for the proposed revisioning rules. You will know exactly where you are at and how compatible two archetypes are. So, if you as a company use draft archetypes, this is the risk you have taken - draft archetypes just cannot be assumed stable or backwardly compatible just because they happen to be expressed in (more or less) correct ADL. The impression that draft archetypes are stable has of course been given by the lack of activity in getting draft archetypes published on the international CKM. The
Licensing of specs and artifacts
text of CC-BY-SA 4.0 http://creativecommons.org/licenses/by-sa/4.0/, the impression it gives is quite different from (my reading of) the legal code! It says: * *ShareAlike*--- If you remix, transform, or build upon the material, you must distribute your contributions under thesame license http://creativecommons.org/licenses/by-sa/4.0/#as the original. That gives the impression that if you make a changed version of a source work, you have to share your result. But in fact it is trying to say that IF you openly share the modified source work (not the final result), you must share with the same license as the source work itself. I think the short form of this licence is one of the problems here - it makes it look like you have to share derivative material, but that's not the case. The licence in fact just prevents you from sharing derivative material under a different licence, and without proper attribution. - thomas On 02/10/2014 08:00, David Moner wrote: Hahaha, it's good you always have LinkEHR in mind ;-) By the way, this is certainly an old and recurring topic. I have checked that there were already discussions back in 2009, so probably we are going to repeat things already commented. I will talk about artefacts (archetypes). The first thing to solve in my opinion is to agree on what does derivative work mean for an archetype. Is just modified archetypes? Auto-generated data base schemas, validation schematron or other technical artefacts? Documentation describing the archetype? I would love to say that only the first case applies, but let's thing in an example. Which is the license for a movie you make from a CC-BY-SA book? It is for sure a derivative work, and the Title 17 Section 101 of the Copyright Act of the United States says it very clear: A derivative work is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a derivative work. (http://www.law.cornell.edu/uscode/text/17/101) Given that definition I don't think a technical transformation of an archetype is a different case. So yes, I'm not a lawyer, but I would say that fears of implementers of commercial products using openEHR archetypes are reasonable if the the CC-BY-SA license is applied as is. David -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/de2da903/attachment-0001.html
Licensing of specs and artifacts
2014-10-02 10:03 GMT+02:00 Thomas Beale thomas.beale at oceaninformatics.com: I think the key things to remember in resolving this are how the various artefacts get used, which helps figure where 'adaptation' actually exists. I can think of the following: - archetype = template = software application - the simplest standard practice - this is USE not ADAPTATION - archetype = specialise = template = software application - the next simplest standard practice - this is USE not ADAPTATION - archetype = software application - not a great idea in general - it means that the 'archetypes' are not really maximal re-usable data sets, but something like predefined templates. However, someone is bound to do this, and produce a good product from it. - this is USE not ADAPTATION - archetype = forking = modification = templating = software application - Result: probably non-interoperable data; but may occur for pragmatic reasons, e.g. openEHR is too slow to make fixes to the archetype. - this is ADAPTATION According to the CC-BY-SA 4.0 licence text only the last of these paths means that the final software or other result is an 'adaptation' of the original archetype, which means that the CC-BY-SA license applies, IF YOU PUBLICLY SHARE THE ARTEFACT. Just to be clear, I repeat that that is exactly what I would like to interpret. But if I read the legal texts trying to be objective (and again, not being a lawyer!) it is normal that doubts arise. If I generate a validation software that includes validation rules from the archetype constraints, that is arguably an adaptation, not just a use. And it is also important to note that if you sell a software you are also publicly sharing it. Publicly share does not imply for free, but outside of a personal use. I fully support the comments of Grahame. Probably the solution is to go just for the simpler option and don't worry about what others do with their own business. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/b357fa49/attachment.html
Archetype Naming proposals - do we need V0?
years (at least in our case). Changing them now on CKM will break logical binding with already existing production data. This cost has to be eventually supported by industry implementers, and I can assure you this is not trivial, and it is giving the impression that openEHR standard is not reliable/stable enough. Basically the proposal is to rename existing CKM archetypes (published or not) in contradiction with what the current openEHR specifications is stating right now, which is not right. Other than this, I personally think that is nice to have v0 for 'drafts', and v1 for stable-published; it might be a better indication about a state of an archetype. So my suggestion is to keep existing CKM archetypes the way they are and only apply the new 'rule' for archetypes created from now one. Published archetypes from the sprint can become v2 (or 3, 4 etc) depends on the need (see specifications). Sebastian Code24 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/ebbd8c98/attachment-0001.html
Archetype Naming proposals - do we need V0?
Hi Diego, There will be a v2 very soon. It will be the first of the small number of published archetypes that has had backwardly incompatible changes required. It is Indirect Oximetry which will go out for further review next week, but we already have had a breaking error identified. Regards Heather -Original Message- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Diego Bosc? Sent: Thursday, 2 October 2014 5:48 PM To: For openEHR technical discussions Cc: For openEHR clinical discussions Subject: Re: Archetype Naming proposals - do we need V0? I agree with your points. I would say that some of your points are the reasons people is reluctant in adopting openEHR more. It's not all about licenses. It has always puzzled me why there is not a single v2 archetype in CKM after 7 years. 2014-10-02 9:17 GMT+02:00 Sebastian Iancu sebastian at code24.nl: Hi Sebastian G, David M, Thank you for your elaborate answers. I can proudly say, years ago, we were one of the early adopters of openEHR. We've been there (in fact actively participating) when the CAM-hash was introduced, or when .v1draft was replaced with .v1, or when the archetype_id versioning policy was polished, or when Thomas started to work on distributed knowledge management and artefact identification. I'm not a stranger to the fact that CKM archetypes are changing without having their version updated, sometimes breaking existing specifications. I also acknowledge the benefits of the industry-sprint, and that we need clearing things out in CKM content for that. Finally, as technician, I'm aware of the impact of using 'draft'-like artefacts in own software. But, I cannot agree with a mass regression to v0: What's the point of having this boolean logic where draft=0, stable=1? Are we never going to have v2? And if yes, would that mean something (published-on-Mars-aswell, or sprint-2)? The version itself should not be important (we can have v1 or v87), it matters only in relation with other versions and a timeline. There are already released specification about versioning, so why violate them doing odd regression? There is no guaranty that all current drafts will be published some day - in which case we might be stuck with v0, while v1 was already available up to 2014. Why should we destroy something that already exists and it works? We know CKM content is not perfect, archetype changes are not fully considered in their version - why should we create even more mess? Furthermore, for my point of view: you hardly get early adopters if you discourage them to use 'draft' archetypes an archetype uploaded on CKM is in fact sort-of technically published, although not domain-published. Breaking it constantly makes it unusable and lowers the adoption or real-life testing chances. encouraging vendors or consumers to use their own archetype repositories (own namespaces) as opposed to a global own (CKM) is a threat to interoperability, and defies some of the openEHR principles. In conclusion, I'm not at all against the new versioning identification, discussed these days (i.e v1.2.3, etc), as long as it is introduced only in/for upcoming specifications (ADL 1.5, 2.0 whatever) and it is not breaking existing systems based on RM 1.0.2 and ADL 1.4 archetypes. Keep things simpler and don't focus too much on only syncing with semver, while you forget the big picture where these archetypes are actually used for (namely to describe data). Sebastian Code24 On 10/1/2014 5:44 PM, Sebastian Garde wrote: Hi Sebastian, I realise you are physically not too far away from me in Germany and we even share the same name, so I hope you won't shoot the messenger here, but I have to say the following... The consequence of what you are saying would be that we cannot publish any v1 archetype if it is already on CKM without an analysis if there have been any breaking changes anywhere during the development and review process (which would be the case in most cases I suspect). However, this is the case with or without any of the changes being discussed here: It doesn't matter if draft archetypes become v0 for a while: once they are published they'd be v1 again anyway - and likely incompatible with the previous v1. If on the other hand, you leave the CKM draft archetypes as v1 and they are published subsequently, there is also no guarantee whatsoever that the published version is compatible with any draft revision (or any of the draft revisions with each other). Either way, if you use them now, no, you cannot just replace a draft archetype with the next revision of the draft archetype or its subsequently published revision. You cannot do it now, because there is no guarantee that they'd be compatible and you cannot do it with or without v0. So, while I certainly acknowledge the problem (more below), it is
Licensing of specs and artifacts
that W3C licensing disallows forks does not dictate that openEHR needs to go the same direction. Using only CC-BY or CC-0 on the specs might be a good FUD-killer, nobody then needs to trust that openEHR governance will stay fit in the future. If the openEHR organization gets overtaken or deadlocked, then forking can occur and progressive people/companies that want to develop new improved versions can do that (if they call the new thing something else than openEHR). Whether such possibilities put bad or healthy pressures on an organization is of course open to debate. W3C seems to see forking as a risk or consider themselves big/trusted enough to not get deadlocked/overtaken. Many open source projects on the other hand see forking-possibilities as a healthy emergency safeguard against potentially poor future governance/leadership. I agree with Bert in the Linkedin-discussion, that it will most likely be possible to continue creating openEHR-compatible software from currently published CC-BY-ND licensed specifications, even if there is a ?hostile takeover? or deadlock of the organization. Especially if all computable specification items (class definitions etc.) are released under Apache 2 license (I believe that is the current intention). What is published is already out there and free to use, it can never be taken back. The ND-clause mainly causes problems for those that in a deadlock/takeover situation want to fork the project and keep working on _new_ future/updated versions of the specification. What the ND actually in practice would protect openEHR against is less obvious to me though. Thus the ND only adds to the confusion/FUD without bringing any obvious big benefit. (W3C gets away with it though.) Compatibility issues are better managed through testing and certification than licensing. Licenses won?t stop errors, or non-conformance. Phew? amazing if you had the energy to read all the way down to here. Tom, regarding what it means to sell Share-Alike (SA) artifacts, I think you can compare that to http://www.gnu.org/philosophy/selling.html Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Li?: erik.sundvall at lio.se http://www.lio.se/itc/ http://www.lio.se/testbadd LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ On Thu, Oct 2, 2014 at 4:14 PM, Grahame Grieve grahame at healthintersections.com.au wrote: Controlling Conformance: CC-0 just means 'public domain', no copyright. How do you exert any kind of control (which you mention) over the conformance not being messed with? The point of a trademark is that you can control what the name means. We say that we define what conformance to FHIR means. We expect that conformance will be messed with - that's just how it works. But no one else is allowed to say what it means to be conformant to FHIR because hl7 owns that trademark Also, we don't assert any rights around copying, but that doesn't mean that hl7 isn't the recognised author. Copyright: I don't see any harm in having a copyright notice if the original author(ity) demands it, e.g. Nehta is like this. Copyright is kind of useless in the land of software and formal models anyway, it's the licence that counts. Well, the way I understand it, with FHIR now, someone can asset a copyright on a derived work, but they could not effectively enforce copyright provisions on the content they include from the FHIR spec. There might not be much left... Attribution: Current thinking has been that if archetypes are copyrighted to whomever, the licence-to-use would require attribution, which just means listing authors. I think the value here is that artefact users know that wide consultation and expertise went into the artefact. I don't think there's any relationship between attribution and copyright. We could choose to attribute if we wanted to. Actually, we do it at the spec level: http://hl7.org/implement/standards/fhir/credits.html#credits Would't that 'contributors' list disappear under the new FHIR approach? No, they're still the contributors. Grahame - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141002/af556f4a/attachment-0001.html
