Meeting minutes
Concept URIs
gaurav: We're down to two main remaining questions.
… Should we discuss on the Monarch Initiative list?
dbooth: I think so.
gaurav: And want to get Grahame's input, then we can submit it to the FHIR zulip.
eric: part of our goal is to produce URLs that the terminology owners will want to honor.
dbooth: opinions?
jim: No strong opinion. I usually say IRI because it's in sem web specs these days.
gaurav: We could ask for IRIs and see if we get pushback.
eric: How about "stem IRI"?
dbooth: Fine with me.
AGREED: Ask for IRIs, and call it stem IRI.
dbooth: Problem: if we go with IRIs, what is the encoding algorithm definition?
eric: We could define the algorithm if we cannot point to one.
From RFc 3987 (IRIs):
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
jim: Should we allow a slash in a code to be passed through?
eric: No, because that would require us to invent our own reserved space.
gaurav: If you want an IRI directly you can use the urn:...rfc3987 Coding.system to allow the IRI to be used directly as the code, without any encoding.
ACTION: Eric to ask Martin Durst if there's an official percent-encoding spec for IRIs
jim: In FHIR data, ever encountered terms from OBO ontologies? Would they use a GO term go1234567? Or would you use the underscore version?
Examples are:
http://www.ebi.ac.uk/efo EFO_0004327 http://www.ebi.ac.uk/efo EFO_0005112 http://purl.obolibrary.org/obo FMA_63919 http://purl.obolibrary.org/obo VT_2000017 http://purl.bioontology.org/ontology/NCBITAXON 9606
dbooth: It is up to whoever is putting those code definitions into the FHIR terminology server.
Making FHIR align better with Sem Web standards
DBooth: ITS meeting Mar 2 will discuss a request from someone at Signa to make FHIR more friendly to Semantic Web: "On the topic of FHIR and existing web standards, my view is that FHIR is made up of web standards but doesn't take advantage of the larger ecosystem as much as I'd like to see. In particular, I wonder about combining FHIR's JSON, XML, and RDF (Turtle) formats with existing standards. By way of examples, JSON would pair nicely with Activi
tyPub, built on top of ActivityStreams, which is in turn built upon JSON-LD. Also I don't know if I see good usage of the RDF capabilities for automated reasoning or semantic inference/querying. I haven't even running assertions on FHIR documents using tools like SHACL." Thoughts?
eric: Not very inspired ActivityStreams. Updating like CRUD.
… Tenuous connection to Sem Web. Some effort to use ActivityStreams for message passing. Since it's JSON-LD it could RDF.
dbooth: It's at 3pm Eastern.
eric: I could join.
dagmar: Me too.
RDF Lists
jim: drafted a document: https://
jim: This is the GitHub issue: https://
jim: Two main issues: 1. it violates the OWL spec. 2. OWL profile support. Not a spec issue, but nodes in a list are bnodes which are anonymous individuals, so EL and QL reasoners do not recognize them. If you're working with big terminologies, you usually use EL.
jim: Tool compatibility is another issue. OWL API is the biggest.
jim: The gist is that the ont works fine in these reasoners. The only issue is that if the data is in RDF -- which it will be -- when you parse it from the OWL API, all the list nodes are lost.
jim: I also tried a few other tools.
jim: Biggest problem: Somebody opens FHIR RDF data in protege, they'll lose data.
jim: Could see if OWL API could do its work without dropping list bnodes.
dagmar: Could you share the file you were trying to parse?
jim: Yes, I'll include it or link to it.
dbooth: What do we need to do to close this issue?
eric: Ask the OWL API user community if this is an option they want.
dbooth: Downsides of RDF lists that I remember of hand: violates the OWL spec; not supported by OWL API; SPARQL ordering of list elements is hard.
dbooth: But practical use has shown that SPARQL ordering of list elements is rarely needed, so low priority.
eric: And easy in SPARQL to grab the first or second list element, which is often what's needed.
ADJOURNED