See also: IRC log
AGREED: Per zulip discussion, all codings are true: https://github.com/w3c/hcls-fhir-rdf/issues/31
eric: We discussed this last
week. Decided on different levels of validation.
... For example you could have a reference that is not
resolvable or resolves to a JPEG. That would be valid in FHIR,
but in the Sem Web we cannot do much with that.
dbooth: And we realized that the
FHIR profile mechanism could be used to trigger additional
validation constraints.
... we decided to have a minimal level of validation that
strictly aligns with FHIR rules, plus allow additional
validation via additional profiles.
An example: http://build.fhir.org/allergyintolerance-example.ttl.html
It does not indicate the type:
[[
fhir: AllergyIntolerance.patient
[
... link <http://hl7.org/fhir/Patient/example>;
... Reference.reference [ fhir:value "Patient/example" ]
];
]]
eric: If you are just converting FHIR JSON or XML to RDF then it might not know what type to put on the type arc.
dbooth: the type is always there for the top level resource (the root), but since it cannot always be determined for a reference (from the FHIR XML or JSON) then we cannot require it always.
AGREED: A type arc is not required on a reference target, but may be there. However if you wish to validate the reference target (with higher-bar validation) then the type arc on the reference target would be required.
rob: we are making progress getting terminology publishers to use URIs, but we have not tried to get them to use a common template.
eric: We could try to use a
template for the ones that FHIR publishes.
... We could offer to host terminologies for those who do not
want to host their own.
AGREED: Too difficult to get all terminology publishers to use the same template, and no benefit unless they all do.
eric: Do the examples indicate the version?
dbooth: No version indicated in the AllergyIntolerance example http://build.fhir.org/allergyintolerance-example.json.html
http://build.fhir.org/capabilitystatement.html
dbooth: it has a fhirVersion to indicate the version the system uses: http://build.fhir.org/capabilitystatement-definitions.html#CapabilityStatement.fhirVersion
eric: If you get data from
different sources, you are likely to have different FHIR
versions.
... If they are tagged with their FHIR version, what am I
supposed to do? Transform them in some way?
rob: Some will be valid, some not.
eric: If you are serving across
REST, then anything you send should conform to the version you
say it is.
... So if your source data is a different version, then you'll
need to transform it in some way. Or in some cases you will not
be able to serve that data, such as if a datum is split into
two in a later version.
dbooth: I don't think the splitting case will come up, because there is attention to not re-defining terms in a harmful way. Instead, a new term should be created. FHIR is more about how the data is packaged.
eric: But models evolve.
dbooth: Good point. So in some cases, a particular FHIR server might not be able to serve some old data.
eric: We could say that one
should not reuse the same predicate for different things over
time.
... If a MedicationDispense.x is defined with one meeting, and
another year the definition changed, then we would want to
catch that at the RDF level and give it a new and unambiguous
name.
... The governance process would have to cover that.
... I.e., we should never define ambiguous predicates (across
versions)
AGREED: We will never define a property to have different meanings across versions. If a definition does change across versions, then we will flag it for a new predicate. (And it would be a bug if we don't.)
rob: IDK what the naming convention would be in that case.
dbooth: I hope it doesn't happen. :)
ADJOURNED
<trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference
<trackbot> Date: 22 November 2016
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Present: Rob_Hausam David_Booth EricP Found Date: 22 Nov 2016 Guessing minutes URL: http://www.w3.org/2016/11/22-hcls-minutes.html People with action items:[End of scribe.perl diagnostic output]