Meeting minutes
Issue 93: Modifier extensions (Eric)
gaurav: What is the domain of fhir:active if it is done this way?
eric: It's generally bad form in RDF to restrict the domain.
eric: you annoy developers if you reify it.
eric: You either risk the property being misinterpreted, or you move it and affect the domain, or you reify.
david: My concern is to avoid accidentally interpreting a modified property, but beyond that I think we should do the absolute minimum.
eric: don't want to force the processing of non-mod extensions to be different if there are mod extensions.
Eric proposes option 2c (in turtle origValue)
david: That looks like it would solve the problem.
gaurav: agreed.
AGREED: Provisionally go with option 2c (origValue) for modifier extension
Issue 92: Significant digits in decimal numbers
gaurav: JSON allows precision to be implementation dependent.
… I think xsd:decimal does everything we need.
… But there's also xsd:precisionDecimal available.
… We cannot really do anything about the FHIR JSON part of it, except to remind people to use a special FHIR JSON parser.
gaurav: our tooling will have to turn FHIR JSON into triples. Some JSON parsers have an option to use xsd:decimal
david: Propose that we close this with no change to R4.
AGREED: All agreed. Close issue 92 with no change to R4.
Issue 78: Context sensitive date data types
gaurav: FHIR spec allows partial dates. But we use xsd:datetimes, and that does not allow approximate dates.
gaurav: XSD has various date types available for the different varieties. The JSON-->RDF conversion could look at which kind is needed and apply it.
gaurav: We could include both xsd:datetime and a less specific type, such as xsd:gYearMonth .
gaurav: But that would add redundancy. Prefer thatwe just use one datatype, such as xsd:gYearMonth
eric: I think that's what we have in R4 now.
Proposal to close 78 with no changes to R4.
AGREED: close 78 with no changes to R4.