Meeting minutes
Issue 77 and 93
david: We need a champion for each issue, to put proposed options on the table, with examples.
https://
eric: Want to look at modifierExtension in conjunction with this, to keep them coordinated.
https://
david: Hard to find good modifierExtension examples in the spec.
david: option 0 is non-monotonic in RDF.
eric: Couple of kinds of extension we need to consider: 1. ext on element that would hide it if it is a modifier; 2. ext on property that would hide it if it is a modifier.
… Grahame didn't want to hide something like a status, because it would not be displayed on the screen, and you get liability if you don't display stuff. I think that's a wrong call, because people will see it without realizing that it is modified.
… I think RDF can depart from the JSON.
david: i think it should be hidden in the RDF.
eric: If this were an Observation example, it would be more evident.
… Could put it under a differnet name, like an underbar version.
Action: Eric to write up option 2 for modifierExtensions
issue 69: Shorten FHIR property names or use superproperties?
https://
eric: github repo: https://
eric: Analyzed the property names used in each FHIR resource, and its definition, and compared them to see which are the same.
eric: this is not just limited to FHIR resources. Might be able to make it easier. Maybe make it use the same 'status' property across resources?
… But we don't have do do that inside data structures.
… E.g., fhir:Observation.status --> fhir:status , but fhir:CodeableConcept.coding would stay the same.
brad: By shortening the name, would we be at risk of not knowing which set of values are permitted?
eric: No, because the validation is context based. E.g., in the OWL pizza tutorial, you describe it in terms of 'toppings' instead of 'pizzaToppings' so that you can reuse that property for ice cream toppings.
brad: so you shorten the property names when they're at the leaf level?
eric: Not because of the nesting, but because it is a different datatype.
david: It's not derived from Element, it's derived from a datatype.
eric: But in principle, we could also shorten the datatype properties.
brad: If you shorten too much, things become ambiguous.
eric: There isn't technically any ambiguity, becuase of the context. The bigger danger is that we could end up with two islands of semantics. Such as 'title' as an honorific or as the kind of a procedure.
brad: I'm currently running SPARQL queries that are 700-1000 lines. It works, but you have to very careful.
eric: The good case is when you query for status=pending, and you get them all. Bad is if you query for all titles and get both honorifics and procedures.
eric: I also generated the inverse analysis: for each definition, what properties use that same definition?
david: Options going forward? Do all of them vs cherry picking?
david: Could also offer both short and long names, with short names be superproperties of long names.
eric: Goal is to promote adoption. making it more complex will make that a harder sell -- not aligned with our marketing objective.
Action: Eric to work up options for issue 69
ADJOURNED