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> wrote:
>
> On 05.10.2014 22:58, Bert Verhees wrote:
>
>
>
> 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.
>
> 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 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
>>
>
>
> --
>
> *This e-mail message is intended exclusively for the addressee(s). Please
> inform us immediately if you are not the addressee.*
>
>
>
> _______________________________________________
> openEHR-clinical mailing listopenEHR-clinical at
> lists.openehr.orghttp://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
>
> 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/20141006/f8423ac6/attachment-0001.html>
