Hi Peter, Diego,

I think the URI way to define constraint bindings can be ambiguous and hide 
some semantics needed to understand where to find the terminology terms and 
codes.
Please correct me if I'm wrong:

One archetype can have this: ["ac0001"] = 
<terminology:Snomed/2002?subset=DrugForm>
And another this: ["ac0001"] = <terminology:Snomed/2002?s=DrugForm>

So, how can a machine know the difference or equivalency of both URIs? (URIs 
are universal, but not a unique way to identify a terminology or a subset).
How can we agree on use one URI or the other in global archetypes?
Do we need a centralized terminology/subset URI repository?

What do you think?

-- 
Kind regards,
A/C Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



> From: peter.gummer at oceaninformatics.com
> To: openehr-technical at openehr.org
> Subject: Re: constraint binding error
> Date: Mon, 21 Feb 2011 11:56:11 +1100
> 
> Diego Bosc? wrote:
> 
> > I know it is on ADL specs, but why limit it to an URI? Second approach
> > could also be used to identify a subset
> 
> The URI approach is able to specify subsets, Diego. Here is an  
> example, generated by the current Archetype Editor beta release  
> (available from 
> http://www.openehr.org/svn/knowledge_tools_dotnet/TRUNK/ArchetypeEditor/Help/index.html)
>  
> :
> 
>       constraint_bindings = <
>               ["Snomed"] = <
>                       items = <
>                               ["ac0001"] = 
> <terminology:Snomed/2002?subset=DrugForm>
>                       >
>               >
>       >
> 
> - Peter
> _______________________________________________
> 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/20110220/3b160ff0/attachment.html>

Reply via email to