W3C

– DRAFT –
FHIR RDF

28 July 2022

Attendees

Present
David Booth, EricP, Houcemeddine, Jim Balhoff, Rob Hausam
Regrets
Gaurav Vaidya
Chair
David Booth
Scribe
dbooth

Meeting minutes

Properties with both scalar and object range #102

jim: Would option 2 also address the RDF list issue?
… Could maybe offer tooling to convert from OWL friendly version to SPAREQL friendly version

DBooth: Preferences?
… most in favor of #5.

dbooth: Would be strongly against having two versions

AGREED: option 5, not hoist scalars (same as R4)

eric: Should also bring awareness to the larger sem web coimmunity about this issue.

dbooth: I think it's a flaw in the OWL to discourage that.

This closes both #102 and #77

This also closes #103

How should modifier extensions be handled in RDF? #93

https://github.com/w3c/hcls-fhir-rdf/issues/93

eric: We want to prevent a FHIR processor from not noticing the modifier ext and processing the data naively.

eric: Without hoisting, if wwe rename properties that have modifier ext by giving them a leading underbar, then we take care of the backbone element and scalar case.

ACTION: Dbooth to propose options

Issue 69: Shorten dot-compound property names?

dbooth: Not aware of any problems. Implemented in the playground.

eric: FHIR folks are doing more to ensure that property names have a consistent meaning.

dbooth: And without hoisting, everything is an object property anyway.

AGREED: Shorten property names.

We should not use fhir:value for non-hoisted scalar properties #104

We could use rdf:value instead. That's what it was made for. Jim: That would not work with OWL.

eric: But you cannot do inference with literals anyway.
… I tried If the code is 123435, then some inference, but could not get it working.

jim: You have to make a class expression

ACTION: jim to look into whether rdf:value would work instead of fhir:value

Issue 76: Ordered lists

jim: PR almost ready for changes to parse the list
… Caveat: If you apply owl annotations to those axioms, those annotations don't get parsed. That would be hard to solve.

dbooth: Is anyone likely to do that?

jim: It won't be in our FHIR output with RDF lists.
… It would be weird to do.
… It would involve reifying the list axiom.

dbooth: Do we still want to go ahead w RDF lists?

eric: Still keen on using lists.

jim: Last week I tried out using non-RDF property names for first and rest, and it worked.

dbooth: We could potentially publicize that as a workaround for folks who are bothered by RDF lists.

ACTION: jim to try OWL example that uses a scalar value

Meet also on Tuesdays, same time?

eric: Maybe

rob: Probably

jim: Can do the second two

houcemeddine: okay for me.

ACTION: DBooth to announce additional meetings

Issue 95: References lack a type arc

dbooth: Grahame pointed out that this would be a breaking change to make the "type" property required in the case of an absolute URL reference, so it isn't a change we can make. And we can live with it anyway.

eric: This would mostly affect validation of local internal hospital networks.

dbooth: Close the issue with no change?

eric: Close with a note saying we do not validate cases with absolute URLs beyond what FHIR requires for validation.

AGREED: Close #95 with no change.

ADJOURNED

Summary of action items

  1. Dbooth to propose options
  2. jim to look into whether rdf:value would work instead of fhir:value
  3. jim to try OWL example that uses a scalar value
  4. DBooth to announce additional meetings
Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).

Diagnostics

Succeeded: i/Topic: Issue 95/ACTION: DBooth to announce additional meetings

Succeeded: s/Topic: Open//

Succeeded: s/Properties with both scalar and object rang/Topic: Properties with both scalar and object rang/

Succeeded: i/We should not use fhir:value for non-hoisted/AGREED: Shorten property names.

Succeeded: s/handled in RF/handled in RDF/

Succeeded: i/Without hoisting, if wwe/eric: We want to prevent a FHIR processor from not noticing the modifier ext and processing the data naively.

No scribenick or scribe found. Guessed: dbooth

Maybe present: AGREED, DBooth, eric, jim, rob