15:00:36 <RRSAgent> RRSAgent has joined #hcls
15:00:36 <RRSAgent> logging to http://www.w3.org/2015/06/10-hcls-irc
15:00:38 <trackbot> RRSAgent, make logs world
15:00:39 <Zakim> Zakim has joined #hcls
15:00:40 <trackbot> Zakim, this will be HCLS
15:00:40 <Zakim> ok, trackbot; I see SW_HCLS()11:00AM scheduled to start now
15:00:41 <trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference
15:00:41 <trackbot> Date: 10 June 2015
15:10:55 <dbooth> Topic: Why do we need 'value' in FHIR RDF?
15:13:18 <hsolbrig> hsolbrig has joined #hcls
15:13:30 <egonw_> egonw_ has joined #HCLS
15:13:35 <ericP> +1https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues
15:13:44 <Tony> Tony has joined #HCLS
15:13:57 <dbooth> https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues
15:15:00 <rhausam> rhausam has joined #HCLS
15:15:26 <dbooth> https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues
15:16:22 <dbooth> tony: really the issue is why there is an extra blank node with an enclosed 'value' property
15:17:07 <dbooth> eric: I think the motivation on datatypes is that there may be an extension attached.
15:18:58 <egonw_> egonw_ has joined #HCLS
15:19:32 <dbooth> eric: Would anyone ever put an extension on a datatype and expect others to understand it?
15:19:52 <dbooth> harold: This sounds like RIM version 3.  We're getting close to making this non-useful in RDF.
15:22:46 <dbooth> eric: I'm surprised there was no pushback in the JSON serialization
15:23:24 <dbooth> https://hl7-fhir.github.io/json.html
15:24:43 <egonw_> egonw_ has joined #HCLS
15:25:04 <dbooth> harold: We need the equiv of an underscore predicate
15:26:47 <dbooth> See slide 27: http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf
15:27:55 <dbooth> eric: For modifying extensions, in RDF we changed the name so that it will not accidentally show up in a query.
15:28:15 <dbooth> ... But they didn't want to have two different names when trying to display things.
15:29:06 <dbooth> ... If you say that modifying extensions must rename the property, then the display system won't know how to display it.
15:29:32 <egonw_> egonw_ has joined #HCLS
15:29:35 <dbooth> ... I'm concerned that any modifying extension will break things.
15:30:50 <dbooth> tony: XML techniques for disambiguation cannot be used either (like namespace)
15:32:16 <dbooth> q+ do say that we can make different, related URIs for the value and the extension data
15:32:32 <dbooth> q+ to say that we can make different, related URIs for the value and the extension data
15:33:38 <dbooth> q+ to say we have multiple issues here: 1. how to handle modifying extensions wrt monotonicity; 2. how to model extensions
15:34:34 <dbooth>  See slide 27: http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf
15:37:09 <dbooth> :john :dob "2003-12-12" .
15:37:42 <dbooth> :john :_dob  _foo .
15:38:24 <dbooth> where _foo is the extension stuff.
15:38:56 <dbooth> And somewhere else there would have to be a statement like this:
15:39:20 <dbooth> :dob fhir:hasExtension :_dob .
15:40:31 <dbooth> eric: If it were not a literal datatype property, then we could just add predicates.
15:40:51 <dbooth> ... For literals, we could do the same  thing by adding an intervening blank node.
15:40:58 <egonw_> egonw_ has joined #HCLS
15:41:12 <dbooth> ... But that is less palatable than directly having the value.
15:42:38 <dbooth> eric: we could call the value :code and the extension :_code .
15:46:00 <hsolbrig> q+ to say that there still has to be an explicit assertion of the :code and :_code relationship (:_code ex:extends :code)
15:46:12 <egonw_> egonw_ has joined #HCLS
15:47:13 <dbooth> # With extensions:
15:47:13 <dbooth>        fhir:CodeableConcept.coding [
15:47:13 <dbooth>            a fhir:Coding;
15:47:13 <dbooth>            fhir:Coding.system <http://snomed.info/sct>;
15:47:14 <dbooth>            fhir:Coding._system [ :mySysExtension "foo" ] ;
15:47:14 <dbooth>            fhir:Coding.code "66493003"^^fhir:code;
15:47:16 <dbooth>            fhir:Coding._code [ :myCodeExtension "bar" ] ;
15:47:18 <dbooth>         ];
15:47:24 <dbooth> ack hsolbrig
15:47:24 <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)
15:47:49 <Lloyd> Lloyd has joined #HCLS
15:48:34 <dbooth> ack dbooth
15:48:34 <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
15:48:38 <Zakim> ... extensions wrt monotonicity; 2. how to model extensions
15:49:42 <dbooth> # With extensions:
15:49:42 <dbooth>        fhir:CodeableConcept.coding [
15:49:42 <dbooth>            a fhir:Coding;
15:49:42 <dbooth>            fhir:Coding.system <http://snomed.info/sct>;
15:49:43 <dbooth>            fhir:Coding._system [ myext:moreSysInfo "foo" ] ;
15:49:43 <dbooth>            fhir:Coding.code "66493003"^^fhir:code;
15:49:45 <dbooth>            fhir:Coding._code [ myext:moreCodeInfo "bar" ] ;
15:49:47 <dbooth>         ];
15:50:13 <dbooth> and in an ontology:
15:50:41 <dbooth> fhir:Coding.code fhir:hasExtensionProperty fhir:Coding._code
15:51:57 <egonw_> egonw_ has joined #HCLS
15:56:41 <dbooth> # SPARQL to select all code extensions:
15:56:41 <dbooth> select * {
15:56:41 <dbooth> ?something a fhir:Coding ;
15:56:41 <dbooth>   fhir:Coding._code ?ext .
15:56:42 <dbooth> }
15:57:36 <dbooth> eric: How often are IDs and other things attached to these?
15:57:49 <dbooth> lloyd: Infrequently.  usually to attach narrative.
15:59:16 <dbooth> eric: I would expect IDs to be most often used on complex types, rather than on simple datatypes.
15:59:29 <dbooth> lloyd: Not necessarily.  Might point to display name.
16:00:17 <dbooth> eric: Want good practice to be terse, and bad practice still accommodated.
16:00:50 <dbooth> lloyd: Wide variety of reasons for putting IDs on things.
16:01:30 <dbooth> ... IDs are not commonly used, but when used are usually for sophisticated things.
16:01:56 <dbooth> eric: Let's try going with the underbar/JSON style.
16:03:39 <dbooth> # SPARQL to select all code extensions:
16:03:39 <dbooth> select * {
16:03:39 <dbooth> ?something a fhir:Coding ;
16:03:39 <dbooth>   fhir:Coding.code ?code ;
16:03:40 <dbooth>   fhir:Coding.code fhir:hasExtensionProperty ?underbar ;
16:03:40 <dbooth>   fhir:Coding._code ?ext .
16:03:42 <dbooth> }
16:04:16 <dbooth> trying again:
16:04:17 <dbooth> # SPARQL to select all code extensions:
16:04:17 <dbooth> select * {
16:04:17 <dbooth> ?something a fhir:Coding ;
16:04:17 <dbooth>   fhir:Coding.code ?code ;
16:04:17 <dbooth>   fhir:Coding.code fhir:hasExtensionProperty ?underbar ;
16:04:19 <dbooth>   ?underbar ?ext .
16:04:21 <dbooth> }
16:04:31 <rhausam> rhausam has joined #HCLS
16:04:47 <dbooth> # SPARQL to select all code extensions:
16:04:47 <dbooth> select * {
16:04:47 <dbooth> ?something a fhir:Coding ;
16:04:47 <dbooth>   fhir:Coding.code ?code ;
16:04:48 <dbooth>   fhir:Coding.code fhir:hasExtensionProperty ?underbar ;
16:04:48 <dbooth>   ?underbar ?ext .
16:04:50 <dbooth> }
16:05:36 <dbooth> lloyd: This would mean two different ways of finding extensions.  Same as in JSON.
16:05:49 <dbooth> ... But you're typically not doing queries as much in JSON.
16:05:57 <dbooth> ... Possible to do a property chain?
16:07:03 <dbooth> ... Would it be possible to have the same query structure for both datatype extensions and object extensions?
16:07:57 <dbooth> eric: we could also decide what is needed for serialization vs what is inferred by an ont.
16:11:11 <dbooth> With an extra bnode, queries would say '?foo fhir:Coding.code / fhir:value ?value' instead of '?foo fhir:Coding.code ?value'
16:12:21 <dbooth> Eric: Could have fhir:Coding.code be both a datatype property and a datatype property.
16:14:05 <dbooth> dbooth: That would force the query to use a FILTER clause to distinguish between an object value and a literal value.
16:16:38 <ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use
16:18:28 <dbooth> lloyd: Saving an extra node seems insignificant.  It feels like the underbar approach interferes with the elegance of query.
16:19:29 <dbooth> ... Will it feel more natural to have the extra bnode and value property, or the underbar approach?
16:19:47 <dbooth> ... I suspect the extra bnode would be more natural to RDF people.
16:20:14 <dbooth> eric: Lots of people will ask why the extra bnode is there.
16:20:19 <Tony> Q+
16:20:31 <dbooth> lloyd: And they ask that in XML, and we say that it is because of extensions, and they they move on.
16:21:06 <dbooth> ... I'm less concerned with questions that people saying 'that is totally unnatural'.
16:21:40 <dbooth> ... Underbar will be harder for people to wrap their heads around.
16:21:47 <dbooth> ack tony
16:22:14 <dbooth> q+ to agree with lloyd
16:23:21 <dbooth> tony: extra blank node aligns better with FHIR
16:24:02 <rhausam_> rhausam_ has joined #HCLS
16:24:06 <dbooth> ack dbooth
16:24:06 <Zakim> dbooth, you wanted to agree with lloyd
16:25:04 <dbooth> 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.
16:25:08 <rhausam_> +q
16:25:27 <dbooth> ack rhausam
16:25:51 <dbooth> rob: Agree with blank node approach.
16:26:41 <dbooth> eric: Net pain seems lower with underbar approach, but I understand the other arguments expressed.
16:26:59 <dbooth> ... Also cannot reused things from RIM.
16:27:26 <dbooth> lloyd: My leaning on that, is that when we get into ORIM alignment, I'm happy to change ORIM to align with FHIR.
16:28:37 <dbooth> eric: If these cases are rare, then there will be more pain with the blank node approach.
16:28:45 <dbooth> ... Also, need to handle modifying extensions.
16:30:20 <dbooth> AGREED: Go ahead with blank node and 'value' property approach
16:30:39 <ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use
16:30:47 <dbooth> Topic: View FHIR as Turtle
16:30:55 <ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use
16:32:24 <dbooth> ADJOURNED
16:52:31 <dbooth> rrsagent, draft minutes
16:52:31 <RRSAgent> I have made the request to generate http://www.w3.org/2015/06/10-hcls-minutes.html dbooth
17:05:09 <egonw_> egonw_ has joined #HCLS
17:44:38 <egonw_> egonw_ has joined #HCLS
18:29:29 <dbooth> Chair: David Booth
18:31:07 <dbooth> Present: Tony Mallia, EricP Harold Solbrig, Lloyd McKenzie, Rob Hausam
18:31:13 <dbooth> rrsagent, draft minutes
18:31:13 <RRSAgent> I have made the request to generate http://www.w3.org/2015/06/10-hcls-minutes.html dbooth
18:58:04 <Zakim> Zakim has left #hcls