Loader Tutorial

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

Map Source to LexGrid See Excel File

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

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

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

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);

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

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

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

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

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

Questions?

Other Loader Entry Points Priority? RRF Loaders OWL Loaders XML

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.

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

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

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

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()

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.