Andrew Patterson wrote:
>> The system at present is performing mappings on pre-modeled archetypes
>> depriving it the luxury of having access to the author.
>
>
>
> This is what I meant by the 'split' case - a split between the
> people/group
> constructing the archetype, and the people doing the binding (in this
> Sam writing the archetype and you guys doing the terminology stuff). It
> doesn't lessen your points about the difficulties of doing the
> terminology
> mapping - I just wanted to clarify that the plan in the 'best case' is
> that there wouldn't be so much of a split (i.e. you'd be in communication
> with the people writing the archetype, or it would all be done within one
> tool by the same author)
Right thats fine. Atleast there is a consensus in thought here !
>
>> I agree that this URL feature sounds a bit complex. Not having complete
>> knowledge of the Ocean methodology and objective makes it rather
>> difficult
>> to comment though. However, 'is_a' trees are only part of the
>> solution to
>> the binding/mapping process. There are a few archetypes that have 'is_a'
>> terms and can be dealt with in a less complex way i.e. without the
>> use of
>> URL's.
>
>
>
> Other than actually enumerating the term codes in the ADL file, what
> other
> mechanism is there other than URLs?
I have a question about the context in which the term URL is being used
in this discussion. What does the URL lead to - is it some sort of web
page with a block of the terminology displayed enabling the user to pick
a few relevant codes or is it some sort of metadata for the location of
the list of relevant codes?
Another form could be to have a Tree Graph of a subset of the entire
terminology with access to only those paths (to 5 depth level or
more/less) that belong to the set of 'allowable' codes. It could make
the task easier and probably more interesting to the user. However, the
graph should be able to display the concept definitions and/or
annotations to enable an informed decision to be taken when selecting
codes for mapping.
Rahil
>
>> Though am not sure whether the Ocean team had something else in mind
>> when using URLs.
>
>
>
> The URL system is not inherently bad - it solves the problem in a
> relatively clean way that allows lots of room for future developments
> in terminologies without constraining the solutions. I just worry that
> with complex terminologies like snomed being used more often
> it may be useful to have an inbetween solution i.e.
>
> simplest)
> list of codes typed in '123123', '3242342', '123123'
> * moderate *)
> simple langauge like "limit depth 5 (is_a('102323','arm fracture'))"
> complex)
> http://www.termserver.com/saved_query?realm=uk&concept_root=1231231
>
> Andrew
>
--
Rahil Qamar
Ph.D. Student
Medical Informatics Group
Room 2.89 Kilburn Building
University of Manchester
Work number: +44 (0) 161 275 5719
Email: qamarr at cs.manchester.ac.uk
Website: http://www.rahilqamar.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070103/b6c5fa03/attachment.html>
-------------- next part --------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
