Meeting minutes
RDF Lists
jim: About to make PR for OWL API change
jim: Go through with that design, given the OWL issues?
jim: We could supply a SPARQL construct to turn RDF lists into something fully OWL compliant.
ACTION: Jim to make a SPARQL construct for converting RDF lists into something OWL compliant
We should not use fhir:value for non-hoisted scalar properties #104
jim: Tested rdf:value in Protege and it worked.
dbooth: It occurs to me that rdf:value might not solve the problem anyway, because we need something that would only be used as an OWL datatype property, but there is nothing in RDF to prevent rdf:value from being used as an object property.
jim: With owl:topDataProperty, every individual is related to every individual in the world.
… which might cause reasoner issues.
jim: Same problem (with rdf:value) exists with rdf:first .
dbooth: OWL is being our biggest problem!
jim: Should we pivot to being fully OWL compliant, or go for an RDF-oriented workflow.
dbooth: I don't think we want to alienate the OWL community.
gaurav: Lean toward being OWL compliant.
jim: Eric likes the brevity of Turtle lists. We could switch to a different list vocabulary.
… I lean toward being OWL valid.
rob: Lean toward OWL compliant -- a priority.
dbooth: Want to Eric's input on this too.
dbooth: R4 is OWL compliant, BTW.
How should modifier extensions be handled in R5? #93
Given that we only have bad options, I'm not sure it's worth try to make a change in R5?
rob: To me the problem is the same in FHIR JSON or XML. If you have an anti-prescription, you have to know not to do certain things.
gaurav: Fine to stay with R4 solution, option 0.
jim: Sounding like option 0 is the way to go.
dbooth: Also want to get Eric's input on this.
Concept IRIs
gaurav: Next step for us is to file a Jira issue for the changes we want.
ACTION: Gaurav to follow up on TSMG voting and Jira after the vote
ADJOURNED