See also: IRC log
harold: Got permission from
grahame and submitted a bunch of bug fixes.
... We have a couple more edge case issues. Need to discuss
them with grahame.
... And a major issue that we need to discuss w grahame, about
how he's gen datatypes.
... It includes types of gYear gYearMonth gDate
... When he generates the turtle he uses those types to
establish the precision of the datetime field.
... But the only datetime that OWL deals with is datetime. OWL
can do < and > comparisons.
... Reasoners get upset if they encounter gDate.
... It's a combination of the FHIR metadata vocab. Reasoner
burps when I say that something is an rdf restriction on
datatype xsd:gYear.
... Only allowed to use xsd:datetime there.
... We use those additional types to describe the precision of
the dates that we found in the json, from parsing the json.
ISSUE: How to handle gYear gYearMonth etc as dateTime in OWL
<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>.
harold: Another issue: FHIR
requires clever JSON parsers -- problem for anyone who is not
coding in java.
... Look at the note in this page about using a custom parser:
http://build.fhir.org/json.html
... and a bignum library. That's all good in the java world,
but they're essentially extending the json world for
FHIR.
... That carries over into RDF.
eric: I think SPARQL can treat the different numbers differently, until you compare them.
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.
... Cannot simultaneously preserve precision and do sensible
comparisons.
... RDF spec says that if you want to preserve precision, then
make yourself a bnode and put in the precision.
dbooth: and we already have fhir:value with a bnode that could be used.
harold: I'm thinking that we
should push back on the FHIR-extended JSON.
... We could say that 'we don't handle the fhir precision, so
the following conversions will fail ..."
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.
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.
... The XML-to-python tool that I use will do the same
thing.
dbooth: It was asserted early on that precision was used in lab values.
luis: Luis Marco
harold: I wrote another converter that is unaware of precision, and I have not found a precision issue anywhere except in money.
eric: Frequently in clinical
informatics, in lab results people want to keep
precision.
... Another is a researcher trying to pull significant digits
from results, but they never trust them anyway.
... So it seems like the use cases where precision is actually
represented in a decimal are vanishingly rare. Have you seen
anything else?
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.
harold: An accident waiting to happen as is. Could use an extension to preserve precision if you care about it.
eric: Want to avoid building a complex object for numerics.
harold:
https://hangouts.google.com/_/elUi/chat-redirect?dest=https%3A%2F%2Fgithub.com%2Fw3c%2Fhcls-fhir-rdf%2Ftree%2Fgh-pages%2Ffhirowl
... Rob Hausam need to discuss next steps. Should it be part of
the distro, or a service?
dbooth: previous discussion about this: https://www.w3.org/2017/07/11-hcls-minutes.html#item02
harold: (looking at fhir
diagnostic-report-status codes in OWL)
... Is this what the OWL should look like?
... 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.
... That's why I have .owl as the file extension instead of
.ttl
... Should it be part of the FHIR distro?
... Also, in the v3 area, I don't think I'm generating the same
URIs as Lloyd did. Should they be the same?
... I.e., in the OWL rendering of the ORIM that Lloyd did a few
years ago.
... I'm currently awaiting advice from Rob Hausam and the
terminology group.
dbooth: What downside of including this with the FHIR spec?
harold: don't know.
... But Rob's group needs to take the lead on that.
... Grahame's terminology server implememtation is now complete
in its RDF support.
<scribe> ACTION: Rob Hausam to discuss with term group about publishing OWL vocabularies for codesystems [recorded in http://www.w3.org/2017/08/01-hcls-minutes.html#action01]
<trackbot> Created ACTION-90 - Hausam to discuss with term group about publishing owl vocabularies for codesystems [on Rob Frost - due 2017-08-08].
harold: grahame doesn't want the
ontology header, but I explained the grief that it causes if it
isn't in there.
... I'd like to propose that we change the version URI to match
the official FHIR model.
... I think the version URI should match the history versioning
of FHIR itself.
dbooth: Makes sense.
ADJOURNED
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/It/OWL/ Succeeded: s/gDate/gYear/ Present: EricP David_Booth Rob_Hausam Harold_Solbrig Luis_Marco No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Found Date: 01 Aug 2017 Guessing minutes URL: http://www.w3.org/2017/08/01-hcls-minutes.html People with action items: hausam rob[End of scribe.perl diagnostic output]