This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

ITS RDF Concall Minutes 20150119

From HL7Wiki
Revision as of 01:45, 27 January 2015 by Dbooth (talk | contribs) (Created page with "Category:ITS RDF Category:ITS RDF Minutes 2015 Return to: ITS Main Page > ITS RDF ConCall Agenda > :Category:Category:ITS_RDF_...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Return to: ITS Main Page > ITS RDF ConCall Agenda > ITS Meeting Minutes > 2015

ITS RDF Face-to-Face Meeting - San Antonio - 19-Jan-2015

Present: @@TODO@ Quorum met: Yes

Chair: Dale Nelson

Scribe: Claude Nanjo (with edits by David Booth)


Purpose and Goals of RDF Subgroup

David Booth reviewed the goals of the RDF subgroup. Suggestion: Talk more about the Yosemite Project on a future teleconference.

Claude Nanjo presented Example Uses of RDF/OWL in Healthcare.

David Booth described progress toward standardizing a FHIR ontology and mappings to convert instance data between FHIR XML/JSON and RDF. Mandate of RDF subworking group is not limited to FHIR RDF. However, given the current momentum of FHIR, we are starting work on a FHIR ontology. Currently collecting requirements. Reviewed four parallel efforts on a FHIR ontology. Also looking at JSON-LD for the JSON resource representation for FHIR. Goal: converge on a single approach and standardize.

Two styles of ontology we could do. Difference between a FHIR ontology to based on FHIR as opposed to an ontology that informs FHIR.

Cecil: Perhaps we can get the latter from the former. That is, start with the former, fix the blemishes, and then move to the latter.

Peter Hendler: Upper ontology should be based on a lightweight RIM ontology - though not a recreation of V3

Charlie Mead: Serialization of the semantics of the model

Paul: May need to capture metadata on the resource external to the model if not explicit in the model

Claude: That metamodel should serve as the source of requirements for FHIR

Craig: Metamodel should not add complexity to FHIR or it will risk its approachability

Road Ahead

Paul: As issues are surfaced in building an ontology on FHIR or the RDF representation, we need to identify these issues, categorize them (architecture, serialization, modifying extensions, etc...) and see how these can be addressed.

Craig: Should RDF be based more on the profile rather than the resource?

Should often used extensions be moved to core? Differing opinions on how easy it is to do this given current FHIR governance. Another concern is that the extension path is taken too quickly rather than considering adding them to FHIR core.

Keith: Conventional looking instances backed with external RDF semantics to support integration - integrating actor semantics with profiles (profile definition enrichment - semantic annotations on the profile)

Craig: May be approaching this from the wrong direction - define the semantic definition and then generate the profile.

Paul: Use the surfacing of semantic enconsistencies in FHIR to address and fix the underlying semantic model for FHIR and then use this model as the source of requirements for FHIR.

How can we be most effective in this effort

Need to encourage the relaxation of the FHIR '80%' (referring to the FHIR aim of covering only 80% of use cases).

Suggestion: Do tutorials at future HL7 meetings to get more uptake - e.g., Intro to RDF (Paris? September?) Eric and Charlie could perform tutorials. Need to show practical applications of the use of RDF/OWL rather than just theoretical discussions. People need to see how this can be used in practice.

Harold: At Mayo we are using RDF to address complex problems. Guoqian Jiang routinely uses RDF as a fundamental toolkit to address complex problems.

FHIR modifier extensions and RDF monotonicity

(This was an informal discussion held outside of our ITS meeting.) David Booth discussed FHIR modifier extensions and RDF monotonicity with Claude and Harold. One approach would be to only map FHIR resource instances that are known to not contain modifier extensions to RDF classes that have the regular semantics, and map others that do have modifier extensions either to other classes (whose semantics may be unknown). Another approach would be to map resource instances that have modifier extensions to assertions in a separate graph that is not necessarily asserted. A third approach would be to map them to reified RDF.

Claude also suggested a fourth approach that had not previously been considered: do a straight syntactic mapping from FHIR XML or JSON to RDF, and treat that RDF merely as a representation of the corresponding FHIR message, rather than as having direct semantics. This would be kind of equivalent to reifying the entire message, so that it is not semantically asserted. This form of RDF could later be mapped to a different, more semantically usable ontology.

David also observed that the existing FHIR approach permitting modifier extensions seems inherently dangerous, even aside from any RDF usage, because an implementation could be installed assuming a particular profile that forbids modifier extensions and therefore has no need to check for them. But the implementation might later be changed to receive data that could have modifier extensions, thus potentially causing the received data to be unknowingly misunderstood. It would be safer to force all modifier extensions to be nested inside an element called <modifierExtension> (or similar), instead of being a tag on an existing resource type. In other words, instead of permitting this:

  <modifierExtension url="">
    <valueBoolean value="true"/>
  <!-- ... other content ... -->

require this:

<modifierExtension url="">
  <valueBoolean value="true"/>
  <!-- ... other content ... -->

This would be safer because it would make the fact that it is a modifier extension harder to ignore. however, the nested resource <Procedure> would still have the same structure as a non-modified <Procedure>, so it could still be processed using the same code if desired.

No conclusions were reached yet, but it was helpful to explore the problem space more.