Page info
title title

1. Object Model Considerations

1.1 Map Set

• Connects two versioned coding schemes
• Is versioned itself.
• Should be named in a descriptive fashion (e.g. MDR12 to SNOMEDCT_2010_07_31 Mappings).
• Significant amount of metadata exists at this level
• Characterize map sets (complexity, completeness, content domain, “officialness”, ..)
• Consider metadata to track whether mappings are curated or not.
• Consider metadata to track whether mappings are generated (and not reviewed) or not.
• Map set metadata should indicate whether map rank is important, useful, or even present.

1.2 Group of Mappings (a mapping subset, or search results, or a page of listings)

This is more sophisticated with complex rule-based map sets where a collection of mapping entries may actually represent only a single mapping.

1.3 Mapping

• "from" and "to" codes (or expressions of codes)
• Represented as an association with qualifiers for other semantically important information
• If target is an expression, represented as an “association to data”
• Have “default preferred name” in the event that a "from"/"to" code cannot be resolved in a loaded coding scheme
• "map rank" may be a standard part of the model.

...

• If so, values should be normalized, so that 1 always means "best" and increasing numbers represent lowering quality (exactly how much lower and why is map set dependent).

...

• A "map rank" threshold can be chosen by an application, so that it pays attention only to the "highest quality" mappings as defined by that application.  Because the values are map set and application specific - algorithms/decisions used are use-case specific.

1.4 Mapping attributes

Any information about a mapping than what directly fits the “association” object model will be rendered as attributes. Hopefully these attributes will have standard names across different types of map set loader. In other words – we can define the semantics of mapping association qualifiers so that particular ones are used to always represent the same aspect of some kind of mapping semantics.

...

• In some cases older versions of map sets will be loaded that contain "to" or "from" codes that cannot be resolved among the versions of loaded vocabularies
• In this case, a "default preferred name" will be available so that browsers can still effectively visualize the data.
• This default name could be indexed so that searches retrieve these results, even though the codes no longer exisexist

3. Browsing/Discovery Scenarios

...

• Pre-select certain map sets for searching based on well-defined criteria

3.3 Misc

• When searching across multiple map sets, consider options like grouping all mappings with the same “from” terminology together to make cognitive task easier.
• Support ability to identify map sets that are “to” or “from” a particular terminology
• E.g. get all map sets where the “from” coding scheme is NCI2010_07

...

• Map Set view (including all known metadata)
• Map Group view (where needed) – e.g. one “subset” in a complex rule-based mapping.
• Mappings view (sortable table, paging capabilities).
  • Standard column headers come from LexEVS view.
  • Need to consider “extended” columns that may not apply to all map sets (e.g. MAP_RANK, or other MRMAP fields like MAPPRIORITY, etc)
• Individual mapping view – link "from" and "to" codes to the concept pages for those things – may not need this
• “Mappings” tab on concept view – render all mappings “to” or “from” that concept
  • need to determine which map sets to search in
  • retrieve this info only when user actually clicks on this tab

...

• “from” coding scheme,
• “to” coding scheme
• Map set coding scheme iteslfitself

Learn what we need to from various mapping maintenance environments about authoring, data models, visualization, etc.

• IHTSDO stand-alone tool (and eventual workbench)
• CogZ (protégé tool)
• Oboedit
• Ad-hoc data manipulation