CTS2 Specification Discussion Notes

CTS 2 Background Lineage (LQS, CTS, LexEVS) History (CTS 2 SFM, RFP, HL7 Adoption process) Current state – Feb 21 deadline – Mar OMG meeting – Jun OMG vote (ideally)

CTS2 Goals HL7 SFM Goals – CTS + distribution, “authoring”, versioning, value sets and “post-coordinated expressions” (invoking reasoners) OMG RFP Goals – Fairly well aligned with SFM – Requires PIM + SOAP PSM

Additional Drivers and Requirements for Mayo Additional drivers and requirements – Leverage NCI/Mayo LexEVS services – Leverage II4SM service model Quick initial implementations – W3C / Ontology community buy-in – BioPortal compatibility – RESTful compatible PSM (and PIM…) – OMV alignment – Addl: Phin VADS, HL7 MIF, IHTSDO RF2

Approach PIM – “Platform Independent Model”, mapped to multiple Platform Specific Models: REST PSM SOAP PSM iRDF PSM PIM – combination of UML, text and Z

Challenges What, exactly is a PIM? How do we create one model that aligns with REST (our primary target), SOA(p), RDF minimalists and POJO? No easy answers, but Z language seems to help considerably

Other Challenges LexEVS – built, runs and already incorporates a significant portion of what is in the requirements LexEVS (XML / POJO) to PIM is a non-trivial transformation Reproducible behavior is a non-trivial process Decision was made to build CTS2 implementation using LexEVS vs deeper embedding.

Before we get started Specification approach UML / text / Z (At the moment, Z is most current) Text and UML follow (or not) at varying rates Do I need to know Z to read it? – At the moment, it would help a lot but… – … the intent is that the text faithfully, clearly and accurately reflects what is said in the Z

Other details Z means LaTeX (more or less) Your faithful narrator is not a LaTeX expert, meaning that it tends to be odd, clumsy, etc. … any assistance would be greatly appreciated Browsing and authoring access is available online (!) Anyone w/ a logon can update and regenerate sections of the spec

Current Status Working through Code System / Code System Version trying to complete import/export/updates/version and query model Not as far as we’d hoped to be, but are learning a lot. Working w/ Dr. Davies / Oxford to improve Z style, readability, and content Changes coming and (unfortunately) partially reflected in model today. UML model is considerably behind the curve at the moment… thanks to a certain UML vendors new- found obsession with security.

Outline of the Specification 1)(Quick intro to working directories) 2)(Quick intro to web site)

Outline of the Specification Core Data Types Complete and independent for various PSM mappings As minimum as possible Eschew Boolean Review TypesOfURI (and why “U”) Review EntityReference (the foundation of the model)

Outline of the Specification (continued) Core Naming RDFTypes – the link to the W3C world Updates The core of the workflow, revision and version model.

Outline of the Specification (continued) Core Resources Resource Description model – Include what resources we describe ARD / RVD – what and why Also focus on the RESTful notion of “Resource”

“Resources” In this context, a “resource” refers to one of the fundamental components that are represented in a CTS2 service. The CTS2 specification states how these various “resources” are represented, queried and updated.

Flavors of Resource Abstract Resource Code System Mapping Value Set Concept Domain Resource Version Code System Version Mapping Version Value Set Definition Concept Domain Binding

Outline of the Specification (continued) Core Statements Serves 3 purposes: 1)Link between structured (UML) model and RDF triple-based model 2)Point of extensibility (describe) 3)Anchor point of “association”

Outline of the Specification (continued) Core Iteration and Filters Generic query structure – by model element or statement Directory model (read only resources)

Outline of the Specification (continued) Information Model Code System (aka. Ontology) Code System Version (aka. Ontology) Value Set Value Set Definition Value Set Resolution Rule Mapping Mapping Version Concept Domain (aka Data Element Concept) Concept Domain Binding (aka Data Element)

Outline of the Specification (continued) Information Model And … Entity – the core aspect being represented – Subdivisions to Class / Individual / Role – Reasons that Entity is not abstract (valid?)

Brief Interlude on Complaince Code System (Version), Value Set (Definition), Concept Domain (Bindings), Mapping (Version) and Entity are all independent compliance points (!) (dependencies present interesting problems) Query / Loader / Exporter / Authoring / History services are all compliance points as well Additional extension (compliance) points wrt. Statements, SPARQL, Context Matching, Event Notification, Business Rules (?) and Loading

Reasoning Services (go over II4SM and SFM)