ITS RDF Concall Minutes 20150119

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

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

Present: Paul Knapp, Dale Nelson, Darrell Woelk, Claude Nanjo, Rob Hausam, Brian Pech, Nicole Antonson, Jamie Ferguson, Peter Hendler, Jeffrey Ting, Craig Parker, Richard Kavanagh, Gaby Jewell, Prashant Triveoi, David Booth, Charlie Mead, Cecil Lynch, Steve Fine, Keith Willard, Michael van der Zel, Cosmo Difazio, Harold Solbrig, Mike Henderson, Peter Antoniw, Daniel Lanphear - Sign-up sheet

Quorum met: Yes

Chair: Dale Nelson

Scribe: Claude Nanjo (with edits by David Booth)

Agenda

Purpose and Goals of RDF Subgroup

David Booth reviewed the goals of the RDF subgroup, and how this work fits into the Yosemite Project roadmap. Someone suggested that the group also discuss 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, unofficial hackathon discussion held outside of our ITS meeting.

David Booth discussed FHIR modifier extensions and RDF monotonicity with Claude, Harold and Peter Hendler. 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 elements with modifier extensions to instead be nested inside an element called <modifierExtension> (or similar), instead of being a tag on an existing resource type.

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

(Example added later) In other words, instead of permitting this:

<foo>
  <modifierExtension url="http://example.org/fhir/ExtensionDefinition/negation">
    <valueBoolean value="true"/>
  </modifierExtension>
  <!-- ... other content ... -->
</foo>

require this:

<modifierExtension url="http://example.org/fhir/ExtensionDefinition/negation">
  <valueBoolean value="true"/>
  <foo>
  <!-- ... other content ... -->
  </foo>
</modifierExtension>

This would be safer because it would make the fact that it is a modifier extension harder to ignore. However, the nested element <foo> would still have the same structure as a non-modified <foo>, so it could still be processed using the same code if desired. Such a modifier element could be allowed at any level of the resource.

One way that multiple modifier extensions mod1 and mod2 could be handled would be to allow them to be nested, which would indicate a clear precedence for determining the semantics. In the following example, mod1 would determine the overall semantics, but would typically be defined in terms of the original semantics of mod2, and the semantics of mod2 would typically be defined in terms of the original semantics of foo.

<modifierExtension url="http://example.org/fhir/ExtensionDefinition/mod1">
  <!-- ... mod1 extensions ... -->
  <modifierExtension url="http://example.org/fhir/ExtensionDefinition/mod2">
    <!-- ... mod2 extensions ... -->
    <foo>
    <!-- ... foo content ... -->
    </foo>
  </modifierExtension>
</modifierExtension>

--Lmckenzi (talk) 02:34, 27 January 2015 (UTC) Don't understand how this could work. First, multiple modifier extensions can be present at the root level of a resource. Second, extensions can occur at places other than the root level of a resource.

User:Dbooth I may not have it right yet, but the thought is to have: (a) the outer resource be <modifierExtension>, to help ensure that it will not be inadvertently ignored; and (b) to tag it with exactly the same name as the original resource (e.g., "Procedure", in the above example), so that it matches without requiring substring or concatenation operations.

FHIR in JSON-LD

This was an informal, unofficial hackathon discussion held outside of our ITS meeting.

David Booth described progress to date on investigating the possibility of using JSON-LD as a FHIR serialization. See slides and files. One issue noted so far is that the current JSON serialization of FHIR creates a pair of related elements for each primitive element that has an extension. The extension element has the same name as the regular element except that it starts with an underscore, such as "dob" and "_dob". But in RDF we need relationships to be explicit, rather than being implied by having names that are syntactically very similar.

[David adds later:] One way this might be better addressed would be to have the extension always indicated with an "extension" element that contains a tag identifying the element that is being extended. I.e., instead of this:

{
 "dob": ...
 "_dob": ...
}

have this:

{
 "dob": ...
 "extension":
    {
       "target": "dob",
       ...
    }
}