Ontology ViewsAn Update

A BISTI Collaborative RO1 with the National Center for Biomedical Ontology

James F. Brinkley, PI

Structural Informatics GroupUniversity of Washington

Personnel

• Dan Suciu

• Linda Shapiro

• Marianne Shaw

• Todd Detwiler

• Joshua Franklin

• Onard Mejino

• Dan Cook

• John Gennari

• Max Neal

• Daniel Rubin

• Natasha Noy

• Mark Musen

Motivation

• Large number of application ontologies• Need to link them together into the semantic

web• Reference ontologies as one way to do this• But reference ontologies are (or will be) too

large for practical use• How can reference ontologies be made practical

for applications, yet retain potential to link application ontologies?

Approach

• Application ontologies as views over one or more reference ontologies

• A view is a query that defines a formal transformation from one or more source ontologies to a target application ontology

Main advantage of views

• View query describes the specific operations used to create the application ontology– Therefore the connection to the source(s) are

not lost– If the query can be made bidirectional (a

mapping) then application ontologies can be related to each other via views

Secondary advantages

• View query can be re-run at any time as the reference ontology changes

• The query is formal so can be manipulated by a GUI

• Application ontology need not be materialized, so the update problem is not an issue (but there may be other reasons to materialize views)

Research Issues (aims)

1. How to define the view

2. How to implement the view query processor

3. How to graphically generate views

Driven by and evaluated in terms of use cases

Topics

• View definition language as SparQL extensions

• Expressiveness for use cases

• UW tools and demos

• Integration into BioPortal

• Current and planned work

Gleen regular path expression library

Todd Detwiler

{fma:Neuraxis gleen:OnPath ("([fma:regional_part]|[fma:constitutional_part])*" ?part)}

vSparQLMarianne Shaw, Todd Detwiler, Dan Suciu

• Subqueries

• Recursive Queries

• Skolem functions

vSparQL Subqueries

• Builds upon CONSTRUCT query

• Subqueries treated as data source• Named or unnamed data source

CONSTRUCT { ?subj ?prop ?obj }FROM < ... >WHERE { ?subj ?prop ?obj }

SELECT ...FROM NAMED <subquery_name> [ CONSTRUCT { ... } FROM < ... > WHERE { ... }]WHERE { GRAPH <subquery_name> { ... } }

Chaining SubqueriesSELECT ...FROM NAMED <subquery_1> [ CONSTRUCT { ... } FROM < ... > WHERE { ... }]

FROM NAMED <subquery_2> [ CONSTRUCT { ... } FROM < ... > WHERE { GRAPH <subquery_1> }]

WHERE { GRAPH <subquery_2> { ... } }

vSparQL Recursive Subqueries

SELECT ...FROM NAMED <recursive_subq> [ CONSTRUCT { ... } # Base queries FROM < ... > WHERE { ... }

UNION # Set union CONSTRUCT { ... } # Recursive queries FROM NAMED <recursive_subq> FROM < ... > WHERE { GRAPH <recursive_subq> { ... } . ... }]WHERE { GRAPH <recursive_subq> { ... } }

• Union of CONSTRUCT queries

Skolem Functions

• [[<skolem_function_url>(arg1, ... )]] =>

<skolem_function_url>?param1=arg1&param2=arg2

• [[fluid_property(blood_in_aorta, fluid_pressure)]] =>

<fluid_property>?param1=blood_in_aorta&

param2=fluid_pressure

Expressiveness in terms of three primary use cases

• Reorganization of RadLex

• Intelligent distributed queries

• Biosimulation model integration

Re-organization of RadLeXOnard Mejino and Daniel Rubin

• Maryanne Martone, Jessica Turner, Beverly Collins

• RadLeX and the need to reorganize

• Neuroimaging as initial domain

• FMA as an organizing framework for the neuroanatomy component

Using FMA to reconcile different neuro terminologiesOnard Mejino

PROBLEM: Correlate neuroanatomical imaging data using different annotation systems

Talairach:

13 Right Cerebrum.Temporal Lobe.Inferior Temporal Gyrus.Gray Matter.Brodmann area 20

Anatomical Automatic Labeling (AAL):

Temporal_Inferior_RIGHT

FreeSurfer (Query Atlas):

ctx-rh-inferiortemporal ctx-rh-G_temporal_inferior

Neurolex (BIRNlex/NeuroNames):

Inferior temporal gyrus

NO ONE TO ONE MAPPING BETWEEN THE TALAIRACH LABEL AND OTHER SOURCES

Example:

Correlate different systems

13 Right Cerebrum.Temporal Lobe.Inferior Temporal Gyrus.Gray Matter.Brodmann area 20

Talairach:

FMA+Brodmann area 20 of right inferior temporal gyrus Part_of

Gray matter of right inferior temporal gyrus Right inferior temporal gyrus Right temporal lobe

Part_of Right Brodmann area 20

AAL Atlas

Temporal_Inferior_RIGHT

FreeSurfer

ctx-rh-inferiortemporalctx-rh-G_temporal_inferior

Inferior temporal gyrusTemporal lobeBrodmann area 20

Neurolex

Implementation in Protégé

neuroFMA as a view of enhanced FMA

FMA+

QueryAtlasAAL

Talairach Neurolex

neuroFMAextract

RadLex

RadLex’

merge

FMAFMA FMA+FMA+ nFMApnFMAp RadlexRadlex

Radlex’Radlex’FMA+FMA+

nFMAvnFMAv nFMApnFMAp

Enhance Procedural

Fram

es to O

WL

Fram

es to O

WL

vSparQ

L

Reorgan

ize

Compare

NeuroFMA ViewMarianne Shaw, Todd Detwiler

– All neural structures from the FMA• Attributes• Properties connecting them

– All types, superclasses, superproperties

NeuroFMA View Query

…

PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl:<http://www.w3.org/2002/07/owl#> PREFIX gleen:<java:edu.washington.sig.gleen.> PREFIX tmp:<http://.../temp#> PREFIX fma:<http://.../fma3.0#> CONSTRUCT { ?a ?b ?c . } # all parts recursively of neuraxis FROM NAMED <pre_na_parts_wo_types> [ CONSTRUCT {tmp:set tmp:elem ?part} FROM <http://.../fma3.0> WHERE {fma:Neuraxis gleen:OnPath ("([fma:regional_part]|[fma:constitutional_part])*" ?part)} ] # all parts of the neuraxis and their types FROM NAMED <pre_na_parts> [ CONSTRUCT {tmp:set tmp:elem ?part . tmp:set tmp:elem ?c. } FROM <http://.../fma3.0> WHERE { OPTIONAL { ?part rdf:type ?c } . GRAPH <pre_na_parts_wo_types> {?a ?b ?part} .} ] # get inter-part attributed relationship instances (& rels) FROM NAMED <na_attr_rels_in> [ CONSTRUCT {?p ?rel ?q} FROM <http://.../fma3.0> WHERE { ?p ?rel ?q. GRAPH <pre_na_parts> {tmp:set tmp:elem ?p.}. OPTIONAL {?q rdfs:subClassOf ?super}. FILTER(!bound(?super)). FILTER((?rel = fma:attributed_part) || (?rel = fma:related_part)). } ] FROM NAMED <na_attr_rels_out> [ CONSTRUCT {?q ?rel2 ?p2.} FROM <http://.../fma3.0> WHERE { ?q ?rel2 ?p2. GRAPH <pre_na_parts> {tmp:set tmp:elem ?p2.}. OPTIONAL {?q rdfs:subClassOf ?super}. FILTER(!bound(?super)). FILTER((?rel2 = fma:attributed_part) || (?rel2 = fma:related_part)). } ] FROM NAMED <na_attr_rels> [ CONSTRUCT { tmp:set tmp:elem ?q. tmp:rel_set tmp:elem ?rel. tmp:rel_set tmp:elem ?rel2.} FROM <http://.../fma3.0> WHERE { GRAPH <na_attr_rels_in> {?p ?rel ?q.}. GRAPH <na_attr_rels_out> {?q ?rel2 ?p2.}. } ] # add all inter-part attributed instances types to parts FROM NAMED <na_parts> [ CONSTRUCT { tmp:set tmp:elem ?p. tmp:set tmp:elem fma:Concept_name. tmp:set tmp:elem fma:Query_Atlas_term. tmp:set tmp:elem fma:Neurolex_term. tmp:set tmp:elem fma:AAL_term. } FROM <http://.../fma3.0> WHERE { { GRAPH <pre_na_parts> {tmp:set tmp:elem ?p} } UNION { GRAPH <na_attr_rels> {tmp:set tmp:elem ?q.} ?q rdf:type ?p. } } ] # build graph containing all properties of all classes FROM NAMED <na_parts_graph> [ CONSTRUCT {?p ?rel ?obj} FROM <http://.../fma3.0> WHERE { ?p ?rel ?obj . GRAPH <na_parts> { tmp:set tmp:elem ?p }. } ]

# get all properties which either connect two of the parts above # or connects a part to a literal; add attributed relationships FROM NAMED <na_parts_props> [ CONSTRUCT { tmp:set tmp:elem ?b. tmp:set tmp:elem ?e. tmp:set tmp:elem ?rel. tmp:set tmp:elem fma:AAL . tmp:set tmp:elem fma:Preferred_name. tmp:set tmp:elem fma:Synonym. tmp:set tmp:elem fma:Non-English_equivalent. tmp:set tmp:elem fma:Query_Atlas. tmp:set tmp:elem fma:Neurolex. } FROM <http://.../fma3.0> WHERE { { GRAPH <na_parts_graph> {?a ?b ?c}. FILTER isLiteral(?c) } UNION { GRAPH <na_parts_graph> {?d ?e ?f}. GRAPH <na_parts> {tmp:set tmp:elem ?f}. } UNION { GRAPH <na_attr_rels> {tmp:rel_set tmp:elem ?rel.} } } ] # Our view only includes a small number of Non-physical_ #_anatomical_entity_template (and subclass) instances; # all others are dropped. Build up a list of things to exclude. FROM NAMED <stoppingPoint> [ CONSTRUCT { tmp:set tmp:elem ?a .} FROM <http://.../fma3.0> WHERE { ?a gleen:OnPath ("[rdfs:subClassOf]*" fma:Non-physical_anatomical_entity_template) . } ] FROM NAMED <exclusionTypes> [ CONSTRUCT { tmp:set tmp:elem ?b } FROM <http://.../fma3.0> WHERE { GRAPH <stoppingPoint> { ?ts ?tm ?a . } ?b rdf:type ?a . FILTER ( ?b != fma:AAL_term && ?b != fma:Concept_name && ?b != fma:Neuro_term && ?b != fma:Neurolex_term && ?b != fma:Non-physical_anatomical_entity_template && ?b != fma:Organ_part_of_relationship_value && ?b != fma:Organ_subdivision_part_of_relationship_value && ?b != fma:Part_of_relationship_value && ?b != fma:Query_Atlas_term && ?b != fma:Structural_relationship_value ) . } ] # determine superclasses, superproperties, and types # add nodes connected to blank nodes and recurse on these FROM NAMED <pre_na_parts_ext> [ CONSTRUCT {tmp:set tmp:elem ?c.} FROM <http://.../fma3.0> WHERE { { GRAPH <na_parts> {tmp:set tmp:elem ?c}. OPTIONAL {GRAPH <exclusionTypes> {?ts tmp:elem ?c}.} FILTER (!bound(?ts)) . } UNION { GRAPH <na_parts_props> {tmp:set tmp:elem ?c}. OPTIONAL {GRAPH <exclusionTypes> {?ts tmp:elem ?c}.} FILTER (!bound(?ts)) . } } UNION CONSTRUCT {tmp:set tmp:elem ?v.} FROM <http://.../fma3.0> WHERE { GRAPH <pre_na_parts_ext> {tmp:set tmp:elem ?c.} {?c rdf:type ?v.} UNION {?c rdfs:subClassOf ?v} UNION {?c rdfs:subPropertyOf ?v} UNION {?c ?rel ?v. FILTER (isBlank(?c) && !isLiteral(?v)).}. OPTIONAL {GRAPH <exclusionTypes> {?ts tmp:elem ?v}.} FILTER (!bound(?ts)) . } ] # add in attributed instances for our ontology tree FROM NAMED <na_parts_ext> [ CONSTRUCT {tmp:set tmp:elem ?p. tmp:set tmp:elem ?q. tmp:set tmp:elem ?cn.} FROM <http://.../fma3.0> WHERE { { GRAPH <pre_na_parts_ext> {tmp:set tmp:elem ?p}. OPTIONAL {{?p fma:Preferred_name ?cn.} UNION {?p fma:Synonym ?cn.} UNION {?p fma:Non-English_equivalent ?cn.} UNION {?p fma:Query_Atlas ?cn.} UNION {?p fma:Neurolex ?cn.} UNION {?p fma:AAL ?cn.} } } UNION { GRAPH <na_attr_rels> {tmp:set tmp:elem ?q}. } } ]

# build graph containing all properties of all classes identified FROM NAMED <na_parts_ext_graph> [ CONSTRUCT {?p ?rel ?obj} FROM <http://.../fma3.0> WHERE {GRAPH <na_parts_ext> {tmp:set tmp:elem ?p}. ?p ?rel ?obj .} ] # build graph containing only properties connecting two classes # in ext or a class in ext to a literal FROM NAMED <na_view_wo_props> [ CONSTRUCT {?a ?b ?c. ?d ?e ?f.} FROM <http://.../fma3.0> WHERE { { GRAPH <na_parts_ext_graph> {?a ?b ?c}. FILTER isLiteral(?c) } UNION { GRAPH <na_parts_ext_graph> {?d ?e ?f}. GRAPH <na_parts_ext> {tmp:set tmp:elem ?f}. } } ] # Fully define all properties. Determine superclasses, # superproperties, and types. Add nodes connected to blank # nodes and recurse on these FROM NAMED <pre_na_parts_props_ext> [ CONSTRUCT {tmp:set tmp:elem ?c.} FROM <http://.../fma3.0> WHERE { { # define all properties to be in the result graph GRAPH <na_view_wo_props> { ?uns ?c ?uno } } UNION { # see if we had any restrictions on properties; # if we did, we need to define those properties fully GRAPH <pre_na_parts_ext> {tmp:set tmp:elem ?c}. ?r rdf:type owl:Restriction . ?r owl:onProperty ?c . } UNION { GRAPH <na_parts_props> {tmp:set tmp:elem ?c}. } } UNION CONSTRUCT {tmp:set tmp:elem ?v.} FROM <http://.../fma3.0> WHERE { GRAPH <pre_na_parts_props_ext> {tmp:set tmp:elem ?c.} {?c rdf:type ?v.} UNION {?c rdfs:subClassOf ?v} UNION {?c rdfs:subPropertyOf ?v} UNION {?c ?rel ?v. FILTER (isBlank(?c) && !isLiteral(?v)).}. } ] FROM NAMED <rec_pre_na_parts_props_ext> [ CONSTRUCT { ?c ?d ?e } FROM <http://.../fma3.0> WHERE { ?c ?d ?e . GRAPH <pre_na_parts_props_ext>{tmp:set tmp:elem ?c} OPTIONAL {GRAPH <na_parts_ext> {?ts tmp:elem ?e}} FILTER (isBlank(?e) || isLiteral(?e) || bound(?ts) || (!bound(?ts) && !regex(str(?e),"http://.../fma3.0"))).} UNION CONSTRUCT { ?e ?f ?g } FROM <http://.../fma3.0> WHERE { GRAPH <rec_pre_na_parts_props_ext> { ?c ?d ?e } . FILTER isBlank(?e) . ?e ?f ?g . OPTIONAL {GRAPH <na_parts_ext>{?ts tmp:elem ?g}} FILTER (isBlank(?g) || isLiteral(?g) || bound(?ts) || (!bound(?ts) && !regex(str(?g),"http://.../fma3.0")) ). } ] # Combine fully defined classes with fully defined properties FROM NAMED <na_view> [ CONSTRUCT {?a ?b ?c. ?d ?e ?f.} FROM <http://.../fma3.0> WHERE { { GRAPH <na_view_wo_props> {?a ?b ?c}. } UNION { GRAPH <rec_pre_na_parts_props_ext> {?d ?e ?f}. } } ] WHERE { GRAPH <na_view> {?a ?b ?c.} }

(A)

(B)

(D)

(E)

(F)

(C)

(G)

(H)

AA BB CC DD

EE FF GG HH

NeuroFMA Query Results

…

…

FMA75,000 classes; 170 properties; >2million relationships

NeuroFMA2,300 classes; 40 properties; >70,000 relationships

Compare two methods

• vSparQL vs procedurally-generated

• Modified version of RDF-Sync

• All differences with triples containing blank nodes

– Only syntactic

• When syntactic differences accounted for no differences were found

• => vSparQL is expressive enough to generate a complex view

nFMAvnFMAv nFMApnFMAp

Intelligent distributed queries over annotated data

Todd Detwiler, Joshua Franklin, Eider Moore, Dan Suciu et al

Data annotation

Middle part of the middle temporal gyrus

CSM MRI SUR

FMAWarps DXQ

CSM MRI SUR

FMAWarps DXQ

EDC Inventory

DXQ OCRE

Biosimulation model integration

Max Neal, Dan Cook, John Gennari

FMA-OPB View: More than one source ontology

Todd Detwiler

FMA-OPB Query

FMA-OPB View

…

FMA-OPB View (graphical example)

RELEASED OR DEPLOYED TOOLS at UW

Todd Detwiler

Gleen Regular Path Library

VSparQL Demo Client

Integrating viewsin BioPortal

Natasha Noy

Csongor Nyulas

Stanford

BioPortal Metadata

• BioPortal infrastructure and functions are supported by metadata– Ontology details– Mappings– Notes, reviews– Views

• Ontologies are used describe metadata and instances of ontology classes are used to store metadata

Metadata as ontology instances

Requirements for representing views

• Each view is itself an ontology and can have metadata, be explorable, etc.

• A view is defined on a specific version of an ontology• There is a notion of a "virtual view" (cf. "virtual ontology"): for

example, a view of Liver-related concepts in FMA created for a particular purpose– each virtual view has at least one version, but can have several– a virtual view has metadata attached to it (name, contact, etc.)– each version of the view also has its own metadata (inherited from

ontology metadata, but with additional fields)

• Must be able to represent views on views• Must be able to represent views that include more than one

ontology

How it will alllook in

BioPortal

Next Steps in Integrating Views in BioPortal

• Finish implementing the complete set of REST services

• Implement a user interface for displaying views and their metadata

• Enable community features, such as commenting on views

• Linking concepts in views to the corresponding concepts in the “master” ontology (right now, a view is independent from the ontology)

Current and Planned work

• Additional features in vSparQL• Optimization• Non-materialized views• Query manager• Graphical view generation• Intermediate Language• Other use cases

Graphical view generation

Intermediate Language

• Higher-level functionality– Can be mapped to vSPARQL queries

• Operations– Extract

• edges, nodes, tree

– Union– Copy– Delete / Add

• edges, nodes, tree

– Merge / split nodes– Cleanup

Other potential use cases

•Ontology of cardiovascular system (OCV) for Cardiovascular Imaging Informatics (CVII)•Ontology of head and neck lymphatic system

for radiation treatment planning•Ontology of musculoskeletal system

in support of Human Phenotype Ontology•Mammalian Anatomy Ontology

as resource for different species ontologies•Ontology of skeletal system

for computational biomechanics of bone and orthopedic devices•Latin only (Terminologia Anatomica) terminology

for head and neck anatomy•Ontology of genito-urinary system

for micturition control studies•Minimum Information for Biological and Biomedical Investigations•Ontology of Clinical Research (OCRE)

•More…..

Conclusions

• A query-based approach to deriving application ontologies from reference ontologies

• Appears to be expressive enough

• Needs to be made faster and easier to use

• Large number of potential applications

Bioportal Challenges/Questions

• Search: should views be searchable just like other ontologies? (if yes, the same concept may appear in multiple views and will be returned multiple times in the search)

• Mapping: should users be allowed to map concepts from the views? If yes, should these mappings propagate to the source ontology?

• Notes: When users comment on a concept on a view, should that note be seen in the source ontology?