Fwd: Re: Question about decimal precision

And followup discussion . . . .

-------- Forwarded Message --------
Subject: Re: Question about decimal precision
Date: Mon, 27 Jul 2015 05:45:42 -0400
From: David Booth <david@dbooth.org>
Reply-To: David Booth <david@dbooth.org>
To: Lloyd McKenzie <lloyd@lmckenzie.com>, Anthony Mallia 
<amallia@edmondsci.com>
CC: HL7 ITS <its@lists.hl7.org>

I think it is more a question of whether a reasoner could treat 1.23 and
1.230 as equal.   In principle they certainly could, but I don't know
off hand (without testing) what particular tool kits will do.

AFAICT 1.23 and 1.231 should only be considered "equal" for application
use cases, such as comparing the same kind of value measured at
different times, e.g. two lab tests.  But it isn't really an equality
comparison, because it isn't transitive.  It's more of a "sufficiently
similar" comparison.

With regard to capturing information in the FHIR spec comments,  we
certainly should strive to capture as much of the semantics as we
reasonably can in RDF and OWL.  Even if out-of-the-box reasoners cannot
make useful inferences from something, specialized inference rules could
as long as we have enough information formally in RDF.

In this case we could capture the precision information in RDF in a few
different ways, such as:
  - having it implied by the class of an object;
  - having it implied by the predicate asserting that object;
  - using a precision decimal datatype in the RDF; or
  - adding an explicit triple for the precision.

The most obvious way to do it would be to use a precision decimal
datatype in the RDF, but we'll have to look at the pros/cons to figure
out whether that would be best.

David Booth

On 07/26/2015 01:40 PM, Lloyd McKenzie wrote:
> Yes, but would any of the RDF reasoners have the capacity to treat 1.23
> and 1.231 as equal regardless of data type?
>
> *Lloyd McKenzie*, P.Eng.
> Senior Consultant, Information Technology Services
> Gevity Consulting Inc.
>
> E: lmckenzie@gevityinc.com <mailto:lmckenzie@gevityinc.com>
> M: +1 587-334-1110 <tel:1-587-334-1110>
> W: gevityinc.com <http://gevityinc.com/>
>
> *GEVITY
> **/Informatics for a healthier world /*
>
> CONFIDENTIALITY – This communication is confidential and for the
> exclusive use of its intended recipients. If you have received this
> communication by error, please notify the sender and delete the message
> without copying or disclosing it*.*
>
> NOTE: Unless explicitly stated otherwise, the opinions and positions
> expressed in this e-mail do not necessarily reflect those of my
> employer, my clients nor the organizations with whom I hold governance
> positions
>
>
> On Sun, Jul 26, 2015 at 10:03 AM, Anthony Mallia <amallia@edmondsci.com
> <mailto:amallia@edmondsci.com>> wrote:
>
>     It would come to play in a datatype equality expression. Is 1.23
>     equal to 1.231? I haven’t found the specification referenceyet.____
>
>     __ __
>
>     Tony____
>
>     __ __
>
>     __ __
>
>     *From:*owner-its@lists.hl7.org <mailto:owner-its@lists.hl7.org>
>     [mailto:owner-its@lists.hl7.org <mailto:owner-its@lists.hl7.org>]
>     *On Behalf Of *Lloyd McKenzie
>     *Sent:* Sunday, July 26, 2015 11:46 AM
>     *To:* Anthony Mallia
>     *Cc:* David Booth; Grahame Grieve; HL7 ITS
>     *Subject:* Re: Question about decimal precision____
>
>     __ __
>
>     I doubt reasoners would be able to do much with precision anyhow.
>     Math isn't generally their strong point :>____
>
>
>     ____
>
>     *Lloyd McKenzie*, P.Eng.
>     Senior Consultant, Information Technology Services
>     Gevity Consulting Inc.____
>
>     E: lmckenzie@gevityinc.com <mailto:lmckenzie@gevityinc.com>
>     M: +1 587-334-1110 <tel:1-587-334-1110>
>     W: gevityinc.com <http://gevityinc.com/>____
>
>     *GEVITY
>     **/Informatics for a healthier world /*____
>
>     CONFIDENTIALITY – This communication is confidential and for the
>     exclusive use of its intended recipients. If you have received this
>     communication by error, please notify the sender and delete the
>     message without copying or disclosing it*.*____
>
>     NOTE: Unless explicitly stated otherwise, the opinions and positions
>     expressed in this e-mail do not necessarily reflect those of my
>     employer, my clients nor the organizations with whom I hold
>     governance positions____
>
>     __ __
>
>     On Sun, Jul 26, 2015 at 8:54 AM, Anthony Mallia
>     <amallia@edmondsci.com <mailto:amallia@edmondsci.com>> wrote:____
>
>     While following this discussion, there appears to be a general issue
>     which will affect the RDF schema transformation from the FHIR model.
>
>     There are documented items which appear to be conformance
>     requirements which are not represented computationally in the model
>     (e.g. in fhir:decimal).
>
>     The question will be whether the RDF schema represents both the
>     computational and documented parts or just the computational parts.
>     Unlike human programmers, reasoners don't understand comments. There
>     is a gray area in the middle (such as cardinality) where the
>     computational model has structured text which could be parsed.
>
>     If indeed we need to capture the documented parts, then total
>     automatic conversion of the FHIR model to OWL Schema Ontology is
>     probably impossible and will have to be done as a combination of
>     automatic and manual transform and is probably the safer way to go.
>
>     Tony
>
>     -----Original Message-----
>     From: owner-its@lists.hl7.org <mailto:owner-its@lists.hl7.org>
>     [mailto:owner-its@lists.hl7.org <mailto:owner-its@lists.hl7.org>] On
>     Behalf Of David Booth
>     Sent: Sunday, July 26, 2015 9:14 AM
>     To: Grahame Grieve
>     Cc: HL7 ITS
>     Subject: Re: Question about decimal precision
>
>     Found it:
>     http://www.w3.org/TR/xsd-precisionDecimal/#precisionDecimal
>     It looks like it is not an official part of XSD 1.1.  (It's
>     published as a W3C Working Group Note rather than a W3C
>     Recommendation.)  And it is not a subtype of xsd:decimal, because it
>     adds three special values: INF (positive infinity), -INF (negative
>     infinity) and NaN (not a number).
>
>     David
>
>     On 07/26/2015 03:29 AM, Grahame Grieve wrote:
>     > they defined a type for this in XSD 1.1
>     >
>     > Grahame
>     >
>     > On Sun, Jul 26, 2015 at 2:37 PM, David Booth <david@dbooth.org <mailto:david@dbooth.org>
>     > <mailto:david@dbooth.org <mailto:david@dbooth.org>>> wrote:
>     >
>     >     I wonder if someone has already defined an XML subtype of
>     >     xsd:decimal for this purpose.   Maybe not, since for schema
>     >     validation purposes it would be the same as xsd:decimal.
>     >
>     >     David
>     >
>     >     On 07/25/2015 07:37 AM, Grahame Grieve wrote:
>     >
>     >         yes that's a good way to phrase it
>     >
>     >         Grahame
>     >
>     >
>     >         On Sat, Jul 25, 2015 at 1:12 PM, David Booth <david@dbooth.org <mailto:david@dbooth.org>
>     >         <mailto:david@dbooth.org <mailto:david@dbooth.org>>____
>
>      >         <mailto:david@dbooth.org <mailto:david@dbooth.org>
>     <mailto:david@dbooth.org <mailto:david@dbooth.org>>>> wrote:
>      >
>      >              Hi Grahame,
>      >
>      >              I see what you mean.  So you are suggesting that
>      >         *syntactically* it
>      >              must conform to xsd:decimal, but semantically it
>     should be
>      >         treated
>      >              as a subtype of xsd:string, because the precision is
>      >         implied by the
>      >              syntactic form?
>      >
>      >              David
>      >
>      >              On 07/24/2015 10:03 PM, Grahame Grieve wrote:
>      >
>      >                  hi David
>      >
>      >                  This is not consistent with widely accepted
>     practice -
>      >         actually,
>      >                  unanimous practice in my experience - where the
>      >         precision is
>      >                  inferred
>      >                  from the presentation. I would expect a deluge of
>      >         complaints if
>      >                  we made
>      >                  people be explicit about precision, and to do it so
>      >         ubiquitiously.
>      >
>      >                  That would mean that any time you migrated
>     content from
>      >         anywhere -
>      >                  existing systems, v2 messages, CDA documents,
>     whatever
>      >         - you'd
>      >                  run into
>      >                  being tripped up by the precision question
>      >
>      >                  And as I've said, not one person has complained
>     to me
>      >         about this in
>      >                  CDA/v3/v2 in 20 years of doing HL7 data exchange.
>      >
>      >                  Grahame
>      >
>      >
>      >                  On Sat, Jul 25, 2015 at 11:56 AM, David Booth____
>
>      >         <david@dbooth.org <mailto:david@dbooth.org>
>     <mailto:david@dbooth.org <mailto:david@dbooth.org>>
>     >                  <mailto:david@dbooth.org <mailto:david@dbooth.org> <mailto:david@dbooth.org
>     <mailto:david@dbooth.org>>>
>     >                  <mailto:david@dbooth.org <mailto:david@dbooth.org> <mailto:david@dbooth.org
>     <mailto:david@dbooth.org>>
>     >         <mailto:david@dbooth.org <mailto:david@dbooth.org> <mailto:david@dbooth.org
>     <mailto:david@dbooth.org>>>>> wrote:
>     >
>     >                       On 07/24/2015 02:23 AM, Grahame Grieve wrote:
>     >
>     >                           Hi All
>     >
>     >                           We've got a task submitted against FHIRhere:
>     >
>      >
>     http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&
>     > tracker_item_id=8175&start=0
>     >
>     >                           The definition of xsd:decimal
>      >
>       (http://www.w3.org/TR/xmlschema-2/#decimal for
>      >         v1.0,____
>
>      > http://www.w3.org/TR/xmlschema11-2/#decimal for v1.1),
>
>
>      > explicitly
>      >
>      >                           precludes implied precision:
>      >
>      >                           "Precision is not reflected in this value
>      >         space; the
>      >                  number 2.0
>      >                           is not
>      >                           distinct from the number 2.00."
>      >
>      >
>      >                           This is not consistent with what we say
>     about
>      >         the data
>      >                  type in
>      >                           the FHIR
>      >                           data types page:
>      >                           The precision of the decimal value is
>      >         signficant (e.g
>      >                  0.010 is
>      >                           regarded
>      >                           as different to 0.01)
>      >
>      >
>      >                       I would prefer to have the FHIR spec say
>     that the
>      >         precision
>      >                  of the
>      >                       decimal value is *not* significant unless
>      >         something else
>      >                  (such as a
>      >                       standard extension or another field) explicitly
>      >         indicates its
>      >                       precision.  This would allow most cases touse
>      >         standard decimal
>      >                       parsers that do not return information
>     about the
>      >         number of
>      >                  digits of
>      >                       precision.
>      >
>      >                       David Booth
>      >
>      >
>      >                           According to the commenter, we would
>     have use
>      >         xsd:string or
>      >                           xsd:precisoinDecimal from xsd v1.1. Or
>     change
>      >         the way we do
>      >                           precision
>      >
>      >                           I don't want to do any of these
>      >                           - using xsd:string would be a big loss
>     for schema
>      >                  generation tools
>      >                           - using xsd 1.1 would be weird, given our
>      >         stated policy for
>      >                           supporting tools
>      >                           - changing the way we do precision
>     would be a
>      >         problem with
>      >                           regard to the
>      >                           other specifications (and with regard to
>      > JSON too)
>      >
>      >                           My inclination is actually to document
>     this as a
>      >                  deviance from
>      >                           schema. I
>      >                           think this is actually ok because we've
>     been
>      >         running
>      >                  this same
>      >                           deviance
>      >                           for more than a decade in the v3 space, and
>      >         not once I have
>      >                           heard about
>      >                           this being a problem anywhere (and I've
>     heard
>      >         a lot
>      >                  about schema
>      >                           problems in the v3 space). And nor in
>     all the work
>      >                  we've done
>      >                           with FHIR
>      >                           so far either.
>      >
>      >                           So I really think that this is a
>     theoretical
>      >         concern,
>      >                  and that
>      >                           we just
>      >                           add another text note to the precision
>     notes
>      >         about this
>      >                  issue
>      >
>      >                           Grahame
>      >
>      >
>      >
>      >                           --
>      >                           -----____
>
>      > http://www.healthintersections.com.au /
>     >grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>>
>     >                           <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>>>
>     >                           <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>>
>     >                           <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>>>> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>      >         <tel:%2B61%20411%20867%20065>
>      >                  <tel:%2B61%20411%20867%20065>
>     >                           <tel:%2B61%20411%20867%20065>
>     >
>     >
>     >
>     >         ***********************************************************************************
>     >                           Manage your subscriptions
>      >                  <http://www.HL7.org/listservice> |
>      >                           View the
>      >                           archives
>     <http://lists.HL7.org/read/?forum=its> |
>      >                  Unsubscribe
>      >
>      >
>      >
>       <http://www.HL7.org/tools/unsubscribe.cfm?email=david@dbooth.org&list=its>
>      >                           | Terms of use
>      >
>      >
>      >
>      > <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>      >
>      >
>      >
>      >
>      >                  --
>      >                  -----
>     >http://www.healthintersections.com.au /
>     >grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >                  <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>>> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>      >         <tel:%2B61%20411%20867%20065>
>      >                  <tel:%2B61%20411%20867%20065>
>      >
>      >
>      >
>       ***********************************************************************************
>      >                  Manage your subscriptions
>      >         <http://www.HL7.org/listservice> |
>      >                  View the
>      >                  archives <http://lists.HL7.org/read/?forum=its> |
>      >         Unsubscribe
>      >
>      >
>       <http://www.HL7.org/tools/unsubscribe.cfm?email=david@dbooth.org&list=its>
>      >                  | Terms of use
>      >
>      >
>      > <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>      >
>      >
>      >
>      >
>      >         --
>      >         -----
>     >http://www.healthintersections.com.au /
>     >grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>
>     >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      >         <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>>> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>      >         <tel:%2B61%20411%20867%20065>
>      >
>      >
>      >
>      >
>     > --
>     > -----
>     >http://www.healthintersections.com.au /
>     >grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>
>      > <mailto:grahame@healthintersections.com.au
>     <mailto:grahame@healthintersections.com.au>> / +61 411 867 065
>     <tel:%2B61%20411%20867%20065>
>
>     ***********************************************************************************
>     Manage subscriptions - http://www.HL7.org/listservice View archives
>     - http://lists.HL7.org/read/?forum=its
>     Unsubscribe -
>     http://www.HL7.org/tools/unsubscribe.cfm?email=amallia@edmondsci.com&list=its
>     Terms of use -
>     http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
>
>     ***********************************************************************************
>     Manage subscriptions - http://www.HL7.org/listservice
>     View archives - http://lists.HL7.org/read/?forum=its
>     Unsubscribe -
>     http://www.HL7.org/tools/unsubscribe.cfm?email=lloyd@lmckenzie.com&list=its____
>
>     Terms of use -
>     http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules____
>
>     __ __
>
>     ***********************************************************************************
>     Manage your subscriptions <http://www.HL7.org/listservice> | View
>     the archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
>     <http://www.HL7.org/tools/unsubscribe.cfm?email=amallia@edmondsci.com&list=its>
>     | Terms of use
>     <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>____
>
>
> ***********************************************************************************
> Manage your subscriptions <http://www.HL7.org/listservice> | View the
> archives <http://lists.HL7.org/read/?forum=its> | Unsubscribe
> <http://www.HL7.org/tools/unsubscribe.cfm?email=david@dbooth.org&list=its>
> | Terms of use
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>

***********************************************************************************
Manage subscriptions - http://www.HL7.org/listservice
View archives - http://lists.HL7.org/read/?forum=its
Unsubscribe - 
http://www.HL7.org/tools/unsubscribe.cfm?email=david@dbooth.org&list=its
Terms of use - 
http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules

Received on Tuesday, 28 July 2015 07:32:07 UTC