15:03:37 <RRSAgent> RRSAgent has joined #hcls
15:03:37 <RRSAgent> logging to http://www.w3.org/2015/07/28-hcls-irc
15:03:39 <trackbot> RRSAgent, make logs world
15:03:39 <Zakim> Zakim has joined #hcls
15:03:41 <trackbot> Zakim, this will be HCLS
15:03:41 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
15:03:42 <trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference
15:03:42 <trackbot> Date: 28 July 2015
15:03:45 <dbooth> Scribe: rhausam
15:03:49 <Tony> Tony has joined #HCLS
15:06:00 <Lloyd> Lloyd has joined #HCLS
15:06:10 <dbooth> Topic: Approve Minutes of previous meeting
15:06:19 <dbooth> july 14: http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20150714
15:06:28 <dbooth> july 21: http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20150721
15:07:55 <rhausam> dbooth: action item for Eric to write up about terminilogies
15:08:17 <dbooth> APPROVED: minutes of july 14 and 21
15:08:26 <dbooth> Topic: HL7 Project Scope Statement (PSS) for computable semantic links from FHIR to RIM
15:08:31 <dbooth> paul: no news
15:08:59 <rhausam> action item for Paul to write up PSS
15:08:59 <trackbot> Error finding 'item'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
15:09:01 <dbooth> Topic: FHIR RDF and Validation/Translation Task Force
15:09:34 <rhausam> eric: won't be available for call tomorrow
15:10:41 <dbooth> david: Use ConceptBase (initially) as the superclass?
15:11:37 <rhausam> david: motion to use ConceptBase as superclass (a.k.a. "CodeableThingy")
15:11:40 <dbooth> i.e., what we called CodeableThingy would be ConceptBase
15:12:03 <dbooth> ... CodingThing is now CodingBase
15:12:13 <dbooth> ... and CodeThingy is now CodeBase
15:12:44 <rhausam> tony: have made all of the changes
15:13:05 <rhausam> david: motion to use those names, second tony
15:13:09 <dbooth> AGREED: use those name
15:13:23 <rhausam> paul: motion approved - unanimous
15:13:41 <dbooth> Topic: xsd:decimal precision
15:13:43 <rhausam> david: discussion of XSD decimal precision
15:14:44 <rhausam> david: the XSD decimal data type for expressing decimal number - in the definition does not distinguish between 2.0 and 2.000
15:15:07 <rhausam> david: in medical field number if digits typically implies precision
15:16:19 <rhausam> david: in FHIR, data type will be xsd:deciman, but note will indicate that digits will be retained to and imply precision
15:16:29 <rhausam> david: how to represent in RDF?
15:17:06 <dbooth> xsd:precisiondecimal
15:17:24 <rhausam> david: several options available - one option is xsd:precisiondecimal
15:18:26 <rhausam> david: that data type also adds 3 special values - pos infinity, neg infinity and "not a number" - those values will not occur in FHIR, if using xsd_decimal underneath
15:18:38 <rhausam> david: could define another data type
15:19:05 <rhausam> lloyd: can't do it for XML representation
15:19:30 <rhausam> lloyd: not sure how tooling will handle it
15:19:56 <rhausam> eric: RDF can deal with alien data types
15:20:27 <rhausam> tony: can add xsd:precisiondecimal to tooling
15:21:11 <rhausam> david: if use precisiondecimal will not lose trailing digits
15:21:45 <rhausam> marc: how do reasoners use this?
15:22:08 <rhausam> tony: for any restriction, reasoner will figure it out
15:22:20 <rhausam> eric: OWL can't do < or >
15:22:59 <rhausam> david: if we do use xsd:precisiondecimal, would we lose anything?
15:23:23 <rhausam> lloyd: will the tools at least recognize that it's a decimal?
15:23:34 <rhausam> eric: SPARQL won't recognize it
15:25:02 <rhausam> eric: most of the time use practical representation, if doing something that calls for it use the precise representation
15:25:29 <rhausam> lloyd: most of the time precision won't matter - only in rare cases it will
15:25:45 <rhausam> david: it does need to be retained
15:26:19 <rhausam> david: our goal is to make it computable
15:26:57 <rhausam> tony: don't want annotation to be considered for computation
15:27:21 <rhausam> david: precisiondecimal is not a subtype of decimal
15:28:05 <rhausam> eric: Pellet has bugs around this - other reasoners may have, as well - doesn't show up in SPARQL engines
15:28:51 <rhausam> david: will want to do comparisons freuently in SPARQL
15:30:15 <rhausam> david: would like to remove option to use xsd:decimal alone in RDF, as toolkits will lose information and cannot round-trip - could use xsd:decimal and an additional attribute
15:31:23 <rhausam> tonY: FHIR decimal is a complex type - has xsd:decimal, and could add an additional attribute - like an extension
15:32:03 <rhausam> david: best 2 options: (1) use xsd:precisiondecimal (2) use xsd:decimal, plus additional attribute for precision
15:33:44 <rhausam> erid: problem is across all of the computational platforms
15:33:54 <rhausam> claude: how will the extension helo?
15:34:32 <rhausam> david: need to capture two pieces of information: (1) quantity (2) precision
15:35:35 <rhausam> david: Tony's suggestion - use fhir:decimal, with base xsd:decimal plus the additional attribute to convey precision
15:35:53 <rhausam> david: precision is number of digits to the right of decimal
15:37:03 <rhausam> david: from SPARQL query perspective, Tony's suggestion with precision attribute probably will work best as tools will be able to recognize xsd:decimal
15:38:00 <rhausam> david: will use xsd:decimal for schema validation, but still need to keep track of number of precision digits
15:39:06 <rhausam> lloyd: if people read the documentation and do what they are supposed to do, they will retain the trailing zeros, but practically most will not as they don't read the documentation
15:39:33 <rhausam> lloyd: precision should be captured as a standard extension
15:40:43 <rhausam> lloyd: not sure how (or if) reference implementations handle this
15:41:01 <rhausam> david: maybe we are premature discussing this for FHIR RDF?
15:41:39 <rhausam> lloyd: should initiate and pursue this getting settled - ask the questions to implementers
15:42:14 <rhausam> lloyd: making precision a separate element makes it harder to lose
15:42:38 <rhausam> claude: move to 1.1?
15:42:56 <rhausam> lloyd: no interest of FHIr in moving to 1.1
15:43:45 <rhausam> david: from an RDF perspective, an additional attribute is ideal
15:44:08 <rhausam> david: should we as a group provide feedback to FHIR?
15:44:18 <rhausam> lloyd: better to do that with evidence
15:46:08 <dbooth> https://hl7-fhir.github.io/datatypes.html#quantity
15:46:15 <rhausam> lloyd: decimal usually used in places like sort order, where precison is not relevant - where precision is relevant we use quantity - an additional element can be added there with less cost
15:47:13 <rhausam> lloyd: the simple types can only add an extension
15:48:57 <rhausam> david: precision logically would fit into quantity
15:49:28 <rhausam> paul: for currency precision is implied
15:50:01 <rhausam> david: not convinced that is necessarily always true - fractional elements are sometimes used
15:50:55 <rhausam> claude: for measurement will use quantity, can't think of other cases
15:52:05 <rhausam> lloyd: analysis of use of decimal in FHIR
15:53:04 <rhausam> lloyd: most of the cases precision will not matter
15:53:46 <rhausam> lloyd: precision is needed for quantity, sampled data, timing, etc.
15:53:55 <rhausam> david: how do we go forward on this:
15:54:16 <rhausam> lloyd: go forward by seeing how reference implementations handle it
15:56:09 <rhausam> lloyd: if majority of implementers get it wrong would imply that the design we have is vulnerable and we should rethink it - the first question is FHIR's implementation (not RDF)
15:56:31 <rhausam> tony: the FHIR spec can't retain the precision
15:56:52 <rhausam> lloyd: FHIR implmentation is xs:decimal+
15:57:44 <dbooth> simple test might be the try round tripping 12.000
15:57:51 <rhausam> lloyd: if implementers are doing it right in XML and JSON, may use that in RDF - if not, need to re-think it in FHIR
15:58:39 <rhausam> david: action item - check to see if precision is preserved with round-tripping in reference implementations currently
15:59:28 <rhausam> david: xsd documentation says you can lose the precision, but FHIR documentation says that you cannot
16:00:49 <rhausam> david: we know that the FHIR documentation of decimal is not lossy
16:01:34 <rhausam> eric: it's not even clear how queries should behave for these comparisons
16:02:32 <rhausam> david: you are asking whether the comparison rules are clear in FHIR?
16:03:12 <rhausam> paul: quick test in .net - precision digits are not retained
16:04:19 <rhausam> david; need to check the reference implemtations behavior
16:05:24 <rhausam> david: provide input - mechanism is to gather evidence - check the reference implementations - who will do that?
16:06:51 <rhausam> david: if reference implementations are not in compliance, that is evidence that people are likely to screw it up
16:07:14 <rhausam> tony: but may not be possible to do this with xsd:decimal
16:08:49 <rhausam> paul: if something is inherenty wrong, we should fix it
16:10:09 <rhausam> paul: bet people are not handling it because they didn't read the spec
16:10:40 <rhausam> eric: something in the spec that no one anticipates effectively isn't in the spec
16:11:32 <dbooth> ACTION: Lloyd to ask James and Ewot about the underlying precision retention of xsd:decimal values
16:11:32 <trackbot> Error finding 'Lloyd'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.
16:11:37 <rhausam> loyd: will take action item to ask Ewout and James how they handle precision
16:13:35 <dbooth> Present: David Booth, EricP, Claude Nanjo, Lloyd McKenzie, Paul Knapp, Rob Hausam, Tony Mallia, Marc T
16:14:05 <dbooth> Chair: David Booth and Paul Knapp
16:14:47 <dbooth> rrsagent, draft minutes
16:14:47 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/28-hcls-minutes.html dbooth
17:07:22 <Zakim> Zakim has left #hcls