– DRAFT –
FHIR RDF

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