Meeting minutes
FHIR Build
jim: Opened a couple of PRs. One on FHIR Core, and the other on Kindling. HL7/
hapifhir/
jim: Also theh profiles (structure defs)
jim: Looking at this example: http://
dbooth: propose address other things first. the Turtle structure defs are less important.
eric: We're looking at the meta level. Claude helped him work out a list of lower priority things.
eric: Low priority to even look for problems at the meta level.
dbooth: Agreed.
dbooth: I saw what looked like extra type arcs.
jim: fhir:deceased[x] has type arcs.
dbooth: Okay, that looks right.
eric: Multi-line comments in examples?
jim: That's still a problem. Will try to fix it.
jim: loinc concept IRIs are hard coded.
dbooth: Loinc prefix should be https://
… per Gaurav's google doc.
dbooth: Suggest adding others defined in the Gaurav's document: https://
jim: There's parsing work to be done also.
dbooth: Discussing parsing FHIR RDF and going back to FHIR JSON or XML.
jim: Can we drop that code? Is it used for anything?
eric: Maybe was used for round-trip testing.
ACTION: Jim check w Grahame about dropping the RDF parsing code (in favor of HAPI).
Ont generation
daniel: Made two commits for updates.
https://
https://
eric: Tried to see if there were commonalities between the various FHIR properties. In principle that would be a nice-ish way to populate the rdfs:labels.
dbooth: How should daniel gen the rdfs:labels ?
eric: 1. Grab the first of each. 2. omit rdfs:label 3. Hand-craft the property names.
dbooth: Option 4. How about concatenate them all?
eric: Option 5: Do option 4 but hand-craft some conspicuous ones.
daniel: Generated a subset for key elements we might care about.
… Then ran rdfdiff to compare latest changes.
eric: Maybe we should not invent generic labels, since they are not currently in FHIR.
dbooth: Propose concatenate the labels for each property, separated by vertical bars, into an rdfs:label
eric: Proposed generic labels might motivate the FHIR group to create generic labels.
… They already have a need for such a doc.
rob: Partly agree. Slowly trying to converge.
AGREED: Including truncated concatenated labels is better than omitting them.
AGREED: Daniel should use a list of generic labels if he has time, and fall back to trucated concatenated labels for others.
Punning for shortened propoerties?
AGREED: Use punning.
daniel: What other OWL assertions do we need?
dbooth: I think we need these:
1. Add global declarations:
fhir:_Resource rdfs:subClassOf [ owl:onProperty fhir:modifierExtension; owl:minCardinality 1 ].
[] a owl:AllDisjointClasses ;
owl:members ( fhir:Resource fhir:_Resource ) .
2. And for each FHIR resource such as fhir:Obs, add this declaration:
:_Obs rdfs:subClassOf fhir:_Resource.
jim: Seems ok to me.
eric: Not sure it should be fhir:Resource. Maybe fhir:DomainResource.
eric: need to investigate more.
daniel: example:
This is the only way that I could get blank node to appear in code atm: [ a owl:AllDisjointClasses ; owl:members ( fhir:Resource fhir:_Resource ) ] .
eric: That's fine that way.
ACTION: DBooth to investigate whether it should be fhir:Resoruce or fhir:DomainResource
http://
• There are a few resources (ones that do not specialize DomainResource) where extensions are not allowed on the root element, but extensions can appear elsewhere through the resource
eric: Can look at the content model of them, and also at the datatypes.
dbooth: So that quote Rob found indicates that the declaration should be for fhir:DomainResource and fhir:_DomainResource
eric: And only declare them on individual resources that are under fhir:DomainResource .
… directly or indirectly.
ADJOURNED