Conceptual Interoperabilityand Biomedical Data

James McCuskerTetherless World Constellation,Rensselaer Polytechnic Institute

Overview

Conceputal, logical, and physical models Use cases for conceptual interoperability Requirements for conceptual interoperability Modeling caBIG (v. 1) layered semantics in

OWL The Conceptual Model Ontology (CMO) Supporting interoperability use cases and

requirements

Back to the Ontology Spectrum

3

Catalog/ID

SelectedLogical

Constraints(disjointness,

inverse, …)

Terms/glossary

Thesauri“narrower

term”relation

Formalis-a

Frames(properties)

Informalis-a

Formalinstance Value

Restrs.

GeneralLogical

constraints

Originally from AAAI 1999- Ontologies Panel by Gruninger, Lehmann, McGuinness, Uschold, Welty; – updated by McGuinness.Description in: www.ksl.stanford.edu/people/dlm/papers/ontologies-come-of-age-abstract.html

Layered Modeling

Conceptual Model: An expression of a domain expert's understanding

of that domain

Logical Model: A representation of a set of logic, declarative or

procedural, that defines entities, their relations, and their properties.

Physical Model: The underlying representation structure that

actually contains the data.

Layered ModelingExamples

Conceptual Models can be: Cmaps, high-level UML class sketches, etc.

Logical Models can be: OWL Ontologies, UML diagrams, software class

structures, etc.

Physical Model: Triple stores, SQL databases, noSQL databases,

flat files, XML files, data streams, RDF files, etc.

Layers of Interoperability

Physical Interoperability: AKA syntactic interoperability. All the labels lign up

properly, and the structures look the same.

Logical Interoperability: All data is represented in a common model.

Conceptual Interoperability: Models expressed in a common vocabulary,

describing things that have a degree of similarity proportional to the degree of similarity of their conceptual models.

Goals of CI

Make similar but distinct data resources available for search, conversion, and inter-mapping in a way that mirrors human understanding of the data being searched.

Make data resources that use cross-cutting models (HL7-RIM, provenance models, etc.) interoperable with domain-specific models without explicit mappings between them.

The Promise of CI

Imagine being able to search across GEO, ArrayExpress, and caArray without writing a query for each.

Imagine being able to search for patient history across domain-specific databases using queries that only talk about patient history.

Use case: Search

Natural language queries with controlled vocabularies:

Find me all things that are nci:TissueSpecimen with an nci:Diagnosis of nci:Melanoma.

And do this with minimal knowledge of the underlying logical model.

In fact, we want to be logical model-agnostic.

Use case: Conversion

We should be able to lift instance data over with a certain level of fidelity data from one logical model to another.

This can be between domain models, or between a domain model and a cross-cutting model, such as a provenance model.

Use case: Mapping

We should be able to create an automated mapping between two logical models.

For instance, take existing caBIG data models and align them with the BRIDG (Biomedical Research Integrated Domain Group) model.

Conceptual Interoperability Requirements

Conceptual models must: use a common vocabulary that is distinct from any particular conceptual model.

A conceptual modeling framework must: support natural, idiomatic expression of the actual

data in its natural form. provide a way to express relationships between

types, properties, and relations. provide a way of expressing additional relationships

between concepts.

Modeling caBIG (v. 1)Layered Semantics in OWL

Efforts from http://bit.ly/147FwJ resulted in additional indirection to express UML attributes:

Modeling caBIG (v. 1)Layered Semantics in OWL

It would look like this if it were regular OWL:

This isn't possible in OWL 1, and doesn't work in OWL 2 if nci:Name and nci:Nucleic_Acid_Hybridization are owl:Classes.

The Conceptual ModelOntology (CMO)

http://purl.org/twc/ontologies/cmo.owl

Tying classes and properties to concepts:

Why SKOS?

Most vocabularies are already being used as terminologies, which SKOS is ideally suited for.

A skos:Concept is an Individual, and therefore can be referenced by non-OWL predicates.

Using SKOS eliminates accidental interference with logical models expressed in OWL.

Conceptual models discuss ideas (concepts), not sets (classes).

Why OWL?

I'm happy to entertain suggestions to the contrary.

The Conceptual ModelOntology (CMO)

Describing relation edges using concepts:

And qualities

of types:

The Conceptual ModelOntology (CMO)

Relating conceptual models to common vocabularies using simple composition tying into existing SKOS heirarchies:

The Conceptual ModelOntology (CMO)

Behaviors are defined in terms of what they use and produce. This is more powerful than it sounds. See SADI for examples.

CMO SatisfiesCI Requirements

✔ Common vocabularies that is distinct from any particular conceptual model

✔ Support natural, idiomatic expression of the actual data in its natural form.

✔ Not limited to caBIG models, but can be used on any logical model expressed in OWL.

✔ Provide a way to express relationships between types, properties, and relations.

✔ Provide a way of expressing additional relationships between concepts.

CI Use Cases: Search

Find me all things that are nci:TissueSpecimen with an nci:Diagnosis of nci:Melanoma.

CU Use Cases: Conversion

Supported using rules like:

→

CU Use Cases: Conversion

Would be filled with this data:

→

CU Use Cases: Mapping

We can also create class relationships:

We're experimenting with this currently.

→

Oh, and it's working today

We've set up a RESTful service for caGrid data and models to linked data (swBIG).

http://swbig.googlecode.com Visible to linked data tools. The models already use CMO. Everything is linked, and have predictable URIs:

caDSR Model: http://purl.org/twc/cabig/model/[project]-[version].owl

Endpoint Model: http://purl.org/twc/cabig/endpoints/[endpoint].owl

List Instances: http://purl.org/twc/cabig/list/[endpoint]/[pkg].[class]

Get Instance: http://purl.org/twc/cabig/endpoints/[endpoint]/[pkg].[cls]/[id]

Conclusions

Conceputal models can play a significant role in automated semantic interoperability.

Conceptual Model Ontology can support important uses cases in conceptual interoperability.

You can experiment with CMO-enhanced models and data today using swBIG.

Not limited to caBIG models, but can be applied to any logical model expressed in OWL.

Thank you!