Meeting minutes
Issue 120
ericP: Some FHIR resources have a "link" property, which causes shex problems for the fhir:link property that we added
… I propose we rename our fhir:link to fhir:n
dbooth: How much will this disturb existing FHIR RDF users?
ericP: In convo w Dutch folks who were using FHIR RDF R4, they never adopted R5.
dbooth: Also concerned that FIHR folks might use n as a property name.
ericP: We could also put fhir:v and fhir:n in a separate namespace.
dbooth: Sounds annoying.
dbooth: Could also use fhir:l (letter ell)
ericP: Intending to update HAPI and shex tooling, to pull whatever name we decide upon, from one source.
ericP: Would be good to ask Grahame also.
dbooth: We might want to use fhir:n for some other purpose in the future, such as if we do something else with lists in the future.
… I'm leaning toward fhir:l
AGREED: Change from fhir:link to fhir:l
ACTION: Jim to change fhir:link to fhir:l in HAPI
jim: Havne't yet looked at handling those relative URIs in HAPI
… Also wondering about the ones that are fragment identifiers.
dbooth: they are also relative URIs
dbooth: Looks to me like the bnode on line 26 in the example Jim is showing, needs to be a <#1111> relative URI instead of a bnode.
jim: Looking at this example: https://
ACTION: EricP to draft a proposed solution in the issue.
ADJOURNED