SWAT4 Conference feedback

gerhard: was the wrong auditorium. Not much FHIR discussion.

FHIR extensions in R5

See: https://github.com/fhircat/FHIRCat/issues/31

harold: There are both extensions on primitives and on objects. Not proposing any change to extensions on objects. Underscores only appear (in FHIR/JSON) when the target is a literal.
... In option 1, the reason underscore is used in JSON is that if the same key (attribute) is repeated, then one overrides the other.
... We don't have that problem in RDF.
... Not a problem when the value is an object instead of a primitive.
... But a downside of option 1 is that it looks like there is an extra value of that attribute, i.e., the blank node for the extension.
... We're also going from the JSON representation to/from RDF instead of going to/from the internal FHIR model.
... For every primitive tag in FHIR, we have to address the possibility of an underscore tag. Option 1 puts it in the @context..
... To make this robust, I think we'll need a separate context that enumerates all the FHIR tags, mapping the underscore tags to non-underscore.
... Option3 means that we still have to deal with every underscore tag, but fhir.ttl must have all of the relationships between each tag and its underscore version, which expands that file.
... Several hundred? Not sure how many.

dazhi: Optoin 1 maps underscore to non-underscore.

harold: For option 3, what changes would be needed in the JSON transformation?
... I want primitives and non-primitives to look the same.
... For option 3, how would non-primitives be handled?
... This also relates to abandoning fhir:value .
... If name is a complex type, today in R4 it would be Patient / name / firstName , and Patient / name / extension
... And that's the way it is in the FHIR/JSON.
... FHIR/XML uses the fhir:value idiom.

<scribe> ACTION: David to write up extension option 2 more.

<scribe> ACTION: Harold to show what is needed for extension option 1 to be reversible.

eric: Both Lloyd and Grahame feel strongly that you should get the extension whenever you ask for an element.
... They believe that the lazy programmer should see the extensions rendered on the screen by default -- a liability issue.
... If we do it differently, we might have an uphill fight. We might be okay because we're RDF.

david: But FHIR/JSON already does not follow that guidance!

harold: Divide each option into 3 questions: what JSON transform is needed, what does the @context need, fhir.ttl ramifications, and what SPARQL impact.

eric: Should we apply these to modifying extensions?

harold: I have a proposal for mod extensions. I want to propose making extensions as first-class elements.
... Look at https://github.com/fhircat/FHIRCat/issues/4#issuecomment-562693074

<scribe> ACTION: Harold to write up proposed handing of mod extensions

eric: Might get weird with a CodeableConcrept made up of a Coding.

harold: Our tooling is robust enough that we can mock up these examples.

david: I don't like option 1's impact on SPARQL, haivng to filter out the extension when querying.

harold: Same impact would exist non-primitives?

<scribe> ACTION: Harold to show examples of both primitive and non-primitive extensions.

eric: Problem with FHIR/JSON is you are obligated to look for the underbar attribute. For mod extensions, we can make it harder to work with, because they'll be much rarer than non-mod ext.

harold: In RDF space, if consumers will be far enough outside the RDF domain, I don't want to take a chance that they'll miss it.

david: Good point.

eric: that would provide a safer version of FHIR/JSON.
... Propose that we don't have shex for them. etc. Forcing people to explicitly address them.

harold: Archetype example for mod ext would be a test for greater-than or less-than.

eric: Also need a test for fhir:value . Also one on status that has a literal that is not fhir:valued.

harold: I don't think that third case exists. A few fields are marked as non-extendable.
... I'm going to load a triplestore with one of the R5 proposals.

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/report/feedback/
Succeeded: s/Option 2/Option3/
Succeeded: s/primitives./primitives?/
Present: Gerhard_Kober Dazhi EricP Harold_Solbrig 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: david harold

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.)