1. Loader Tutorial

2. Set Up Mapping Coding Scheme Values to LexGrid Model Creating a Loader – Step by Step Loader Review

3. Map Source to LexGrid See Excel File

4. Write Your Own Loader Navigate to the lbInterfaces project folder Extend the Loader Interface with your own custom interface called FrenimiesLoader. Add public final static attributes name and description Add load and validate methods This will be what LexEVS calls to load your terminology

5. Create an Implementation of the FrenimiesLoader Navigate to the lbImpl project folder Implement your Loader by extending the BaseLoader and implementing the interface you just wrote

6. Override Methods There are a lot of options for overriding methods We’ll keep it simple Create a default constructor that calls the default super().

7. Override Methods Override the validate method but leave it a no-op. Override the declareAllowedOptionsMethod and declare desired options or retrieve current. Override the load method, providing appropriate methods and calling super this.load(URI source);

8. Goal Provide a model of your ontology in a Coding Scheme object and turn it over to the LexEVS loading system. One way to do this is to create a brute force mapping to a coding scheme object

9. Map Your Source To LexGrid Access source Through API Use a file reader and parse source Parse or Marshall XML to coding scheme objects

10. Map Your Source To LexGrid Useful Paradigm: Load Basic Coding Scheme Metadata Load Entities and Property elements Load Associations While loading entities and associations compile other coding scheme assertions

11. Coding Scheme Assertions SupportedCodingSchemes SupportedNameSpaces SupportedAssociations SupportedProperties Qualifiers SupportedContainerNames (relation containers)

12. Coding Scheme Assertions Also: Hierarchy, source, EntityType, Language and DataType. Creating a supported hierarchy allows transitive table to be built.

13. Questions?

14. Other Loader Entry Points Priority? RRF Loaders OWL Loaders XML

15. RRF Loader The mysteries of the application context. Entry point is “metadata.xml” file in resources. This defines flow of execution, dependency injection and which classes are executed to populate various coding scheme data objects.

16. Parsing Spring XML Requires moving back and forth between class files and XML definitions to find what type of objects are populating the bean created from the context file. We can use this to help determine what is read, processed and created This can be a painful process

17. Reading a “Group Discriminator” We’ll find the kick off point for loading entities – and eventually look for the place where a CUI is read from a MrSat bean. Winding up at: MrsatMetaEntityGroupDiscriminator

18. “Easier” Entry Points Fortunately most other loaders mapping is more compactly built into the “ 2LGMain” So that you know that HL72LGMain will be the place to find mapping code.

19. OWLch OWLApi2LG: The structure is dictated by the OWL model and processing the sets of elements in OWL2. Getting to: buildDataTypeEntity(OWLObject, String) From: processOWLDataProperties()

20. LexGrid XML Moving content to model elements is simple Processing the variety of Top Level LexGrid objects from XML is hard. See LgRevisionListener.fieldAdded() and LexGridElementProcessor. processCodingSchemeEntityRevisio n() classes.