# Presentation: 820047

## Proposed Revision UML Load/Transformer Semantic Mappings for Class Inheritance

- Denise Warzel
- Bilal Elahi    Christophe Ludet  Wendy Ver Hoef
- Associate Director
- CORE Infrastructure 
- Semantics Infrastructure & Operations Team
- Presentation to VCDE
- Feb. 19, 2009

## Class Inheritance Background: 

- The annotation process is imperfect – results in different concept representations for the same information
- Why?
- Modeling differences
- Full hierarchy of a class may or may not be included in a given model, so the selection of the concepts associated with the class may appear to be different
- Model annotation performed by EVS not model owner
- Model owner working definitions – may be by design, imperfect
- Overlapping concepts in NCIt
- Inheritance not visible in the model while performing annotations
- Result: Variances in UML Class concept annotations for classes that should be semantically the same

## UML Class with Inheritance Concept Mappings - illustration

- Option 1: superclass concepts inherited by subclasses

- Option 2: superclass concepts not inherited by subclasses

- Activity (C43431)

- Activity (C43431)

## Inheritance Question?	

**Inheritance Paths:**
- Case 1
- Activity > PlannedActivity > PlannedSubstanceAdministration
- Activity > PerformedActivity > PerformedSubstanceAdministration
- Is the essence of the grandchild class supposed to be
- “PlannedActivity Planned SubstanceAdministration”?
- Or
- “PlannedActivity SubstanceAdministration”?
- Or was the model owner simply repeating the words at the lower level classes?
-  Case 2
- Activity > Planned > SubstanceAdministration
- Activity > Performed > SubstanceAdministration
- Case 2: If the concepts for each class’s super class are not included in the concept mapping for the subclass, (e.g. that substance administration is an activity) then the class conceptually different “PlannedActivitySubstanceAdministration” and “PerformedSubstanceAdministration “would each only have **Substance (CC45306) **and **Administration (C25409) **which means both those classes are mapped to the same two concepts.  (This would be an error is SIW- annotations would need to be differentiated)

## Semi-Automated Class Concept Inheritance Concerns

**Wiki Page : **This page documents the concerns around Class concept inheritance raised by VCDE Mentors, BRIDG and COPPA team members during BRIDG annotation and review, to these concerns.
- _[https://wiki.nci.nih.gov/display/CommonProjects/Semantic+Concept+Mapping+Inheritance+Concerns](https://wiki.nci.nih.gov/display/CommonProjects/Semantic+Concept+Mapping+Inheritance+Concerns)_

## Enforcement of Semantic Inheritance (examples)	

- The goal of recording Data Elements in caDSR is to accurately record individual data semantics, and to use the concept annotations of classes to detect reuse.  The following use cases look at how classes inheritance should drive semantic inheritance.
**Person Patient Doctor. **

- In this case, model uses inheritance instead of, for example, duplicating the firstName attribute in Patient and Doctor.

- Interpreting this modeling construct, SIW is able to ‘navigate’ the model and create the desired outcome:
-  - Person mapped to "Person (PConcept)“
-  - Patient mapped to "Patient (Q)" and "Person (PConcept)"
-  - Doctor mapped to "Doctor (Q)" and "Person (PConcept)"
- Semantically, this model structure is correctly reflected.

## Semantic Inheritance examples (cont.)

- This example is essentially the same as the previous case, however, it interesting to treat is as a separate use case because the outcome is significantly different. Let's look at the following model:
**DomainObject. **

- In this case, the model uses inheritance in order for objects belonging to different types to respond to method, field, or property calls of the name “DomainObject”   and the programmer (and the program) does not have to know the exact type of the object in advance: e.g. “Patient” and “Doctor”
-  This use case is similar to the previous. The desired outcome would be: (this is probably not what we want, semantically, but it illustrates the point and a follow-on recommendation)
-  - DomainObject mapped to "Domain (Q)" and "Object (PConcept)"
-  - Patient mapped to "Patient (Q2)", "Domain (Q)" and "Object (PConcept)"
-  - Doctor mapped to "Doctor (Q2)", "Domain (Q)" and "Object (PConcept)“

## Semantic Inheritance examples (cont.)

-  This use case is a combination of the previous use cases.
**DomainObject and Person**
** **
-  The desired outcome is:
-  - DomainObject mapped to "Domain (Q)" and "Object (PConcept)"
-  - Person mapped to "Person (Q2)", "Domain (Q)" and "Object (PConcept)"
-  - Patient mapped to "Patient (Q3)", "Person(Q2)", "Domain (Q)" and "Object (PConcept)"
-  - Doctor mapped to "Doctor (Q2)", "Domain (Q)" and "Object (PConcept)"

## Semantic Inheritance Real Examples

-  The following are samples taken out of models currently registered in caDSR. This section will describe SIW's new behavior, and the suggested changes that each Model Owner may have to make.  (note the Parent class is at the bottom)

**caElmir**

- In caElmir, we note the use of a class called Abstract.
- A possible outcome would be:  - AbstractSpecimen: Abstract (Q) Specimen (PConcept)
-  - Specimen: Specimen (Q2) Abstract (Q) Specimen (P)
-  - TissueSpecimen: Tissue (Q3) Specimen(Q2) Abstract (Q) Specimen (P)

## Semantic Inheritance Real Examples (cont.)

- In caTissueCore, Specimen extends "AbstractDomainObject" and both TissueSpecimen and CellSpecimen extend Specimen.**This model would load as is**, and the most likely correct annotation would be:
-  - AbstractDomainObject ---> "Abstract (Q2)" "Domain (Q)" "Object (P)“
-  - Specimen ---> "Specimen (Q3)" "Abstract (Q2)" "Domain (Q)" "Object (P)"
-  - CellSpecimen ---> "Cell (Q4)"  "Specimen (Q3)" "Abstract (Q2)" "Domain (Q)" "Object (P)"
-  - TissueSpecimen ---> "Tissue (Q4)"  "Specimen (Q3)" "Abstract (Q2)" "Domain (Q)" "Object (P)"

## SIW and UML Loader Enhancements

**Need for SIW's to support automatic Concept Harmonization**
- E.g. Ensure that annotators have a view of the model hierarchy while annotating, and also of possible parents to the class that have already been registered in caDSR, regardless of whether the class in in the model or not
**Changes to Semantic Connector**
- Minimize impact at this level in order not to cause an explosion of annotations during this phase of annotation
- Need for **Validators**
- Detect concept duplication “Planned Activity Planned Substance Administration” and allow model owners to make decisions about whether the duplication is intentional or redundant
- Design Document WIKI – Please visit the site and comment or offer additional use cases
-  _[https://wiki.nci.nih.gov/display/caDSR/SIW+to+Enforce+Semantic+Inheritance](https://wiki.nci.nih.gov/display/caDSR/SIW+to+Enforce+Semantic+Inheritance)_