15:01:00 RRSAgent has joined #hcls 15:01:05 logging to https://www.w3.org/2026/05/21-hcls-irc 15:01:05 rrsagent, make logs public 15:01:27 Meeting: FHIR RDF 15:01:32 Chair: David Booth 15:04:24 Topic: Concept IRIs for CodeableConcepts 15:05:34 tim: Zulip discussion: https://chat.fhir.org/#narrow/channel/179186-ontology/topic/RDF.20Concept.20IRI.20extension.20vs.20rdf.3Atype/with/596600877 15:06:11 ... Lloyd thought we were only going to use the ext syntax for JSON and XML, but I thought we were proposing it for RDF syntax also 15:06:14 dbooth: Agreed. 15:06:31 tim: And we discussed not showing this in the gen examples. 15:07:29 ... But when you add the ext, you are adding to the FHIR data in the FHIR vocab. 15:08:48 AGREED: to describe the optional ext in the rdf.html page, but not in the generated examples 15:09:19 https://github.com/w3c-cg/hcls-fhir-rdf/issues/219 15:10:10 tim: But rdf:type does not completely make sense for all concepts. 15:11:03 ... Eg, the code of a blood panel is not really a blood panel, but the observation of it is. 15:12:59 dbooth: That class is really a union of a BP itself, and codes for BPs. 15:14:08 ericp: dbooth is sanewashing the logic :) 15:15:01 ... I feel like it's close enough. The obs itself might be in multiple coding systems. Like in Bridge model for clinical trials, they have different stages like Defined and Performed. 15:15:32 ... When it actually happens, it's a diff concept (Performed). 15:16:03 ken: The BP itself is a list of obs, but it might be only a few of them. 15:16:30 ... It's a code of a list of possible distinct observations that get aggregated in the report. 15:16:54 tim: I'm searching through the examples, where the concept IRI is asserted. 15:19:48 ... If we want to show the concept IRIs in the CodeableConcepts, then we're just moving the rdf:type up to its parent CodeableConcept. 15:20:04 ... And it would be optional, and added to the gen examples. 15:23:27 dbooth: I think we should say "If someone wants to retain a concept IRI between serializations, then they should add the ext" 15:26:06 ericp: HAPI serializing JSON to RDF, would recognize any code sys that have an IRI stem, it would make the concept IRIs, but not add the ext. 15:26:52 ... But it could have an option to add the ext. 15:29:18 dbooth: So we would no longer say that you can optionally add the rdf:type to the Coding, right? 15:29:54 ... I.e., take it out of the shex? 15:30:57 ericp: Correct, take it out of the shex. 15:33:13 AGREED: We no longer suggest using the rdf:type on the Coding 15:35:13 ACTION: Tim to register the ext 15:36:24 ACTION: Tim to start a jira ticket for #219 resolution and others 15:37:28 Topic: Issue 223 15:37:52 tim: The class hierarchy has some unexpected things, including the _Backbone. 15:38:00 ... Want to make ont modules instead. 15:38:47 ... w a Base ont that looks like the FHIR hierarchy. 15:38:59 ... and an Elements ont. 15:39:15 ... and a Modifiers ont. 15:39:34 ... You could also have one for profiles, valueset bindings and logical models. 15:39:55 ericp: Sounds good to me. 15:40:21 dbooth: Me too. 15:40:47 ken: Are there any other org principles for those classes? 15:41:03 ... E.g., temporal aspects? Provenance? 15:41:32 tim: The meaning is reflected in the structure defs. The elements just enumerates what they all are. 15:41:47 ... You can import them, then it aligns them were they need to go. 15:42:17 ... The axioms are all on the structure defs. 15:42:36 ... Eg, pt birthday, they can only have one, and that's a max 1 axiom on pt. 15:42:55 ... But the Elements ont could say that it's specifically a Patient.birthdate. 15:44:13 ken: Practitioner also has a birthdate. 15:46:34 tim: Yes, and it's separate from pt birthdate. 15:47:21 ... For mappings, the object properties are more useful. 15:48:51 ... This might lead to Patient.name being both a class and an object property. 15:51:15 ... unless we changed Patient.name to lower case patient.name for the property. 15:52:13 ken: In UCM we want to separate identities across domains. Patient becomes more of a role class, not an entity class. That gets tricky. 15:52:33 ... I look at Patient.name as more of a data element than a class. 15:54:15 dbooth: Don't want to change to lower case without a lot more thought, so let's defer that to later. 15:55:57 tim: The canonical version will include the extra Element... classes, to avoid them being anon classes. 15:56:27 ... But I want to make the isDefinedBy to point to the element instead of the structure def. 15:56:54 ... Which means it was derived from an element def instead of the structure def. 15:58:39 https://github.com/w3c-cg/hcls-fhir-rdf/issues/223 15:59:30 tim: Regarding modifiers ont, I think I can I can make it using SPARQL. 16:00:07 dbooth: But we want these onts to be downloadable from the spec, which means it needs to be generated by the spec gen process, so prob don't want to use SPARQL for it. 16:02:36 AGREED: Adopt options 2 and 3 in issue 223 16:03:41 ADJOURNED 16:04:23 Present: David Booth, EricP, Tim Prudhomme, Ken Lord 16:04:38 rrsagent, draft minutes 16:04:39 I have made the request to generate https://www.w3.org/2026/05/21-hcls-minutes.html dbooth 16:06:13 s/Topic: Issue 223/Topic: Issue 223: Remove complex ontology classes 16:06:15 rrsagent, draft minutes 16:06:17 I have made the request to generate https://www.w3.org/2026/05/21-hcls-minutes.html dbooth 16:13:50 i/We no longer suggest/AGREED: In the rdf.html, say you can optionally add the rdf:type to CodeableConcepts, and show them in the generated examples 16:13:59 rrsagent, draft minutes 16:14:00 I have made the request to generate https://www.w3.org/2026/05/21-hcls-minutes.html dbooth