<trackbot> Date: 28 July 2015

<dbooth> Scribe: rhausam

Approve Minutes of previous meeting

<dbooth> july 14: http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20150714

<dbooth> july 21: http://wiki.hl7.org/index.php?title=ITS_RDF_Concall_Minutes_20150721

dbooth: action item for Eric to write up about terminilogies

<dbooth> APPROVED: minutes of july 14 and 21

HL7 Project Scope Statement (PSS) for computable semantic links from FHIR to RIM

<dbooth> paul: no news

action item for Paul to write up PSS

<trackbot> Error finding 'item'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.

FHIR RDF and Validation/Translation Task Force

eric: won't be available for call tomorrow

<dbooth> david: Use ConceptBase (initially) as the superclass?

david: motion to use ConceptBase as superclass (a.k.a. "CodeableThingy")

<dbooth> i.e., what we called CodeableThingy would be ConceptBase

<dbooth> ... CodingThing is now CodingBase

<dbooth> ... and CodeThingy is now CodeBase

tony: have made all of the changes

david: motion to use those names, second tony

<dbooth> AGREED: use those name

paul: motion approved - unanimous

xsd:decimal precision

david: discussion of XSD decimal precision
... the XSD decimal data type for expressing decimal number - in the definition does not distinguish between 2.0 and 2.000
... in medical field number if digits typically implies precision
... in FHIR, data type will be xsd:deciman, but note will indicate that digits will be retained to and imply precision
... how to represent in RDF?

<dbooth> xsd:precisiondecimal

david: several options available - one option is xsd:precisiondecimal
... 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
... could define another data type

lloyd: can't do it for XML representation
... not sure how tooling will handle it

eric: RDF can deal with alien data types

tony: can add xsd:precisiondecimal to tooling

david: if use precisiondecimal will not lose trailing digits

marc: how do reasoners use this?

tony: for any restriction, reasoner will figure it out

eric: OWL can't do < or >

david: if we do use xsd:precisiondecimal, would we lose anything?

lloyd: will the tools at least recognize that it's a decimal?

eric: SPARQL won't recognize it
... most of the time use practical representation, if doing something that calls for it use the precise representation

lloyd: most of the time precision won't matter - only in rare cases it will

david: it does need to be retained
... our goal is to make it computable

tony: don't want annotation to be considered for computation

david: precisiondecimal is not a subtype of decimal

eric: Pellet has bugs around this - other reasoners may have, as well - doesn't show up in SPARQL engines

david: will want to do comparisons freuently in SPARQL
... 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

tonY: FHIR decimal is a complex type - has xsd:decimal, and could add an additional attribute - like an extension

david: best 2 options: (1) use xsd:precisiondecimal (2) use xsd:decimal, plus additional attribute for precision

erid: problem is across all of the computational platforms

claude: how will the extension helo?

david: need to capture two pieces of information: (1) quantity (2) precision
... Tony's suggestion - use fhir:decimal, with base xsd:decimal plus the additional attribute to convey precision
... precision is number of digits to the right of decimal
... from SPARQL query perspective, Tony's suggestion with precision attribute probably will work best as tools will be able to recognize xsd:decimal
... will use xsd:decimal for schema validation, but still need to keep track of number of precision digits

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
... precision should be captured as a standard extension
... not sure how (or if) reference implementations handle this

david: maybe we are premature discussing this for FHIR RDF?

lloyd: should initiate and pursue this getting settled - ask the questions to implementers
... making precision a separate element makes it harder to lose

claude: move to 1.1?

lloyd: no interest of FHIr in moving to 1.1

david: from an RDF perspective, an additional attribute is ideal
... should we as a group provide feedback to FHIR?

lloyd: better to do that with evidence

<dbooth> https://hl7-fhir.github.io/datatypes.html#quantity

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
... the simple types can only add an extension

david: precision logically would fit into quantity

paul: for currency precision is implied

david: not convinced that is necessarily always true - fractional elements are sometimes used

claude: for measurement will use quantity, can't think of other cases

lloyd: analysis of use of decimal in FHIR
... most of the cases precision will not matter
... precision is needed for quantity, sampled data, timing, etc.

david: how do we go forward on this:

lloyd: go forward by seeing how reference implementations handle it
... 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)

tony: the FHIR spec can't retain the precision

lloyd: FHIR implmentation is xs:decimal+

<dbooth> simple test might be the try round tripping 12.000

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

david: action item - check to see if precision is preserved with round-tripping in reference implementations currently
... xsd documentation says you can lose the precision, but FHIR documentation says that you cannot
... we know that the FHIR documentation of decimal is not lossy

eric: it's not even clear how queries should behave for these comparisons

david: you are asking whether the comparison rules are clear in FHIR?

paul: quick test in .net - precision digits are not retained

david; need to check the reference implemtations behavior

david: provide input - mechanism is to gather evidence - check the reference implementations - who will do that?
... if reference implementations are not in compliance, that is evidence that people are likely to screw it up

tony: but may not be possible to do this with xsd:decimal

paul: if something is inherenty wrong, we should fix it
... bet people are not handling it because they didn't read the spec

eric: something in the spec that no one anticipates effectively isn't in the spec

<dbooth> ACTION: Lloyd to ask James and Ewot about the underlying precision retention of xsd:decimal values [recorded in http://www.w3.org/2015/07/28-hcls-minutes.html#action01]

<trackbot> Error finding 'Lloyd'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.

loyd: will take action item to ask Ewout and James how they handle precision

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)

Found Scribe: rhausam
Inferring ScribeNick: rhausam
Present: David_Booth EricP Claude_Nanjo Lloyd_McKenzie Paul_Knapp Rob_Hausam Tony_Mallia Marc_T
Found Date: 28 Jul 2015
Guessing minutes URL: http://www.w3.org/2015/07/28-hcls-minutes.html
People with action items: lloyd

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.