oship-dev team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Sergio,

On Thu, 2009-03-19 at 12:05 -0300, Sergio Miranda Freire wrote:
> because Tim implemented a termserver, but not the terminology interface.
> Even worse, I would have to dig into his code to know how to call the
> server, because I do not have a contract to look at.
> 

Ahhh, but you do.  Have you browsed the API links under the resources
section of the main OSHIP page?  It gives you a complete hierarchy of
interface definitions.  No one terminology interface definition can
satisfy all terminologies.  From SNOMED to ICD to openEHR, the
structures are COMPLETELY different.

> IMHO, the terminology API in the specification is a starting point for
> building an API for accessing terminology servers. Probably it will have to
> be improved as we gain experience in working with several terminologies
> (from a simple one like openEHR codes to very complex terminologies, e.g.,
> SNOMED).

If you want to go through this pain then fine....have at it.  I have
studied the resources available in Grok/Zope3.  

If you have a better approach that meshes well with the application
server then I am open to changes.  

> If Roger implements the ICD server his way, soon we will have a plethora of
> terminology servers, and then we will feel the need for a common API.

With the various terminologies the VERY best you can hope for is a name
and a release number/date.  After that; the structure of terminology
each changes.  In addition to releases, there  is a need for subsets of
terminologies (SNOMED,ICD, etc).  

Anyone can ask Ocean informatics or other vendors about their
experiences with subsets that run into the tens of thousands of
entries.  

> 
> Finally, it seems to me that the terminology package will not raise any of
> those problems that Tim had with the rm. 

True.  Except that it would result in duplicate code for no apparent
reason that would have to be managed inside each application differently
instead of the "Grok way".  Remember; goal #2.

> The methods there are simple to
> implement, once you define how you are going to implement the terminology
> server or how you are going to access a server outside OSHIP domain. 

This is a red herring.  There is no reason to access the OSHIP
terminology server outside of OSHIP.

Can you give me a use case?

Cheers,
Tim

Attachment: signature.asc
Description: This is a digitally signed message part