Hi Bert, I agree with a lot of what you are saying here. The important bit is the AOM not the physical instantiation and I hope that the development of AML (Archetype Modelling Language) the UML extension that is being developed by our CIMI colleagues with guidance from Thomas, will help cement the idea that ADL is only one kind of representation.
Having said that, as a modeller, working with a wide variety of clients, the text file paradigm is very helpful. It means I can use industry standard approaches such a git/svn etc. It means I can pass the files to colleagues easily. I think it is interesting that the distributed governance approach required by open source environments has if anything, cemented the text file as the universal sharing format. In those terms I think we need to regard each archetype as a tiny software library package, rather than a single file. I completely agree that file names should not ever be regarded as the source of truth in terms of naming/numbering but having a filename which matches the internalID (or at least does not conflict) does help avoiding errors in practical authoring environments. I am very interested in harnessing the power of git to make archetype authoring/production environments easier to handle for people who are working with multiple projects and I think this will lead to an interesting discussion about filenaming / branching / tagging approaches. Perhaps something that is a mix of the archetypeID, a bit more like the SNOMED CT Fully specified Name and a more human narrative might be helpful. e.g. "Systemic Blood Pressure (Observation).1.0.0.json" I think this should be framed in terms of guidance, rather then fixed in the specifications, with a lot of optionality e.g re including version numbers. In some cases this can be helpful, in others not. Ian On 3 October 2014 19:54, Bert Verhees <bert.verhees at rosa.nl> wrote: > On 03-10-14 20:27, David Moner wrote: > > > > >> >> I would incorporate also an automatich versioning system, that every time >> an archetype changes, at least the path-number increments. You don't want >> that situation from the "drafts" anymore. >> >> >> Bert >> >> > That is something we have also thought about to incorporate some day in > LinkEHR Editor (I think this is more a responsibility of the archetype > editors rather that the archetype management systems). The idea is to force > the users to, at least, increment the PATCH number of the archetype if it > is modified in the editor. But we also know by experience that many times > people don't like to be forced to do things in some way, even if it is > mandated by the specifications. So when all these changes come to the > tools, an education effort will also be needed. > > > Some compiler environments, like Delphi, automatically increment > version-numbers, but it is possible to set it off. > To really annoy people, you can refuse to do a save, and force a "save as" > with an incremented patch-number, also in the internal id. > But in fact, this is all legacy-thinking. > > 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. > > Ask people to give it a name, any name they want, give them > responsibility. Then it isn't your problem anymore. > > Less technical people think very strange about archetypes. They think that > an archetype is a file. > But in most kernels, I guess, it is not a file, but something in a > database. > > We must intuitive learn people that archetypes are not files, are not ADL, > but can also be JSON or XML, or even a relational model conform AOM. > We must learn them that a file is only a way an archetype can occur. It is > the file-metaphor which causes so much trouble. > > Maybe an archetype-editor should not save files at all, but maintain a > local database, or connect to a company-server if appropriate, and if > needed, in some cases, export it to a file. > It would give unexpected features if an archetype editor would store > archetypes in relational databases according the AOM-model. > It would be possible to have a collections of archetype-snippets to copy > from, to have repositories of CComplexObjects. > > Hmmm, let's see, I need an element with a DvDate, I have three kinds, > which one do I take..... hmmm, I also need an medication-cluster, I have 7 > types, yes, this looks most suitable. > > Remember, we tell all the customers about Lego-bricks. > > Business opportunities. Quick call my patent-lawyer. ;-) > > Bert > > > David > > -- > 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) > > > _______________________________________________ > openEHR-clinical mailing listopenEHR-clinical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_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-clinical_lists.openehr.org/attachments/20141004/e77e14c0/attachment.html>
