Intra-archetype semantic relationships

Diego Boscá yampeku at gmail.com
Wed Jan 15 04:09:14 EST 2014


I agree that sometimes regular expressions can be tricky, and surely they
don't look pretty on its current form. However, but they have an advantage:
They are formal and easily evaluated in any language. The problem I see
with this approach is that you will need a single ontology (or access to
it) to be able to assure that the meaning is the same for everyone. Also
you will have to forbid more radical changes that are being made on the
archetypes (changing its root entity, for example).

Also, if this approach is taken, precise rules and clarifications are
needed. e.g. in the last example, are 'massage' children allowed? (in other
words, does EXCEPT refer to the children too or not?). Are there some kind
of precedence rules implied? These kinds of things should be formally
defined in any case.


2014/1/14 Thomas Beale <thomas.beale at oceaninformatics.com>

> On 14/01/2014 11:07, Diego Boscá wrote:
>
>> I like the idea, we were already exploring something similar to this for
>> intra-archetype semantic relationships.
>>
>>
> Since Diego brought up the topic....
>
> one of the final things needed in ADL/AOM 1.5 is a better kind of slot,
> which works off an ontology of archetypes. The question is: is the ontology
> hierarchy defined by their specialisation relationships (and going up into
> the categories Observation, Evaluation etc) or by some independent
> ontology? The former would be automatically extractable from the
> specialisation relationships of a population of archetypes, but the latter
> is more likely to work as needed. Anyway, assuming that the ontology can be
> established (e.g. in CKM or somewhere), new slots would look something like:
>
> items matches {
>
>     allow_archetype CLUSTER[id24] matches {< device_description OR <<
> manual_procedure}
> }
>
> Where 'device' means CLUSTER archetypes classified under a
> device_description node in the ontology. The '<' means any child (but not
> this concept), '<<' means this concept or any child. The value of this
> approach is that you may define your slot and publish your archetype, then
> some time later, you realise you need to allow a new archetype to be a slot
> filler. Assuming that the new archetype can be reasonably classified as a
> 'device' or 'manual procedure' then you do this in the ontology, and your
> slot definition now evaluates to pick up your new archetype - no changes
> needed to either archetype.
>
> More complex constraints could be defined:
>
> items matches {
>
>     allow_archetype CLUSTER[id24] matches {< device_description OR <<
> manual_procedure EXCEPT massage }
> }
>
> These kinds of expressions start to look like ref-set definitions, where
> the ref-set are being defined on the archetype ontology rather than some
> external terminology like SNOMED. If the archetype ontology were defined in
> a SNOMED extension or similar, the same technical tools could be used to
> evaluate slots.
>
> - thomas
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140115/165408bb/attachment.html>


More information about the openEHR-technical mailing list