Certainly good deal, Ian,
I agree, because the archetypeId is very often a compromise between one
side : [short-length, funny underscores, dashes and periods] and on the
other side: [trying to communicate something about the archetype].
People should not be confronted with such technically, strict syntaxly
formed strings.
I am sure very few people can write an archetypeId down without errors,
even when dictated, maybe less then five-hundred worldwide.
And maybe less people understand what is meant here:
openEHR-EHR-CLUSTER.amount-range.v1, while this is perfectly understood
by ten thousands: Amount of medication as a range
Bert
Ian McNicoll schreef op 6-10-2014 13:06:
> Hi Bert,
>
> While I understand your argument that 'archetype as file' can confuse
> people, from an archetype author perspective, it is really helpful to
> be able to handle archetypes as files. For you as a developer though,
> I completely agree that you are going to manage the operationalised
> 'compiled' versions of these files completely differently.
>
> As Sebastian has said, I would like any tools that offer to export an
> archetype as a file to offer some sort of sensible name, but perhaps
> we can think of an alternate (optional) file naming scheme that is
> clearly different from the archetypeId
>
> I would suggest the
>
> Clinical Concept Name ("Indirect oximetry")
> The Class "(observation)" to help disambiguate similar concept names
> from different classes. e.g "medication" action vs "medication"
> instruction (same idea as SNOMED CT FSN)
> The major revsion part of the revision string
>
> "Indirect oximetry (observation).v2.adl"
>
> This is pretty close to the file naming scheme that I am using for
> templates.
>
> Definitely optional and not intended to be parsable.
>
> Ian
>
>
>
>
>
> On 6 October 2014 12:08, Sebastian Garde
> <sebastian.garde at oceaninformatics.com
> <mailto:sebastian.garde at oceaninformatics.com>> wrote:
>
>
> 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>
>> 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
>>>
>>> http://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
>> <tel:%2B44%280%29141%20560%204657>
>> mobile +44 (0)775 209 7859 <tel:%2B44%20%280%29775%20209%207859>
>> 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 <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 <mailto: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
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> <mailto: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 <mailto: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>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20141006/d65addf7/attachment-0001.html>
