> -----Original Message----- > From: Tim Churches [mailto:[EMAIL PROTECTED] > Sent: Thursday, 5 January 2006 10:33 AM > To: General Practice Computing Group Talk > Cc: 'General Practice Computing Group Talk' > Subject: Re: RE: GP Requirements - was [GPCG_TALK] Re: The Dreaming ... > So, one would hope that the sociology of open source > archetypes is similar. That remains to be seen. One > difference is that there is a high overhead in maintaining a > fork of a complex piece of software, whereas a fork of a > single archetype involves far less of a commitment of future > time and effort on the part of the forker. However, > archetypes are intended to form a complex, interdependent > fabric, and a fork of a whole raft of archetypes is a large > commitment to the future. >
A couple of differences between open source code and archetypes may break the analogy 1. Many players have legacy code/data that is expensive to change giving them incentive to channel the energy that would be needed to change their system into creating archetypes more compatible with their system. While many open sources programs probably have less legacy issues to contend with. 2. A code in a program fork has to be written while archetypes could probably be automatically generated in bulk from a players existing data storage structures and automatically merged in to create a modified openEHR archetype. That is a much lower barrier to archetype forking. Although Thomas Beale in "Archetypes: Constraint-based Domain Models for Future-proof Information Systems" http://www.deepthought.com.au/it/archetypes/archetypes_new.pdf sees as the ideal domain experts producing archetypes the reverse direction approach of data mining domain level descriptions from existing data structures (which although crafted by IT experts really do have a lot of domain expert input) may win out (essentially reversing the arrows in figure 6 of the paper). Nigel > The other thing to remember is that archetypes are designed > with backwards compatibility in mind This would appear to require the use of GUI Archetype editors, validators and browsers to enforce backwards compatibility as incompatible archetypes are otherwise likely when lower level manipulation (text editor or automated merging) is used. Nigel > - far more so than with > software, where even the smallest chnage can render software > code incompatible. By contrast, the archetype framework > encourages specialisation which is still backwardly > compatible, but makes incompatible forking much harder. > > Having said all that, I think that the idea that one set of > achetypes or standards can meet all needs is a pipe dream, > and that there are real advantages to moderate degrees of plurality. > > It is a bit like human language. As an Australian, you are > not forced to speak English, although it is vastly more > convenient to use English in most day-to-day dealings with > others than not. But sometimes it is better to deal with > certain groups of other people using other languages. > > > As Hugh Leslie wrote: > > "You are absolutely right that having a centralised archetype > > repository that is properly managed is important. openEHR > won't work > > if everyone is using > > different archetypes for the same thing." > > but as a centralised repository isn't enforced by the > licence isn't the > > practical conclusion therefore that 'openEHR won't work' ? > Or perhaps > > that > > the defacto central repository will be the repository of modified > > archetypes > > maintained by the dominant commercial player? > > Yes, it takes time and effort to maintain a repository. There > may well be more than one, but there is unlikely to be an > unmanageable number. And having a handful of them may be > better than having just one. > > Tim C > > > -----Original Message----- > > From: Sam Heard [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 4 January 2006 9:20 PM > > To: [EMAIL PROTECTED]; General Practice Computing > Group Talk; Dipak > > Kalra > > Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming > > > > > > Tim > > > > I think this is a very helpful suggestion. We have > trademarked openEHR > > and > > do not release anything without copyright as there is a need for an > > authorative publisher of archetypes. The openEHR Foundation > will not > > accept > > any archetypes that are not free to use to be labelled with openEHR. > > > > Cheers, Sam > > > > Tim Churches wrote: > > > > Dr Nigel Brown <mailto:[EMAIL PROTECTED]> > > <[EMAIL PROTECTED]> > > wrote: > > > > > > > > I also note the "copyright (c) 2004 Ocean Informatics" on the > > archetype. > > > > > > > > > > > > See http://www.openehr.org/about_openehr/t_licensing.htm > > <http://www.openehr.org/about_openehr/t_licensing.htm> for > details of > > the > > licenses under which this and other openEHR material is > distributed. A > > reminder: open source does not mean "no copyright" - in fact, the > > opposite: > > open source licensing relies on assertion of copyright and > observance of > > copyright law. However, the copyright holder then uses an explicit > > license > > to grant additional rights to end users, as copyright law > permits the > > copyright holder to do. > > > > > > > > However, I think that it would be useful to provide a > pointer to the > > licensing provisions in each and every archetype published > by openEHR > > (and > > others) - make it part of the archetype metadata. > > > > > > > > Tim C > > > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
