On 05.10.2014 22:58, Bert Verhees wrote: > > > Op zaterdag 4 oktober 2014 heeft Ian McNicoll <ian at mcmi.co.uk > <mailto: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. > Bert, you can always go to the Share With Colleague tab for an archetype (or other resource) and you will see the direct link for it. You can also select an action (e.g. go to the mindmap directly or the discussion page). There is also a webservice to get the archetypes directly. If you want to go by the archetype id (which might change of course, pre-publication), you can also use e.g. http://openehr.org/ckm/#showArchetypeById_openEHR-EHR-OBSERVATION.blood_pressure.v1
> 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. > For the browsers I know at least, this is a setting of the browser. You can select if you want the browser to save downloads immediately to a pre-defined download folder or save it under a folder/name of your choice. Depending on the browser, this is somewhere under settings, e.g. Chrome: Under setting, go to "show advanced settings" and then to the "Downloads" section. The option is called something like: "Ask where to save each file before downloading" I am fairly confident that if we wouldn't suggest anything there as a filename that people would complain as well. Sebastian > 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 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 > > > _______________________________________________ > 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 <http://www.phcsg.org> > > > > -- > /This e-mail message is intended exclusively for the addressee(s). > Please inform us immediately if you are not the addressee./ > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20141006/6b693461/attachment-0001.html>
