1. Overview of LexEVS 5.0 LexGrid 2009 Model November, 2009

2. 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.

3. 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.

4. 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

5. 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

6. Lesson 1: LexGrid 2009 Model Overview 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

7. Lesson 1: LexGrid 2009 Model Overview 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.

8. Lesson 1: LexGrid 2009 Model Overview 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

9. Lesson 1: LexGrid 2009 Model Overview 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.

10. Lesson 1: LexGrid 2009 Model Overview 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. LexGrid Data base LexBIG Objects LexEVS API

11. Lesson 1: LexGrid 2009 Model Overview 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

12. Lesson 1: LexGrid 2009 Model Overview 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

13. Lesson 1: LexGrid 2009 Model Overview 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?

14. Lesson 1: LexGrid 2009 Model Overview 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

15. Lesson 1: LexGrid 2009 Model Overview Review 2  TRUE or FALSE: LexGrid defines how vocabularies should be formatted and represented programmatically.

16. Lesson 1: LexGrid 2009 Model Overview Answer 2  TRUE or FALSE: LexGrid defines how vocabularies should be formatted and represented programmatically. Answer: TRUE  Bonus: What advantage does this definition offer?

17. Lesson 1: LexGrid 2009 Model Overview 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.

18. Lesson 1: LexGrid 2009 Model Overview 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?

19. Lesson 1: LexGrid 2009 Model Overview 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.

20. 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.

21. Lesson 2: Modeling the Coding Scheme 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.

22. Lesson 2: Modeling the Coding Scheme Coding Scheme Elements CodingSchemesA collection of one or more coding schemes CodingSchemeA resource that makes assertions about a collection of terminological entities EntitiesA set of entity codes and their lexical descriptions RelationsA collection of relations that represent a particular point of view of community VersionsA list of past versions of the coding scheme MappingsA list of all of the local identifiers and defining URIs that are used in the associated resource PropertiesA collection of Property type elements for the coding scheme Major coding scheme elements in LexGrid

23. Lesson 2: Modeling the Coding Scheme Coding Scheme Class Note how the coding scheme class appears to be the entry point into an instance of a terminology. codingSchemes

24. Lesson 2: Modeling the Coding Scheme 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. codingSchemes

25. Lesson 2: Modeling the Coding Scheme 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

26. Lesson 2: Modeling the Coding Scheme 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.

27. Lesson 2: Modeling the Coding Scheme Retrieving a Coding Scheme If we want to retrieve a coding scheme in LexEVS what can we get? From LexBIG From LexGrid some classes are removed from these diagrams for clarity

28. 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. From LexBIG

29. 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.

30. Lesson 2: Modeling the Coding Scheme Review 1  Does the coding scheme object have a useful reference to the concepts contained in the vocabulary it defines?

31. Lesson 2: Modeling the Coding Scheme 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.

32. Lesson 2: Modeling the 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?

33. Lesson 2: Modeling the Coding Scheme 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.

34. Lesson 2: Modeling the Coding Scheme Review 3  Does a user have an option to make a method call to retrieve a “lightweight” coding scheme object from the terminology service.

35. Lesson 2: Modeling the Coding Scheme 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.

36. Lesson 2: Modeling the Coding Scheme Review 4  What does a coding scheme object define?

37. Lesson 2: Modeling the Coding Scheme 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)

38. 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.

39. Lesson 3: Concepts in LexGrid and LexBIG 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

40. Lesson 3: Concepts in LexGrid and LexBIG 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

41. Lesson 3: Concepts in LexGrid and LexBIG 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

42. Lesson 3: Concepts in LexGrid and LexBIG 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. EntityA set of lexical assertions about the intended meaning of a particular entity code InstanceAn entity that represents an instance or an individual. The entity Type for the class concept must be “instance” AssociationA 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” ConceptAn entity that represents a class or category. The entity Type for the class concept must be “concept”

43. Lesson 3: Concepts in LexGrid and LexBIG Concept (Entity) Properties CommentA 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” DefinitionA property that defines the entity in a particular language or context. The property Type of definition must be “definition” PresentationA property that represents or designates the meaning of the entityCode. The property Type of presentation must be “presentation” PropertyA 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.

44. Lesson 3: Concepts in LexGrid and LexBIG 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.

45. Lesson 3: Concepts in LexGrid and LexBIG 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.

46. Lesson 3: Concepts in LexGrid and LexBIG Review 1  Name some Entity attributes that are kinds of properties.

47. Lesson 3: Concepts in LexGrid and LexBIG Answer 1  Name some Entity attributes that are kinds of properties. Presentation, Comment, Definition, Property

48. Lesson 3: Concepts in LexGrid and LexBIG Review 2  What kind of objects inherit from the Entity class?

49. Lesson 3: Concepts in LexGrid and LexBIG Answer 2  What kind of objects inherit from the Entity class? Concept, Instance, and Association

50. Lesson 3: Concepts in LexGrid and LexBIG Review 3  We have a LexGrid concept object, why is it wrapped in a LexBIG object?

51. Lesson 3: Concepts in LexGrid and LexBIG 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.

52. Lesson 3: Concepts in LexGrid and LexBIG 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?

53. Lesson 3: Concepts in LexGrid and LexBIG 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

54. Lesson 3: Concepts in LexGrid and LexBIG Review 5  Define what a concept is in a coding scheme.

55. Lesson 3: Concepts in LexGrid and LexBIG 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

56. 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?

57. Lesson 3: Concepts in LexGrid and LexBIG 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

58. 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.

59. Lesson 4: Relations in LexBIG 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.

60. Lesson 4: Relations in LexBIG 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.

61. Lesson 4: Relations in LexBIG 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

62. Lesson 4: Relations in LexBIG 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.

63. 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. Some entities are removed from these diagrams for clarity

64. 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?

65. Lesson 4: Relations in LexBIG 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 Resolved Concept Reference Associated Concept a Associated Concept g Concept b Associated Concept e Concept c Concept h Concept d Associated Concept f Resolved Concept Reference Concept j Concept i subClassOf Is_a Some_kind _of Is_a Sort_of_a Might_be_ a Could_have _been subClassOf Alpha Beta

66. Lesson 4: Relations in LexBIG LexGrid Association While metadata about the association is still stored in a LexGrid table (And is accessible as such)

67. Lesson 4: Relations in LexBIG 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.

68. Lesson 4: Relations in LexBIG 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

69. Lesson 4: Relations in LexBIG Review 2  LexGrid has a modeled example for both Association functionality and metadata. What does LexEVS use for functionality? How about Association metadata?

70. Lesson 4: Relations in LexBIG 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.

71. Lesson 4: Relations in LexBIG Review 3  Define what an association is in a coding scheme. (The short answer)

72. 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).

73. 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.

74. Lesson 4: Relations in LexBIG Answer 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. The relations container still defines discrete containers in which associations can occur.

75. Lesson 4: Relations in LexBIG Review 5  A ResolvedConceptReference is a wrapper for concepts only … right?

76. Lesson 4: Relations in LexBIG Answer 5  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.

77. Lesson 4: Relations in LexBIG Review 6  How does LexBIG represent an association for LexEVS?

78. Lesson 4: Relations in LexBIG 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.

79. 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.

80. Lesson 5: Model History and Transition 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.

81. 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. Reminder: some classes are removed from these diagrams for clarity

82. 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.

83. Lesson 5: Model History and Transition 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.

84. Lesson 5: Model History and Transition LexBIG So while the ResolvedCodedNodeReference has a reference to an Entity object…

85. Lesson 5: Model History and Transition LexBIG …ResolvedConceptReference maintains a reference to the legacy object

86. Lesson 5: Model History and Transition 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

87. Lesson 5: Model History and Transition 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.

88. Lesson 5: Model History and Transition Review 1  What is the difference between a ResolvedCodedNodeReference and a ResolvedConceptReference?

89. Lesson 5: Model History and Transition 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.

90. Lesson 5: Model History and Transition Review 2  Why did we need to rename the “Concept” class?

91. Lesson 5: Model History and Transition 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.

92. Lesson 5: Model History and Transition Review 3  What do developers have to do to adapt to these changes

93. Lesson 5: Model History and Transition 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.

94. 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.

95. Lesson 6: EVS to LexGrid 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.

96. Lesson 6: EVS to LexGrid EVS elements vs LexGrid elements EVS ModelLexGrid Model DescLogicConceptEntity MetaThesaurusConceptEntity RoleAssociation QualifierAssociationQualifier VocabularyCodingScheme Property Presentation PropertyDefinition PropertyComment

97. Lesson 6: EVS to LexGrid 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?

98. Lesson 6: EVS to LexGrid 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.

99. Lesson 6: EVS to LexGrid Review 2  All these property definitions … which one will help me get a brief description of the concept when making a QBE call?

100. Lesson 6: EVS to LexGrid 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.

101. 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.

102. 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?

103. 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

104. 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?

105. 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.

106. 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?

107. 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

108. LexGrid 2009 Model Review 4  What’s the importance of creating semantically neutral elements in the LexGrid model?

109. 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

110. 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

111. Questions?