GUI-directives/hints again (Was: Developing usable GUIs)

[info]

I am happy to read this opinion and I do fully agree on this.

This makes it possible to use templates for any purpose desired.
I already had thought of some template enrichments which work with CSS.

Now that there is template parsing software in Java, I am thinking of 
further developing/implementing it.

Next step will be a repository with archetyped controls, like a GUI 
building developing tool, it even could be an eclipse or visual studio 
plugin, or write an own development environment, and so enabling a drag 
and drop development tool for people close to the medical professions.

The templates could be the base of a Windows-executable GUI, or Mono, or 
Java, or PHP, or Javascript/HTML (AJAX), a client application that 
changes, depending on the template loaded. It is all a matter of just 
work to do.

Maybe I am jumping too many steps in one time, but something like that 
is my bit further goal.

Bert

Op 1-12-2010 19:30, Tim Cook schreef:
 IMO templates are an implementation specific issue and should not be
 part of the reference model.  Archetypes that express a concept as a
 maximal dataset are sufficient for interoperability.  Local templates
 are just that; local templates.  Certain implementations may share
 templates between applications but I dare say any attempt to 'standard'
 across implementations is wheel-spinning.

 If people are expecting magic pop-out-of-the-box applications then they
 are taking something mind-altering.  :-)

 My 2 cents,

 Tim


 On Wed, 2010-12-01 at 18:08 +, Ian McNicoll wrote:
 Hi Olof,

 I agree this is a significant missing piece of the reference model and
 I am not sure how close the overall ADL 1.5 spec is to being finalised
 but the operational template definition appears to be very stable and
 can act as a reference point for coalescing various local template
 implementations and tooling developments. Thomas has already added
 ADL1.5 support to the ADL Workbench and the specs seem to me to be
 stable enough to start implementation in Java. I think the issue is
 lack of time/resource, rather than immaturity of the specifications -
 it would be interesting to get Rong's take on this but I suspect he
 implemented a great deal of the current Java model prior to a stable
 RM being specified. Indeed I would only expect a truly stable
 specification to emerge after some implementation experience.

 IMO most real-world implementations which strive for interoperability
 and maximally-defined archetypes will almost all work via operational
 templates for validation, code -generation GUI integration. I don't
 think we have to wait for the full ratification of ADL1.5 and template
 spec to start doing interesting things in downstream support, assuming
 that the opt definition is pretty stable.  The issues of extra
 directives and extensions are important at this stage as arguably some
 should be supported in the operational template, as I discussed above.

 Ian

 Dr Ian McNicoll
 office / fax  +44(0)1536 414994
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com


 Clinical analyst, Ocean Informatics
 openEHR Clinical Knowledge Editor www.openehr.org/knowledge
 Honorary Senior Research Associate, CHIME, UCL
 BCS Primary Health Care SG Group www.phcsg.org




 On 1 December 2010 17:19, Olof Torgerssonolof.torgersson at chalmers.se  
 wrote:
 Hi,
 When it comes to templates, what I would like to see is that they are
 finalized and become a part of standard implementations such as the Java
 reference model. This is something I've been waiting for since I first
 viewed this list a couple of years ago.
 Then, as a next step one could start discussing various extensions,
 directives etc.
 Regards
 Olof Torgersson
 1 dec 2010 kl. 13.24 skrev Erik Sundvall:

 Hi All!
 There was a related discussion regarding GUI-directives/hints around june
 2008, that I tried to summarize in the post
   http://www.openehr.org/mailarchives/openehr-technical/msg03755.html
 As you will see that post is somewhere in the middle of the thread, so you
 can find other interesting things before and after that post in the
 archives.
 Now, if I understand things correctly there is now implementatin experience
 from at least three projects regarding GUI-hints/directives (please add more
 if you know any):
 - Zilics
 (http://www.openehr.org/mailarchives/openehr-technical/msg03767.html)
 - GastrOs Endoscopy Application by Koray Atalag et.al.
 - Open EHR-Gen by Pablo Pazos et.al.
 What about trying to formalize some recommendations based on this
 experience, and perhaps even write a piece of specification draft that fits
 the new ADL 1.5 thinking regarding templates and archetypes.
 Would it be possible for anybody from any of the three projects to start a
 wiki page to describe your GUI-directives/hints and then we could compare
 them all and get a discussion going on the list possibly followed by some
 community driven development of a draft specification to try out.
 

IP on OpenEHR

[info]

I wrote it confusing, so I try again, it is because English is not my 
first language and the subject is a bit complicated to explain in 
another language..

There is no IP-claim on any part of the kernel-concept, except from on 
the literally text of the specification (copyright)
So anyone building a kernel can license it to his customers as he wants, 
open source, closed source, whatever. There is no payment at all 
required to the OpenEHR-foundation.
When using sourcecode trom the OpenEHR-website, one must comply to the 
terms agreed when using that sourcecode. That can differ. But one can 
always (without any payment done to who-ever) write a kernel from 
scratch and sell it to who-ever he wants for any price which seems 
reasonable.

I hope it is clear now.

If someone disagrees please report this.
Also if Gerard Freriks disagrees I would like him to report this, and 
discuss this.

Thanks
Bert Verhees




Op 10-2-2010 17:24, Bert Verhees schreef:
 Please consider the previous as not being send. Thank you

 Op 10-02-10 15:35, Gerard Freriks schreef:
 Stef,

 It is a good step.
 But not sufficient.


 That OpenEHR artifacts are published with such a Creative Commons License 
 policy attached to it is a good thing, I agree.
 But when a new Reference Model, Archetype Model, Template models change and 
 are published that decision is made by the owners because they own the IP 
 and can issue any new License policy they wish.

 Our customers do not want to be held hostage when they invest in the exiting 
 new technology based on En13606/openEHR.
 They are taking enough risks already, they feel.

 Then minutes ago you did not now about this, you were talking about 
 the organization-model which would impose IP?
 No that is proven wrong and still you know it is not sufficient?
 How do you know what you customers feel about this new knowledge you 
 just (ten minutes ago) heard of?

 I come back to this later, because your remarks do raise questions.

 (IP = intellectual property)

 _Anyone considering using OpenEHR, read carefully_

 It is impossible to attach IP to an RM-implementation to build. It is 
 not patented, so anyone can build an implementation.
 Same story for the Archetype Model.
 The only thing that can carry IP is a RM-implementation (copyright) 
 but that is as with any software-product you license.

 You can only protect an idea by patents, there is no other way. You 
 can protect an implementation of an (ICT) idea by copyright on 
 sourcecode, but that only applies to the specific implementation.

 So we must ask: Is there a patenting application? Do you know, does it 
 seem likely?

 To me it does not.
 Let me explain:

 As soon as the OpenEhR foundation would consider that, it would be a 
 big problem because many people volunteered, and I think OpenEHR would 
 be quickly out of business.
 In my opinion it is impossible to patent  it because many people 
 volunteered, and a lot can be considered as prior art.
 We also have the lache-doctrine. You cannot patent anything which you 
 let people use for years.

 I think an patent-application on the OpenEHR: RM or AOM is impossible.

 So if it is not patented, anyone can build an implementation without 
 considering any IP. That is very sure. I have dealt a lot with patents.

 Anyone who does business with me can go to a lawyer to check, and if 
 it is not true what I write in here, I pay the lawyer-bill.

 Conclusion: OpenEHR-foundation has no IP on implementations.
 Maybe there is IP on the published archetypes, IP in the form of 
 copyright. I don't know. But if that is the case anyone is free to 
 create his own archetypes, IP-free.

 _end of subject_

 It looks to me as if you are looking for ways to publicly discouraging 
 hospitals to use OpenEHR. Why is that?

 What is the matter Gerard? You used OpenEHR for years, you invested 
 lots of time and money, even build your own implementation, and now 
 you discovered that you cannot use it? That you have to pay?
 Where you sleeping that you did not think about these urgent 
 IP-questions you bring up here?

 A strange story.

 regards
 Bert Verhees


 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/ec001ef4/attachment.html