1. Web Web 3.0 = Web 5.0?
The HSFBCY + CIHR + Microsoft Research SADI and CardioSHARE Projects
Mark Wilkinson
Heart + Lung Research Institute
iCAPTURE Centre, St. Paul’s Hospital, UBC

2. “Non-logical” reasoning and SPARQL queries over distributed data that doesn’t exist

3. How do we make data and tools easily available to biologists

4. Ontologies!

5. Problem…

6. WHY? Ontology Spectrum Because it fulfils XXX Because I say so!
Catalog/ ID
Selected
Logical
Constraints
(disjointness,
inverse, …)
Terms/
glossary
Thesauri
“narrower
term”
relation
Formal
is-a
Frames
(Properties)
Informal
instance
Value Restrs.
General
constraints
Because I say so!
Originally from AAAI Ontologies Panel by Gruninger, Lehmann, McGuinness, Uschold, Welty;
– updated by McGuinness.
Description in:

7. My Definition of Ontology (for this talk)
Ontologies explicitly define the things that exist in “the world” based on what properties each kind of thing must have

8. Ontology Spectrum Thesauri Frames “narrower (Properties) term”
relation
Frames
(Properties)
Selected
Logical
Constraints
(disjointness,
inverse, …)
Catalog/ ID
Formal
is-a
Informal
is-a
Formal
instance
General
Logical
constraints
Terms/
glossary
Value Restrs.

9. My goal with this talk: the “sweet spot”

10. COST Thesauri Frames “narrower (Properties) term” relation Catalog/ID
Selected
Logical
Constraints
(disjointness,
inverse, …)
Terms/
glossary
Thesauri
“narrower
term”
relation
Formal
is-a
Frames
(Properties)
Informal
instance
Value Restrs.
General
constraints

11. COMPREHENSIBILITY Thesauri Frames “narrower (Properties) term”
Catalog/ ID
Selected
Logical
Constraints
(disjointness,
inverse, …)
Terms/
glossary
Thesauri
“narrower
term”
relation
Formal
is-a
Frames
(Properties)
Informal
instance
Value Restrs.
General
constraints

12. Likelihood of being “right”
Catalog/ ID
Selected
Logical
Constraints
(disjointness,
inverse, …)
Terms/
glossary
Thesauri
“narrower
term”
relation
Formal
is-a
Frames
(Properties)
Informal
instance
Value Restrs.
General
constraints

13. Here’s my argument…

14. Semantic Web?
An information system where machines can receive information from one source, re-interpret it, and correctly use it for a purpose that the source had not anticipated.

15. Semantic Web?
If we cannot achieve those two things, then IMO we don’t have a “semantic web”, we only have a distributed (??), linked database… and that isn’t particularly exciting or interesting…

16. Where is the semantic web?
Catalog/ ID
Selected
Logical
Constraints
(disjointness,
inverse, …)
Terms/
glossary
Thesauri
“narrower
term”
relation
Formal
is-a
Frames
(Properties)
Informal
instance
Value Restrs.
General
constraints
REASON: “Because I say so” is not open to re-interpretation

17. Founding partner

18. SADI Premise #1: Web Services in Bioinformatics expose the implicit biological relationship between an input and its associated output

19. SADI Premise #1:

20. SADI Premise #2: A web services registry that provides WS discovery based on these properties enables the behaviours expected of the Semantic Web

21. Dynamic Distributed Discovery Interpretation Re-interpretation

22. Example SADI-enabled App Imagine: there exists a “virtual graph” connecting every conceivable input to every conceivable Web Service and their respective outputs... How do we query that graph?

23. “SHARE” A SADI-enabled query resolver for life sciences
DEMO
“SHARE” A SADI-enabled query resolver for life sciences

24. A SPARQL database query was entered into the SHARE environment
Recap what we just saw
A SPARQL database query was entered into the SHARE environment
The query was passed to SADI and was interpreted based on the properties being asked-about
SADI searched-for, found, and accessed the databases and/or analytical tools required to generate those properties

25. We asked, and answered a complex “database query”
Recap what we just saw
We asked, and answered a complex “database query”
WITHOUT A DATABASE

26. Founding partner

27. CardioSHARE A domain-specific implementation of SADI
Utilizes OWL ontologies describing cardiovascular concepts
Ontologies are designed to lie in the
“sweet spot”
of the Semantic range

28. CardioSHARE Premise #1: Ontology = Query = Workflow

29. “Homologous Mutant Image”
QUERY:
SELECT images of mutations from genes in organism XXX that share homology to this gene in organism YYY
Concept:
“Homologous Mutant Image”
WORKFLOW

30. Phrased in terms of properties:
SELECT image P where {
Gene Q hasImage image P
Gene Q hasSequence Sequence Q
Gene R hasSequence Sequence R Sequence Q similarTo Sequence R
Gene R = “my gene of interest” }

31. …but these are simply axioms…
HomologousMutantImage is equivalentTo {
Gene Q hasImage image P
Gene Q hasSequence Sequence Q
Gene R hasSequence Sequence R Sequence Q similarTo Sequence R
Gene R = “my gene of interest” }

32. homologous mutant images
Class:
homologous mutant images

33. Retrieve homologous mutant images for gene XXX
QUERY:
Retrieve homologous mutant images for gene XXX

34. We are not building massive ontologies!
CardioSHARE
We are not building massive ontologies!
Publish small, independent single-Classes of OWL
Cheap
Scalable
Flexible
Don’t try to describe all of biology!

35. DEMO
CardioSHARE

36. SADI interprets queries (SPARQL + OWL Class Definitions)
Recap
SADI interprets queries (SPARQL + OWL Class Definitions)
Determine which properties are available, and which need to be discovered/generated
Discovery of services via on-the-fly “classification” of local data with small OWL Classes representing service interfaces

37. Recap
CardioSHARE encapsulates workflows as OWL Classes Ontology = Query = Workflow
Ontologies consist of one class
Low-cost, high accuracy

38. CardioSHARE
OWL Classes are shared on the Web such that third-parties, potentially with different expertise, can utilize the expertise of the person who designed the Class.
Easily share your expertise with others
Easily utilize the expertise of others
...all based on the premise that we define the world by its properties, rather than its classes

39. CardioSHARE repercussion
CardioSHARE repercussion... if Ontology = query = workflow and query = hypothesis then Ontology = Hypothesis

40. Currrent Research How far can we push the Ontology = Hypothesis approach?? Attempting to duplicate some clinical outcomes research using ONLY ontologies

41. What we achieve Re-interpretation :
The SADI data-store simply collects properties, and matches them up with OWL Classes in a SPARQL query and/or from individual service provider’s WS interface

42. What we achieve Novel re-use:
Because we don’t pre-classify, there is no way for the provider to dictate how their data should be used. They simply add their properties into the “cloud” and those properties are used in whatever way is appropriate for me.

43. What we achieve Data remains distributed – no warehouse!
Data is not “exposed” as a SPARQL endpoint  greater provider-control over computational resources
Yet data appears to be a SPARQL endpoint… no modification of SPARQL or reasoner required.
No longer dependent on “pure” DL logic

44. Fin O | B | F Credits Edward Kawas and ~40 others (Moby)
Benjamin VanderValk (SADI & SHARE)
Luke McCarthy (SADI & SHARE)
Soroush Samadian (CardioSHARE)
Maria Markov & Veronika Grandl (CardioSHARE “dumb” data model)
Microsoft Research
O | B | F