Licensing of specs and artifacts
*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/20141003/9c241e12/attachment.html
Archetype Naming proposals - do we need V0?
Note that in AOM 1.5 (to be renamed AOM2) spec http://www.openehr.org/releases/trunk/architecture/am/aom1.5.pdf, the idea of fixed string 'ids' is gone. Multi-part ids are now generated functionally. See Fig 8 Right now, the functions interface_id and physical_id are defined a certain way, and they do include the 'v'. But other functions can be added. The only place I can think of where the full string id really matters is in ADL syntax. In all other syntax, it's in pieces. E.g. this is the JSON output from the current AWB for a flat archetype serialisation: I don't personally think it matters about having the 'v'. Although I fully agree that the anglo-centric nature of the internet (domain names, etc et) and IT in general (UML models are mostly published only in latin alphabet languages, and mostly english in multi-national orgs and standards orgs) is in one sense unfair, it's also a) there and b) useful in solving what could otherwise be protracted and useless debates on minutiae. The main reason to keep it is for backward compatibility in ADL texts; we could certainly define an 'id' function without it. - thomas On 03/10/2014 09:15, Bert Verhees wrote: On 03-10-14 01:36, Bert Verhees wrote: org.openehr:openehr-ehr-composition.something:1.0.0 It seems wise to me to not regard the version-indication as a part of the archetypeId, the same for the namespace. The archetypeId is to indicate what the conceptual contents of the archetype is about. The version does not changes this, so it should not be part of the archetypeId, the same for the namespace. This idea justifies the use of the colon between namespace and archetypeId and between version and archetypeId. It also makes the use of the v before the version unnecessary. V is a language-specific indication, v stands for version, and version is an English/Latin term. In Danish they say udgave, in Russian it is ??, in Hebrew: , in Arabic: , in Maori: putanga and in Chinese: ?? Wonderful tool, Google translate ;-) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/0a33dfcb/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: aehahefi.png Type: image/png Size: 40191 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/0a33dfcb/attachment-0002.png -- next part -- A non-text attachment was scrubbed... Name: ehigebbb.png Type: image/png Size: 18564 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/0a33dfcb/attachment-0003.png
Archetype Naming proposals - do we need V0?
On 03/10/2014 14:32, Bert Verhees wrote: Thanks for getting involved in this important discussion. I am on a plane and don't have ooportunity for a full answer but it is not as simple as u have suggested. Amongst other things You have to consider what happens to archetype numbering when the archetype has been published and goes back into review, at which point it is in an unstable state. More That is why you often see in addition to Semver-conventions some terms added. My bash-version for example is: GNU bash, version 4.3.11(1)-release, My Linux version is: 3.13.0-36-generic Most artefact producers have the need to communicate more then only the version-number. The discussion is if the version-number is the place to communicate this. Software too can become stable, unstable, unsafe, release, beta, without anything changed to the bits and bytes. But suppose it is: Suppose you have version 1.1.3-release, and then you have 1.1.3-unstable, which is later? You cannot tell. the latest rules that Ian and Sebastian have worked out would mean that if there was 1.1.3 released, then the next version of that archetype if it goes back to development is 1.1.4-unstable, i.e. at least the patch number has to be incremented. It could be that something more is incremented say 1.2.0-unstable. So I think this is pretty logical (and also pretty much the way we do it in software). - thomas
Archetype Naming proposals - do we need V0?
the situation of the archetypes in CKM. Then for every mirroring, copy, and reuse of what's in openEHR.org CKM, there is no need to educate anyone on anything - it's obvious what the situation is. So we are only talking about a limited period of time where the rules are being broken (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. - 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 listopenEHR-clinical at lists.openehr.orghttp://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 Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/e7c7e94d/attachment-0001.html
Archetype Naming proposals - do we need V0?
On 03/10/2014 16:40, Ian McNicoll wrote: When this published v1 archetype needs to go back into review it gets labelled as org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1-unstable+build.e34dgtj67856 or using the uid - 123rhturytu55634567.v.1.0.1-unstable+build.e34dgtj67856 Probably a side issue from Ian's main points, but I think that at the system interface (i.e. in any web service interfaces), we should stick to org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1 not UID-based archetype ids. Internal to the system, a translation might be done from the above id to e.g. an instance UID, or something entirely different, that the system wants to use. When AQL queries are built, and when data are shared between systems, the multi-axial id should be used - think of it as a safe symbolic id. Actual data can have whatever it likes as ids, as long as it can translate properly between what it uses internally and what the outside world uses. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/fdbd4fe8/attachment.html
Archetype Naming proposals - do we need V0?
On 03-10-14 18:36, Thomas Beale wrote: On 03/10/2014 16:40, Ian McNicoll wrote: When this published v1 archetype needs to go back into review it gets labelled as org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1-unstable+build.e34dgtj67856 or using the uid - 123rhturytu55634567.v.1.0.1-unstable+build.e34dgtj67856 Probably a side issue from Ian's main points, but I think that at the system interface (i.e. in any web service interfaces), we should stick to org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1 not UID-based archetype ids. Internal to the system, a translation might be done from the above id to e.g. an instance UID, or something entirely different, that the system wants to use. When AQL queries are built, and when data are shared between systems, the multi-axial id should be used - think of it as a safe symbolic id. Actual data can have whatever it likes as ids, as long as it can translate properly between what it uses internally and what the outside world uses. My main objection against MLHIM was always that it had UUID's as element-names. For a programmer this is not very nice. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/ad967ab4/attachment.html
Archetype Naming proposals - do we need V0?
On 03/10/2014 19:54, Bert Verhees wrote: The best solution is to decouple the version from the archetypeId. And also decouple the file and filename from the archetypeId. People are responsible for overwriting their documents in Word, or save a backup, if that is their choice. The same can go for the archetype-editors. All - please read my other post where I included some of the AOM spec, showing that the 'identifier' is actually multiple data parts, and the string 'ids' are computed. Something called an 'interface_id' is one of those things; that's just the multi-axial id with only the major version number, e.g. org.openehr::openEHR-EHR-CLUSTER.prescription.v1 This 'id' includes the major version number so that archetypes with breaking changes with respect to each other are treated as different archetypes, operationally. In the design environment, tools know that xxx.v1 and xxx.v2 are related. But that doesn't hold in the runtime environment. Filename is irrelevant, and has been freely choosable for 5-10 years in all archetype modelling tools that I know of. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141003/5b777801/attachment-0001.html
