Meeting minutes
R5 Ballot comments
rob: Submitted the 7 issues this morning to jira. Still need to make sure that they are formal ballot comments.
… I'll make sure they become formal comments prior to the deadline closing tomorrow.
… Will also make sure that they're triaged to ITS.
eric: He's writing the code to generate the shex from the FHIR build process.
dbooth: jim reported an update:
This week I need to attend the GO consortium meeting, which conflicts with the FHIR RDF meeting. I pasted a proposed SPARQL update in the issue: https://github.com/w3c/hcls-fhir-rdf/issues/110#issuecomment-1272069777 I tested this using the Jena command line ‘update’ tool. I bugged Grahame G. in Zulip, and he said he had not gotten to the build issue, but would try this week.
Concept IRIs
gaurav: Wrote a proposal for UTG to add concept IRIs for LOINC. This will act as a template for future additions.
gaurav: NamingSystem now has an "identifier" attribute that we can use. But need to wait for their tooling to support that R5 change.
rob: The "identifier" field was added because it's a standard field. Also an identifier of the naming system itself, not what is being named.
gaurav: For NamingSystem, they have a uniqueID field. Use that?
rob: I think so.
… 'identifier' doesn't serve the same purpose.
gaurav: what about CodeSystem.identifier?
rob: I think that could be a place to put an IRI stem.
ACTION: Gaurav to update the above draft proposal to propose that NamingSystem.uniqureID should be used.
dbooth: Timeline to bring this to UTG?
gaurav: Update this write-up before the next call, then submit to UTG.
Script to convert R5 RDF to OWL-and-SPARQL-friendly RDF
dbooth: We'll bring it up next time he's on the call.
… Do we need any more converters, or is one SPARQL one enough?
eric: Enough.
AGREED: One is enough.
Deepak's work on converting things to shex
eric: Deepak is being very diligent, looking at extensions. I was only looking at profile resource, types, valuesets. That gave me FHIR core.
… But there are also extensions defined. Unlike bindings, which are in the resource elements, extensions say "My URL is ___ , my use context is these elements/attributes".
… That's beyond what I thought of, but it makes sense to do them.
… Could be handled a few ways. 1. Exchanging clinical data, if I send an extension that is outside of something, I want to know about it, even if it's not a modifier extension. 2
… 2. Promiscuous, allow all extensions you want, but make sure they follow the rules for extensions.
… 3. (In between solution) "I accept a generic extension, but if you give me one that I recognize, I'll validate it".
… But that doesn't verify that you're using it in the right place.
… So the utility falls down if you don't use it in the right place.
… So maybe option 1 would be better.
… Another option 4. We could say for every extension, when we have a domain resource or datatype that allows extensions, in both of those, you can have an ext here. We could say you can have certain URLs and what URLs are not allowed.
… So for the extension we know about, we could say they are NOT allow in places where they don't belong.
… if there's code for validating profiles, then it could check using one of those options. But we also need to figure out the use case for the download of fhir.shex. How would it be used?
dbooth: That download would reflect one of those 4 approaches?
eric: Yes.
dbooth: What pros/cons other than programming effort?
eric: If you had lots of extensions, option 4 might get unwieldy.
dbooth: Any idea how many extensions there are currently?
eric: Guessing 50 extensions, each one used in about 3 place.
rob: I think it's at least 100.
http://
eric: These extensions are allowed in 912 places
dbooth: If deepak has time to do #4, and you think it's best, then that sounds good to me.
<Github> https://
dbooth: I think we should validate as much as we can.
gaurav: Might be biting off more than we can do.
ADJOURNED