See also: IRC log
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.
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
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
Notes from earlier today: http://www.w3.org/2016/06/14-hcls-minutes.html
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[End of scribe.perl diagnostic output]