Meeting minutes
R4 issues and plans for R5
harold: One goal is round-trippability of FHIR JSON <--> FHIR RDF, without losing or gaining information.
… Design decisions in FHIR RDF R4 made sure that we could round-trip, but it added complexity, such as an extra blank node to allow extensions on a boolean.
… We should revisit some of these decision, to make FHIR RDF easier to use.
… But we don't want to make unneeded.
Issue 77: Blank nodes to support FHIR extensions
jim: Option 1 Will make OWL unhappy, because the same property would be both datatype and object type property.
harold: could add .extension to the property, like syntactic convention of underscore in front of the property name.
siviram: Nice to have the consistency of everything using the fhir:value everywhere.
emily: over-engineering may not be worth changing this.
harold: We thought we had over-engineered it when we came up with this.
gopi: would like to known where those blank nodes are. Might be easier to explain to non-RDF people without the blank nodes. But if it's a set pattern you can get used to it.
harold: While FHIR allows datatype extensions, and shows how it might be done, but how many profiles actually do this? Anybody?
… We could just say that we don't support primitive extensions in RDF, or we support them the way JSON does, with an underscore in front of the name.
sivaram: OWL distinguishes datatype properties from object properties, but most languages don't make that distinction.
harold: FHIR makes an internal distinction between datatypes (as we know them; value is its identity) and compound datatypes (that still lack identity).
sivaram: There's the basic data, and then inferred data. Maybe treat the extensions as a similar enrichment, so a short-cut way to the value -- a shadow property that mirrors the object property.
Captured in issue 77: https://
ADJOURNED