W3C

- DRAFT -

Semantic Web Health Care and Life Sciences Interest Group Teleconference

10 Jun 2015

See also: IRC log

Attendees

Present
Tony_Mallia, EricP_Harold_Solbrig, Lloyd_McKenzie, Rob_Hausam
Regrets
Chair
David Booth
Scribe
dbooth

Contents


<trackbot> Date: 10 June 2015

Why do we need 'value' in FHIR RDF?

<ericP> +1https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues

https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues

https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues

tony: really the issue is why there is an extra blank node with an enclosed 'value' property

eric: I think the motivation on datatypes is that there may be an extension attached.
... Would anyone ever put an extension on a datatype and expect others to understand it?

harold: This sounds like RIM version 3. We're getting close to making this non-useful in RDF.

eric: I'm surprised there was no pushback in the JSON serialization

https://hl7-fhir.github.io/json.html

harold: We need the equiv of an underscore predicate

See slide 27: http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf

eric: For modifying extensions, in RDF we changed the name so that it will not accidentally show up in a query.
... But they didn't want to have two different names when trying to display things.
... If you say that modifying extensions must rename the property, then the display system won't know how to display it.
... I'm concerned that any modifying extension will break things.

tony: XML techniques for disambiguation cannot be used either (like namespace)

See slide 27: http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf

:john :dob "2003-12-12" .

:john :_dob _foo .

where _foo is the extension stuff.

And somewhere else there would have to be a statement like this:

:dob fhir:hasExtension :_dob .

eric: If it were not a literal datatype property, then we could just add predicates.
... For literals, we could do the same thing by adding an intervening blank node.
... But that is less palatable than directly having the value.
... we could call the value :code and the extension :_code .

# With extensions:

fhir: CodeableConcept.coding [

a fhir:Coding;

fhir: Coding.system <http://snomed.info/sct>;
... Coding._system [ :mySysExtension "foo" ] ;
... Coding.code "66493003"^^fhir:code;
... Coding._code [ :myCodeExtension "bar" ] ;

];

<Zakim> hsolbrig, you wanted to say that there still has to be an explicit assertion of the :code and :_code relationship (:_code ex:extends :code)

<Zakim> dbooth, you wanted to say that we can make different, related URIs for the value and the extension data and to say we have multiple issues here: 1. how to handle modifying

# With extensions:

fhir: CodeableConcept.coding [

a fhir:Coding;

fhir: Coding.system <http://snomed.info/sct>;
... Coding._system [ myext:moreSysInfo "foo" ] ;
... Coding.code "66493003"^^fhir:code;
... Coding._code [ myext:moreCodeInfo "bar" ] ;

];

and in an ontology:

fhir: Coding.code fhir:hasExtensionProperty fhir:Coding._code

# SPARQL to select all code extensions:

select * {

?something a fhir:Coding ;

fhir: Coding._code ?ext .

}

eric: How often are IDs and other things attached to these?

lloyd: Infrequently. usually to attach narrative.

eric: I would expect IDs to be most often used on complex types, rather than on simple datatypes.

lloyd: Not necessarily. Might point to display name.

eric: Want good practice to be terse, and bad practice still accommodated.

lloyd: Wide variety of reasons for putting IDs on things.
... IDs are not commonly used, but when used are usually for sophisticated things.

eric: Let's try going with the underbar/JSON style.

# SPARQL to select all code extensions:

select * {

?something a fhir:Coding ;

fhir: Coding.code ?code ;
... Coding.code fhir:hasExtensionProperty ?underbar ;
... Coding._code ?ext .

}

trying again:

# SPARQL to select all code extensions:

select * {

?something a fhir:Coding ;

fhir: Coding.code ?code ;
... Coding.code fhir:hasExtensionProperty ?underbar ;

?underbar ?ext .

}

# SPARQL to select all code extensions:

select * {

?something a fhir:Coding ;

fhir: Coding.code ?code ;
... Coding.code fhir:hasExtensionProperty ?underbar ;

?underbar ?ext .

}

lloyd: This would mean two different ways of finding extensions. Same as in JSON.
... But you're typically not doing queries as much in JSON.
... Possible to do a property chain?
... Would it be possible to have the same query structure for both datatype extensions and object extensions?

eric: we could also decide what is needed for serialization vs what is inferred by an ont.

With an extra bnode, queries would say '?foo fhir:Coding.code / fhir:value ?value' instead of '?foo fhir:Coding.code ?value'

Eric: Could have fhir:Coding.code be both a datatype property and a datatype property.

dbooth: That would force the query to use a FILTER clause to distinguish between an object value and a literal value.

<ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use

lloyd: Saving an extra node seems insignificant. It feels like the underbar approach interferes with the elegance of query.
... Will it feel more natural to have the extra bnode and value property, or the underbar approach?
... I suspect the extra bnode would be more natural to RDF people.

eric: Lots of people will ask why the extra bnode is there.

lloyd: And they ask that in XML, and we say that it is because of extensions, and they they move on.
... I'm less concerned with questions that people saying 'that is totally unnatural'.
... Underbar will be harder for people to wrap their heads around.

tony: extra blank node aligns better with FHIR

<Zakim> dbooth, you wanted to agree with lloyd

lloyd: Not a violation of our approach, because JSON does that, but from a class model perspective it should be there in RDF because that's what's going on. RDF should better reflect the class semantics than JSON.

<rhausam_> +q

rob: Agree with blank node approach.

eric: Net pain seems lower with underbar approach, but I understand the other arguments expressed.
... Also cannot reused things from RIM.

lloyd: My leaning on that, is that when we get into ORIM alignment, I'm happy to change ORIM to align with FHIR.

eric: If these cases are rare, then there will be more pain with the blank node approach.
... Also, need to handle modifying extensions.

AGREED: Go ahead with blank node and 'value' property approach

<ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use

View FHIR as Turtle

<ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use

ADJOURNED

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/06/10 18:31:18 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth
Present: Tony_Mallia EricP_Harold_Solbrig Lloyd_McKenzie Rob_Hausam
Found Date: 10 Jun 2015
Guessing minutes URL: http://www.w3.org/2015/06/10-hcls-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]