And followup discussion . . . .
-------- Forwarded Message --------
Subject: Re: Question about decimal precision
Date: Mon, 27 Jul 2015 05:45:42 -0400
From: David Booth <[email protected]>
Reply-To: David Booth <[email protected]>
To: Lloyd McKenzie <[email protected]>, Anthony Mallia
<[email protected]>
CC: HL7 ITS <[email protected]>
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: [email protected] <mailto:[email protected]>
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 <[email protected]
<mailto:[email protected]>> 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:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>]
*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: [email protected] <mailto:[email protected]>
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
<[email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>____
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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____
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>>> 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 /
>[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>>> / +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/[email protected]&list=its>
> | Terms of use
>
>
>
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>
>
>
>
> --
> -----
>http://www.healthintersections.com.au /
>[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> / +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/[email protected]&list=its>
> | Terms of use
>
>
> <http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules>
>
>
>
>
> --
> -----
>http://www.healthintersections.com.au /
>[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> / +61 411 867 065
<tel:%2B61%20411%20867%20065>
> <tel:%2B61%20411%20867%20065>
>
>
>
>
> --
> -----
>http://www.healthintersections.com.au /
>[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> / +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/[email protected]&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/[email protected]&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/[email protected]&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/[email protected]&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/[email protected]&list=its
Terms of use -
http://www.HL7.org/myhl7/managelistservs.cfm?ref=nav#listrules
