See also: IRC log
https://github.com/BD2KOnFHIR/BLENDINGFHIRandRDF
harold: Files with .owl extension
are OWL functional syntax
... wrapper.owl names the prefixes that we use, and imports all
the files that are used.
... We want the FHIR files to be static, so several of these
files on github are copies of FHIR files.
... FHIR just went to STU3.
... The FHIR ontology, fhir.ttl, is about FHIR clinical records
-- not about patients, tests, diagnoses, etc. It is an ont
about what FHIR records about those things.
... It's generated from the FHIR build using Apache2 jena,
though we want to switch to the OWL API.
... Everything in here is a transformation of things on the
FHIR site.
... This ont has changed radically since it was first done
about a year ago.
... It uses OWL features that are friendly to reasoners.
... Need to decide whether it needs to talk about datatypes
(concrete ranges).
... The w5 ont (who what why where when) is used in generating
the FHIR front page.
... If you found Patient in the fhir.ttl ont it would be a
subclass of something in the w5 ont.
dbooth: what is the benefit of Patient being a subclass of a w5 class?
harold: w5 acts as a small upper
ont.
... snomed_subset.ttl is a subset of SNOMED CT. Because the
FHIR ont and the rules take advantage of data properties and
other things, we cannot use SNOROCKET classifier, and that's
the only one that can handle all of SNOMED CT.
... So we extracted a neighborhood of concepts used for this
demo. There's a tool for making that extraction
SNOMEDtoOWL.
... The SNOMEDtoOWL repository is actively in dev to support a
formal spec for how SNOMED CT should be represented in
OWL.
... There's also Kent Spackman's perl script for generating
OWL, but IHTSDO never said formally what the OWL should
be.
... But the perl script only works on SNOMED international, and
even on that it does odd things.
... The spec being defined in this repository should be
finalized in April.
... I also built a tool RF2Filter that makes a subset of
OWL..
... The script snomed_subset.sh gets all the ancestors and
descendants of specified classes.
... All the rules were previously used.
... In this brainct.ttl example, the status is final.
... A DiagnosticReport can be a patient or a device, but we're
specifically looking for patients.
... We've included an assertion that patient f201 is a
fhir:Patient.
... Also interested in the codedDiagnosis
... We've said that it is an instance of snomed class
sct:188340000
... This file also declares f201.ttl to be an owl:Ontology and
imports fhir.ttl to make protege happy. It also declares the
version of this turtle.
... This specifies the specific version of f201.ttl
... For STU3 grahame gave this an STU3-specific URI, and we'll
discuss that later.
... The final bit is a set of rules rules.owl that we have
authored.
... A FinalizedReport is equivalent to any DiagnosticReport
that has a status of final, amended, corrected, appended.
... And corrected and appended statuses are sub-statuses of
amended, so it's a mini-ontology.
... But the folks who defined those need to decide exactly
which ones should be considered final.
... Also the use of these strings in rules.owl gives trouble to
a lot of reasoners.
... If these strings were URIs instead (in a mini ont, with a
single superclass for final) then this would work with a lot
more, simpler reasoners.
... To simplify the rules, we're defining property
chains.
... And if we had URIs for the statuses, then the status would
be an instance of one of the status classes.
... So then in protege if you load wrapper.owl, and open the
FACT++ classifier and classify it ...
... and view individuals ...
... While that's running the reasoner, there are two
catalog.xml files that protege likes to use. One is local. YOu
need to use one of them.
(back to the reasoner in protege)
harold: now I can show (if it
works right) all the individuals in the CancerDiagnosis class,
including patient f201.
... Success! It just took a while to run.
Screenshot: https://lists.w3.org/Archives/Public/www-archive/2017Mar/att-0007/2017-03-21-120129_1600x1172_scrot.png
harold: We should consider converting the SNOMED compositional grammar to OWL, to enable things like left femur to be determined.
eric: I think we want a tool that pushes everything into snomed.
harold: This imaging study
example will be in the upcoming AMIA paper.
... It includes a body site and laterality. I looked into how
we would classify it, but it would require shuffling. The
laterality is implied, not explicit. This makes a compelling
case for the work that Lynda Byrd and Grahame are doing.
... They are working on using the finer mapping language to put
this into the laterality to create the right compositional
expression. As is I can't find a way to make this classify as
left femur.
dbooth: Would microparsing those snomed compositional strings using ShEx make sense?
harold: It would only use the
regex capability, so that would be done better at a different
level.
... But shex could be an alternative to the approach that Linda
and Grahame
... If you see issues with the instructions in the github, then
file an issue please.
ADJOURNED
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s|(insert f201 screenshot here)|Screenshot: https://lists.w3.org/Archives/Public/www-archive/2017Mar/att-0007/2017-03-21-120129_1600x1172_scrot.png| Present: Louis_Amanis Julia_Chan Harold_Solbrig David_Booth EricP No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Found Date: 21 Mar 2017 Guessing minutes URL: http://www.w3.org/2017/03/21-hcls-minutes.html People with action items:[End of scribe.perl diagnostic output]