All Minutes

Meeting minutes

HL7 meeting report

dbooth: Meeting went well. They were interested in the Concept IRI idea, but didn't have any feedback on it.
… I didn't sense any thought of pulling the plug on FHIR RDF.
… Small group, only HL7 ITS chairs and Vassil Paytchev(sp?) from Epic.

RDF Lists

gaurav: Jim is working on a PR for the OWL API group.

Concept IRIs

gaurav: Looking for example codes that might be hierarchical. Found Clinical Care Classification.
… Example: C.06.1.3

https://careclassification.org/online-code-builder-1/

gaurav: c= cardiac
… 06 = cardio vascular alteration
… .1 is blood pressure alteration
… 3 is expected outcome

gaurav: Another example I found: https://www.hcup-us.ahrq.gov/toolssoftware/ccs/CCSCategoryNames_FullLabels.pdf
… 10.1.5.1 Calculus of kidney

eric: If someone (re-)designed this for use in web space, they might use slashes.

gaurav: Two more examples are like the dewey decimal system.
… J82.83 Eosinophilic asthma

eric: For a demo, we could take these and turn the dots into slashes.

https://www.hcup-us.ahrq.gov/toolssoftware/ccs/ccs.jsp

dbooth: This is convincing me that we should not try to support hierarchical URLs. I think it's natural for people to use things like dots as hierarchy separators.

gaurav: Hierarchical could be in its own sub-proposal, for submission after the FHIR group accepts the basic idea.

dbooth: Web servers are always free to interpret their URLs hierarchically however they want. They can treat dots as hierarchy if they choose, for example.

AGREED: We will only do flat proposal first. Hierarchical would be a separate proposal later.

ACTION: gaurav to update draft doc for only flat stem IRI

<ericP> https://www.w3.org/2008/Talks/31-ASPE/xRIs.svg

dbooth: Should the code be percent-encoded to be part of a URI or (more generally) a part of an IRI? I.e., which set of chars should be percent-encoded?

example IRI (w Japanese/chinese): http://伝言.example/?user=أكرم&channel=R%26D
… http://伝言.example/?user=أكرم&channel=R&D

eric: First you punycode the domain name, then you URL encode the path. Then you have ambiguity: Need to know whether to decode the %26

eric: Eg if a code were: كرم

dbooth: Even if we pass that through, we'll still want to percent-encode things like slash, ampersand, equal, questionmark, etc.

eric: But we only need to worry about escaping the ones that are enumerated.

https://www.w3.org/TR/2012/REC-r2rml-20120927/#dfn-iri-safe

eric: Propose that iunreserved be the set we do not percent-encode.

iunreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF

/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD

/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD

/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD

/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD

/ %xD0000-DFFFD / %xE1000-EFFFD

eric: everhthing that's reserved is below 7F. These are all A0 or above.

dbooth: That looks good to me.

gaurav: "

The 17 planes can accommodate 1,114,112 code points. Of these, 2,048 are surrogates (used to make the pairs in UTF-16), 66 are non-characters, and 137,468 are reserved for private use, leaving 974,530 for public assignment."

FHIR RDF Playground

dbooth: People were impressed w the playground.

eric: The process loads fhir defs, turns them into shexJ, then whenever it's asked for a @context file, it generates it on the fly from the shexJ, then uses the shexJ again for the rendering. That means I'm validating everything that I'm generating!
… Downside is that changing to collections means you need lists of things: Instead of a codeable concept having N codings, it has a list of codings, which has an rdf:first and an rdf:rest that is either a list or a rdf:nil. That means I had to add a lot of lists: went from 1500 shapes to 2000 shapes.
… i want to make that a primitive in shex, to make that unnecessary.

Meeting minutes

RDF Lists

jim: Made a PR on OWL API

dbooth: And you added a test case? jim: yes.

jim: I'm continuing with parsing the list triples into property assertions.

FHIR RDF Playground

eric: I got Hoisting of scalars, and RDF collections working. And worked on marketing to make the nested write render collections nicely. Working on a test suite now.

(David did demo)

eric: One issue: if you hoist scalars, you need RDF collections.

dbooth: Suggest make the "Hoist" toggle auto-enable collections.
… And maybe add a hover-over to say the if Hoist is selected then Collections are required.

eric: The playground still runs the code 5 times. Could someone track this down?

dbooth: How about James?

dbooth: I noticed that the UI was slow when typing.

eric: I think that's the design of it, using onChange events. Could maybe have it set a timer instead. If you stop typing for a second or so, then it does an update.

eric: preprocessor take 5-10% of the time. LD parsing takes half the time, and the validation takes half.

dbooth: Small bug: clicking "Generate JSON-LD" causes "input preprocessed" to be displayed.

eric: Might be an interaction with code mirror.

dbooth: Do we want the JSON-LD pane to be editable?

eric: Probably, but not a high priority.

dbooth: Suggest change "Generate JSON-LD" to "JSON-LD" and disable the button.

Concept IRIs

gaurav: I took hierarchical stuff out of the proposal. Pretty much done, though there's a bunch of unneeded text at the end.

eric: Propose to change "Stem IRI" to "IRI Stem" throughout.

AGREED: change "Stem IRI" to "IRI Stem" throughout

gaurav: On vacation next week (Tue through a week from Thurs)

AGREED: Capitalize "Concept IRI" etc.

ACTION: DBooth to make an editing pass through the doc

https://docs.google.com/document/d/1sW3Tgj2J_wBzlUWih07e0Vf_M9Ue8YyPqjK0arhajS8/edit#

ADJOURNED

Meeting minutes

RDF Lists

jim: Submitted PR to OWL API. They merged it in. Next step is to parse the list into axioms. Busy w conf paper this week, but will continue next week.

Concept IRIs

Please review the document: https://docs.google.com/document/d/1sW3Tgj2J_wBzlUWih07e0Vf_M9Ue8YyPqjK0arhajS8/edit

Daniel: fhir:link is not being generated in HAPI

dbooth: Needs to be updated for our R5 features. New issue: https://github.com/w3c/hcls-fhir-rdf/issues/100

ADJOURNED

Meeting minutes

FHIR RDF Playground

Eric: All features work except things that are not legal structures. Need someone to download a matching pair of examples and definitions, and go through them to figure out if they align.
… Currently they don't render. Cannot even preprocess some, because the preprocessor needs to navigate the content model. So if it encounters a property it doesn't recognize, it bombs out.

dbooth: Lack of coordination in how they're generated?

eric: Yes. Not sure they are being validated when they should be.
… When you go to build.fhir.org
… the downloadable examples should be in sync with the definitions.

eric: They might not be consistent on the nightly builds, but the releases should be consistent.

eric: Patient example pre-loaded into playground was for FHIR 4.1

eric: "If you want to load different examples into the playground, you can supply a parameter like

https://fhircat.github.io/fhir-rdf-playground/?manifestURL=http://myserver.example/somewhere/manifest.json

default is:

https://fhircat.github.io/fhir-rdf-playground/playground/manifest.json

could be handy for demo-ing, but remember that you'll have to enable CORS on myserver.example (i.e. whatever server you're using)

(now its search parameter interface looks like everything else i build) "

eric: That allows someone to load a different manifest, that allows you to replace the "Example" buttons over the playground text area.

eric: "so e.g. "../fhirlib/test/json/playground-Patient.json" in the manifest gets resolved against the manifest URL as

https://fhircat.github.io/fhir-rdf-playground/fhirlib/test/json/playground-Patient.json "

eric: So now you can upload both the examples and the definitions. The preloaded definitions are the 4.0.1 defs

eric: Patient, Observation, CodeSystem do what we want.
… But Bundle doesn't entirely work, but it tells you what's wrong. If you take out the offending part, it works.
… The bundle was tough, because I had to be able generate every resource. To gen content model it looks at the resourceType .
… Need to do that in two situations: Bundles and Contained.
… No intersection bewteeen a viable 4.0.1 and 4.6.0 resource, because of required things.
… So we need to examine these to line up the examples w the content models. I've been using jq, a fiendishly handy but difficult to use package.

NOT THIS PACKAGE: https://npmjs.com/package/jq

The correct package is: https://stedolan.github.io/jq/manual/

eric: I wrote some instructions here: https://github.com/fhircat/fhir-rdf-playground/blob/main/fhirlib/READMD.md

eric: Here's an example:

```
"Medication.identifier -- Identifier"
"Medication.code -- CodeableConcept"
"Medication.status -- code"
"Medication.marketingAuthorizationHolder -- Reference"
"Medication.doseForm -- CodeableConcept"
"Medication.totalVolume -- Ratio"
"Medication.ingredient -- BackboneElement"
"Medication.ingredient.item -- CodeableReference"
"Medication.ingredient.isActive -- boolean"
"Medication.ingredient.strength[x] -- Ratio -- CodeableConcept -- Quantity"
"Medication.batch -- BackboneElement"
"Medication.batch.lotNumber -- string"
"Medication.batch.expirationDate -- dateTime"
```

dbooth: THat's looking at the defs. How do you compare with the examples?

eric: The playground tells you what the error is. You look at the error, and then look up the result of the def query to see what the def said it should have been.

dbooth: How much work would it be to generate an exhaustive list of all examples that fail validation?

eric: Maybe a day.

eric: Big screw case: hl7.fhir.org site needs to send CORS headers.

ADJOURNED

Meeting minutes

Concept IRIs

Gaurav: http://snomed.info/sct/ is the wrong IRI stem for post-coordinated example. Should be scg.

https://docs.google.com/document/d/1sW3Tgj2J_wBzlUWih07e0Vf_M9Ue8YyPqjK0arhajS8/edit#

AGREED: Make the post-coordinated example use "id", because IHTSHO erred in using "scg".

dbooth: The bigger problem is that the System URI is the same for both pre-coord and post-coord, and we need this to be a mapping. IHTSDO goofed in using a different prefix for post-coord.

ACTION: Gaurav to file FHIR issue (if needed) to correct LOINC IRI stem

ACTION: DBooth address Daniel Stone's comments

ACTION: Gaurav to review DBooth';s edits after they are done.

dbooth: Should be able to bring this to the terminology group after these issues are resolved.

ACTION: Gaurav to verify that the hand wave example is properly percent encoded

eric: I ran into problem swith 16-bit encoding. Library didn't handle it properly. I had to check if the length of the encoding was greater than one, the handle it separately. I'll point you to the recipe.

ACTION: Gaurav to send this to the termilogy group after the above actions are done.

ADJOURNED

Meeting minutes

FHIR RDF Playground

eric: Still need to do the value type simplification.
… Need to update shex library first though.

eric: Revelations: if we want to hoist scalars -- scalars have deep XML representation, but in JSON they're hoisted -- but in RDF we need to come up w the analog to the extension point. That means that we need to use RDF Collections.
… If there's a CodeableCOncept w n codings, the fhir:index goes into each of the codings. But if I have two status, it isn't a bnode, so I can attach the fhir:index. That means that if we want to use hoisting, that pushes us to also use RDF Collections.

Issue 95: References lack a type arc

https://github.com/w3c/hcls-fhir-rdf/issues/95

dbooth: More to be done on this issue?

eric: Preprocessor job.. Needs to infer type from ref URL.
… That will work for FHIR URLs, but not other URLs.

dbooth: i wonder if the broader FHIR community has raised this issue

gaurav: <<reference attribute, a "Literal reference, Relative, internal or absolute URL">> (from the issue)

eric: Right now, there's a small set of types that are allowed, which comes from the resource definition.
… In the shex I was saying "it has to be one of these types". If we cannot validate that it is one of those things, then we need explicit code in the shex to relax that.

eric: OWL property constraint.
… i.e., the owl analog to range.

ACTION: DBooth to find out if the broader FHIR community is looking at this issue.

eric: Preprocessor already does the microparsing of the relative URL to determine the type.

dbooth: If the broader community doesn't address this, do we close this issue with a WONTFIX tag?

eric: yes.

Concept IRIs

gaurav: Fixed the final issue (UTF16 encoding issue).
… but want Eric to review my code.

eric: You should never see a surrogate pair when you are expecting a unicode char.
… In JS, python, etc, you get the string and then should never see any BOMs.

https://github.com/w3c/hcls-fhir-rdf/issues/94

ACTION: Eric to review gaurav's code

dbooth: A couple of slides here: https://docs.google.com/presentation/d/19Xd8i6mK-fhgoCPF3q9BvUu1RFmUxrGCOzWKbfVN5J4/edit#slide=id.g1280217e6c0_0_19

ACTION: gaurav to reach out to Terminology group.

ADJOURNED

<dbooth> s/needs to implement it. Also need/job. Needs/

Meeting minutes

Concept IRIs

gaurav: Posted to zulip, but no response yet: https://chat.fhir.org/#narrow/stream/194616-terminology-.2F-utg/topic/Meeting.20with.20UTG.20group.20to.20discuss.20incorporating.20IRI.20stems

FHIR RDF Playground

eric: More than half way through the implementation of the last feature we need for R5.
… Q: Preprocessor works in tandem w the @context generator.
… Last feature is to change properties like fhir:valueQuantity to fhir:value (and have the type in the RDF type).

dbooth: preprocessor needs to break apart that single property into two pieces of information?

eric: yes.

dbooth: hope to make the preprocessor as stable as possible, so that most tweaking can be done to the @context

eric: The content model in the JSON-LD @context needs to know what type it is.

Issues list

dbooth: Looking at issue 95: https://github.com/w3c/hcls-fhir-rdf/issues/95

eric: we should push back to the larger FHIR community to say the type property SHOULD be included if the reference URL is not relative. Would prefer a MUST.

eric: Does their validator deference to find out the type?
… Validation would ensure that it is the right type.

ACTION: DBooth to ask the FHIR community about requiring a type property when a ref is an absolute URI

Issue 93: How should modifier extensions be handled in R5?

Issue 70: FHIR rdf representation does not pass shex - canonical URL properties need metadata

dbooth: Closing this, because it will be caught by shex validation in the build process, so we will address then if it is still an issue.

In issue 77 (Simplifying primitive properties while still supporting FHIR extensions) https://github.com/w3c/hcls-fhir-rdf/issues/77 The issue of connecting FHIR extension element "_foo" to element "foo" does not necessarily have to be addressed in the preprocessor, because it is a static relationship -- it does not depend on the instance data -- so it could be included in the ontology instead of being generated in the instance data.

ADJOURNED

Meeting minutes

Concept IRIs

gaurav: Need slides for meeting on July 7

dbooth: Old slides are here: https://docs.google.com/presentation/d/19Xd8i6mK-fhgoCPF3q9BvUu1RFmUxrGCOzWKbfVN5J4/edit#slide=id.g1280217e6c0_0_19

ACTION: gaurav to determine which MeSH Coding.system URI is correct, and file a bug report if one is wrong.

Example here: https://github.com/gaurav/UTG/blob/28b2c022e619809ada2d3152bca8f5d9e6eea997/input/sourceOfTruth/external/v3/codeSystems/cs-v3-snomed-CT.xml#L14-L18

rob: On line 16 it should not say CodeSystem, because it isn't a CodeSystem, but maybe an IdentifierSystem.
… But in general seems like the right approach.
… There's been a decision not to move everything in there, but need to discuss.

eric: Only a few code systems have specified their own IRI stems (SNOMED and MeSH).
… But we could in HL7 define placeholder IRI stems, for use until the vocabulary authority chooses something else.

gaurav: Also for NamingSystem, we've used "other" so far, because it's a controlled vocabulary on line 39

https://github.com/gaurav/UTG/blob/28b2c022e619809ada2d3152bca8f5d9e6eea997/input/sourceOfTruth/external/v3/namingSystems/v3-snomed-CT.xml#L38-L42

gaurav: If we use "uri", that's already being used for the System URI, such as on line 34.

rob: Might need a different way to distinguish them.

gaurav: Got any examples of non-ascii codes? Rob: No

rob: Should also consider with FHIR should allow Code Systems and/or codes to be a broader unicode range (to allow concept IRIs)

rob: "other" (on line 39) should only be used if it is not a URI.

ACTION: gaurav to create slides to further explain concept IRIs and issues

https://confluence.hl7.org/display/VOC/Meetings+and+Calls+Details
Online Meeting Link: https://join.freeconferencecall.com/vocab
Online Meeting ID: vocab
3:30pm Boston time
July 7

eric: Interested in non-ascii, because hospitals in china probably won't use ascii.

rob: Even if we had the IRI stem, would URI encoding be okay?

eric: Not optimal. If you put one of these IRIs into a browser, it will do the right thing with the IRI.

eric: Could be an issue if someone rolled their own HTTP library.

jim: The core issue of why we don't URL encode, they won't match other uses of the concept IRIs.

rob: FHIR should be compatible with the general sem web standards.

References lack a type arc, issue 95

https://github.com/w3c/hcls-fhir-rdf/issues/95#

Eric commented: https://chat.fhir.org/#narrow/stream/291844-FHIR-Validator/topic/Requiring.20the.20type.20of.20a.20Reference/near/287238355

ACTION: Eric to follow up w Lloyd about that question

Properties with both scalar and object range: fhir:value inside of fhir:value #102

jim: Cannot have a property be both a datatype property and an object property.

jim: I think it's an RDF serialization issue.

dbooth: Need to determine: 1. Is this a problem? 2. Is this the only place this problem shows up?

eric: This issue is the result of both hoisting of scalars and de-currying.

ACTION: Jim to find in the spec why this is a problem.

jim: Out the next two Thursdays.

ADJOURNED

Meeting minutes

Concept IRIs

Gaurav's Presentation: https://docs.google.com/presentation/d/1boDoAK8_8pndD4W_EXtYVg9OnRtrYCGmZ-OcPbWGIIA/edit

(Group worked on Gaurav's slides)

dbooth: Gaurav will present his slides to the FHIR Vocab group at their meeting later today.

ADJOURNED

Meeting minutes

References lack a type arc #95

https://github.com/w3c/hcls-fhir-rdf/issues/95

Zulip discussion: https://chat.fhir.org/#narrow/stream/291844-FHIR-Validator/topic/Requiring.20the.20type.20of.20a.20Reference/near/287238355

dbooth: Need to get clarity about whether the type can be parsed from the URL. If we can, then that requirements should be stated somewhere in the FHIR spec.

eric: Still cannot know that a ref URL will indicate the ref type.

eric: We can validate it if it's a relative URL or a frag ID. Could also add a switch to treat abs URL ref as unknown type or force it to assume that it conforms to FHIR server URL convention.

ACTION: Eric to push back on Lloyd that there still is a gap that would be good to address.

eric: Could add a switch to force deref to determine the result type

Concept IRIs

https://github.com/w3c/hcls-fhir-rdf/issues/94

Proposal document: https://docs.google.com/document/d/1sW3Tgj2J_wBzlUWih07e0Vf_M9Ue8YyPqjK0arhajS8/edit#heading=h.c6hm077hkuue

Gaurav's message, included with his permission:
-------- Forwarded Message --------
Subject:  Re: FHIR RDF - Concept URIs document
Date:  Tue, 12 Jul 2022 22:54:13 +0000
From:  Vaidya, Gaurav <gaurav@renci.org>
To:  David Booth <david@dbooth.org>
Hi everybody,
So at the end of our presentation last Thursday, the FHIR Vocab group left us with four questions:
1. Who gets to pick IRI stems and with what criteria?
   - Rob McClure would like a solution where all the CodeSystems and NamingSystems (or at least the HL7 ones) have IRI stems, and would like to know how we plan to assign them where the terminology does not itself provide concept IRI templates (as SNOMED CT and LOINC does, for instance).
2. How do we deal with versioning? (i.e. the Coding.version field, which is the version of the vocabulary)
3. How do we do with characters that aren’t in ASCII?
   - I think Eric and I managed to explain this to them after they asked it.
   - They seemed particularly concerned about spaces, since FHIR code fields [0] have weird restrictions on spaces: "Technically, a code is restricted to a string which has at least one character and no leading or trailing whitespace, and where there is no whitespace other than single spaces in the contents” — so we should make sure this works with our code, and probably put some examples on this on one of the slides.
4. Our proposal does not specifically call for changing FHIR ValueSets to support concept IRIs, but they thought we should consider this
   - I think we might just want to make it clear that we don’t plan to incorporate concept IRIs in FHIR itself — except maybe with a {system=urn:ietf:rfc:3987, code=[IRI]}?
   - Rob or Reuben specifically mentioned “ValueSets”, but I think what we want to do is more related to “Coding”s — unless I’m missing something?
I took a stab at modifying our presentation to address these four questions specifically [1], except for the “ValueSets” question, which I’ve just left as a blank slide for now. We can discuss this in more detail on Thursday (and figure out if we really want to pitch this to the entire HTA this Monday [2]), but I wanted to send the slides to you now so you could see what I think the answers are for those questions.
Oh, also, here are the meeting minutes [3] if anybody is curious!
Cheers,
Gaurav
[0] https://www.hl7.org/fhir/datatypes.html#code <https://www.hl7.org/fhir/datatypes.html#code>
[1] https://docs.google.com/presentation/d/1boDoAK8_8pndD4W_EXtYVg9OnRtrYCGmZ-OcPbWGIIA/edit <https://docs.google.com/presentation/d/1boDoAK8_8pndD4W_EXtYVg9OnRtrYCGmZ-OcPbWGIIA/edit>
[2] http://www.hl7.org/concalls/CallDetails.cfm?concall=61788 <http://www.hl7.org/concalls/CallDetails.cfm?concall=61788>
[3] https://confluence.hl7.org/pages/viewpage.action?pageId=131052401 <https://confluence.hl7.org/pages/viewpage.action?pageId=131052401>

gaurav: Not sure we're scheduled for that mtg.
… They want an IRI stem assigned for all of them.

dbooth: I think it would be beneficial to fill in IRI stems to the repo.

rob: Two cases: Those that HL7 controls, vs ones that are controlled by other orgs.

rob: Could follow the same process as for System URI.

eric: What if there isn't a System URI, and then the terminology owner decides they want to define one?

rob: Try to get them to find out if they have a preference, and use that. If not, then HTA assigns one.
… Some were decided in the early days of FHIR. Don't want to change those arbitrarily. But becoming more stable process now.

rob: In a few cases an org suggested a different URI, but were convinced to stick with the prev one.

eric: And when the org doesn't say what it should be, it gets assigned to something in the HL7 space? rob: yes.

rob: A few times in the past namespace squatting was done, but no longer.

gaurav: Here are the slides I'm currently editing if anybody wants to follow along: https://docs.google.com/presentation/d/1boDoAK8_8pndD4W_EXtYVg9OnRtrYCGmZ-OcPbWGIIA/edit#slide=id.g13d055c3e1a_0_2

dbooth: Approach amounts to 'choose it or lose it'. Rob: yes.

eric: if Kent Spackman hadn't chosen a SNOMED URI for IRI stem, and we assigned an HL7 URI, then if SNOMED wants to later they want their own URI used, then what?

dbooth: If the org asserts that they then want their own URI used, then they're accepting responsibility for breaking people's code.

rob: If the org doesn't step up, then HTA will look around for what is already in use, such as bioportal.

gaurav: Could also use a URL forwarding mechanism.

eric: Need to go to orgs and ask them if they want to assign one.

eric: Want to make IRI stem changes only 0 or 1 times.

dbooth: separate questions: 1. put IRI stems into the repo at all? 2. Who (which group) should decide what goes into the repo? 3. What should be done if a terminology owner does not step up to specifying their preferred IRI stem? 4. Should we have a way to indicate that an IRI stem may be volatile?

rob: For HTA, they would only own some of these questions. #1 would be question for the THO group. SHould put in a UTG proposal (Jira ticket), and goes through voting and approval process. UTG voters.

gaurav: if UTG doesn't want IRI stems into the repo, then we could do our own.

rob: Re #2, that also should go through UTG proposal, with the exception that if it is external org, then it needs to go through HTA first.

rob: Re #3, if the org doen't step up, then HTA woudl assign one.

rob: Re #4, that's more of an HTA thing.

ACTION: Gaurav to check with UCG group about presenting on July 18.

ADJOURNED

Meeting minutes

RDF Lists and OWL

jim: Still working on OWL API PR.

jim: Use of RDF lists is technically an OWL violation. But I've been looking at the OWL API to enable it to work properly with RDF lists anyway.
… Concensus seems to be that we want to RDF lists, even if it technically violates the OWL spec, provided that OWL tooling can use it.

eric: The other issue was whether fhir:value can be both a datatype and an object type.
… We could use separate properties for those if needed.

jim: Could also change all the lists to a different namespace.

eric: That's hilarious!

dbooth: That's one of several work-arounds that we could offer.

dbooth: Do we have consensus to continue going ahead with the RDF list approach provided that Jim is successful in getting it to work with OWL API?

eric: It would be easier to sell it if we could demonstrate that the namespace renameing hack works as a workaround

ACTOIN: jim to show the namespace renameing hack works as a workaround

a/ACTOIN/ACTION/

Concept IRIs

ACTION: Gaurav to sched followup with TSMG on Monday.

Properties with both scalar and object range: fhir:value inside of fhir:value #102

https://github.com/w3c/hcls-fhir-rdf/issues/102

jim: It causes reasoners to treat it as an annotation property -- loses the semantics.

eric: This is also a problem with fhir:Codes , because we're adopting the FHIR names for properties.
… Observation.code

jim: rdf:value is not a valid property name.

dbooth: Should we emit a different property name for datatype vs object properties?

jim: I like that idea, of using two property names.

eric: Easier to rename the scalar property.

dbooth: But FHIR JSON uses the word "value" for that, so I'd prefer to rename the valueX property. Might even call it literally fhir:valueX.

eric: Or fhir:_valueX

eric: Or fhir:value_X

houcemedine: or fhir;hasValue

AGREED: Use two different property names

Or also fhir:value_x.

rob: i prefer lower case x
… Because if it were a datatype it would start with a capital letter.

Dbooth: Preferences: value_x, value_x, value_x, value_x

AGREED: use fhir:value_x for object properties.

rob: Will this be only for properties that are union types or for all object properties?

eric: Oops, that's a problem. We didn't consider that.

ACTION: Rob to figure this out.

ACTION: Dbooth to look at what else we need to tie up for R5.

ADJOURNED

Meeting minutes

Properties with both scalar and object range #102

jim: Would option 2 also address the RDF list issue?
… Could maybe offer tooling to convert from OWL friendly version to SPAREQL friendly version

DBooth: Preferences?
… most in favor of #5.

dbooth: Would be strongly against having two versions

AGREED: option 5, not hoist scalars (same as R4)

eric: Should also bring awareness to the larger sem web coimmunity about this issue.

dbooth: I think it's a flaw in the OWL to discourage that.

This closes both #102 and #77

This also closes #103

How should modifier extensions be handled in RDF? #93

https://github.com/w3c/hcls-fhir-rdf/issues/93

eric: We want to prevent a FHIR processor from not noticing the modifier ext and processing the data naively.

eric: Without hoisting, if wwe rename properties that have modifier ext by giving them a leading underbar, then we take care of the backbone element and scalar case.

ACTION: Dbooth to propose options

Issue 69: Shorten dot-compound property names?

dbooth: Not aware of any problems. Implemented in the playground.

eric: FHIR folks are doing more to ensure that property names have a consistent meaning.

dbooth: And without hoisting, everything is an object property anyway.

AGREED: Shorten property names.

We should not use fhir:value for non-hoisted scalar properties #104

We could use rdf:value instead. That's what it was made for. Jim: That would not work with OWL.

eric: But you cannot do inference with literals anyway.
… I tried If the code is 123435, then some inference, but could not get it working.

jim: You have to make a class expression

ACTION: jim to look into whether rdf:value would work instead of fhir:value

Issue 76: Ordered lists

jim: PR almost ready for changes to parse the list
… Caveat: If you apply owl annotations to those axioms, those annotations don't get parsed. That would be hard to solve.

dbooth: Is anyone likely to do that?

jim: It won't be in our FHIR output with RDF lists.
… It would be weird to do.
… It would involve reifying the list axiom.

dbooth: Do we still want to go ahead w RDF lists?

eric: Still keen on using lists.

jim: Last week I tried out using non-RDF property names for first and rest, and it worked.

dbooth: We could potentially publicize that as a workaround for folks who are bothered by RDF lists.

ACTION: jim to try OWL example that uses a scalar value

Meet also on Tuesdays, same time?

eric: Maybe

rob: Probably

jim: Can do the second two

houcemeddine: okay for me.

ACTION: DBooth to announce additional meetings

Issue 95: References lack a type arc

dbooth: Grahame pointed out that this would be a breaking change to make the "type" property required in the case of an absolute URL reference, so it isn't a change we can make. And we can live with it anyway.

eric: This would mostly affect validation of local internal hospital networks.

dbooth: Close the issue with no change?

eric: Close with a note saying we do not validate cases with absolute URLs beyond what FHIR requires for validation.

AGREED: Close #95 with no change.

ADJOURNED

Meeting minutes

How should modifier extensions be handled in R5? #93

dbooth: The essential problem I see is that EVERYTHING inside a resource that has been modified (modifierExtension) must not be asserted.

eric: If we hide only the resource type, that may be safe enough.
… That at least makes the common cases clear.

houcemeddine: Could have been done in a better way. But they want extensible data.

eric: Propose that for modified resources, change the resource name to have a leading underbar.
… For other elements that are modified, prepend an underbar to the modified property.

dbooth: I'd really like to get more input from others in the RDF community.

eric: If we ask, it might bias toward undue vigilence.

dbooth: Suggest we reach out to Harold, Emily, Chris Mungall

ACTION: DBooth to ask those people for input

We should not use fhir:value for non-hoisted scalar properties #104

https://github.com/w3c/hcls-fhir-rdf/issues/104

dbooth: I realized that rdf:value might not solve the problem anyway, because we need something that would only be used as an OWL datatype property, but there is nothing in RDF to prevent rdf:value from being used as an object property.

eric: This problem should have been faced in owl already. Need a property that is a superproperty of all datatype properties.

eric: Maybe there's something in the Relation Ont.

dbooth: Or look in OWL, or make up a property in a FHIR namespace.

ACTION: DBooth to look into those 3 options.

Maybe fhir:scalar or fhir:v or fhir:literal

ADJOURNED

Meeting minutes

RDF Lists

jim: About to make PR for OWL API change

jim: Go through with that design, given the OWL issues?

jim: We could supply a SPARQL construct to turn RDF lists into something fully OWL compliant.

ACTION: Jim to make a SPARQL construct for converting RDF lists into something OWL compliant

https://github.com/w3c/hcls-fhir-rdf/issues/76

We should not use fhir:value for non-hoisted scalar properties #104

jim: Tested rdf:value in Protege and it worked.

dbooth: It occurs to me that rdf:value might not solve the problem anyway, because we need something that would only be used as an OWL datatype property, but there is nothing in RDF to prevent rdf:value from being used as an object property.

jim: With owl:topDataProperty, every individual is related to every individual in the world.
… which might cause reasoner issues.

jim: Same problem (with rdf:value) exists with rdf:first .

dbooth: OWL is being our biggest problem!

jim: Should we pivot to being fully OWL compliant, or go for an RDF-oriented workflow.

dbooth: I don't think we want to alienate the OWL community.

gaurav: Lean toward being OWL compliant.

jim: Eric likes the brevity of Turtle lists. We could switch to a different list vocabulary.
… I lean toward being OWL valid.

rob: Lean toward OWL compliant -- a priority.

dbooth: Want to Eric's input on this too.

dbooth: R4 is OWL compliant, BTW.

How should modifier extensions be handled in R5? #93

Given that we only have bad options, I'm not sure it's worth try to make a change in R5?

rob: To me the problem is the same in FHIR JSON or XML. If you have an anti-prescription, you have to know not to do certain things.

gaurav: Fine to stay with R4 solution, option 0.

jim: Sounding like option 0 is the way to go.

dbooth: Also want to get Eric's input on this.

Concept IRIs

gaurav: Next step for us is to file a Jira issue for the changes we want.

ACTION: Gaurav to follow up on TSMG voting and Jira after the vote

ADJOURNED

Meeting minutes

List ordering #76

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/76 : How should list ordering be preserved in R5?

jim: In FHIR RDF, would rdf:first ever be used both as object and datatype property?

eric: No, not without hoisting scalars.

eric: And someone using OWL would not have run into this already, because OWL would already complain of using rdf:first if they had used an RDF list.

dbooth: The issue is that an RDF list could hold both scalars and objects and that would cause a conflict in OWL.

ACTION: Eric to post a message to semantic-web list complaining about this OWL problem.

dbooth: I don't think it would be proper to declare rdf:first to be an OWL object property, because it's defined by RDF without that restriction.

jim: People use dc properties as annotation properties.

eric: The basis of the problem is that OWL won't allow it to hold both object and datatype values

Modified extensions #93

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/93 : How should modifier extensions be handled in R5?

eric: Propose renaming modified properties, with leading underbar.

dbooth: I don't think we have time to work out the details and test it out.

rob: Concerned this proposal might be overly cautious.

eric: Desiderata should be if some of the data is non-monotonic, then it should be an explicit act to query that data.

dbooth: Given how little time we have, I would be strongly against a proposal that does not have examples and working in the playground.

dbooth; Another example of non-mono is MedicationRequest.doNotPerform

eric: But that is less likely to be accidentally ignored, because it's documented up front.

rob: Could live with option 6.

gaurav: From FHIRCat perspective, we have the ability to try something out with this round of balloting. Then we have another project to convert data to FHIR RDF. Could wait until next ballot.
… Could leave w R4 and then try changing it properly on the next round.
… Leaning toward trying the new thing and see if it works.

houcemeddine: We don't have time to make adjustments. Or we can define rules about this in the spec.

rob: Is there any concern about confusion w underscore and JSON representation?

eric: JSON makes it easier by reserving the underbar--prepended properties.

rob: But it would have an entirely differnet meaning in JSON and RDF?

eric: Yes.

jim: Not sure what I think. Not able to picture the solution.

dbooth: I also think there's a lot of value in having the RDF exactly mirror the XML and JSON. Easier to understand and mentally translate.

rob: Are we dealing with only modifierExtensions, or also modifier elements?

eric: Anything with a modifier on it, if it's a property it has a leading underbar, and if it's an element then the element gets a leading underbar.

rob: With Observation.status, only if the value is "entered-in-error" is it a modifier. Not a modifier for other values. If we are goign to address modifiers then we should address that also.

rob; Changed my mind: rather stick with R4.

ACTION: Eric to put option 6 examples into github issue.

ADJOURNED

Meeting minutes

Replacing fhir:value

https://github.com/w3c/hcls-fhir-rdf/issues/104

AGREED: Eliminate options 0 and 1

jim: Prov ont has prov:value . One axiom, domain prov:Entity . Range is not stated.

dbooth: If it is not limited to being a datatype property, thenn it will have the same problem as rdf:value.
… Also would mean using yet another namespace.

houcemeddine: prov:value a owl:DatatypeProperty

dbooth: Ranked preference?

eric: v, literal, scalar, prov:value

gaurav: literal, v, prov:value, scalar

houcemeddine: v, prov:value, literal, scalar

jim: prov:value, literal, v, scalar

dbooth: v, scalar/literal, prov:value

AGREED: Eliminate scalar and prov:value

dbooth: Two candidates now are v and literl.

eric: FHIR folks could choos literal for something else.

eric: v

gaurav: v

houcemeddine: v

jim: v

AGREED: choose fhir:v

Concept IRIs

https://github.com/w3c/hcls-fhir-rdf/issues/94

gaurav: FHIR TSMG group voted to add IRI stems to terminology.hl7.org site.

https://confluence.hl7.org/display/TA/Teleconference+2022-07-28

gaurav: The only outstanding concern was to have full commitment and support from FHIR RDF. Asked us to vote to confirm that we will provided commitment and support for managing the IRI stems: 1. Provid initial set of IRI stems. 2. In the future, if we learn of an IRI stem for something that's in terminology.hl7.org, we'll add it. 3. If HTA adds a new code system they cn ask us for an IRI stem.
… They want to ensure there's always someone at our end to look after this.

AGREED: All agreed to confirm that we will provided commitment and support for managing the IRI stems: 1. Provid initial set of IRI stems. 2. In the future, if we learn of an IRI stem for something that's in terminology.hl7.org, we'll add it. 3. If HTA adds a new code system they cn ask us for an IRI stem.

gaurav: Need to add something to the FHIR spec, where it defines a type called URI
… If you have a system/code pair, and you set it to the identifier for 3986, then we should add a second row for IRI 3987.

https://build.fhir.org/identifier-registry.html

eric: I like the idea.

AGREED: Add 3987 to the table at https://build.fhir.org/identifier-registry.html

RDF lists #76

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/76 : How should list ordering be preserved in R5?

eric: Should have said to click the turtle button also.

dbooth: opinion?

gaurav: leaning R4

eric: leaning lists

houcemeddine: leaning R4

jim: pref lists

dbooth: R4

eric: want to wait until tuesday.

Modifier extensions #93

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/93 : How should modifier extensions be handled in R5?

eric: No options are currently implemented.

dbooth: Option -1 could be to say that modifierExtensions are not supported in FHIR RDF.

dbooth; Options on the table are 0, -1 and 6.

dbooth: Re option -1, I would would be against that, because i do not want to give the FHIR community any reason to give us the boot.

dbooth: option 6 vs 0?

eric: It's not implemented in the HAPI code that I wrote.

rob: leaning 6

eric: 6

gaurav: 6

houcemeddine: 6
… but for simplicity, some may want option 0

dbooth: 0
… seems less risk.

rob: could be persuaded for option 0

ACTION: DBooth to study option 6 examples, and return to this issue on Tuesday.

ADJOURNED

Meeting minutes

RDF Lists #76

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/76 : How should list ordering be preserved in R5?

dbooth: Preferences on RDF lists?

houcemeddine: No opinion.

jim: Keep R4 for OWL compatibility.

gaurav: Keep R4

eric: Pref RDF lists, and use a transformation for OWL folks.

dbooth: R4

eric: R4 would complicate shex.

rob: Pref RDF lists.

eric: narrative.div has a direct string value, not an object.

dbooth: example: fhir:div "<div>…</div>"

dbooth: I view that as a bug. It should be an object, to avoid potential OWL clash of ddatatype vs object property

ISSUE: Should narrative.div be an object property or datatype property?

rob; Willing to be persuaded .. . . (lost him)

gaurav: I could live with either option, so I don't feel strongly one way or another.

eric: Worried about deviating from the model.

rob: why?

eric: Because you can't have a fhir:index list if you have a list of scalars directly.

dbooth: Views?

rob: RDF lists

gaurav: Either option

houcemeddine; Either

jim: Both fine for me.

AGREED: Adopt RDF lists

Should FHIR datatype values have an rdf:type? #106

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/106 : Should FHIR datatype values have an rdf:type?

dbooth: I think it's too late to consider for this R5 ballot

eric: explicit is nice, but terse is nice also.

AGREED: Table this for the moment.

Modifier extensions #93

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/93 : How should modifier extensions be handled in R5?

dbooth: opinions?

rob: somewhat persuaded by option 6

jim: option 6

houcemeddine: option 6

gaurav: option 6. FHIR validator is ridiculously specific about validating all modifier fields. Not sure how we'll replicate that.

eric: option 6.

dbooth: ok w option 6

AGREED: Go with option 6.

eric: I'm editing things at https://w3c.github.io/hcls-fhir-rdf/spec/v2

dbooth: things to vote tomorrow:

1. Shortening property names

2. RDF Lists #76

3. Modifier extensions #93

4. Concept IRI

5. fhir:v

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/76 : How should list ordering be preserved in R5?

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/93 : How should modifier extensions be handled in R5?

ADJOURNED

Meeting minutes

...

<dbooth> s/… fhir:value [//g

<dbooth> s/fhir: start [//g

<dbooth> s/fhir: v "2009-03-14"^^xsd:date//g

<dbooth> s/a fhir:Period;//g

<dbooth> s/did it work?//g/

1 of 5 - Shortening property names #69

https://jira.hl7.org/projects/FHIR/issues/FHIR-37937?filter=allopenissues

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/69 : Shorten FHIR property names or use superproperties?

APPROVED: 4-0-0

Brian made motion, David seconded.

2 of 5 - fhir:v #104

https://jira.hl7.org/projects/FHIR/issues/FHIR-37938?filter=allopenissues

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/104 : We should not use fhir:value for non-hoisted scalar properties

David made the motion, EricP seconded

APPROVED: 4-0-0

3 of 5 - RDF Lists #76

https://jira.hl7.org/projects/FHIR/issues/FHIR-37939?filter=allopenissues

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/76 : How should list ordering be preserved in R5?

David made a motion to approve; Eric P seconds

APPROVED: 4-0-0

4 of 5 - Modifier extensions #93

https://jira.hl7.org/projects/FHIR/issues/FHIR-37940?filter=allopenissues

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/93 : How should modifier extensions be handled in R5?

David made a motion to approve, Eric seconded

APPROVED: 4-0-0

5 of 5 - Concept IRIs #94

https://jira.hl7.org/projects/FHIR/issues/FHIR-37941?filter=allopenissues

<Github> https://github.com/w3c/hcls-fhir-rdf/issues/94 : Lack of concept URIs for CodableConcepts -- Concept IRIs

paul: Recommend discussing this with MnM about storing non-ASCII chars in URIs

David made a motion to approve, EricP seconded

APPROVED: 4-0-0

Approval of minutes

Paul: Ran out of time. Let's approve them on the next call.

gaurav: We also should have included a link to TSMG's minutes, where they approved the IRI Stem inclusion in the Terminology website: https://confluence.hl7.org/display/TSMG/2022-08-08+TSMG+Agenda+and+Minutes

ADJOURNED

<dbooth> s|s/… fhir:value [//g||g

<dbooth> s/... fhir:value [//g

Meeting minutes

Updating the FHIR spec for R5 RDF changes

dbooth: Eric edited RDF page. I am now taking a pass though editing it also. Hope to merge our changes in with Rob Hausam's changes, to reduce the total number pf PRs and builds that have to be done.
… Our changes should not affect the build, because they are only about documentation.

dbooth: We will still need to update examples, but they're not normative, so they don't have to meet the Sept 4 deadline.

rob: Correct, but they should still be done at least in the ballot reconciliation window, to make it into the R5 publication.

eric: I have I18N tests that should be included, prompted by Grahame.

dbooth: When do those have to be done?

eric: In principle, no deadline, but would be helpful to Grahame ASAP.

gaurav: This is the test cases repo that Grahame mentioned: https://github.com/FHIR/fhir-test-cases

gaurav: repo for test cases: https://github.com/FHIR/fhir-test-cases/tree/master/turtle

eric: Those are generic Turtle tests --- note FHIR specific.

gaurav: Test cases: https://github.com/FHIR/fhir-test-cases/tree/master/r5/examples

rob: The rest of the spec is here: https://github.com/HL7/fhir
… Kindling, suppotive classes etc: https://github.com/HL7/kindling/
… THere's also the HAPI core, used both for FHIR spec and HAPI server: https://github.com/hapifhir/org.hl7.fhir.core

dbooth: So fixing the Turtle examples is also high priority
… But also the Turtle-specific schema for each resource needs to be updated.

rob: Those are generated from the structure defs by Grahame's magic.

ACTION: Rob to find the code for generating the Turtle templates from the structure defs.

jim: I can work on the java changes

gaurav: I can help on the java stuff, but have deadlines through Aug 31.

Issue 94: Concept URIs -- (Leader: Gaurav)

gaurav: Will need to do a UTG ticket. Should we wait until R5 comes out or do one for R4 and then make changes against it.

dbooth: I think we should wait until R5 comes out.

https://jira.hl7.org/browse/FHIR-37960

https://jira.hl7.org/browse/FHIR-37962

gaurav: Discussed on zulip. https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Adding.20IRIs.20as.20an.20identifier.20type.20to.20the.20FHIR.20specification

rob: source code for templates: kindling/src/main/java/org/hl7/fhir/definitions/generators/specification/FhirTurtleGenerator.java

gaurav: grahame is worried about IRIs with non-ascii chars, because of security.

gaurav: We could switch to using URI stems instead.

eric: Could negotiate w grahame, to prove it's no less safe than what's already there.

dbooth: IRI security considerations are already written up here in general: https://datatracker.ietf.org/doc/html/rfc3987#section-8
… and our Concept IRI already lists security considerations: https://docs.google.com/document/d/1sW3Tgj2J_wBzlUWih07e0Vf_M9Ue8YyPqjK0arhajS8/edit#

https://docs.google.com/document/d/1sW3Tgj2J_wBzlUWih07e0Vf_M9Ue8YyPqjK0arhajS8/edit#bookmark=id.1ud5nwhumjin

gaurav: I think it might be worth (1) adding a link to the security concerns to the Zulip chat anyway, and (2) David, if you could read through the chat conversation to see if you can get a better read on Grahame?

dbooth: Ok, I will

ADJOURNED

Meeting minutes

Merging updated rdf.html

dbooth: Sent edited rdf.html page to Rob to merge.

rob: Running the build now to check it.

rob: Do we want a "TODO" left on the page?

eric: Could change that to point to someplace on github.

<ericP> https://github.com/w3c/hcls-fhir-rdf/blob/gh-pages/scripts/download_fhir_spec

<ericP> https://github.com/w3c/hcls-fhir-rdf/blob/gh-pages/scripts/flattenLists

dbooth: Forgot to bold some parts of hte example

rob: https://loinc.org/rdf / is rendering with a space.
… and the hand and smiley icons need to be bigger.

<ericP> https://github.com/w3c/hcls-fhir-rdf/tree/gh-pages/scripts/flattenFhirLists

dbooth: Need to fix: <code class="rdf" style="font-size=larger"><span>👋🏾</span></code><

eric: Dir for the list conversion: https://github.com/w3c/hcls-fhir-rdf/blob/gh-pages/scripts/flattenLists

rob: It is failing on: Error: Exception inserting section numbers in rdf.html: Malformed XHTML: Found "</p>" expecting "</br>" at line 167 column 10

gaurav: In the doc, we use the SNOMED id prefix, but for SNOMED compositional we're supposed to use a different prefix..

eric: Could note that the IRI stem for compositional grammer is wrong.

houcemeddine: Propose removing the row

gaurav: My comment that I needed to look up that SNOMED CT suggests using “http://snomed.info/scg/” as the IRI stem for SNOMED compositional grammars, e.g. http://snomed.info/scg/404684003%3A47429007%3D79654002 -- this is as per https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard. I know we decided to continue to use “http://snomed.info/id/” since FHIR doesn't distinguish between compositional and non-compositional IDs.

AGREED: Remove the SNOMED compositional row from the examples and add a note saying what the correct IRI stem should be for the compositional grammar.

houcemeddine: https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard

Updating the build process

gaurav: Jim is looking at the code, but it's complicated.
… He found 3 versions of the RDF parser.

gaurav: r5: https://github.com/hapifhir/org.hl7.fhir.core/blob/master/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/formats/RdfParser.java

and

r4: https://github.com/hapifhir/org.hl7.fhir.core/blob/master/org.hl7.fhir.r4/src/main/java/org/hl7/fhir/r4/formats/RdfParser.java

There is also 4b:

https://github.com/hapifhir/org.hl7.fhir.core/blob/master/org.hl7.fhir.r4b/src/main/java/org/hl7/fhir/r4b/formats/RdfParser.java

gaurav: Need to change the parser and the kindling.

rob: Needs to be done by Sunday to get it into the ballot, or during ballot reconciliation.

rob: Shouldn't do major changes during ballot reconciliation, but need to file a comment to start the process.

I18N examples

gaurav: Grahame said in zulip: Grahame Grieve: ok I'm ok with adding IRIs as stems. I wouldn't be surprised if there's a need to add IRIs at the concept level (ICD-11)

Grahame Grieve: I'm not a fan of allowing non-ascii characters. I don't think that's the only difference between URI and IRI

Grahame Grieve: but I'm not clear what data type would be used for IRIs either. I don't think they're OK in the definitional framework right now

https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Adding.20IRIs.20as.20an.20identifier.20type.20to.20the.20FHIR.20specification

gaurav: But you can already put non-ascii in fhir strings.

gaurav: I think he's assuming that the IRI stems would already be converted to URIs before putting them into the terminology repo.

eric: The issue is that if they're pre-converted to URIs, then the issue is you don't know how many times they've been encoded.

dbooth: I think we should stick to our guns and say "these are IRIs -- not URIs".

<ericP> https://www.w3.org/2008/Talks/31-ASPE/xRIs.svg

ACTION: DBooth, Eric and Gaurav to craft a response to Grahame

ADJOURNED

Meeting minutes

Updated RDF page

dbooth: It's done, thanks to Rob!

http://build.fhir.org/rdf.html

FHIR spec build process

jim: Trying to understand how to do the RDF list. It doesn't use an RDF data model.

eric: I think there are multiple parsers. One is driven by the data model. Grahame's parser is different because it cares about whitespace, comments, etc., but not complete but good for the examples.

eric: The regular HAPI parser/serializer walks through the structure def and either parses or serializes. Grahame's is separate, to make the examples more readable.

eric: IntelliJ has a nice "Code with Me" feature.

dbooth: Multiple things to be updated in the build: 1. Examples. 2. resource templates. 3. ShEx 4. ontology, including relation between properties/resources and their underscore version.

eric: Should add a comment to the top of the ont file, saying how it differs from most ontologies.

gaurav: What are all the changes we need to make? dbooth: they're in the jira issues.
… Suggest a github issue for them.

ACTION: DBOoth to make a github action for them.

Write an OWL conversion for RDF lists

dbooth: Suggest we target SPARQL, Python, Java, JavaScript

jim: Should we define the target first? Could use SPARQL to change the namespaces from rdf: to notrdf: .

eric: Or could make them repeated properties.
… I want my code to work over the FSH (FHIR Short Hand).

eric: If somebody writes an extension, they'd likely use the standard datatypes. OLO would require a standoff.
… We could use the R4 approach.

ADJOURNED

Meeting minutes

Concept IRIs

gaurav: Next step is a UTG-specific request to add a specific stem IRI to the repo.
… BUt don't need to do that until after the R5 balloting dust settles.

RDF generation in the build process

eric: Every time a property ends in "[x]", it has multiple types.
… You could throw an exception if you find something different.

ADJOURNED

Meeting minutes

FHIR build update

jim: Trying to run the generator to see the changes in the build, but not able to run it.
… Asked on zulip, got a little response from Grahame.

eric: Has Deepak had success?

jim: I don't think he's got into that code gen stuff.

dbooth: Suggest asking Mark Iantorno <markiantorno@gmail.com> on zulip

https://github.com/w3c/hcls-fhir-rdf/issues/110

Concept IRIs

gaurav: Waiting until after the R5 balloting, then will put in a change request for one of the code systems or naming systems so that we can track how that changes, then we can do that for others.

FHIR Ontology draft on W3C github

AGREED: Mark the W3C versions as obsolte and point to the FHIR versions

ACTION: DBooth to make those changes.

ADJOURNED

Meeting minutes

Ballot comments

dbooth: comments due Oct 14. Rob Hausam will file on our behalf.

Ballot process: http://35.190.153.146/ballot-intro.html

ACTION: DBooth to draft ballot comments for Rob Hausam

Scripts to convert FHIR RDF to ontology friendly RDF

eric: Don't want to reinvent all of R4 RDF. We only want to add indexes.

dbooth: Another possibility would be to gen R4 RDF

eric: But that would be harder, because we'd have to fully qualify all the property names -- we'd have to know all of them.

dbooth: We'd have to generate a big lookup table of everything in the hierarchy.

option 1: add explicit indexes without changing property names

option: Generate R4, which has explicit indexes and fully qualified property names

option 3: Change the rdf: namespace of the of the list predicates to nonRdf: namespace.

eric: Options 1 and 2 will help SPARQL users, but not option 3.

dbooth: I'd like to help both SPARQL and OWL users with the same generator.

eric: What's good for OWL is not necessarily the same as what's good for SPARQL.

dbooth: How much do we care about generating an explicit index for SPARQL users?

eric: Most users who care about the order of items in a list will want the first element, which is easy to get with SPARQL without an explicit index.

AGREED: We don't need to gen an explicit index

gaurav: Should we document the nonRdf: namespace?

dbooth: We could, to make it standard.

gaurav: Like the idea of making it dereferenceable to an explanation.

gaurav: Could use figshare for the document

jim: Could use a w3id

dbooth: Or it could go to the FHIR rdf.html page, as an anchor

dbooth: Preferences?

jim: w3id or github

gaurav: figshare or github

eric: rdf.html

houcemeddine: Suggest w3id, https://purl.archive.org/

dbooth: Could use the fhir: namespace

jim: Could do fhir:rdfFirst and fhir:rdfRest

dbooth: Or fhir:f and fhir:r

AGREED: Use the fhir: namesAPCE

AGREED: Use fhir:rdfFirst and fhir:rdfRest for OWL-friendly lists.

eric: What about literals?

jim: For literals we could use fhir:rdfFirstLiteral

AGREED: Use fhir:rdfFirstLiteral for literal predicate

eric: Only care about literals if you're using a list and wanto to preserve order and you're doing a logical model that has those.

ACTION: Jim to propose SPARQL to for list conversion

Concept IRIs

gaurav: Hope to have something to share by next Thursday

ADJOURNED

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.

https://docs.google.com/document/d/1e_g-sJCCbVIhbBdjoIYTCN4znwCCK2z7E-Oss2VqgrA/edit#heading=h.wch9s83t9l3r

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://build.fhir.org/extensibility-registry.html

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://github.com/w3c/hcls-fhir-rdf/issues/4 : What should be the media type for FHIR RDF in Turtle or other serializations?

dbooth: I think we should validate as much as we can.

gaurav: Might be biting off more than we can do.

ADJOURNED

Meeting minutes

Ballot comments

dbooth: Rob got them submitted.

rob: I assigned them all to ITS.
… I heard people mention late Feb deadline for completing them. We should plan to have them done by early Feb.

FHIR spec build progress

jim: Messaged Grahame last week. He said he'd try to get to it in the next few days.

dbooth: I think we can wait a little longer for Grahame.

SPARQL Update code

jim: Made a PR for limiting the SPARQL update to non-OWL use od RDF lists: https://github.com/w3c/hcls-fhir-rdf/pull/111/files

eric: You could do a ?p query and filter for the ?p that start with the fhir: namespace.
… If you had other data using lists, it would avoid changing them.

eric: I can imagine having some other bio data in the same RDF.

dbooth: Agreed. I think we want restrict the changes to the fhir: uses of RDF lists.

ACTION: Jim to change this SPARQL accordingly.

dbooth: Would be good to test this for scalability, and ensure it works.

eric: We should offer a few alternatives implementations.
… You can use synthea to generate data for testing, convert to JSON then to RDF.

jim: My data is R4.

Concept IRIs

gaurav: Updated the UTG proposal.
… Back to using unique ID for our purpose. Not ideal, because we need a new type for IRI.

dbooth: Should we meet w UTG?

rob: Meeting today and in two weeks.

rob: Recently spun off the term mgmt governance group. Trying to figure out the respective roles. Now TSMG has taken a big chunk of the work, including TSO. Other than making rec to TSMG, not sure what the vocab group can do. They'd have to make the decision.

gaurav: When we pitched the idea of concept IRIs, we started with vocab group, then went to TSMG, then back to vocab. May do the same thing this time.

gaurav: My dream scenario would be to iterate on this in jira, then figure out what concerns they have.
… But it seems that jira tickets don't get much attention.

rob: But zulip gets attention.

gaurav: Process is to put in the request, then put in the changes to show them what it looks like.

https://docs.google.com/document/d/1e_g-sJCCbVIhbBdjoIYTCN4znwCCK2z7E-Oss2VqgrA/edit#

rob: UTG proposals are about content, but structural changes need to be through github.

gaurav: only need a new type for IRIs.

rob: That can be a UTG request to add that concept.
… There's a UTG subgroup of TSMG, and they'd be responsible for the changes.

rob: Is an IRI stem always an IRI?

dbooth: I think it should be.

eric: We should prohibit things like a partial domain name.

gaurav: TSG would have to agree both to use uniqueID and to add an IRI type. If they want it done as an extension instead, then that would be more work.

gaurav: Why does NamingSystem.identifier not work?

rob: It only identifies the naming system resource instance.

eric: We'd want them to be same when possible.

gaurav: Suppose we add an identifier to the Loinc code sys resource, the idneifier class has a system field, so the system could be a naming system.

rob: I have a feeling that won't fly. But not sure we need to.
… If these IRI stems act as unique IDs then it's appropriate to put them into the Code System.

gaurav: Every time I see a Code Sys, there's a Naming Sys that goes with it. But we could say that IRI stems only make sense for a Code System.

rob: Naming System just says how things can be referenced.
… The other IDs will end up in Naming System, because that's part of the TSMG practice.

eric: Do we want some governance to support changes to the IRI stem?

rob: Purpose of the repo is to account for changes like that.

gaurav: Both of them have a Period that says when they were valid.

eric: Use case would be combinign old data (using old IRI stem) with new data using the current IRI stem.

gaurav: To what should the system point?

dbooth: Point to the rdf.html page?

ACTION: Eric and DBooth to read the document.

ADJOURNED

Meeting minutes

Update on FHIR build process

jim: No progress on the build code. no update from Grahame yet.

SPARQL list updater

jim: I updated the SPARQL code. Seems to work. Also added another one, with a different filter. This one looks for predicates that are in the fhir: namespace, and only changes object of those predicates.

dbooth: For performance test, you only need a bunch of data that uses RDF lists, then add in a little FHIR data with lists.

eric: If someone is using this in anger, they'll probably be using an API.
… GO has lots of things that use lists in OWL.

dbooth: Where should we store these scripts?
… Could be rdf.html page. Or github, or a wiki.

rob: Or the THO site
… THO is the same a FHIR IG -- Implementation Guide.

rob: Anything you can do in the FHIR spec you can do in THO, in terms of formatting.

AGREED: Keep in on github

eric: Propose to change the page name to owlSafeLists

AGREED: Change page name to owlSafeLists

ACTION: Eric to make these changes

ACTION: DBooth to finish edits on that page.

Concept IRIs

https://docs.google.com/document/d/1e_g-sJCCbVIhbBdjoIYTCN4znwCCK2z7E-Oss2VqgrA/edit#heading=h.wch9s83t9l3r

gaurav: Should we add some text to rdf.html to say what restrictions should be on IRI stems?

dbooth: Make sense.
… E.g., don't put in a partial domain name.

eric: Agreed.

rob: Should we add an IRI type?
… But not (yet) as a FHIR datatype?

dbooth: Sounds good to me.

gaurav: Do we need to worry about NamingSystem at all? Or should we view this as only being a CodeSystem thing?

rob: Policy is that for every CodeSystem, there is a NamingSystem.

dbooth: And in point 2 we need to add an iri-stem code to NamingSystemIdentifierType

rob: But if we're adding iri-stem, shouldn't we also add an iri code?

dbooth: If there isn't yet a use for it, I generally think it should not be added.

rob: Okay to leave it out, and see if it comes up in discussion.

jim: I don't think we should require the IRI stem to end with a hash or slash.

dbooth: Agreed.

jim: Wonder how people put HPO codes into FHIR.

ACTION: Gaurav to draft text on IRI stems for rdf.html

gaurav: Next step is make a PR for proposing the changes to THO.

dbooth: Next step on updating rdf.html?

rob: Put the proposed changes into the jira ticket, and get it approved.
… For approval by ITS.

Implementation Guidelines

eric: What are IGs doing now? What made CDA super successful was the IG that told you everything you need to write in the health record that did not have a defined structure. E.g., how to write when someone quit smoking. Will FHIR IG do that also?

rob: Yes, depends on how far you take it. Some constraints may be loose, some may be very locked down. Might take more than one layer to get there.

eric: CDA had one set. Would every FHIR profile define their own?

rob: Reverse of that. CDA also had realm specific guides. CDA also had CCDA for USA, etc. But Europoe has different ones.
… In FHIR you can do universal, or a particular realm, etc.
… But the IG is a container that included profiles, which are almost alwasy part of an IG.
… An IG typically includes multiple profiles.
… Profiles are computable constraints.

eric: The point is that if you are going beyond the specificity of what's in a terminology, then you give guidance.

ADJOURNED

Meeting minutes

Introductions

Joe: At Johns Hopkins, working w Chris Mungall

Chris: Working at U Colorado

OWL usage

joe: Have some questions on how to represent things.
… Working on PR for ont access kit. We have a FHIR server and want to load content from a number of sources. Need to convert to FHIR, some data already in OWL/RDF. Not sure how to structure it.
… There's a github w existing OWL converter, but it's leaving out a lot of content.

https://github.com/aehrc/fhir-owl The Australian e-Health Research Centre

joe: Working on a PR: https://github.com/INCATools/ontology-access-kit/pull/320
… How to represent CURIEs? How to include classes from external code systems? Synonym structuring?
… Is-a hierarchy -- want to check it.

jim: Two issues in converting OWL. In our IRI stem proposal, we assume lots of code with one prefix. But a lot of OBO ont include terms from a number of namespaces.
… Also, our proposal assumes that the code is a local code and not a CURIE.
… RDF group has expectations about how that should work?

eric: Converting OWL to FHIR? joe: Yes.

joe: Converting OWL ont to FHIR code system resource. Suppose some content maps could be involved.

dbooth: Your intent is to use those with FHIR data later?

chris: Yes.

gaurav: Not sure how pyrophen is related, but it looks like it could be useful: https://pyrophen.readthedocs.io/en/latest/example-json.html It highlights the problem we have.

chris: It was written by the phenopackets guy.

https://pyrophen.readthedocs.io/en/latest/representation.html

jim: For a code like "HP:000300", if we prepend an IRI stem directly, then it won't match the OBO IRIs, that OBO assigns.

joe: i like those CURIEs in there but Idk if that's conformant?

joe: code: Indicates that the value is taken from a set of controlled strings defined elsewhere (see Using codes for further discussion). Technically, a code is restricted to a string which has at least one character and no leading or trailing whitespace, and where there is no whitespace other than single spaces in the contents xs:token JSON string

Regex: [^\s]+( [^\s]+)*

This datatype can be bound to a ValueSet

joe: i don't mind using a fhir extension element for the prefix/namespace, but whenever extensions come into play that is certainly an area where we'd want to have a consensus or explicit standard

joe: I'm thinking like: CodeSystem.extension.curie_map

joe: CodeSystem.concept.extension.uri maybe

eric: The code should just be the number part. You can still have valuesets that draw from multiple code systems.

gaurav: We could ask everybody to use either:
… { system: OBO, code: “HP:101” } OR { system: HPO, code: “101” }

houcemeddine: An excellent practice will be the use of OBO Ontologies instead of SNOMED-CT.

joe: I was thinking one OWL file should generate one FHIR resource.

jim: If you're making a FHIR resource for Mondo, maybe it should only have the Mondo terms.

gaurav: So then { system: MONDO, code: “UBERON:101” }?

eric: If there's no need to unify codes w other ontologies, then ... if you have hp: on the front of each, and take those off, but leave others off, you'd effectively be making aliases for them in your code system.
… But the cleanest way to do it is to emit one code system for each prefix.

rob: Agreed.

joe: Suppose I have one with only one term. Would that confuse?

eric: I don't think so. It would be more confusing if you kept the prefixes.

chris: Want to check with Peter.

jim: Our goal is that it comes out looking how people expect it to look.

joe: Tooling available for FHIR RDF?

jim: The playground.

eric: Also Harold's demo of using SNOMED and reasoning with FHIR RDF.

https://yosemiteproject.org/tutorial-fhir-rdf-as-a-bridge-to-the-semantic-web-in-healthcare/

gaurav: Also concept IRI https://github.com/fhircat/fhir-rdf-playground/pull/12

dbooth: Also HAPI server does FHIRRDF R4. Not yet R5.
… and the playground: https://fhircat.github.io/fhir-rdf-playground/

gaurav: Given that FHIR thinks of codes as system-code pair, and RDF uses IRIs. We're planning to use the HL7 terminology website to host the IRI stems.

https://jira.hl7.org/browse/UP-364

https://bit.ly/fhir-rdf-concept-iris-july-2022

eric: hapi-fhir RDF tests: https://github.com/hapifhir/hapi-fhir/blob/master/hapi-fhir-structures-r4/src/test/java/ca/uhn/fhir/parser/RDFParserTest.java

gaurav: We've made the proposal to the terminology group, and want to start adding actual IRI stems.

dbooth: And the underscore should be a part of the IRI stem, because it isn't a part of the code.

joe: For sysnonyms, if it's exact, shoudl I use "designation"?

rob: Yes, that sounds right.
… For broader/narrower, it could be done with a property.

Other updates

gaurav: No progress on concept IRIs

jim: No word from grahame.

dbooth: Eric, HAPI progress?

eric: Need time to work on it.

dbooth: And simplifying the playground URI?

eric: James is doing that.
… Might want an OWL-friendly option. So it might be useful to keep those optoins somewhere.

ACTION: DBooth to check with James about trimming the playground UI

ADJOURNED

Meeting minutes

Stem IRIs

chris: Talked w Peter. Seems to be personal preference to use underscore rather than colon.

jim: Sounds good. Underscore will be in the stem.

jim: Joe is incorporating them into his tool.

Getting Stem IRIs into terminology website

gaurav: I have a write-up for getting something into the website. An informative (non-normative) section.

https://docs.google.com/document/d/1e_g-sJCCbVIhbBdjoIYTCN4znwCCK2z7E-Oss2VqgrA/edit#heading=h.wch9s83t9l3r

gaurav: I think we should have an IRI Stem section in rdf.html

rob: Arent' we going to add a specific code for IRI stem?

gaurav: For NamingSystem yes. But didn't choose for Identifier.

rob: suggest using urn:ietf:rfc:3987

gaurav: Suppose there is an IRI with non-latin chars, then they might wnat to use the puny-code version for the URL.

rob: Instead of adding it to Identifier.system, add it to the type.

eric: The system identifies its form, and the type identifies its purpose.

rob: Need two UTG proposals: One to update the page, and one to add the code to the valueset.

rob: Process is to put the jira ticket our proposed resolution.

dbooth: Need to distinguish UTG proposal from changes that fall under our existing ballot comment issues.

ACTION: Gaurav to provide checklist for R5 checklist

FHIR build process

jim: Grahame fixed it. I will get back to it.

Conversion of FHIR R5 RDF to OWL friendly

dbooth: Have we done enough on this?

jim: I have not yet done performance test

eric: I think we have done enough.

ACTION: DBooth to clarify that we want community contributions.

AGREED: We have done enough on the OWL conversions.

FHIR RDF playground

dbooth: Wrote to James Champion , but have not yet heard back.

ADJOURNED

Meeting minutes

FHIR RDF Playground

james: Added controls to switch between R4 and R5.

ACTION: James to add a button for enabling expert options

james: Found where it was executing the preprocessor on every keystrroke, and commented it out.
… Now adding R4/R5 buttons.

dbooth: Suggest using radio buttons for R4 vs R5, and delete "RDVch".

eric: Medication 4.6 should be Medication R5.
… Could also have a min/max version in the manifest.

james: The version selection will cause the proper versions of the examples to be shown.

eric: If you switch from R4 to R5, you'll need to lead the R4 defs instead of the R5 defs.
… you can pull them directly from the FHIR downloads.

AGREED: Make R4 the default version for the moment

dbooth: Could do a stripped-down download of R4 definitions, since they are stables, but pull R5 from the FHIR build site.

dbooth: How about hiding the middle pane by default.

AGREED: Hide middle pane by default.

Concept IRIs

gaurav: When someone uses a code system like LOINC, we want the system to be "urn:ietf:rfc:4987" and identifier type of iri-stem.

gaurav: This raises two issues. 1. we'll have to add iri-stem as an identifier type.
… 2. Need to add identifier system for 3987 to THO.
… This used to be easy, but this info is now moving into THO, and THO doesn't have a simple list of identifiers now, which I think means that it now needs to become a naming system.
… That's how URI is handled.
… So I think we'll have to define a URI ..../iri .

gaurav: Should these be bundled together?

rob: yes

gaurav: We previously requested this, and just got a question from Lloyd.
… Asking whether it was intended only as an identifier system, or also as a coding system.

gaurav: If we wanted we could make coding.system.value that is the IRI.

rob: But that goes away from the intent of a code system.
… If you specify ...3986, that's all possible URIs.
… It's used more as an identifyuer.

eric: Would SNOMED post-coord terms be similarly infinite?

rob: yes

gaurav: We certainly don't need it for codings.

AGREED: It is only for identifiers, not codings

gaurav: Also working to get my permissions set up to be able to make the proposal.

FHIR build

gaurav: Grahame checked in his code, and jim now needs to get it.

R5 cleanup

dbooth: Finished adding a link to the rdf.html,, and in the jira ticket. Ready for ITS vote on it.

gaurav: How to handle the IRI stem explanation we need to add to rdf.html page?

rob: Need a separate jira ticket for it.

ACTION: Gaurav to create a separate jira ticket for rdf.html page change of adding IRI stem explanation.

ADJOURNED

Meeting minutes

FHIR build process

jim: Heard back from Grahame in Nov. Tried to check out latest code from HAPI core. Not sure what the situation is. Master branch now fails the test. Trying to figure out what the right branch is.

Concept IRIs

gaurav: Created an issue earlier to add IRI stems: https://jira.hl7.org/browse/FHIR-37960
… Lloyd had a question. I've added a response to his quetsion.
… It's linked from our other issue: https://jira.hl7.org/browse/UP-364
… I've updated it to use urn:...RFC3987
… We need a codesystem and a string.
… I've made these changes to the jira issue.
… The type field for a naming system can only be one of the defined values in the valueset define in FHIR itself -- not in THO.
… It would be the same UTG people to make that decision.
… There's now a branch that goes with this. Diffs: https://bitbucket.hl7.org/projects/UTG/repos/utg/compare/diff?sourceBranch=refs%2Fheads%2FUP-364-request-to-add-iri-stems-to-loinc&targetRepoId=1

ACTION: Gaurav to create a new jira issue for adding the iri-stem type

ShEx

eric: Working hard on the jena implementation of shex.

ADJOURNED

Meeting minutes

FHIR build

jim: Met w Deepak. Very helpful. He confirmed that the tests won't pass. But grahame says it passes.

dbooth: Bring it up in the committers channel.

Concept IRIs

https://jira.hl7.org/browse/UP-364

gaurav: I think I'm ready to submit the UTG change proposal, for adding stem IRIs to LOINC.

rob: TSMG meetings are Thursdays, 3:30 Eastern.

rob: Gaurav should reach out to chair to join the call when it is discussed.

dbooth: I';m happy to join the call also. LMK when it will be.

dbooth: OUr minutes from Aug 17, 2022 where concept IRIs were approved in ITS: https://www.w3.org/2022/08/17-hcls-minutes.html
… but the link https://jira.hl7.org/projects/FHIR/issues/FHIR-37941?filter=allopenissues doesn't work right. It should be https://jira.hl7.org/projects/FHIR/issues/FHIR-37941 .

rob: You need to beat the bushes to be people to vote on it.
… in jira.

gaurav: We now have two proposals: one to add iri type, the other to add iri-stem type.

https://jira.hl7.org/projects/FHIR/issues/FHIR-37941?filter=allopenissues

proposal to add "iri-stem”:

proposal to add “iri”:

AGREED: Drop the proposal to add "iri".

rob: FHIR-I on agenda for Monday 3pm Eastern

https://jira.hl7.org/browse/FHIR-37960 will be discussed

HAPI server updates

eric: Still working on jena.
… Will work on HAPI next.

ADJOURNED

Meeting minutes

Build process

jim: Got everything set up in eclipse again. Back to trying to run the code gen. Opened a zulip topic this morning.

Editorial updates

dbooth: checks failed when I submitted PR.

rob: Need to rebase and try it again.

Updating playground for modifier extensions

dbooth: Realized that we also need to update the playground to handle modifier extensions. Need to update the preprocessor, i think.

james: When needed?

dbooth: Soft dependency. I need it to test examples in the playground.

james: Finishing up UI changes.

Concept IRIs

gaurav: I emailed TSMG group to ask about presenting to them. They said yes. Likely sched Jan 10.

rob: Anything that's core spec needs to go through vocab and jira. Other UTG changes do not need to meet the deadline.

https://jira.hl7.org/browse/UP-364

gaurav: As a fallback, could always do this as an ext.

rob: Could this be a pro forma change that would not need consensus?

gaurav: Yes, they said since this was already voted, it can be pro forma.

rob: Then why bring this up again?

gaurav: now we're being more concrete about the terms.

rob: You've already got the green light. Needs to start w the proposal w all the details we have now.

gaurav: Only the change to NamingSystem identifier type will need to be ...
… If someone says we cannot do that, then we would have to modify the UTG proposal.

rob: Then we need to get that decided first.

https://jira.hl7.org/browse/FHIR-39604

rob: That's on the vocab WG this afternoon, could vote on it today.
… 3:30-5:30pm Eastern.

rob: Okay, 3:45.

https://jira.hl7.org/browse/FHIR-39604

ACTION: Gaurav to join today's vocab call to decide 39604

dbooth: If vocab agrees, do you still need to meet w TSMG on Jan 10?

gaurav: Not sure. Would like someone to look at it.

rob: We can figure out on today's call whether the TSMG call would be needed.

ACTION: Gaurav to send Rob all links needed for today's call

gaurav: We had a proposal to add IRIs as identifier type. Now resolved.

ACTION: Gaurav to do a PR to implement the iri identifier type.

ACTION: DBooth to send gaurav the jira link to the issue on updating rdf.html page

ADJOURNED

Meeting minutes

FHIR ShEx

eric: made some progress.
… Bug fixing.

dbooth: Anything on the critical path for Feb 24, to complete the build process and get PRs merged?

eric: Need to build the ShEx, then use the ShEx.
… Ideally the ShEx should be used to validate all the examples during the build. But it got pulled out ages ago.
… That would depend either on Scala ShEx or Jena.
… Jose Labra is working on the scala.
… If I don't get jena done, we can use the scala anyway.

dbooth: HAPI is higher priority.

eric: Are the XML or JSON examples validated?

dbooth: IDK

Concept IRIs

gaurav: Two FHIR requests have been approved and are waiting for the code to be written (prob by me in January):

- https://jira.hl7.org/browse/FHIR-37960

- https://jira.hl7.org/browse/FHIR-39604

No comments yet on UP: https://jira.hl7.org/browse/UP-364 — I go on vacation after tomorrow, so I’m planning to leave this over the holidays and then start bugging people about this in January unless Rob H has other suggestions.

gaurav: - Gaurav will be presenting at the Terminology and Infrastructure Management Services (TIMS) Strategy meeting on Jan. 06 at 11am EST for 20 mins. I’ll focus on the concept IRI stuff. Should we talk about other FHIR/RDF things? Chris Chute and Melissa Haendel will be there along with other people from their groups. I could forward an invite to anyone interested
… both of those requests have been approved.
… Today is my last working day for the year.
… I'll make a PR for both of these when I return Jan 5.

gaurav: The UTG proposal is now in consensus review. Not sure what that means. Needs a certain number of votes?

rob: Yes. I'll vote on it.
… If you look at the voting tabulation, there's multiple vote categories that need to be received. Might need to reach out directly to some individuals.

rob: Jan 5 I leave for Japan for ISO mtg.

gaurav: On vocab call last week, Davera and Gabrielle want it to be presented at meeting that Chris Chute and Melissa Handel have. Jan 6, 11pm Eastern, 20 minutes. Only present on Concept IRIs?

dbooth: Ask them what they want to hear about.
… Maybe: 1. Concept IRIs and IRI Stems; 2. FHIR RDF R5 "what's new". 3. FHIR RDF in geeneral.

gaurav: Sounded like they want to know if other IRI stems will be registered for everything.

ACTION: Gaurav to review verbiage DBooth added to https://docs.google.com/document/d/1e_g-sJCCbVIhbBdjoIYTCN4znwCCK2z7E-Oss2VqgrA/edit#

ADJOURNED

Meeting minutes

Concept IRIs

gaurav: No updates. When we left off, we have a UTG proposal in, for adding concept IRIs to LOINC. Discussed doing another proposal to add IRI stems to MESH. That will be used as an example in the rdf.html page.

dbooth: When the MESH jira ticket is in, I can reference that from rdf.html

gaurav: 1. Need people to vote on the existing proposal. 2. Need to put in the MESH proposal. 3. Need to write the code for the existing accepted proposals.

chris: This comes up in working w Chris Mungall. I might be able to help.

dbooth: I believe the code changes are changes to XML files.

gaurav: Also will meet tomorrow with M Handel's group, on IRI stems. Term Infra Mgmt.
… Meeting is 11am-12, Eastern US time.

dbooth: Working on slides?

gaurav: Yes, adapting previous slides.

dbooth: Please share slides w me to review.

https://jira.hl7.org/browse/UP-364

https://docs.google.com/document/d/1e_g-sJCCbVIhbBdjoIYTCN4znwCCK2z7E-Oss2VqgrA/edit#

https://jira.hl7.org/browse/FHIR-37960

https://jira.hl7.org/browse/FHIR-39604

FHIR build process

jim: Chatted w grahame. He explained that the generator always produces code that doesn't quite compile, and he has to manually tweak.
… He set out to run the gen, but only copy over the java parser into my branch. My PR would only be changes there.
… If I just copy the generated parser into my branch, it almost compiles. (Only 5 errors.) Two parameters: 1. branch I'm working on. 2. When running the generator, you put in a version for a FHIR pkg that it downloads. I was prev running w the "current" pkg, but grahame said to use snapshot3.
… Resolved all that over the last couple days. Tried gen from that and latest release code. Will now go back and re-apply my changes to master branch.
… Not sure what to do w a couple of these problems. Will have to go back to grahame if I don't figure them.
… need to get the procedure nailed down.
… Two big things after that: 1. Implementing remaining changes. 2. Compile the whole lib and see the changes show up in the RDF examples and templates.

HAPI

eric: Working on SWAT4LS tutorial. Will try to get my part done.
… Next couple weeks.
… Can someone else help? Anyone familiar w the POJOs that drive the parsers?

rob: I have some familiarity. Could help next week.

eric: When you're parsing a polymorphic thing, like observation.value, next version will be called ObservationValue.

rob: I'm central timezone.

ACTION: Eric and Rob to meet on HAPI updates needed

ADJOURNED

Meeting minutes

Concept IRIs

gaurav: Have to drop in 30 minutes.
… Prepared the MeSH jira ticket: https://jira.hl7.org/browse/UP-377
… Still need to write the code for the other proposals.
… Will be out next Thur.
… Also need to let people know about LOINC issue on zulip, to get votes.

ACTION: DBooth to add link to Jira MeSH ticket as example in rdf.html

Meeting w TIMS group

dbooth: Group suggested adding FAQ to the list maintained by FHIR-I.

eric: Suggest find out more specifically what Davera was suggested.

ACTION: Chris to ask Davera what she meant to suggest and whether it needs to be done before Feb 24

gaurav: Chris Chute was confused about the SNOMED relevance. But no action needed.

jim: There was a question about the ICD10 namespace.

gaurav: When there is not an authoritative IRI stem, we should reach out to groups to ask.

eric: There's a serious risk if we claim authoritative IRIs for things if the publisher does not provide one.
… I think we should not provide one if the publisher does not provide one.

dbooth: Same problem in choosing system URI.

AGREED: At least for the moment, we won't publish non-authoritative IRI stems.

ITS WG meeting

dbooth: I'll join virtually, and give an update.

CHris: I might be able to join. I'll be there.

FHIR Build process

jim: Good news and more questions. Been making changes in the FHIR core library, in HAPI fhir repo.
… It has RDF code, some of which is generated. Kindling depends on that, and then FHIR gen depends on kindling.
… Grahame helped me through where I was stuck. Got it close to compiling, then a have a few things to fix, then able build the whole fhir lib.

jim: structure defs seem to have fhir:v, but examples like observation still use fhir:value .

dbooth: the ontology rdf.ttl has some fhir:v in it, so maybe grahame already did something.

ACTION: DBooth ask Guoqian about adding Rob (and Jim) to skype channel.

ACTION: Jim to follow up with Daniel and Deepak

HAPI

eric: Rob and I went through the code, got a feeling about what's needed. Mostly deletions, some additions on polymorphic types.

dbooth: How soon do you think you can have something testable?

eric: 3 weeks? Rob will be busy with other things the next two weeks.

dbooth: If someone became available, whould they be helpful? Eric: Yes.

ADJOURNED

Table of Contents

Attendees

Meeting minutes

FHIR RDF Update

Approval of minutes

Attendees

Meeting minutes

HL7 meeting report

RDF Lists

Concept IRIs

FHIR RDF Playground

Attendees

Meeting minutes

RDF Lists

FHIR RDF Playground

Concept IRIs

Attendees

Meeting minutes

RDF Lists

Concept IRIs

Attendees

Meeting minutes

FHIR RDF Playground

Attendees

Meeting minutes

Concept IRIs

Attendees

Meeting minutes

FHIR RDF Playground

Issue 95: References lack a type arc

Concept IRIs

Attendees

Meeting minutes

Concept IRIs

FHIR RDF Playground

Issues list

Attendees

Meeting minutes

Concept IRIs

References lack a type arc, issue 95

Properties with both scalar and object range: fhir:value inside of fhir:value #102

Attendees

Meeting minutes

Concept IRIs

Attendees

Meeting minutes

References lack a type arc #95

Concept IRIs

Attendees

Meeting minutes

RDF Lists and OWL

Concept IRIs

Properties with both scalar and object range: fhir:value inside of fhir:value #102

Attendees

Meeting minutes

Properties with both scalar and object range #102

How should modifier extensions be handled in RDF? #93

Issue 69: Shorten dot-compound property names?

We should not use fhir:value for non-hoisted scalar properties #104

Issue 76: Ordered lists

Meet also on Tuesdays, same time?

Issue 95: References lack a type arc

Attendees

Meeting minutes

How should modifier extensions be handled in R5? #93

We should not use fhir:value for non-hoisted scalar properties #104

Attendees

Meeting minutes

RDF Lists

We should not use fhir:value for non-hoisted scalar properties #104

How should modifier extensions be handled in R5? #93

Concept IRIs

Attendees

Meeting minutes

List ordering #76

Modified extensions #93

Attendees

Meeting minutes

Replacing fhir:value

Concept IRIs