Meeting minutes
Intros
SteveMunini: Run Helios company. Int in ont work.
KenLord: Run a company exchanging data models, including FHIR, CDA, X12, etc.
… This group has an opportunity to put an ont that helps ensure semantic correctness of data exchange
RobHausam: MD, informaticist, co-chair of FHIR patient care.
ErichBremer: Sunnybrook U, formulating a community standard of RDF casting of DICOM.
ken: Eric Jahn works for Bitfocus. We collaborate. He is dev an ont for the HUD domain.
Extending the FHIR ont
ken: Rec that we use SULO as the basis for harmonizing multiple ontologies. It's very simple, but has important charactistics.
… Separates identities from roles, has concepts, uses OWL.
tim: I don't know enough about it, but I think eventually there will be mappings to a bunch of different ontologies. The more mappings the better. I don't see issues with mapping to SULO.
ericp: Long-time semantic web geek.
dbooth: SULO looks good to me.
tim: Might be easier to map to a more specific ont that is under SULO. BFO has an ont called OBI.
… Is there something more specific under SULO that might make the mapping easier?
ken: At present, the base level of SULO doesn't have many subclasses or object properties. If there are others that we can use . . .
tim: OBI https://
ericp: Michel says he can join next week.
Concept IRIs for CodeableConcepts
w3c/
ericp: Do Codings represent, just a structure, or a class?
rob: The set of meanings in the Codings, is the aggregage of the meanings of the elements.
… I agree that if you have multiple Codings, their intersection should be non-empty -- substantially non-empty.
dbooth: Maybe we should have used rdfs:subClassOf instead of rdf:type, on Codings.
ericp: rdfs:subClassOf might be too strong.
tim: dbooth, you want it to be a restriction? dbooth: yes.
jim: If I were doing this in OWL, I would use an existential restriction.
… If you have this Coding, there must be some anonymous instance of this Coding thing
tim: putting rdf:type on fhir:bodySite is needed for bindings also.
dbooth: I'm convinced that we erred in declaring the Coding as being an instance of the class.
rob: Does the varying levels of granularity have any adverse consequences?
… Often one Coding would be a subclass of another, e.g., right arm vs upper extremity.
ericp: How mechanically difficult is it, if the type arc is on the CodeableConcept?
tim: I think it's pretty easy. I also thought of a way to infer them.
dbooth: That looks exactly right to me.
dbooth: For practical purposes, I'd rather somehow attach the concept IRIs at the Coding levels, so that generic inference could later hoist them up to the CodeableConcept level.
ericp: But Codings also appear outside of CodeableConcepts, so we need to account for that.
… Would the tooling show up in two different places?
rob: Need a notion that the Coding outside of CodeableConcept is like a CodeableConcept with only a single Coding -- a degenerate case.
tim: To add a concept IRI to the Coding, we just need a suitable predicate.
tim: Sometimes codes are also used by themselves, like fhir:status.
dbooth: Seems like we're getting into the issue of something being treated sometimes as an instance and sometimes as a class. To avoid that problem, some people advocate only using classes, even if some of those classes only have one member.
ADJOURNED