Em 09/09/2011 12:24, Ian McNicoll escreveu:
>> What I meant was that: if we, in the future, have several CKMs around the
>> world, maybe forming a hierarchy or not, we need a clear specification of
>> the versioning rules for this distributed CKM.I don't know for sure if the
>> versioning issue is solved or not, or if it's
>> solved only at the CMK or if it's part of the specifications. What we need
>> is the latter.
> [IAN] It is nearly solved
> Not so long ago there was a very interesting discussion about that:
> http://www.openehr.org/mailarchives/openehr-technical/msg05797.html
>>
>>> There is active work exploring how to tighten up the governance
>>> issues, especially around namespaces but I think we are pretty close
>>> to having this worked out.
>>>
>> I would love to see that. Can you point me to some information or
>> discussions about those issues?
> [IAN] Coming soon!
>>> Once you consider the potential dependencies of templates, archetypes,
>>> specialisations and termsets, there are some interesting challenges
>>> ahead in understanding how best to keep good blend of agile
>>> development and the kind of stability that vendors and other projects
>>> will require.
>>>
>> Is this a closed discussion? I would like to help.
> [IAN] Thanks. Once we get some coherent thoughts/ proposals properly
> documented, we will definitely open this up to a wider audience, and
> your input would be very welcome.
>
>> The Release Set is a nice idea. but I think CKMs should support individual
>> artefact commits also.
> [IAN] Absolutely. Individual commits will always take place but will
> inevitably result in a loss of coherence between dependent artefacts.
> Part of the idea of Release sets is to give an extra level of
> assurance to consumers that any dependency issues between artefacts
> have been at least minimally resolved i.e all templates have the
> correct version of archetypes, termsets available.
>
>
>>
>
>>> Yep, it would take time, but is necessary if we want worldwide impact. Maybe
>>> is not only necessary, but strategic.
>> We (the Open EHR Gen team) have developed very basic service oriented
>> repository, a simple web oriented template editor that communicates with the
>> reposiotry to load archetypes and templates, and save templates. It would be
>> nice to try other groups tools and see how we can join efforts.
>>
> [IAN] You should start a discussion with Sebastian about how this
> works. There is a lot of interest in web-based openEHR
> archetype/template tools. I am not personally convinced that this
> makes sense, any more than web-based Eclipse or Visual Studio makes
> sense, but I am willing to be convinced otherwise. We certainly need
> to integrate any authoring tools, web or desktop, much better with
> repositories such as yours and CKM but these have to be able to
> support the local developer private authoring phase.
>
> Is there any potential for using your work as part of the openEHR
> community repository idea? Derek Hoy of Snowcloud might well be
> interested in further discussion in this area. He does lurk on these
> lists but I will give him a nudge.
>
>
> Ian
>
> Dr Ian McNicoll
> office +44 (0)1536 414 994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical Modelling Consultant, Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care www.phcsg.org
>
>
>
>
> On 8 September 2011 18:17, pablo pazos<pazospablo at hotmail.com> wrote:
>> Hi Ian,
>>
>>> I think we do have very good versioning / revisioning rules and CKM
>>> has implemented these within its comparator function when we upload a
>>> modified archetype.
>>>
>> What I meant was that: if we, in the future, have several CKMs around the
>> world, maybe forming a hierarchy or not, we need a clear specification of
>> the versioning rules for this distributed CKM.
>> I don't know for sure if the versioning issue is solved or not, or if it's
>> solved only at the CMK or if it's part of the specifications. What we need
>> is the latter.
>> Not so long ago there was a very interesting discussion about that:
>> http://www.openehr.org/mailarchives/openehr-technical/msg05797.html
>>
>>
>>> There is active work exploring how to tighten up the governance
>>> issues, especially around namespaces but I think we are pretty close
>>> to having this worked out.
>>>
>> I would love to see that. Can you point me to some information or
>> discussions about those issues?
>>
>>
>>> Once you consider the potential dependencies of templates, archetypes,
>>> specialisations and termsets, there are some interesting challenges
>>> ahead in understanding how best to keep good blend of agile
>>> development and the kind of stability that vendors and other projects
>>> will require.
>>>
>> Is this a closed discussion? I would like to help.
>>
>>
>>> I think Release Sets will play an important part here by giving
>>> different projects a fixed, coherent set of artefacts to work with,
>>> even as the leading-edge development moves on. I think it is much more
>>> likely that connections between repositories will be through Release
>>> Sets than by full 'current' access. We are starting to look at this
>>> issue of 'federation' in CKM but current thinking is that a simple
>>> view of, or reference to, assets in another repository is really not
>>> going to help real development very much. The key issue is how to
>>> request and acheive change in a non-native artefact, and how to handle
>>> the inevitable mismatch in development cycles between native and
>>> non-native artefacts.
>>>
>> The Release Set is a nice idea. but I think CKMs should support individual
>> artefact commits also.
>>
>>
>>> Although the Ocean CKM is a pretty unique product for now, I am sure
>>> alternatives, quite possibly open source, will emerge but as David
>>> Ingram suggested this kind of functionality is complex and will take
>>> time to develop.
>>>
>> Yep, it would take time, but is necessary if we want worldwide impact. Maybe
>> is not only necessary, but strategic.
>>
>>
>>> I would be much more interested in starting with a light-weight
>>> community repository tool, without the burden of tight governance
>>> requirements of a CKM-like application. I think this can get started
>>> with relatively low development requirements based around Derek's
>>> Snowcloud template tool.
>>>
>> We (the Open EHR Gen team) have developed very basic service oriented
>> repository, a simple web oriented template editor that communicates with the
>> reposiotry to load archetypes and templates, and save templates. It would be
>> nice to try other groups tools and see how we can join efforts.
>>
>>
>> regards,
>> Pablo.
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
federating things is always a challenge, I?m a doctor not a tecnology
guy, but I think that middlewares like an ESB helps, am I right?
