Semantic Web Health Care and Life Sciences Interest Group Teleconference -- 17 Jan 2017

Approval of Minutes

Minutes Approved! 2 abstain, 7 for, 0 against

Status of Shape Expressions (ShEx) -- EricP

<ericP> ShEx CG formed before xmass

<ericP> https://www.w3.org/community/shex/

eric: shex community group formed before christmas, 20 members, 5 implementations
... expect to ratify the RDF representation this week.
... Have implementation reports for 3 implementations. 800 validation tests, 400 syntax tests, and some structural tests
... Have a tutorial but needs more lovin. Spec is in pretty good shape, but if we ratify the RDF rep then it will need more text to define the @context and describe the parsing for recognizing the schema.
... People can now participate without being w3c members, because it is a community group.
... shex is a schema language for RDF. It's main value is sound semantics from people from University of Lille, and it has a couple other representations that it can round-trip through.
... purpose of other reps is to programmatically construct the schema language, such as in FHIR RDF pages on github, that shex is pretty printed, but can also be serialized by consuming a structure def and emitting a json structure for equiv schema in shex.
... Plan to do that and check it against the pretty printed syntax.

harold: in talking about abstract syntax trees, would be useful to create a FHIR logical model of the shex syntax tree. that would open up possibilities, also model-driven nicities about constructing classes. would allow shape expressionsn without going through the formal grammer.
... At the moment we emit strings.
... If we're in the business of building abstract syntaxes, then we could ...

grahame: Never occurred to me that you might want to do that.
... You might reverse engineer back to logical model then forward engineer to what you want . . . almost.

harold: The JSON is very json-centric. I earlier worked on an XML abstract syntax, and put effort into making it easy for people who read xml.

<ericP> JSON Grammar for the JSON grammar

harold: How close do they have to match?

grahame: If I were eric, i'd be very interested in an abstract syntax.

ken: We've done a little bit of models for resources

harold: we'd want to back off to UML (except that UML doesn't work that well) and shex works better.

(Eric shows the grammar of shexj at https://github.com/shexSpec/shexTest/blob/master/doc/ShExJ.jsg )

eric: I think we could wedge most of that into FHIR

grahame: If I turned that into a FHIR logical model, I think you'd lose some expressivity around the grammar, but you'd get much more knowledge.

harold: This is the AST for the grammar.

grahame: someone will start asking why shouldn't we produce JSGs for FHIR
... Is there a validator?

eric: Yes, one.

<ericP> JSG online validator

eric: here's an example of validating an address
... It has recursive shapes, etc.
... Do we want to express shexj in FHIR?

grahame: We'll come back to both JSG and ... want to continue discussing logical model for shex?

harold: Wanted to get it on people's thoughts.
... We have the BNF for the syntax, etc. I like having an API for a model, and JSG does not have API generators, and I wanted some tech that generates APIs.

dbooth: How best to follow up?

eric: let folks with skin in the game think about it a little first.
... Grahame has the shex validation working?

grahame: Using Jose's validator, and it's giving slightly different answers from Eric's, but it's almost there.

fhir:concept -- Harold

harold: This is a diag report in json, pulled from FHIR. It has a conclusion with a SNOMET CT coding.
... If we look at it in RDF, we have the RDF equiv, where we've added a fhir:concept assertion, because the URI for that snomed concept is not mechanically creatable from the code and system.
... Doing it in OWL reasoner is not the way to do it. It is done in a preprocessing step instead.
... The challenge: can I take this record, with snomed ct, and determine whether this pt has cancer?
... Start w a FHIR DiagnosticReport. Inserted owl:Ontology assertion.
... Then created RDF semantics, OWL ont. Should be the OWL ont generated by the FHIR build process, but I hand gen this one.
... Used a subset of snomed ct, but FACT++ is too slow for the whole of snomed.
... We used a tool to grab a subset of the OWL that we need.
... Then we wrote the query as an OWL class def.
... Defined hasDiagnosis, using a property chain.
... But with semantics of fhir:concept, the snomed concept must be an instance -- not a class.
... So I had write "fhir:concept [ a sct:553490112]" instead of sct:553490112
... But bnodes cause grief. So we created a new URI for the snomed concept: sct:SCT553490112 (instance) corresponding to sct:553490112 (class).

grahame: what about defining fhir:concept as a subProperty of rdf:type?

eric: OWL doesn't treat rdf:type as a regular property. It doesn't have axioms about it.

harold: instances of classes exist in snomed ct, but there are an infinite number of classes of classes. snomed cannot name them all.

grahame: But it's strange for the user to define those names.
... There's a conceptual misalignement between snomed and ont rep.
... I say that a patient is assigned a med of this type.

harold: This issue is not specific to snomed. It is about OWL.
... You have a class that represents tumors, and that's a set of all instances of tumors.
... When we reason about class person, joe is a person -- an instance.
... Here we're saying this diagnosis is an instance of tumor class.

grahame: Have you looked at the FHIR ont, at fhir.ttl?
... That holds all of the defs for the FHIR/RDF wire format.
... fhir:concept is missing though.

harold: Can we define fhir:concept as a subPropertyOf rdf:type?

eric: No

harold: That's the one property that is special to OWL, and you can define a subPropertyOf it.

grahame: THis feels like a terminiology problem. SHouldn't have to invent a name in the fhir space.
... The instance data user should not have to bridge between the instance and class of the terminology. That should be the business of the terminology.

harold: But for post-coordinated expressions, we cannot define a URI for every one of them.

grahame: If you are precoordinating then the terminology could provide them, but if you are postcoordinating then you could use this trick.

harold: The only issue is that this belongs in the snomed namespace?

eric: people have glossed over this in the past

dbooth: Weird to say that two patients have the exact same disease instance.

grahame: No, it is saying they have the same diagnosis.

eric: The thing that's pointing to me has a member of this class.
... snomed describes observations.

harold: no, it's anybody who writes OWL DL. They'll have to create instances of their classes.
... Need to engage Daniel, Steffan, Michael Wally

<scribe> ACTION: Harold to follow up on fhir:concept issue of instance vs class [recorded in http://www.w3.org/2017/01/17-hcls-minutes.html#action01]

<trackbot> Created ACTION-74 - Follow up on fhir:concept issue of instance vs class [on Harold Solbrig - due 2017-01-24].

harold: fhir:concept issue is around OWL.
... We've been slipping other things into RDF also, such as fhir:index.

Linked Data Profile

harold: Should we create a linked data profile? If I'm in XML and want to get to OWL I still need a URI.
... Should we define a FHIR profile that adds these features, such as fhir:concept, fhir:index?

eric: The main one is whether you can look at a reference and know its type.

grahame: In effect the RDF page is a profile on the content -- these are the things you're expected to do if you're using RDF.
... If you look at the things that are different in FHIR/RDF, they have different purposes. Some are in the turtle as a work-around for different serializations, and they appear in the JSON-LD in order to produce the same triples. treeRoot would otherwise be superfluous in JSON-LD.
... Then there's denormalizing the patient or ref type -- not the same as an extension. If you added info about the ref target, that would be unnatural in XML or JSON.
... We said that you might want to round-trip fhir:concept, but we didn't add the fhir ext (yet) to do that.

harold: simple way would be to define fhir extensions

<scribe> ACTION: Grahame to create an extension for fhir:concept and fhir:link type [recorded in http://www.w3.org/2017/01/17-hcls-minutes.html#action02]

<trackbot> Error finding 'Grahame'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.

grahame: FOAF has a document concept, and items can appear in a document. Should we use that instead of treeRoot?

harold: How would bundle relate to document?

grahame: Typically a bundle is a document.
... a Document cannot contain a Document.

<scribe> ACTION: DBooth to put this on agenda for a future call [recorded in http://www.w3.org/2017/01/17-hcls-minutes.html#action03]

<trackbot> Error finding 'DBooth'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.

Update of Linked Data Module pages

dbooth: Please review and provide suggestions/comments.

harold: would still like to discuss fhir:index sometime.

ADJOURNED

- DRAFT -

Semantic Web Health Care and Life Sciences Interest Group Teleconference

17 Jan 2017

Attendees

Contents

Approval of Minutes

Status of Shape Expressions (ShEx) -- EricP

fhir:concept -- Harold

Linked Data Profile

Update of Linked Data Module pages

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output