IRC log of hcls on 2017-08-01

Timestamps are in UTC.

15:11:13 [RRSAgent]
RRSAgent has joined #hcls
15:11:13 [RRSAgent]
logging to http://www.w3.org/2017/08/01-hcls-irc
15:11:15 [trackbot]
RRSAgent, make logs world
15:11:15 [Zakim]
Zakim has joined #hcls
15:11:17 [trackbot]
Zakim, this will be HCLS
15:11:17 [Zakim]
ok, trackbot
15:11:18 [trackbot]
Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference
15:11:18 [trackbot]
Date: 01 August 2017
15:11:36 [dbooth]
Topic: FHIR Metadata Vocabulary - fhir.ttl
15:12:06 [dbooth]
harold: Got permission from grahame and submitted a bunch of bug fixes.
15:12:32 [dbooth]
... We have a couple more edge case issues. Need to discuss them with grahame.
15:12:49 [dbooth]
... And a major issue that we need to discuss w grahame, about how he's gen datatypes.
15:13:21 [dbooth]
... It includes types of gYear gYearMonth gDate
15:13:42 [dbooth]
... When he generates the turtle he uses those types to establish the precision of the datetime field.
15:14:06 [dbooth]
... But the only datetime that OWL deals with is datetime. It can do < and > comparisons.
15:14:22 [dbooth]
s/It/OWL/
15:14:35 [dbooth]
... Reasoners get upset if they encounter gDate.
15:16:59 [dbooth]
... It's a combination of the FHIR metadata vocab. Reasoner burps when I say that something is an rdf restriction on datatype xsd:gDate.
15:17:17 [dbooth]
s/gDate/gYear/
15:17:48 [dbooth]
... Only allowed to use xsd:datetime there.
15:18:17 [dbooth]
... We use those additional types to describe the precision of the dates that we found in the json, from parsing the json.
15:19:08 [dbooth]
ISSUE: How to handle gYear gYearMonth etc as dateTime in OWL
15:19:08 [trackbot]
Created ISSUE-44 - How to handle gyear gyearmonth etc as datetime in owl. Please complete additional details at <http://www.w3.org/2014/HCLS/track/issues/44/edit>.
15:20:04 [dbooth]
harold: Another issue: FHIR requires clever JSON parsers -- problem for anyone who is not coding in java.
15:21:19 [dbooth]
... Look at the note in this page about using a custom parser: http://build.fhir.org/json.html
15:21:45 [dbooth]
... and a bignum library. That's all good in the java world, but they're essentially extending the json world for FHIR.
15:21:51 [dbooth]
... That carries over into RDF.
15:22:41 [dbooth]
eric: I think SPARQL can treat the different numbers differently, until you compare them.
15:23:57 [dbooth]
harold: if you're using a native RDF lib, and you know that 2 is different from 2.0 there is a way to use strings to stop RDF lib from treating it as a number.
15:24:51 [dbooth]
... Cannot simultaneously preserve precision and do sensible comparisons.
15:25:22 [dbooth]
... RDF spec says that if you want to preserve precision, then make yourself a bnode and put in the precision.
15:26:50 [dbooth]
dbooth: and we already have fhir:value with a bnode that could be used.
15:28:40 [dbooth]
harold: I'm thinking that we should push back on the FHIR-extended JSON.
15:29:28 [dbooth]
... We could say that 'we don't handle the fhir precision, so the following conversions will fail ..."
15:30:03 [dbooth]
eric: XML happens to be pretty good at this. Nobody said you shouldn't do it this way. No special functionality that deals with precision.
15:30:50 [dbooth]
harold: But if you take jaxb, it will take the xsd:decimal and turn it into a java double. It won't address that use case.
15:31:06 [dbooth]
... The XML-to-python tool that I use will do the same thing.
15:32:13 [dbooth]
dbooth: It was asserted early on that precision was used in lab values.
15:33:41 [dbooth]
Topic: Introductions
15:34:23 [dbooth]
luis: Luis Marco
15:34:45 [dbooth]
Topic: FHIR JSON datatypes
15:35:25 [dbooth]
harold: I wrote another converter that is unaware of precision, and I have not found a precision issue anywhere except in money.
15:37:09 [dbooth]
eric: Frequently in clinical informatics, in lab results people want to keep precision.
15:37:32 [dbooth]
... Another is a researcher trying to pull significant digits from results, but they never trust them anyway.
15:38:12 [dbooth]
... So it seems like the use cases where precision is actually represented in a decimal are vanishingly rare. Have you seen anything else?
15:39:07 [dbooth]
dbooth: FHIR has an 80/20 mantra, so if we can provide data to back up the assertion that precision is not used in practice, then maybe the decision could be changed.
15:39:38 [dbooth]
harold: An accident waiting to happen as is. Could use an extension to preserve precision if you care about it.
15:39:54 [dbooth]
eric: Want to avoid building a complex object for numerics.
15:40:22 [dbooth]
luis: https://hangouts.google.com/_/elUi/chat-redirect?dest=http%3A%2F%2Fwww.openehr.org%2Freleases%2FRM%2Flatest%2Fdocs%2Fdata_types%2Fdata_types.html%23_dv_quantity_class
15:41:08 [dbooth]
Topic: OWL for codesystems
15:41:14 [dbooth]
harold: https://hangouts.google.com/_/elUi/chat-redirect?dest=https%3A%2F%2Fgithub.com%2Fw3c%2Fhcls-fhir-rdf%2Ftree%2Fgh-pages%2Ffhirowl
15:41:38 [dbooth]
... Rob Hausam need to discuss next steps. Should it be part of the distro, or a service?
15:42:25 [dbooth]
dbooth: previous discussion about this: https://www.w3.org/2017/07/11-hcls-minutes.html#item02
15:44:02 [dbooth]
harold: (looking at fhir diagnostic-report-status codes in OWL)
15:44:13 [dbooth]
... Is this what the OWL should look like?
15:45:09 [dbooth]
... We now have two possible rrepresentations of these codesystems. We have a spec that says how to generate an RDF representation of a diagnositic report, and it isn't this one.
15:45:28 [dbooth]
... That's why I have .owl as the file extension instead of .ttl
15:45:38 [dbooth]
... Should it be part of the FHIR distro?
15:46:16 [dbooth]
... Also, in the v3 area, I don't think I'm generating the same URIs as Lloyd did. Should they be the same?
15:47:24 [dbooth]
... I.e., in the OWL rendering of the ORIM that Lloyd did a few years ago.
15:48:00 [dbooth]
... I'm currently awaiting advice from Rob Hausam and the terminology group.
15:53:13 [dbooth]
dbooth: What downside of including this with the FHIR spec?
15:53:19 [dbooth]
harold: don't know.
15:53:33 [dbooth]
... But Rob's group needs to take the lead on that.
15:54:22 [dbooth]
... Grahame's terminology server implememtation is now complete in its RDF support.
15:55:17 [dbooth]
ACTION: Rob Hausam to discuss with term group about publishing OWL vocabularies for codesystems
15:55:17 [trackbot]
Created ACTION-90 - Hausam to discuss with term group about publishing owl vocabularies for codesystems [on Rob Frost - due 2017-08-08].
15:56:07 [dbooth]
Topic: OWL header in ttl file
15:56:27 [dbooth]
harold: grahame doesn't want the ontology header, but I explained the grief that it causes if it isn't in there.
15:57:09 [dbooth]
... I'd like to propose that we change the version URI to match the official FHIR model.
15:57:43 [dbooth]
... I think the version URI should match the history versioning of FHIR itself.
15:58:07 [dbooth]
dbooth: Makes sense.
16:00:24 [dbooth]
ADJOURNED
16:00:39 [dbooth]
Present: EricP, David Booth, Rob Hausam, Harold Solbrig, Luis Marco
16:02:49 [dbooth]
Chair: David Booth
16:02:57 [dbooth]
rrsagent, draft minutes
16:02:57 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/08/01-hcls-minutes.html dbooth
18:50:03 [Zakim]
Zakim has left #hcls