The goals of conceptual interoperability are: 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.

1. Conceptual Interoperability
and Biomedical Data
James McCusker
Tetherless World Constellation,
Rensselaer Polytechnic Institute

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

3. Back to the
Ontology Spectrum
Thesauri Selected
“narrower Formal Frames Logical
Constraints
Catalog/ term” is-a (properties)(disjointness,
ID relation
inverse, …)
Terms/ Informal Formal General
Value Logical
glossary is-a instance
Restrs. 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 3

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

5. Layered Modeling
Examples
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.

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

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

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

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

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

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

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

13. Modeling caBIG (v. 1)
Layered Semantics in OWL
Efforts from http://bit.ly/147FwJ resulted in
additional indirection to express UML attributes:

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

15. The Conceptual Model
Ontology (CMO)
http://purl.org/twc/ontologies/cmo.owl
Tying classes and properties to concepts:

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

17. The Conceptual Model
Ontology (CMO)
Describing relation edges using concepts:
And qualities
of types:

18. The Conceptual Model
Ontology (CMO)
Relating conceptual models to common
vocabularies using simple composition tying
into existing SKOS heirarchies:

19. The Conceptual Model
Ontology (CMO)
Behaviors are defined in terms of what they use
and produce. This is more powerful than it
sounds. See SADI for examples.

20. CMO Satisfies
CI 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.

21. CI Use Cases: Search
Find me all things that are nci:TissueSpecimen
with an nci:Diagnosis of nci:Melanoma.

22. CU Use Cases: Conversion
Supported using rules like:
→

23. CU Use Cases: Conversion
Would be filled with this data:
→

24. CU Use Cases: Mapping
We can also create class relationships:
→
We're experimenting with this currently.

25. 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]

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

27. Thank you!