Meeting minutes
Playground
emily: James is creating and adding versions of R5 examples.
FHIR Build
emily: Jim thinks he's now on track to finish by Feb 22.
ShEx validation
deepak: Some of the tests only work for primitive types -- not object comparison.
… Doesn't work for things like fhir:start should be less than fhir:end .
… Jose Labra said that's not implemented. Eric: Right.
deepak: Add test cases are passing except percentage value things. Wondering if we need to set context for each shape.
eric: Those are supplied at validation time.
deepak: To resolve those constraints, they're specified in the constraints -- nothing wrong with the shape. But it needs to know the values. IDK how to supply that.
eric: Where are they used? deepak: In the structure defs.
deepak: fails for 168 shapes.
eric: Ruled out: meta resources; field comparison (like start before end).
deepak: The ones we cannot map are in a list of unmapped functions.
eric: also ruled out: where validation requires external context. We can go to print with that. That's already 100x more than you get w XML Schema, and 1000x more than you get w JSON schema.
… If we're ambitious later, we can encode the ones we need as semantic actions.
… We can create a semantic action language for that, but not high priority. Highest priority now is negative tests: look at the code you're using to encode this as shex, and look for neg tests that give complete coverge of that.
… Having a small set of resources for those tests would be useful, even if they're not from FHIR.
… Putting FHIRPath constraints on those, and then putting neg tests on them, would be a good way to show we have coverage.
eric: Would be nice to say that we have both positive and negative tests.
deepak: I don't want test cases for unimplemented features yet.
eric: Is there a convention for disabled tests? To make it clear what's done and what's not done.
deepak: I learned how to set context vars, but need to know how they should be set.
eric: Who knows what those values should be?
deepak: If we look, maybe we can figure it out.
eric: My first guess is that it's used in the FHIR validator. But don't want to guess. Ask first.
eric: Trying to understand: shape extensions to get from resource to domain resource, etc. When you work down the tree and have a datatype, then a Quantity, then an Age. But Age is not like the others: all the others add elements, but Age only adds constraints.
… My guess is that we have some minor permissiveness in our schema: if you have a quentity and you allow any subtype of that quantity to validate as a quantity. But that might not be quite right, for things that are restrictions on quantities. They should be not be considered subtypes, because they're not substitutable. But not a show stopper, becuase w'e're still doing much better than other validation. "This shape uses the elements of another
shape, bu t is not substitutable".
dbooth: Sounds like it's going in the direction of modifier extensions: reusing the structure, but something has changed, so it is no longer substitutable.
eric: When you validate a BP w a quantity, and it conforms to an Age, you get back an Age of 110 instead of a Quanity of 110. Not a big deal, but still curious. Would be nice to reflect the intended semantics.
deepak: I'll do the min to get through the PR process.
… And I'll add pos and neg tests.
Ont generation
dbooth: Good progress on gen tportions of the he ont selectively. Needed next?
daniel: Need to know what the Turtle should look like.
modifier extension
eric: Tempted to say fhir:Obs fhir:modifierExtensionClass fhir:_Obs .
… and fhir:status fhir:modifierExtensionProperty fhir:_status
dbooth: Sounds reasonable to me.
… Will be rarely used, so it doesn't need to be terribly convenient.
eric: Long name seems unlikely to clash in the future.
AGREED use the properties EricP suggested.
Introductions
Phliippe: Working for AstraZeneca and Oxford U.
daniel: What would be the class of the modified Patient class?
dbooth: Underbar-patient: fhir:_Patient
OWL punning when shortening properties
dbooth: Propose Option 3: Change the class to start with an upper case: fhir:Code
daniel: Would case sensitivity cause problems?
dbooth: RDF is already case sensitive, so no new problem.
eric: Prefer Option 1: Use OWL punning. Have both a class fhir:code and a property fhir:code
philippe: This convention is followed by schema.org . Anyting starting w an upper case is a class, and anything starting w a lower case is a property.
eric: The primitive types would be an exception to that, becasue they chose lower case a while back.
… In logical models we have no control over whether they use upper or lower case.
… Want to be sure our code will continue to work on logical models.
dbooth: Wouldn't those be in a different namespace?
eric: Yes, but our code would probably do the wrong thing.
dbooth: Are there other practical issues, such as with SPARQL?
(lost EricP)
dbooth: Let's finish deciding this one on Thursday.
ADJOURNED