W3C home > Mailing lists > Public > public-hcls-coi@w3.org > July to September 2008

Re: Multi-layered Knowledge Representations for Healthcare (was RE: An argument for bridging information models and ontologies at the syntactic level)

From: Dan Russler <dan.russler@oracle.com>
Date: Wed, 23 Jul 2008 23:02:31 -0400
Message-ID: <4887F0C7.6040501@oracle.com>
To: Samson Tu <swt@stanford.edu>
CC: "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>, "Elkin, Peter L., M.D." <Elkin.Peter@mayo.edu>, public-semweb-lifesci@w3.org, public-hcls-coi@w3.org
Hi Samson,

Sorry for my older-style jargon...

Here is the Wikipedia entry on collection/aggregation. We often called 
these classes "collectors" in jargon:


        "Aggregation

Class diagram showing Aggregation between two classes

Aggregation </wiki/Aggregation_%28object-oriented_programming%29> is a 
variant of the "has a" or association relationship; aggregation is more 
specific than association. It is an association that represents a 
part-whole relationship. As a type of association, an aggregation can be 
named and have the same adornments that an association can. However, an 
aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other 
classes, but where the contained classes do not have a strong life cycle 
dependency on the container--essentially, if the container is destroyed, 
its contents are not.

In UML </wiki/Unified_Modeling_Language>, it is graphically represented 
as a clear diamond shape </wiki/Rhombus> on the containing class end of 
the tree of lines that connect contained class(es) to the containing class."


In my camel-back example "ObservationCollectorClass" instance would 
formally be an instance of a class with an aggregation association to a 
set of observation instances.

Again, sorry for the confusion.

In any case, my point is the same.

Dan


Samson Tu wrote:

> Dan,
>
> You've lost me. What is an ObservationCollectorClass? Googling the 
> term gives only one hit, namely your message.
>
> The conceptualization of a class as denoting a set of instances is 
> quite common. It's in UML, frame representation, and OWL. I don't 
> understand why Observation, as a RIM class, should be an exception. 
> Maybe what you mean is that, within a (model of) health record system, 
> one doesn't deal with Observation as a whole, but always subsets 
> (e.g., problems in Problem List), but that's a question separate from 
> the semantics of a class.
>
> Matt, some of the terms (HL7 RIM, LOINC, OKBC) have specific meanings 
> that you can look up by googling. I am confused about the layering of 
> models that have been mentioned in this thread too.
>
> Samson
>
> Dan Russler wrote:
>
>> Ouch...
>>
>> A class of Observation does not denote a set of instances of type 
>> Observation...One uses "collector" classes to describe sets. In other 
>> words, an instance of an ObservationCollectorClass contains instances 
>> of an ObservationClass. The ObservationCollectorClass (and instances 
>> thereof) certainly has different properties than an ObservationClass 
>> (and instances thereof respectively).
>>
>> Dan
>>
>> Samson Tu wrote:
>>
>>> Yes, if we understand the semantics of a class as denoting a set of 
>>> instances. Specifying WBC_Count_Observation is equivalent to 
>>> defining a subset of all Observations, which is natural to think 
>>> about. If we see Observation as a metaclass, then it's the set of 
>>> sets of observations.The properties of observations and the 
>>> properties of a set of observations are quite different.
>>>
>>> It is possible to talk about layers, but one should be careful about 
>>> the precise meaning of their relationships. I'd say that the 
>>> relationship between Vipul's layer 1 and 2 is one of specialization, 
>>> not instantiation.
>>>
>>> Samson
>>>
>>> Dan Russler wrote:
>>>
>>>> Hi Samson,
>>>>
>>>> I agree...It is wrong to confuse the process of creating an 
>>>> instance in the narrow sense (where the structural attributes and 
>>>> other attributes are constrained to specific values) and creating 
>>>> an incremental constraint on the structural attributes and code 
>>>> that allow one to define "more concrete information models."  By 
>>>> constraining classCode, moodCode, and code to smaller value sets, 
>>>> one is creating more concrete models, not creating instances in the 
>>>> narrow sense. In creating an instance, one is constraining 
>>>> classCode to one value, moodCode to one value, and constraining the 
>>>> CD datatype for code to a single semantic meaning as well as 
>>>> setting values for other attributes (that might be updated later).
>>>>
>>>> Dan
>>>>
>>>> Samson Tu wrote:
>>>>
>>>>> My understanding of the HL7 RIM is that, when you clone a RIM 
>>>>> class, such as Observation, into a specific domain model class 
>>>>> (e.g., WBC_Count_Observation), you are placing restrictions on the 
>>>>> RIM class, i.e., constraining the cloned class's properties to 
>>>>> have specific values or to take values from a restricted 
>>>>> vocabulary domain. The process, I think, is characterized as 
>>>>> creating a subclass of the RIM class, not an instance. If you 
>>>>> understand metaclass/class/instance in the sense of OKBC, 
>>>>> WhiteBloodCount as an instance of Observation where code is 
>>>>> specified to be the LOINC code for WBC means that code is not a 
>>>>> property of Bob's WBC. To query for the code, you need to go up 
>>>>> the class level.
>>>>>
>>>>> I see no advantage in modeling the domain classes (detailed 
>>>>> clinical models) as instances of HL7 RIM classes. What's wrong 
>>>>> with seeing them as specializations?
>>>>>
>>>>> Samson
>>>>>
>>>>> Kashyap, Vipul wrote:
>>>>>
>>>>>> Dan,
>>>>>>  
>>>>>> Looks like there is increasing convergence in our view points and 
>>>>>> some minor divergences.
>>>>>>
>>>>>>     <dan> I'm confused...can you illustrate in UML, perhaps with
>>>>>>     the blood pressure example? />
>>>>>>     [VK] The UML Diagram illustrating WBC is attached with this
>>>>>>     e-mail (GIF format). Look forward to your thoughts on this issue.
>>>>>>      
>>>>>>     <dan> depends what one means when one says they "create" an
>>>>>>     ontology. An ontology is just another name for a belief
>>>>>>     system. When one writes down one's beliefs, one is not really
>>>>>>     creating an ontology. />
>>>>>>     [VK] Well, that could be part of the confusion. Another
>>>>>>     viewpoint is that an ontology is a knowledge artifact that
>>>>>>     has a broad consensus on what it means. 
>>>>>>
>>>>>>      <dan> looks like the antecedent to my statement "In small
>>>>>>     domains..." is lost somewhere above. In any case, in small
>>>>>>     domains, one can easily get a picture of all the classes on a
>>>>>>     small diagram that is easy for people to look at together. In
>>>>>>     large domains, the multitude of classes makes the diagram
>>>>>>     huge and makes it difficult to express the essentials on one
>>>>>>     computer screen or piece of paper (too many trees to see the
>>>>>>     forest). The HL7 UML model of the RIM that makes mood and
>>>>>>     class code attributes is simply a pictorial approach that
>>>>>>     assists discussion in many venues, i.e. one doesn't need a
>>>>>>     huge piece of paper on the wall! Again, not to get hung up in
>>>>>>     pictures of concepts. Focus on the concepts. />
>>>>>>     [VK] Yes, the requirement to make a model compact shouldn't
>>>>>>     negatively impact the understandability of the model. Mood
>>>>>>     and type codes can be very tricky to understand. Also these
>>>>>>     are some sort of attributes at layer 1 as opposed to Layer 2.
>>>>>>     In some cases, the model may be more understandable in one
>>>>>>     explicitly represents subclasses based on these codes. 
>>>>>>
>>>>>>>>             [VK] OK, then what you are suggesting is that a
>>>>>>>>             template is logically equivalent to a set of
>>>>>>>>             constraints on the information model. Would be
>>>>>>>>             interested in representing these conformance
>>>>>>>>             statements as a set of OWL axioms
>>>>>>>>
>>>>>>     <dan> I agree...Adding an OWL version of these conformance
>>>>>>     statements would be a great next step. />
>>>>>>      
>>>>>>     I hope this long-winded description helps in this
>>>>>>     "multi-layered Knowledge Representation" discussion. How one
>>>>>>     classifies the concept of "context" for a given concept, or
>>>>>>     the concept of "conformance testing the constraints on an
>>>>>>     aggregation of structure and vocabulary" in a multi-layer
>>>>>>     Knowledge Representation is not clear to me.
>>>>>>
>>>>>>>         <dan> There are many kinds of "conformance." One basic
>>>>>>>         example is testing the contents of a data entry field
>>>>>>>         before committing the contents to the database to make
>>>>>>>         sure the contents have the right kinds of characters,
>>>>>>>         e.g. numeric, alphabetic, etc.
>>>>>>>         [VK]  This is basically syntax checking which checks for
>>>>>>>         the format in which data is represented and is not an
>>>>>>>         information modeling or semantics issue.
>>>>>>>          
>>>>>>>          Schematron testing in CDA tests the conformance of the
>>>>>>>         XML structure and the codes and other values within the
>>>>>>>         XML structure (think terminology) to make sure the wrong
>>>>>>>         codes aren't used in a specific XML structure.
>>>>>>>         [VK] XMl structure testing can be tricky because the
>>>>>>>         healthcare IT community has used XML Schema to represent
>>>>>>>         information models. XML Schema is a language designed to
>>>>>>>         describe the format and structure of XML documents in
>>>>>>>         contrast with languages
>>>>>>>         such as RDF, OWL and UML which seek to describe the
>>>>>>>         semantics underlying these documents. So "checking for
>>>>>>>         conformance of XML Structure" could either (A) check for
>>>>>>>         the validitiy of the structure of the XML Document or
>>>>>>>         for (B) validity of the information
>>>>>>>         model (R-MIM) underlying the XML document. What would be
>>>>>>>         relevant is (B) and we could try to use OWL axioms to
>>>>>>>         describe the type of conformance statements represented
>>>>>>>         by (B)
>>>>>>>         Finally matching terminologies is a semantics issues and
>>>>>>>         OWL/Description Logics have been used to represent
>>>>>>>         Snomed and terminology matchin can be expressed in terms
>>>>>>>         of OWL subsumptions.
>>>>>>>
>>>>>>     <dan> Again...agreed...OWL is a natural tool for this task />
>>>>>>
>>>>>>>          
>>>>>>>          I'm sure that a broader definition of conformance can
>>>>>>>         be created that includes things as basic as character
>>>>>>>         validation and as complex as information
>>>>>>>         model/vocabulary model validation. />
>>>>>>>         [VK] What can easily be implemted using OWL is
>>>>>>>         information model/vocabulary validation
>>>>>>>          
>>>>>>>         In Summary, we could propose the following
>>>>>>>         Task Force which looks at the following aspects as a
>>>>>>>         part of HCLSIG:
>>>>>>>         (A)  Determine the feasibility of OWL as a common
>>>>>>>         representational formalism for healthcare delivery
>>>>>>>         information models and terminologies
>>>>>>>         (B) Define and implement the notion of "Semantic
>>>>>>>         Conformance" of an information model to HL7/RIM +
>>>>>>>         Terminologies (may require a restructuring of the RIM to
>>>>>>>         some extent)
>>>>>>>          
>>>>>>>         Let me know what your thoughts are on this and we can
>>>>>>>         figure out the next steps.
>>>>>>>          
>>>>>>>         Cheers,
>>>>>>>          
>>>>>>>         ---Vipul
>>>>>>>
>>>>>>The information transmitted in this electronic communication is intended only
>>>>>>for the person or entity to whom it is addressed and may contain confidential
>>>>>>and/or privileged material. Any review, retransmission, dissemination or other
>>>>>>use of or taking of any action in reliance upon this information by persons or
>>>>>>entities other than the intended recipient is prohibited. If you received this
>>>>>>information in error, please contact the Compliance HelpLine at 800-856-1983 and
>>>>>>properly dispose of this information.
>>>>>>
>>>>>>
>>>>>>  
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>-- 
>>>>>---------
>>>>>Samson Tu                                   email: swt@stanford.edu 
>>>>>Senior Research Scientist                   web: www.stanford.edu/~swt/
>>>>>Center for Biomedical Informatics Research  phone: 1-650-725-3391
>>>>>Stanford University                         fax: 1-650-725-7944
>>>>>
>>>>>
>>>>>
>>>>>  
>>>>>
>>>
>>>-- 
>>>---------
>>>Samson Tu                                   email: swt@stanford.edu 
>>>Senior Research Scientist                   web: www.stanford.edu/~swt/
>>>Center for Biomedical Informatics Research  phone: 1-650-725-3391
>>>Stanford University                         fax: 1-650-725-7944
>>>
>>>
>>>
>>>  
>>>
>
>-- 
>---------
>Samson Tu                                   email: swt@stanford.edu 
>Senior Research Scientist                   web: www.stanford.edu/~swt/
>Center for Biomedical Informatics Research  phone: 1-650-725-3391
>Stanford University                         fax: 1-650-725-7944
>
>
>
>  
>
Received on Thursday, 24 July 2008 03:03:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 July 2008 03:03:44 GMT