HCLS/ClinicalObservationsInteroperability/FDATherapeuticAreaOntologies/LoadingTAOntologiesIntoTBC

From W3C Wiki

Document Conventions

  • User actions are in headings - Readers can perform the demo from the table of contents and click on the sections when they need to see screenshots.
  • Menu actions separated by "·" - Text like "File·New·Project..." indicates the "File" menu with a submenu of "New" etc.
  • Window hints in () - It's easy to lose windows so hints are included in "()". The text "(Window·Show view·Navigator)" shows how to restore the "Navigator pane from Window·Show view submenu.
  • back references to earlier actions - Readers can traverse the demo in any order. Repeated actions, like importing a file from the web, have links back to where the action is explained.


TBC demo setup - Creating a project

Top Braid Composer is built on top of Eclipse. Eclipse source files and user interface state are organized in "projects".

File·New·Project

General·Project, enter "FDA-TA" and select Finish

This creates a new directory called "FDA-TA" in your Eclipse workspace. You can look there for the files you import. If you move files in or out of the project directory, or edit them with an external editor, you may need to "Refresh" the directory (File·Refresh or Right-click on the project in the Navigator pane and select "Refresh").

TBC demo 1 - loading all TA Ontologies

The files you need for this demo are available on the web. The following instructions load a data file from the web and save it in the project.

In the Navigator window (Window·Show view·Navigator), right click "FDA-TA", select Import...

Select "Import RDF/OWL file from the Web"

Enter "http://www.w3.org/2013/12/FDA-TA/_allTAs" in the Source URL and "_allTAs.ttl" for the Target file name

In the Navigator, Double-click FDA-TA·_allTAs.ttl to load it

The Imports window will show the import tree:

  • TBC made a copy of the file "_allTAs.ttl" and saved it in the project directory.
  • _allTAs.ttl imports several other parts of the ontology, e.g. "http://www.w3.org/2013/12/FDA-TA/Anticoagulants".
  • These imported resources are not saved locally; each time you load _allTAs.ttl, TBC will re-import those resources with HTTP GET.
  • If you wish to use a web copy of _allTAs you can instead create a new file and import "http://www.w3.org/2013/12/FDA-TA/_allTAs" with the Imports pane.

Review the loaded triples (Window·Show view·Triples):

Start class hierarchy with owl:Thing

This simplifies the rendered class hierarchy by hiding the syblings underneath the rdf:Resource root.

Expand the Rheumatoid Arthritis hierarchy

Double-click ra:DiseaseActivityScoreEndpoint to show class form

Hold down control and hover over ra:DAS28_OutcomeAssessment to navigate to it

Use the arrows like a Web browser

to go back and forth through you traversal history.

TBC demo 2 - loading instance data

Follow the import instructions above to import and load "http://www.w3.org/2013/12/FDA-TA/tests/RenalTransplantation/subjects" into "subjects.ttl"

Execute an endpoints query over the loaded data

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?endpoint ?count ?labels {
  {
    SELECT ("GraftSurvival" AS ?endpoint) (COUNT(*) AS ?count) (GROUP_CONCAT(?name) AS ?labels)
    WHERE {
     ?s bridg:Subject.performingBiologicEntity [ foaf:name ?name ] ;
        core:hasOutcomeAssessment [
          a xplant:GraftSurvivalAssessment ]
    }
  }
  UNION
  {
    SELECT ("GraftLoss" AS ?endpoint) (COUNT(*) AS ?count) (GROUP_CONCAT(?name) AS ?labels)
    WHERE {
     ?s bridg:Subject.performingBiologicEntity [ foaf:name ?name ] ;
        core:hasOutcomeAssessment [
          a xplant:GraftLossAssessment ]
    }
  }
}

The xplant:GraftSurvivalAssessment and xplant:GraftLossAssessment types are not asserted directly in the data so we expect counts of 0 GraftSurvival and GraftLoss:

Click the play button icon to run inferencing

View Inferences (Window·Show view·Inferences) to see the inferred triples

Somewhere in there are the xplant:GraftSurvivalAssessment and xplant:GraftLossAssessment type arcs required by the endpoint query.

Re-run the SPARQL query and see 1 result for each endpoint

The loaded data has only three patients, including one with a graft survival (Amy) and one with a graft loss (Sue). Had the data included more patients with clear loss or survival outcomes, their names would have been listed in the same row.


TBC demo 3 - sufficient reasoning

This demonstrates how OWL uses the properties of a node in a graph to discover the RDF type of that node.

Follow the import instructions above to import and load "https://www.w3.org/wiki/images/c/cc/Sufficient.ttl" into "Sufficient.ttl"

This imports a small ontology 

xplant:GraftSurvivalAssessment 
  rdfs:subClassOf core:PositiveOutcome ;
  owl:equivalentClass [
    owl:onProperty core:hasResultValue ; owl:hasValue xplant:NormalFunctioningGraft 
  ] .

data:someOutcome core:hasResultValue xplant:NormalFunctioningGraft .

View Triples (Window·Show view·Inferences) and note the 4 type arcs

Execute a query for everything of type core:PositiveOutcome

SELECT *
WHERE {
  ?subject a core:PositiveOutcome
}

The core:PositiveOutcome type is not asserted so we expect no solutions:

Change the inference from TopSPIN to OWLIM

  • Select Inferences·Configure Inferencing...) from the menu.

File:TBC-FDA-TA-inference-TopSPIN.png

  • Check 'Customize Setting for "Sufficient.ttl"'.
  • Click the "TopSPIN (SPARQL Rules)" box on the right and the white 'X' above "Input: Asserted Triples".
  • Double-click SwiftOWLIM on the left.
  • Check "Complete Mode: Do not filter redundant inferences" at the bottom. You should now see:

Click the play button icon to run inferencing

View Inferences (Window·Show view·Inferences) to see the inferred triples

Note that one of the four inferred type triples in the image asserts data:someOutcome rdf:type core:PositiveOutcome.

If you did not check "Complete Mode" while configuring inferencing, you will only see four triples. These will not include transitive subclass inferencing, e.g. that data:someOutcome rdf:type core:PositiveOutcome.

Re-run the SPARQL query and see the type of data:someOutcome

TBC demo 4 - necessary reasoning

The demonstrates how OWL can infer properties for a graph node based on its type.

Follow the instructions for demo 3 above to import and load "https://www.w3.org/wiki/images/2/23/Necessary.ttl" into "Necessary.ttl"

This imports the small ontology 

xplant:GraftCSARAssessment 
  rdfs:subClassOf 
    [ owl:onProperty core:hasResultValue ;
      owl:hasValue xplant:NonFunctioningGraft ] .

data:someOutcome a xplant:GraftCSARAssessment .

Change the inference from TopSPIN to OWLIM as above

Execute a query for data:someOutcome's core:hasResultValue

As above, you will need to run inferencing first to see results. 

SELECT *
WHERE {
    data:someOutcome core:hasResultValue ?v .
}

Necessary and sufficient=

In general, owl:equivalentClass asserts that some pattern is sufficient to assert membership in a class and rdfs:subClassOf to assert that membership in a class implies that certain constraints are met. The rdfs:subClassOf idiom may seem peculiar but it may be easy to visualize in terms of Venn diagrams, one representing the set of things in the world with a core:hasResultValue of xplant:NonFunctioningGraft and one which is the set xplant:GraftCSARAssessment. Since xplant:GraftCSARAssessment is a subclass of the other set, we can see that every xplant:GraftCSARAssessment must core:hasResultValue of xplant:NonFunctioningGraft.

TBC demo 5 - validation

Follow the instructions for demo 3 above to import and load "https://www.w3.org/wiki/images/7/72/Valid-spin.ttl" into "Valid-spin.ttl"

This imports the ontology 

xplant:GraftCSARAssessment 
  rdfs:subClassOf 
    [ owl:onProperty core:hasResultValue ; owl:hasValue xplant:NonFunctioningGraft ] .
    [ owl:onProperty core:hasResultValue ; owl:cardinality 1 ] .

[ a owl:AllDifferent ;
  owl:members (xplant:NonFunctioningGraft xplant:FullyFunctioningGraft) ] .

data:someOutcome a xplant:GraftCSARAssessment ;
    core:hasResultValue xplant:FullyFunctioningGraft .

One might expect that data:someOutcome is obviously invalid because it has the wrong value for core:hasResultValue. This would be the case in a DL reasoner (which would, perhaps surprisingly, require the owl:AllDifferent to know that xplant:FullyFunctioningGraft is not another name for xplant:NonFunctioningGraft), but an RL reasoner doesn't enforce cardinality. Looking at the inferred triples shows you that data:someOutcome core:hasResultValue xplant:NonFunctioningGraft..

Change the inference from TopSPIN to OWLIM as above

Re-add TopSPIN below SwiftOWLIM:

Execute a query for data:someOutcome's core:hasResultValue

As above, you will need to run inferencing first to see results. 

SELECT *
WHERE {
    data:someOutcome core:hasResultValue ?v .
}

We see that data:someOutcome has two core:hasResultValue. An OWL DL reasoner would flag this as an error because of the [ owl:onProperty core:hasResultValue ; owl:cardinality 1 ] constraint.

View Problems (Window·Show view·Inferences) and refresh the problem list

In order to enforce this cardinality constraint, we can use a SPIN rule. Note that data:someOutcome is of type xplant:GraftCSARAssessment. Adding a constraint to xplant:GraftCSARAssessment will allow us to make sure there's only ever one core:hasResultValue and that it's value is xplant:NonFunctioningGraft


Retrieved from "https://www.w3.org/wiki/index.php?title=HCLS/ClinicalObservationsInteroperability/FDATherapeuticAreaOntologies/LoadingTAOntologiesIntoTBC&oldid=77386"