eric: When someone extends a
profile, and someone extends it in shex, how to represent
that?
... Two approaches: 1. not reusing the HL7 code. 2. loftier
goal express your profile, combine the shex with the hl7 shex
and work from there.
... We have hl7 profiles, such as for patient. You can import
them in your FHIR app. You import into your app and work with
it. That's the simple use of fhir.
rob: by "profile", you mean structure def?
eric: Yes.
... Everythign that is falsifiable: core stuff -- structure
def, value sets. If you follow fhir interop guidance and use
profiles and make more restrictions, then you profile down for
more precision. There would be a shex for that also. What is
the relationship between that and the core shex for the
resources?
... One possibility: no relationship. When you build from the
profile, you import the base and add more restrictions.
rob: forge tools
eric: Take the forge tools,
restrict them down, add constraints. When you do that you
import a half gig of resource defs, and you emit all the
original plus some your extra restrictions.
... There are two forms: differential and snapshot (which has
everything).
rob: Snapshot is optional. Some
tools generate it.
... Harold's tool works with the snapshots, right?
harold: right.
... It is intertwined with the FHIR commital build. Don't know
how much can live on its own.
... Trying to get the RDF code into HAPI server, but we also
need to get shex generation into the things that generate
profiles.
ISSUE: Need to get shex genersation into the tools that generate profiles
eric: in theory, if someone makes a profile they could use harold's code.
harold: it uses the shex template
prior to the official AST model (or whatever it is called). At
some point it should be switched to use the AST model.
... Python implementation generates pretty readable output
not.
eric: Minimum would be to capture
the profile restrictions in the shex. Nicer would be that the
increments that someone puts into the profile could be
expressed directly in shex to validate those resources in
shex.
... If the shex worked with incremental, then we take one step
toward reusing core resources when profiling.
... Other thing needed for that, is that all the reuse stuff
that is implicit in the ability a structure def, the same
semantics needs to be available in shex.
... e.g., when you extend a profile def, you implicitly import
it and meet the combined constraints.
... So to reuse the core resource shex, then the incremental
shex needs to have the same functionality, to import and
extend/restrict.
david: what is needed to accomplish that?
eric: Harold and others and I had
a long chat a few weeks ago. Arrived at something that would
allow shex profiles that exactly capture semantics of fhir
structure defs.
... Right harold?
harold: Yes, but need to prove it. That's one reason why I foughjt so hard against extensions that invalidate the core. Anything valid in the profile should be valid in the base.
eric: Not sure that is true.
Slicing.
... Max cardinality could be violated.
rob: You cannot do that with just
the profile, but you can with an extension.
... No, in FHIR extensions are automatically valid, though it
might not know what to do with the extension.
eric: What if I said there are two components, then give it three?
rob: The extension could add a third, so it does not collide with the base.
eric: I thought that with slicing, you could extend the base.
rob: The extension does not change the base.
eric: if I have a slice on an Observation component, a BloodPressure resource, with exactly two components.
rob: The base allows as many
components as you want. A profile might limit it to two
components.
... Profile of a profile?
eric: Want to break down two components into pieces.
rob: Depends on how you set up your slicing. If you restrict to max components 2, then you are stuck with that down the chain. But if you do slices, then downstream you can add whatever yuou want.
eric: If you build a structure
def that has a slice on a component with max cardinality 2,
then you are stuck. But if you say you have at least 2
components, then you can add more.
... That means that whenver we write slices, we need to think
hard about how to write them, allowing for more components.
harold: The premise i run under is that in the FHIR constraint world, things are monotonic. Something must conform to the base. Once you get to the differential notation that is essential.
david: Harold expressed the monotonicity well: anything valid to the profile must be valid to the base.
harold: Patient has a bunch of
values and a bunch of tagged elements. Only modifier extension
violate that.
... In extension, you can restrict the cardinality and types of
the base, but you cannot take a required field and make it
optional.
eric: Then when we do anything
with slicing, anytime we're turning fhir into shex, and we see
a slice, we have to use a shex construct to say extra, and
whatver the slice says, to allow for additional
component.
... BP profile on Observation, and it's expecting systolic and
diastolic, and I give it one with an extra component, so it
won't reject it.
rob: If you do open slicing then you can do that. With closed slicing you cannot.
eric: that's different than putting a max cardinalityu on?
harold: Correct.
eric: whenever you an openn slice on component, and I'm expecting two components, if you give me a resource that has 3 components and 2 are systolic and diastolic, I would reject it?
rob: correct
... If you had set in your systolic slice a max cardinality 1,
and you gave it 2, it would be rejected.
eric: The way to express that in
shex is to allow extra components that do not match systolic or
distolic. You do that with EXTRA in shex -- the extras cannot
match the ones you specified.
... Any gotchas?
rob: I'm running into stuff with discriminators. Not supported in the tooling. But basic rules are pretty solid.
eric: shex does not have a notion
of discriminators. Discriminators allow a code to determine
which rules are used.
... If you have a discriminator on component.type, and it is
systolic with a foo property, the value must be a particular
data type.
rob: Java validators tools are available for this.
harold: In xml, a lot is done in
schematron, but not getting much attention anymore. Validation
is in server code.
... Should pay attention to valuesets soon. Tooling is getting
rigorous on that, looking for valid LOINC codes.
... The extensible fields and big valuesets can't be done by
enumerating values. Need to link with an API for external
validation.
... FHIR terminology services is moving along. Another
possibility is just to have things masquerade as shex
validators that determine through riules whther a URI is in a
list. Need a clean separation between shex validatoin and code
validation services.
eric: Terminology server would be a subset of shex validator
ADJOURNED
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/validation services/code validation services/ Succeeded: s/would a/would be a/ Present: EricP Harold_Solbrig Rob_Hausam David_Booth No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]