overview of lexevs 5.0 lexgrid 2009 model november, 2009

Overview of LexEVS 5.0

LexGrid 2009 Model

November, 2009

Session Details: LexGrid 2009 Model Course Outline

• Overview of LexGrid, the data model for the LexEVS terminology service.

• Define core structures of the terminology model in LexGrid, the terminology service data model, and in LexBIG, the service model.

• LexEVS use of core structures via LexGrid model elements (through LexBIG, directly, or with LexBIG acting as a surrogate).

• 2009 model elements and/or changes from the previous model(s)

• how those changes may affect legacy program implementation.

Session Details: LexGrid 2009 Model Course Objectives

When you complete this course, you will be able to: • Understand the core structure and relations of the LexGrid Data Model and

the LexBIG Service models.

• Define the purpose of the LexBIG model in relation to the LexGrid model and the LexEVS API.

• Discuss the model elements that are new in 2009 and/or changes from the previous model(s) and understand how those changes may affect legacy program implementation.

Session Details: LexGrid 2009 Model Lesson Syllabus

• Lesson 1: LexGrid 2009 Model Overview

• Lesson 2: Modeling the Coding Scheme

• Lesson 3: Concepts in LexGrid and LexBIG

• Lesson 4: Relations in LexBIG

• Lesson 5: Model History and Transition

• Lesson 6: EVS to LexGrid -- correlations

Lesson 1: LexGrid 2009 Model Overview

• When you complete this lesson, you will be able to: • Use core objects to define how LexEVS works through LexBIG to access

elements stored in the data model, LexGrid.

• Understand the advantage of LexGrid as a Terminology Service model.

• Recite details of the implementation of LexGrid as used by LexEVS


What Is It?

• The LexGrid Model is Mayo’s proposed mechanism for standard storage of controlled vocabularies and ontologies:

• Defines HOW vocabularies should be formatted and represented programmatically

• Flexible enough to accurately represent a wide variety of vocabularies and other lexically-based resources

• Defines several different server storage mechanisms and a XML format

• Provides the core representation for all data managed and retrieved through the LexEVS system


Why is it useful ?

• Once the vocabulary information is represented in a standardized format, it becomes possible to build common repositories to store vocabulary content and common programming interfaces and tools to access and manipulate that content.

• For Example: …

• Terminologies from widely varying resources such as RRF, OWL, and OBO can be loaded to a single data base management system and accessed with an single API.


What’s New?

• Model accommodates entities other than concept/instance/association

• Attributes are converged (e.g. associated properties) to ‘Entity’ superclass

• Single resource can be defined as multiple types

• Allows more granular version tracking (e.g. per concept or per property)

• Extensive updates have been made to value domain and pick list representation

• Antiquated packages & classes (e.g. LDAP) have been removed.

• Improved accuracy and alignment of internal lexicon (URNMap -> URIMap)

• Influenced by CTS2, OWL, XMDR, GE/IHC


LexBIG model

• The LexGrid model stands alone as a complete terminology model

• LexEVS uses the LexBIG model in conjunction with the LexGrid model

• Why is this the necessary?• Let’s define these three elements to see why.


LexGrid, LexBIG and LexEVS

• LexEVS: Optimizing query code that retrieves LexBIG objects.

• LexBIG: How the terminology service looks as objects returned to the user.

• LexGrid: How the terminology service looks

• in a data base.

• As we continue our discussion of the LexGrid model, it will always be with an eye towards its place in the LexEVS API.

LexGridData base

LexBIGObjects

LexEVSAPI


Model Definition

• We’ll use some core objects to show how LexGrid, LexEVS and LexBIG work together:

• High level core objects incorporated into the LexGrid model definition

• Coding Scheme• Concept• Association

• These objects are touchstones for the most common traversal paths through LexEVS and into LexGrid


Developers Note

• model attribute types are described in classes as non-platform specific types to insure platform neutrality

• In this example:• formal Name is of type

tsCaseIgnoreIA5String. (Where the “ts” means terminology service)

• But when this model element is generated into Java source code by a tool for LexEVS it is generated as a java.lang.String.

codingSchemes


Review 1

We’re going to use core objects to define how LexEVS works through LexBIG to access element stored in the data model, LexGrid. What are the three core objects?


Answer 1

What are the three core objects that define how LexEVS works through LexBIG to access element stored in the data model, LexGrid? Coding Scheme Concept Relations


Review 2

TRUE or FALSE: LexGrid defines how vocabularies should be formatted and represented programmatically.


Answer 2

TRUE or FALSE: LexGrid defines how vocabularies should be formatted and represented programmatically. Answer: TRUE

Bonus: What advantage does this definition offer?


Bonus Answer

TRUE or FALSE: LexGrid defines how vocabularies should be formatted and represented programmatically. Answer: TRUE

Bonus: What advantage does this definition offer? It gives the user the flexibility to accurately represent a wide

variety of vocabularies and other lexically-based resources. Once this is done, it becomes possible to build common repositories to store vocabulary content and common programming interfaces and tools to access and manipulate that content.


Review 3

The model driven architecture of LexEVS dictates a java representation of LexGrid and LexBIG. How do model attributes change when java code is generated?


Answer 3

The model driven architecture of LexEVS dictates a java representation of LexGrid and LexBIG. How do model attributes change when java code is generated? For LexEVS, many model attributes that are LexGrid objects

become low level java objects such as Strings or Booleans or may even be represented as java primitives.

Lesson 2: Modeling the Coding Scheme

• When you complete this lesson set, you will be able to: • Recite what some of the attributes of a coding scheme are and

how they are defined in LexBIG and LexGrid so that they can be used by LexEVS.

• Gain some perspective on how, in general, LexBIG and LexGrid work together.


Coding Scheme in LexGrid

• A coding scheme object in LexGrid contains metadata about the coding scheme.

• The population of a coding scheme object’s attributes can define how a coding scheme is structured and represented.

• Developers need be able to access this information to understand how properties and relationships and other elements in the coding scheme are defined.


Coding Scheme Elements

CodingSchemes A collection of one or more coding schemes

CodingScheme A resource that makes assertions about a collection of terminological entities

Entities A set of entity codes and their lexical descriptions

Relations A collection of relations that represent a particular point of view of community

Versions A list of past versions of the coding scheme

Mappings A list of all of the local identifiers and defining URIs that are used in the associated resource

Properties A collection of Property type elements for the coding scheme

Major coding scheme elements in LexGrid


Coding Scheme Class

Note how the coding scheme class appears to be the entry point into an instance of a terminology.

codingSchemes

class CodingScheme

lgCommon:versionableAndDescribable

«XSDcomplexType»codingScheme

«XSDattribute»+ approxNumConcepts: tsInteger+ codingSchemeName: lgCommon:codingSchemeName+ codingSchemeURI: lgCommon:URI+ defaultLanguage: lgCommon:language+ formalName: tsCaseIgnoreIA5String+ representsVersion: lgCommon:version

«XSDelement»+ copyright: lgCommon:text [0]+ localName: tsCaseIgnoreIA5String [0..*]+ properties: lgCommon:properties [0]+ source: lgCommon:source [0]


Coding Scheme Queries

You might surmise that a user would get a coding scheme object, and through it query the entities (or concepts) through a coding scheme class. But you’ll soon find that this is not the case.

class CodingScheme

«XSDcomplexTyp...Concepts::Entities

«XSDelement»+ entity: Entity [1..*]

codingSchemes


Coding Scheme Class

Becoming a student of the LexGrid Model does not necessarily inform the user of how the LexEVS API uses the model.

While the coding scheme representation of the model provides a useful metadata container the entry point to LexGrid data Model elements from LexEVS lies elsewhere.

codingSchemes


Coding Schemes in LexGrid

• The actual entry point is through LexBIG, the service model and a “permeable” layer above the LexGrid Model

• The LexBIG model largely acts as a layer between LexEVS and LexGrid. When it does it functions in three categories:

• an alternative to LexGrid Objects

• an option to fully resolving LexGrid Objects

• a functional replacement for LexGrid relationships

• As we proceed through each of the high level coding scheme objects we’ll touch on at least one of these kinds of LexBIG behavior.


Retrieving a Coding Scheme

• If we want to retrieve a coding scheme in LexEVS what can we get?

class CodingSchemeRendering

«XSDcomplexType»CodingSchemeRendering

«XSDelement»+ referenceLink: ReferenceLink [0..1]+ serviceHandle: ReferenceLink

«XSDcomplexType»Core::CodingSchemeSummary

«XSDelement»+ codingSchemeDescription: entityDescription [0..1]+ formalName: tsCaseIgnoreIA5String

«XSDattribute»+ codingSchemeURI: URI+ localName: tsLocalId+ representsVersion: version

+codingSchemeSummary 1

class CodingScheme

lgCommon:versionableAndDescribable

«XSDcomplexType»codingScheme

«XSDattribute»+ approxNumConcepts: tsInteger+ codingSchemeName: lgCommon:codingSchemeName+ codingSchemeURI: lgCommon:URI+ defaultLanguage: lgCommon:language+ formalName: tsCaseIgnoreIA5String+ representsVersion: lgCommon:version

«XSDelement»+ copyright: lgCommon:text [0]+ localName: tsCaseIgnoreIA5String [0..*]+ properties: lgCommon:properties [0]+ source: lgCommon:source [0]

From LexBIG

From LexGrid

some classes are removed from these diagrams for clarity

Lesson 2: Modeling the Coding Scheme Retrieving a Coding Scheme (cont’d)

A lightweight object with the absolute minimum information required to distinguish it in the terminology service.

An advantage to retrieving this object is that no calls will be made to the data base, instead it searches a local Lucene index to quickly verify that this coding scheme exists in this terminology service.

class AbsoluteCodingSchemeVersionReference

«XSDcomplexType»AbsoluteCodingSchemeVersionReference

«XSDattribute»+ codingSchemeURN: tsURI+ codingSchemeVersion: version

From LexBIG

Lesson 2: Modeling the Coding Scheme After Retrieving the Coding Scheme

• After retrieving a coding scheme object in any of these cases we still don’t have a reference to an object that connects us with the nodes and hierarchies of a coding scheme.

• But we have established a pattern for LexBIG.

• It provides an option to resolve a potentially heavyweight object as an object that contains the minimum reference required to distinguish it either within the terminology service, or within a terminology.


Review 1

Does the coding scheme object have a useful reference to the concepts contained in the vocabulary it defines?


Answer 1

Does the coding scheme object have a useful reference to the concepts contained in the vocabulary it defines? It has a reference to an entities container, but that reference is not how

LexEVS returns concepts for a coding scheme.


Review 2

Can you directly access the LexGrid coding scheme object from LexEVS or must you make a call to a wrapper object from LexBIG?


Answer 2

Can you directly access the LexGrid coding scheme object from LexEVS or must you make a call to a wrapper object from LexBIG? Coding Scheme metadata can be referenced from both LexBIG and

LexGrid.


Review 3

Does a user have an option to make a method call to retrieve a “lightweight” coding scheme object from the terminology service.


Answer 3

Does a user have an option to make a method call to retrieve a “lightweight” coding scheme object from the terminology service. Yes they do, using the AbsoluteCodingSchemeVersionReference Object

which is populated in LexEVS by accessing a Lucene index.


Review 4

What does a coding scheme object define?


Answer 4

What does a coding scheme object define? The coding scheme object defines metadata about the coding scheme.

Containers for sets of relationships, properties for the coding scheme, supported attributes used in the coding scheme (For example, associations and property types for concepts and their relationships)

Lesson 3: Concepts in LexGrid and LexBIG

• When you have finished this lesson you should be able to:

• Identify the attributes of an Entity

• Know what kind of objects inherit from the Entity class.

• Understand why the LexGrid object is wrapped in a LexBIG object for use by LexEVS.

• Define what a concept is in a coding scheme.

• Understand what parts of a concept needs to be defined in coding scheme metadata.


Concept (Entity)

• How do we get those concepts anyway?

• We have a reference to an entities container from the LexGrid CodingScheme, but it is not populated with the entities of this container.

• We have references to LexBIG CodingSchemeRendering and the minimal coding scheme reference, but neither has a reference to concepts or entities


Concepts and LexBIG

• Instead the LexBIG service model retrieves “concept” objects directly, by-passing LexGrid Coding Scheme objects and working through the LexBIG service model.

• ResolvedConceptReference objects should be familiar to users of the LexEVS API. LexGrid Concepts are retrieved from these objects wrapped in a LexBIG service model object, the ResolvedConceptReference.

• This is an example of how LexBIG provides an option to LexGrid objects and can provide a minimal reference to a fully resolved object. (More on how this works later.)

LexGrid

LexBIG

class Concept core

ResolvedCodedNodeReference

«XSDcomplexType»ResolvedConceptReference

Entity

«XSDcompl...Concepts::

Concept

+referencedEntry 0..1


Concept

• A coding scheme may define zero or more coded concepts, encapsulated within a single container.

• A concept:

• Represents a coded entity within a particular domain of discourse

• Is unique within the code system that defines it

• Must be qualified by at least one designation represented in the model as a property to be valid

• Intended meaning may be represented or defined by a property or characteristic such as an attribute or facet

• May be the source for and/or the target of zero or more relationships.

• A legacy implementation in the model, slated to be replaced by the model element Entity


Concepts: Entity and Its Types

• The Concept class still exists in LexGrid but it inherits its characteristics from the Entity class. How the Entity class came to be is a part of Lesson 5, History and Transition.

Entity A set of lexical assertions about the intended meaning of a particular entity code

Instance An entity that represents an instance or an individual. The entity Type for the class concept must be “instance”

Association A binary relation from a set of entities to a set of entities and/or data. The entity Type for the class concept must be “association”

Concept An entity that represents a class or category. The entity Type for the class concept must be “concept”


Concept (Entity) Properties

Comment A property that is used as an annotation or other note about the state or usage of the entity. The property Type of comment must be “comment”

Definition A property that defines the entity in a particular language or context. The property Type of definition must be “definition”

Presentation A property that represents or designates the meaning of the entityCode. The property Type of presentation must be “presentation”

Property A description, definition, annotation or other attribute that serves to further define or identify a resource

When we talk about how a property type must be defined we mean defined in the coding scheme as a supported attribute.


Concept (Entity)

This diagram contains a centrally located class Entity which has references to 4 property classes Presentation, Comment, Property, and Definition. It also has a reference to a Property Link class. Concept, Instance and Association classes are shown inheriting from the Entity class.

class Concepts

versionableAndDescribable

«XSDcomplexType»Entity

«XSDattribute»+ entityCode: entityCode+ entityCodeNamespace: namespaceName+ isAnonymous: tsBoolean+ isDefined: tsBoolean

«XSDelement»+ entityType: entityType [0..*]+ property: property [0..*]

«XSDcompl...Concept

«XSDcompl...Instance

property

«XSDcompl...Comment

property

«XSDcomplexType»Definition

«XSDattribute»+ isPreferred: tsBoolean

property

«XSDcomplexType»Presentation

«XSDattribute»+ degreeOfFidelity: degreeOfFidelity+ isPreferred: tsBoolean+ matchIfNoContext: tsBoolean+ representationalForm: representationalForm

«XSDcomplexType»PropertyLink

«XSDattribute»+ propertyLink: propertyLinkName+ sourceProperty: propertyId+ targetProperty: propertyId

«XSDcomplexType»Relations::association

«XSDattribute»+ associationName: associationName+ forwardName: tsCaseIgnoreIA5String+ inverse: associationName+ isAntiReflexive: tsBoolean+ isAntiSymmetric: tsBoolean+ isAntiTransitive: tsBoolean+ isFunctional: tsBoolean+ isNavigable: tsBoolean+ isReflexive: tsBoolean+ isReverseFunctional: tsBoolean+ isSymmetric: tsBoolean+ isTransitive: tsBoolean+ reverseName: tsCaseIgnoreIA5String

versionable

«XSDcomplexType»CommonTypes::property

«XSDattribute»+ language: language

«XSDextension»

«XSDextension»«XSDextension»

+propertyLink

0..*

+comment

0..*

+definition 0..*

+presentation

0..*

+property 0..*


Concept (Entity)

Why should we wrapper the entity object with a LexBIG object?

Because a “Resolved” reference object in LexBIG inherits attributes that can represent the minimum information required to distinguish a concept in a vocabulary.

This means resolving the contained concept is optional and that resolving the minimal ResolvedConceptReference can be done against a Lucene index just like the minimal coding scheme reference.

This is a useful, performance enhancing, option that developers should use whenever a list of concepts is required for further processing.

class Concept core



Entity

«XSDcompl...Concepts::

Concept



Review 1

Name some Entity attributes that are kinds of properties.


Answer 1

Name some Entity attributes that are kinds of properties. Presentation, Comment, Definition, Property


Review 2

What kind of objects inherit from the Entity class?

Lesson 3: Concepts in LexGrid and LexBIG Answer 2

What kind of objects inherit from the Entity class? Concept, Instance, and Association


Review 3

We have a LexGrid concept object, why is it wrapped in a LexBIG object?


Answer 3

We have a LexGrid concept object, why is it wrapped in a LexBIG object? It allows high performance list creation with light weight objects, which

can be used with API calls to fully resolve each object as needed.


Review 4

ResolvedConceptReference class has attributes which uniquely identify a concept within a terminology releasing the user from the need to resolve an entire entity. What do you suppose those attributes are?


Answer 4

ResolvedConceptReference class has attributes which uniquely identify a concept within a terminology releasing the user from the need to resolve an entire entity. What do you suppose those attributes are? Coding scheme name and version and the concept code of a concept


Review 5

Define what a concept is in a coding scheme.


Answer 5

Define what a concept is in a coding scheme Represents a coded entity within a particular domain of discourse Is unique within the code system that defines it Must be qualified by at least one designation represented in the model as

a property to be valid Intended meaning may be represented or defined by a property or

characteristic such as an attribute or facet May be the source for and/or the target of zero or more relationships

Lesson 3: Concepts in LexGrid and LexBIG Review 6

Why does the property type of a concept property have to be defined for the coding scheme?


Answer 6

Why does the property type of a concept property have to be defined for the coding scheme? Business rules within the terminology service require that it be stated as a

supported property for the coding scheme

Lesson 4: Relations in LexBIG

• At the end of this lesson you should be able to:

• Define what an association is in a coding scheme.

• Understand how LexBIG represents an association for LexEVS

• Enlarge your understanding of what a ResolvedConceptReference can represent in the LexBIG model.

• Explain the place of a LexGrid association in the coding scheme.


Relations in LexBIG and LexGrid

• We’ve seen how coding schemes and the concepts they contain can be expressed and accessed by the user. But how, in these models, are relationships expressed and accessed?

• We have the LexGrid coding scheme which defines a “Relations” container for relationships.

• It also defines SupportedAssociations in its “Mappings ” container.

• LexBIG coding scheme objects do not describe association containers, but LexBIG does describe discrete association objects.

• These association objects are attached to ResolvedConceptReference objects.


Coding Scheme Relation Containers

• Each coding Scheme may define one or more containers to encapsulate relationships between concepts.

• The LexGrid Relations class represents that container.

• Each relations container must define one or more association.


Coding Scheme Associations

• Each named relationship (e.g. “hasSubtype” or “hasPart”) is represented as an Association.

• The association definition may also further define the nature of the relationship in terms of transitivity, symmetry, reflexivity, forward and inverse names, etc.

• Multiple instances of each association can be defined, each of which provide directed relationships between source and target concepts.

• Source and target concepts may be contained in the same code system as the association or another if explicitly identified.

• By default, all source and target concepts are resolved from the code system defining the association.

• The code system can be overridden by each specific association, relation source or relation target


LexBIG Associations

Association The representation of a particular association as it appears in a CodedNode. (A binary relation from a set of entities to a set of entities and/or data. The entityType for the class concept must be "association".)

AssociationList A list of Binary Relations defined as LexBIG Associations.

ResolvedCodedNodeReference Resolved information for an entity identified by coding scheme and code.

ResolvedConceptReference Resolved information for a concept. Maintained for backward compatibility, but no longer enhanced in favor of the more flexible ResolvedCodedNodeReference.

Lesson 4: Relations in LexBIG LexBIG Association

The LexGrid association is not used to represent the structure of associations for LexEVS.

The service model provides this functionality.

LexBIG associations are defined in sourceOf and targetOf lists.

class Core

ConceptReference

«XSDcomplexType»ResolvedCodedNodeReference

«XSDattribute»+ codingSchemeURI: tsURI+ codingSchemeVersion: version

«XSDelement»+ entity: Entity [0..1]+ entityDescription: entityDescription [0..1]


«XSDelement»+ referencedEntry: Concept [0..1]

«XSDcomplexType»Collections::AssociationList

«XSDcomplexType»Association

«XSDelement»+ associatedConcepts: AssociatedConceptList [0..1]+ associatedData: AssociatedDataList [0..1]

«XSDattribute»+ associationName: tsLocalId+ directionalName: tsCaseIgnoreIA5String

«XSDextension»

0..*

+sourceOf

0..1

+targetOf

0..1

Some entities are removed from these diagrams for clarity

Lesson 4: Relations in LexBIG LexBIG Association

Associations are linked, in turn, to the source or target concepts of the original ResolvedConceptReference object via a

list of AssociatedConcepts

Since AssociatedConcepts are a kind of ResolvedConceptReference, this completes relationships between entities and insures the ability to

traverse a given terminology’s hierarchy of relationships

What might this look like?

class Core

«XSDcomplexType»Association

«XSDelement»+ associatedData: AssociatedDataList [0..1]

«XSDattribute»+ associationName: tsLocalId+ directionalName: tsCaseIgnoreIA5String

ResolvedConceptReference

«XSDcomplexType»AssociatedConcept

«XSDelement»+ associationQualifiers: NameAndValueList [0..1]

«XSDattribute»+ isNavigable: boolean

«XSDcomplexType»Collections::AssociatedConceptList

+associatedConcepts 0..1

0..*


LexBIG Association

If your method returns Resolved Concept Reference “Alpha” with all source and target associations then you will get and association list containing subClassof and Is_a. In turn these will have an Associated Concept list of one element.

Associated concepts are types of Resolved Concept references, so they can contain their own references to source and target association lists. In this case concept a has a list with two target associations, subClassof and Could_have_been. Subclassof has a list of two associated concepts: concept b and concept c. The association “Could have been” contains a list of associated concepts with one concept, concept d.

The first example is a “root” node. That is, it has no parent nodes so no source association exists. The Beta resolved concept reference has both source and target associations.

Options in LexEVS will allow you to resolve all or parts of these hierarchies as well as all or part of the concepts, so that the user can adjust returned sets of resolved concept references tailored to the needs of the user.

subClassOf

ResolvedConcept

Reference

Associated Concept a

Associated Concept g

Concept b

Associated Concept e

Concept c

Concept h

Concept d

Associated Concept f

ResolvedConcept

Reference

Concept jConcept i

subClassOf Is_a

Is_a

Is_a

Some_kind_of

Is_a

Sort_of_a

Sort_of_aMight_be_a

Could_have_beensubClassOf

Alpha

Beta


LexGrid Association

While metadata about the association is still stored in a LexGrid table (And is

accessible as such)

class Relations

Entity

«XSDcomplexType»association



Why LexGrid and LexBIG?

• LexBIG provides references into the data model without requiring resolution of the a complete terminology node set or graph.

• As such it functions as a kind of lazy loading mechanism, similar to what can be found in Hibernate.

• Elements of LexBIG that are resolved in a minimal manner can often avoid database calls by referring to a Lucene index, saving response time.


Review 1

We’ve learned how associations are handled by LexBIG and LexGrid for LexEVS. How can we put that knowledge into practice? (A rhetorical question) No answer expected


Review 2

LexGrid has a modeled example for both Association functionality and metadata. What does LexEVS use for functionality? How about Association metadata?


Answer 2

LexGrid has a modeling for both Association functionality and metadata. What does LexEVS use for functionality? How about Association metadata. LexEVS uses the LexBIG model to represent associations. Association

metadata is still represented by the LexGrid Association class.

Lesson 4: Relations in LexBIG Review 3

Define what an association is in a coding scheme. (The short answer)

Lesson 4: Relations in LexBIG Answer 3

Define what an association is in a coding scheme. (The short answer) A binary relation between two concepts (entities).

Lesson 4: Relations in LexBIG Review 4

We’ve learned we won’t retrieve concepts from an entities container. Will we retrieve associations from a “Relations” object? If not how is the Relations container used.


We’ve learned we won’t retrieve concepts from an entities container. Will we retrieve associations from a “Relations” object? If not how is the Relations container used. The relations container still defines discrete containers in which

associations can occur.


Review 5

A ResolvedConceptReference is a wrapper for concepts only … right?


A ResolvedConceptReference is a wrapper for concepts only … right? Resolved Concept References also can contain references to

associations. Therefore it can represent both sets of concept nodes and graphs of concept nodes.


Review 6

How does LexBIG represent an association for LexEVS?


Answer 6

How does LexBIG represent an association for LexEVS The resolved concept reference contains references to “source of” and

“target of” associations. In turn these associations maintain references to any associated concepts, which are kinds of resolved concept references.

Lesson 5: Model History and Transition

• When you finish this lesson you should be able to:

• Distinguish between a ResolvedCodedNodeReference and a ResolvedConceptReference

• Understand what prompted changes in the renaming of “Concept” class.

• Know the consequences of this change for developers.


Overview

• Since the 2006 version of the LexGrid model, it was discussed how naming model elements confused the structure of a terminology model with the what the model is actually supposed to represent.

• Changing model element names from say, concept to entity, allows a more semantically neutral implementation of terminology nodes.

• While this changes implementations of LexEVS, it may also allow LexEVS to implement more accurate representations of terminology sources.

Lesson 5: Model History and Transition History and Transition

This slide shows two diagrams demonstrating the current transition to the neutrally named classes Resolved Coded Node Reference and Entity from Resolved Concept Reference and concept.

class Entity

ConceptReference

«XSDcomplexType»Core::Resolv edCodedNodeReference


«XSDelement»+ entityDescription: entityDescription [0..1]





+entity 0..1

Reminder: some classes are removed from these diagrams for clarity

Lesson 5: Model History and Transition The First Step

In the LexGrid model, for purposes of backward compatibility, concept became a type of Entity.

Instances were included to provide an implementation of owl individuals.

Associations also became a type of entity insuring another model element has semantic neutrality.

class Entity





«XSDcompl...Concept

«XSDcompl...Instance

«XSDcomplexType»Relations::association


«XSDextension» «XSDextension»

«XSDextension»


LexBIG

• LexBIG neutral elements CodedNodeReference and ResolvedCodedNodeReference are included in the LexGrid 2009 model.

• ConceptReference and ResolvedConceptReference become types of the neutral elements in order to maintain backwards compatibility.

class CodedNode

«XSDcomplexType»CodedNodeReference

«XSDattribute»+ code: entityCode+ codeNamespace: namespaceName

«XSDelement»+ entityType: entityType [0..*]

«XSDcomplexType»ConceptReference

«XSDelement»+ conceptCode: entityCode [0..1]





«XSDextension»

«XSDextension»

«XSDextension»

Lesson 5: Model History and Transition LexBIG

So while the ResolvedCodedNodeReference

has a reference to an Entity object…

class CodedNode

ConceptReference





«XSDcomplexType»Concepts::Entity



+entity 0..1


LexBIG

…ResolvedConceptReference maintains a reference to the legacy object

class CodedNode



Entity

«XSDcomplexType»Concepts::Concept



Consequences

• What are the consequences of making concepts and associations types of the class Entity and adding instances.

• Concepts are currently treated as a legacy object and still available to the user with some changes in attribute names

• Instances are now loaded as a type of Entity• When the Entity type is set to instance, it is available to the API through the

ResolvedCodedNodeReference or CodedNodeReference

• Association names are loaded as they were before in RRF and OBO loads

• NCI Owl source changes in conjunction with model changes allowing associations to inherit from entity cause associations to be loaded with a numerical code instead of a association name in our entityAssocToEntity table


LexBIG - Associations

Associations from NCI OWL sources are stored with an entity code instead of the association name. This requires a different call from the LexEVS API for retrieval of the association name.


Review 1

What is the difference between a ResolvedCodedNodeReference and a ResolvedConceptReference?


Answer 1

What is the difference between a ResolvedCodedNodeReference and a ResolvedConceptReference? Resolved coded node reference is a more neutrally named class than one

with the word concept in the name. As such it provides the user with some assurance that it is entity neutral and nonspecific in application.


Review 2

Why did we need to rename the “Concept” class?


Answer 2

Why did we need to rename the “Concept” class? Classes with the name concept confused terminology modeling objects

with instances of objects that were concepts.


Review 3

What do developers have to do to adapt to these changes


Answer 3

What do developers have to do to adapt to these changes? Developers can use legacy objects which inherit from the neutrally named

object.

Lesson 6: EVS to LexGrid

• When you complete this lesson you will be able to :

• Understand how to resolve concepts in a manner similar to that used for the EVS data service.

• Sort out what concept property might best give a brief description of the concept.


Overview

• EVS model and the LexGrid model are quite differenct

• LexGrid is larger and more complex in many ways.

• Data services pulled data elements from EVS model elements, and data services have been created for LexEVS as well

• While model elements are similar a brief comparison between the two is worth while.


EVS elements vs LexGrid elements

EVS Model LexGrid Model

DescLogicConcept Entity

MetaThesaurusConcept Entity

Role Association

Association Association

Qualifier AssociationQualifier

Vocabulary CodingScheme

Property Property

Property Presentation

Property Definition

Property Comment


Review 1

I’d like to get a Metathesaurus concept while making a RESTful interface call. This doesn’t exist anymore. What do I do now?


Answer 1

I’d like to get a Metathesaurus concept while making a RESTful interface call. This doesn’t exist anymore. What do I do now? Make a call to Concept (Entity) which encompasses both previous types

of Concepts.


Review 2

All these property definitions … which one will help me get a brief description of the concept when making a QBE call?


Answer 2

All these property definitions … which one will help me get a brief description of the concept when making a QBE call? The presentation type of property will provide the best brief description of

the concept.

LexGrid 2009 Model

Review: Points to Remember

• For implementation in LexEVS attributes are generally generated in a platform specific set of primitives from the schema

• The LexBIG service model overrides some of the LexGrid model’s functions.

• That is, what appear to be active representations of entry points and associations in the model have their functions subsumed by LexBIG model elements.

• Instead as in the cases of coding scheme and association classes, the LexGrid model elements maintain metadata about those elements.

• The model is in transition and maintains legacy elements to provide backwards compatibility

• We’ve presented a subset of the model -- largely a vertical slice of model elements most likely traversed by a common method call in LexEVS.

• There is more to learn.

LexGrid 2009 Model

Review 1

The LexGrid Coding Scheme entities object contains the coding scheme entities in LexGrid. Is this the entry point for accessing LexGrid concept objects?

LexGrid 2009 Model

Answer 1

The LexGrid Coding Scheme entities object contains the coding scheme entities in LexGrid. Is this the entry point for accessing LexGrid concept objects? No, the entry point for accessing LexGrid concepts is the

ResolvedConceptReference

LexGrid 2009 Model

Review 2

LexGrid and LexBIG both model relations between terminology nodes. Which does LexEVS use to allow the user to traverse relations? Which does LexEVS use to get Association metadata?

LexGrid 2009 Model

Answer 2

LexGrid and LexBIG both model relations between terminology nodes. Which does LexEVS use to allow the user to traverse relations? Which does LexEVS use to get Association metadata? LexEVS uses the ResolvedConceptReference to access LexBIG type

associations and traverses those associations based on whether they are in a list of source or target associations.

LexEVS uses LexGrid associations as the template for storing metadata about associations.

LexGrid 2009 Model

Review 3

LexBIG defines the attribute “associationName” in the class “Association” as type “tsLocalId”. What’s your guess as to what type it is in the java source generated by Castor, the designated code generation tool?

LexGrid 2009 Model

Answer 3

LexBIG defines the attribute “associationName” in the class “Association” as type “tsLocalId”. What’s your guess as to what data type it is in the java source generated by Castor, the designated code generation tool? The correct guess would be java.lang.String

LexGrid 2009 Model

Review 4

What’s the importance of creating semantically neutral elements in the LexGrid model?

LexGrid 2009 Model

Answer 4

LexGrid is a full terminology service model. Why does LexEVS use LexBIG model elements to retrieve data model elements? LexBIG is the service model and as such it creates a layer of objects

useful in the way they can be adapted to use less overhead

Session Details: LexGrid 2009 Model

Resources and References

• Reference on the transition to semantically neutral elements in LexGrid:

• http://icbo.buffalo.edu/Proceedings.pdf

• A white paper on LexGrid:

• http://www.jamia.org/cgi/reprint/16/3/305.pdf

• Model representations in xsd format:

• http://informatics.mayo.edu/LexGrid/index.php?page=lgm

• http://informatics.mayo.edu/LexGrid/index.php?page=lexex

http://icbo.buffalo.edu/Proceedings.pdf

http://icbo.buffalo.edu/Proceedings.pdf

http://www.jamia.org/cgi/reprint/16/3/305.pdf

http://informatics.mayo.edu/LexGrid/index.php?page=lgm




http://informatics.mayo.edu/LexGrid/index.php?page=lexex




Questions?

overview of lexevs 5.0 lexgrid 2009 model november, 2009

Documents

lexgrid data model

lexgrid model elements

terminology model

model history

model overviewlesson

model overviewwhy

model overviewwhen

implementation of lexgrid