Op zaterdag 4 oktober 2014 heeft Ian McNicoll <ian at mcmi.co.uk> het volgende geschreven
Sorry for my late reaction, I was very busy with outdoor sports events, I hardly did see a computer, which is very special for me. > > 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 > by the way, I discovered that it is hard to link directly to on archetype in CKM, maybe I am doing something wrong. But it would be very handy to communicate archetypes, inclusive connection to other tooling like mind maps, etc. I don't think git/svn offers some useful functionality in this context, having already a good versioning system. But maybe there is something I overlook. There are some disadvantages to the file-paradigm, that is, why I guess you keep on needing the "v", to point out where the versionnumbering starts, so software can handle it. It is of course because Windows as only OS does not allow a colon as legal character for a file name, so you need the "v". And we are used to having the version in the file name. The namespace is separated from the archetypeId by a colon. I think that is a good thing, the namespace should not be part of the content-indicating part of the archetypeId. So should the version. But I already mentioned that. The naming of the file, the tooling should be helpful. There are several ways to be helpful, this should be decided by the tool builders. In CKM, it is, because the archetype-download is under a button! it is not possible to do "save as", we have the name CKM offers. So there is a file name enforced, and because CKM is often the starting source from where an archetype enters a company-network, this name remains. This encourages the file paradigm, which is in fact disadvantageous. So to do what you advertise, discouraging the file paradigm, I hope you agree those two issues in CKM, possibility to link directly to an archetype, and possibility to do a "save as" when saving an archetype from CKM. Thanks Bert > 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 > <javascript:_e(%7B%7D,'cvml','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.org >> <javascript:_e(%7B%7D,'cvml','openEHR-clinical at >> lists.openehr.org');>http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','ian at freshehr.com');> > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > -- *This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20141005/85159e72/attachment.html>
