ShEx Validation of FHIR RDF

harold: we have an incomplete steady state. All of the core FHIR examples validate in ShEx. We have a known set of things that we need to do, such as minValue, maxValue. And some bigger issues to work through.
... There are three resource bundling mechanisms, by reference and by value.
... Grahame thinks the shex should included validating everything that you could put inside.
... For the moment we do not validate the referents. Discussion will continue.
... I propose two modes: complete shex, and a mode that only validates the non-referents.
... The other thing is extensions. At the moment we're faithful with the FHIR approach. Josh had proposed representing extensions as first-class predicates, and there's a huge value in doing that.
... I'll propose a hybrid to carry them both as tagged values, to make it easy to roundtrip. But also add a URI as a predicate into the RDF.
... That's important because as soon as we add extensions, closed and complete validation becomes more of an issue.
... Slicing does not work right now. If you give it slicing it generates invalid shex.
... The most difficult one is the declaration of the discriminator. Even if it is one attribute, often the discriminant is a coding that has multiple properties. That will be the biggest challenge in shex.

eric: The discriminator allows you to write a simple verifier.

harold: The simplest form is one with only the discriminator.

eric: That will require 'unique' in shex.

harold: I did a rough review of the constraints in the FHIR core -- 400 constraints. While the patterns were not consistent enough to characterize, the majority were existential combinations.
... Diminishing returns for the extension model.
... I looked for comparisons with paths on both sides, and there were only about 5 of them. Not sure if they're worth doing.
... Much of our funding comes from someone in the academic world, and papers are important to them. We wrote a paper on this.
... Reviews and coauthors welcomed.

eric: Most of the shapes can now be easily captured.

harold: If you look at the lastest FHIR distro, they have an RDF template language that is consistent with the XML and JSON.
... Propose using shex, with added comments, instead of this made-up pseudo-Turtle

dbooth: With grahame we discussed possibly having both the pseudo-Turtle and shex.

harold: We'll try the shex, and then we can do an A-B comparison.

dbooth: An example is in the structure definition of AllergyIntolerance: https://hl7-fhir.github.io/allergyintolerance.html

harold: Also proposing a REST service for the validator.

dbooth: You can put it on yosemiteproject.org site.
... How do we know if we're done? i.e., covered all of FHIR?

eric: we can either do formal coverage analysis, or we can hope that grahame notifies us if he adds anything.

harold: we have a pretty good list in the paper.

dbooth: We should use that as our punch list.

<scribe> ACTION: Harold to provide the list of remaining items that need to be implemented in FHIR RDF [recorded in http://www.w3.org/2016/06/14-hcls-minutes.html#action01]

<trackbot> Created ACTION-60 - Provide the list of remaining items that need to be implemented in fhir rdf [on Harold Solbrig - due 2016-06-21].

harold: Also need to verify round tripping.
... That's indirectly in grahame's court.
... There are skeletons for round tripping.

dbooth: I wonder if michael would be willing to look at that.

<scribe> ACTION: Dbooth to ask Michael about implementing the round tripping. [recorded in http://www.w3.org/2016/06/14-hcls-minutes.html#action02]

<trackbot> Created ACTION-61 - Ask michael about implementing the round tripping. [on David Booth - due 2016-06-21].

harold: Also need failing tests.

dbooth: Grahame already has some of those for XML and JSON. We should mimic those for RDF. But we may want more also.

eric: Grahame said he would look into that.

<scribe> ACTION: Harold to prepare slicing and extension examples for discussion next week [recorded in http://www.w3.org/2016/06/14-hcls-minutes.html#action03]

<trackbot> Created ACTION-62 - Prepare slicing and extension examples for discussion next week [on Harold Solbrig - due 2016-06-21].

harold: A selling point of RDF: there are 4-5 different modeling paradigms in FHIR. Some are more obvious than others. Converting it to RDF and shex gives you a uniform representation and a single constraint model.

Agenda planning

marc: We should brainstorm on a call

dbooth: want to include renato ianella and grahame and marc on discussiong FHIR on schema.org

<scribe> ACTION: Dbooth to contact Renato, grahame and marc about joining a call on fhir and schema.org [recorded in http://www.w3.org/2016/06/14-hcls-minutes.html#action04]

<trackbot> Created ACTION-63 - Contact renato, grahame and marc about joining a call on fhir and schema.org [on David Booth - due 2016-06-21].

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

What should the type of fhir:link target be in the ShEx? Issue #30

eric: We could move the rdf:type arc down to the actual (referenced) patient
... That does not enable full validation of the referent. But it avoids using a different type arc.

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

<ericP2> <Obs1> a fhir:Observation; fhir: Observation.performer [ link <http://hl7.org/fhir/Practitioner/f005>; Reference.reference [ fhir:value "Practitioner/f005" ] ];

here it is again, hopefully a little more readable:

<Obs1> a fhir:Observation;

fhir: Observation.performer [

link <http://hl7.org/fhir/Practitioner/f005>;

Reference.reference [

fhir: value "Practitioner/f005" ] ];

<ericP2> damn, i was being so elequent

<ericP2> type arc on referrent: <Obs1> a fhir:Observation; fhir: Observation.performer [ link <http://hl7.org/fhir/Practitioner/f005>; Reference.reference [ fhir:value "Practitioner/f005" ] ]; <http://hl7.org/fhir/Practitioner/f005> a fhir:Practitioner .

<ericP2> type arc on referrence: <Obs1> a fhir:Observation; fhir: Observation.performer [ link <http://hl7.org/fhir/Practitioner/f005>; Reference.reference [ fhir:value "Practitioner/f005" ] ; a fhir:PractitionerReference .];

here is the second example again:

type arc on referrent:

<Obs1> a fhir:Observation;

fhir: Observation.performer [

link <http://hl7.org/fhir/Practitioner/f005>;

Reference.reference [

fhir: value "Practitioner/f005" ] ];

<http://hl7.org/fhir/Practitioner/f005> a fhir:Practitioner .

the third example again:

type arc on referrence:

<Obs1> a fhir:Observation;

fhir: Observation.performer [

link <http://hl7.org/fhir/Practitioner/f005>;

Reference.reference [ fhir:value "Practitioner/f005" ] ;

a fhir:PractitionerReference .];

ADJOURNED

trackbot, start meeting

<trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference

<trackbot> Date: 14 June 2016

============== 5pm Call ===============

Notes from earlier today: http://www.w3.org/2016/06/14-hcls-minutes.html

ShEx Validation Status

grahame: Got shex working in the build, then tried to validate with fhir.shex, got some validation errors, and i could not figure out how to tell it which graph to connect to the starting point.

eric: Could a parameter be passed indicating where to start?

grahame: Yes, but maybe not always.
... In a stream you'd have to look into the stream and figure out where it is. I guess you could always look at the RDf triples first, to find the entry point.

eric: You're mostly using type validation in XML Schema, but you use element validation for the resource roots.
... Because element validation is very simple, because you know what the root element is.

dbooth: We have treeRoot in FHIR RDF

grahame: we could have shex be told what node to validate.
... but my API says "here's a graph and here's the shex. go validate" and it wouldn't know what starting node to use.

eric: my temptation is to leave it to the caller to decide how to tell shex the starting node.

grahame: v3 features are not widely supported. Even if we can get them through the standards process, they probably won't be adopted.
... So I'm wary of saying "let's do this cool fhir". But the "where do i start" is not just a shex problem.

eric: For FHIR RDF, we coudl have it look for treeRoot, then pick up the type from that.

grahame: we could put that in the spec, but i suspect that's not the last you've heard of the problem.

<ericP> we want something more specific than simple validation as a Resource; we want something more like a LeafResource, which is a disjunction of ~140 resources

dbooth: How about a shex execution mode that allows a set of types to be specified, and it will validate any instances that are found?

ADJOURNED

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Status/ShEx Validation Status/
No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth
Present: EricP Chad_Albert Rick_Kiefer Amol Shahram Harold_Solbrig Brian_Pech David_Booth Sajjad_Hussain Marc_T Grahame_Grieve Rob_Hausam
Found Date: 14 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/14-hcls-minutes.html
People with action items: dbooth harold