harold: We have a test harness for testing conformance against R5 shex. They added a new attribute called 'link". We need to add that. The test tool is on the fhircat github.
harold's test tool: https://github.com/hsolbrig/fhir_model_generator
<ericP> https://github.com/ericprud/shex-to-jsonld-context/ -> repo
<ericP> https://github.com/ericprud/shex-to-jsonld-context/tree/master/build -> build products
<ericP> https://github.com/ericprud/shex-to-jsonld-context/blob/master/bin/shex-to-jsonld-context -> script
harold: First goal is to produce JSON-LD to match the current FHIR/RDF (including fhir:value etc.) We're calling that "R4 JSON-LD". "R5 JSON-LD" would not have the fhir:values.
repo: https://github.com/ericprud/shex-to-jsonld-context/ build products: https://github.com/ericprud/shex-to-jsonld-context/tree/master/build script: https://github.com/ericprud/shex-to-jsonld-context/blob/master/bin/shex-to-jsonld-context
eric: We have FHIR/JSON already
-- mature, lots of use, etc. RDF version doesn't get much love.
With JSON-LD 1.0, we were not able to generate RDF from
FHIR/JSON, because it did not have context-sensitive
processing. JSON-LD 1.1 adds context-sensitivity., and allows
lots of @contexts to be used in different contexts.
... I took a stripped-down AllergyIntolerance shex, with only a
few properties, and ran a little script that takes all the ones
without a dot and builds a new data structure file for them,
then does some templating, looks at constraints, an dgenerates
json-ld @context for each resource or datatype. (Will
eventually be ~250 of these.)
... dateTime is expected to have that datatype, but the JSON
does not have any datatype in the FHIR/JSON spec. But the JSON
serializatoin does not tell you which type it is. It will have
to be done by recognition.
harold: The way the RDF is put together, you can give something as xsd:date. But in JSON we only have the value and we have to infer the type from the value.
eric: There are two ways the type
is presented. In one case the property gives the type, but
dateTime is the other way -- you have to look lexically at the
value.
... lastOccurrence is a union, but you can distinguish
lexically between the choices.
... dateTime is misleading, because it is really a union of
date, gMonth and gYear.
harold: Could either leave it in RDF as a string, or do pre/post processing to add the actual type. Which way should we go?
eric: RDF community likes things fully typed, to catch errors.
deepak: What is the plan? Generate these @contexts for all the resources?
harold: yes. By Jan FHIR
Connectothon we want to have a first cut of all
resources.
... But we'll evenually have to write an equivalent to shexj
but in java, to add to the build process.
eric: It's an opportunity to look for places that I made assumptions but shouldn't have.
deepak: FHIR build process has to be extended with Java to gen the @contexts?
harold: Want to demonstrate that
we can use JSON-LD 1.1 @context to produce today's R4 RDF. That
will give us a benchmark for comparison as we evolve to
R5.
... Shex generator is template driven. Should be easy enough to
change the current java shex emitter to gen the @context
files.
... Given that we cannot change the FHIR spec, we'll have to
emit some parsing and shim code to do this also.
... In JSON-LD, anything that begins with an @ sign is
reserved, so we could sneak processing instructions into
it.
... But processors might reject them.
... One way or another we'll have to do lexical pre/post
processing.
ISSUE: Should we add explicit types to the RDF where they are unions in the FHIR?
david: What do we want to show in January?
harold: Generate a complete
library somewhere (maybe on github for the moment) of all of
the @context files for FHIR.
... And accompany those with a pre/post processor that turns it
into valid R4 FHIR/RDF.
... Those things in the pre/post processing are the primary
things we want to reconsider for R5 FHIR/RDF?
deepak: Do we have a list of those things?
<hsolbrig> david: there will be some things that have to be a pre-processing step, such as numberic digits (5.5 vs. 5.50)...
<hsolbrig> ... you can't use a generic JSON processor to do this. It would be better to only do one step (pre) vs. splitting them
<hsolbrig> eric: We don't have to worry about this in RDF-land...
<hsolbrig> ... in RDF, xsd:float 1.0 is different that 1.00
<hsolbrig> david: treeroot is another place info is lost, along with fhir:index
david: I realized that
pre-processing may be helpful, for treeRoot, fhir:index and for
retaining digits in numbers, and we could use the same blank
node and fhir:value technique to add the extra datatype
information, in the case of union types.
... That would allow all of the extra processing to be done in
a single pre-processing step.
deepak: I would have to write that java pre-processor?
david: Yes. We would want to provide that for the commiunity, and JS and python versions.
ADJOURNED
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/AllergyIntolerance example/AllergyIntolerance shex/ Present: Nansu_and_Yue_from_Mayo_Clinic Harold_Solbrig Dan_Stone EricP Dazhi Giorgio. hsolbrig David_Booth No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]