Meeting minutes
FHIR build process
david: The FHIR build process generates the entire spec and all of the examples, in XML, JSON and Turtle. Right now the Turtle is generated by Grahame's custom code, and it's pretty to look at -- very readable. If we also generate RDF via JSON-LD 1.1, then we can validate against what Grahame's code produces.
emily: What about prettifiying the JSON-LD generated RDF?
eric: Having multiple implementations gives more variety of tools and provides more sanity checking.
david: don't know how we could eaisily do prettifying.
eric: We'd have to write our own, esp to keep the same order of properties, but would end up being as complicated as the current generation in the build process.
emily: Does HAPI play a role in the build process today?
eric: I think the HAPI libraries used in the build process.
Issue 77 - How should extensions be represented in R5, both for primitive datatypes and for objects?
david: I pulled out modifier extensions to issue 93.
eric: I think we need to be aware of modifier ext in considering regular ext.
eric: for modifier, want to break the graph, but use the same structure for the extension.
… We have a coherent model, but not so user friendly. Mostly extensions are not used, except for confidence levels and saying the something is not present.
… For modifier ext, should change the name of the predicate.
… Goal in simplifying common use case, is that the JSON-LD we emit does not require post-processing. JSON-LD cannot invent extra levels of indirection. In the common case, if we got rid of the stand-off, we'd be able to do most of the work in JSON-LD without pre/post processors, until we hit extensions.
(Reviewed options in https://
david: Please review the options, suggest improvements or new ideas, and think about which options you like and which you don't like.
ADJOURNED