See also: IRC log
<trackbot> Date: 10 June 2015
<ericP> +1https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues
https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues
https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Issues
tony: really the issue is why there is an extra blank node with an enclosed 'value' property
eric: I think the motivation on
datatypes is that there may be an extension attached.
... Would anyone ever put an extension on a datatype and expect
others to understand it?
harold: This sounds like RIM version 3. We're getting close to making this non-useful in RDF.
eric: I'm surprised there was no pushback in the JSON serialization
https://hl7-fhir.github.io/json.html
harold: We need the equiv of an underscore predicate
See slide 27: http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf
eric: For modifying extensions,
in RDF we changed the name so that it will not accidentally
show up in a query.
... But they didn't want to have two different names when
trying to display things.
... If you say that modifying extensions must rename the
property, then the display system won't know how to display
it.
... I'm concerned that any modifying extension will break
things.
tony: XML techniques for disambiguation cannot be used either (like namespace)
See slide 27: http://dbooth.org/2015/fhir/json-ld/fhir-in-json-ld.pdf
:john :dob "2003-12-12" .
:john :_dob _foo .
where _foo is the extension stuff.
And somewhere else there would have to be a statement like this:
:dob fhir:hasExtension :_dob .
eric: If it were not a literal
datatype property, then we could just add predicates.
... For literals, we could do the same thing by adding an
intervening blank node.
... But that is less palatable than directly having the
value.
... we could call the value :code and the extension :_code
.
# With extensions:
fhir: CodeableConcept.coding [
a fhir:Coding;
fhir: Coding.system <http://snomed.info/sct>;
... Coding._system [ :mySysExtension "foo" ] ;
... Coding.code "66493003"^^fhir:code;
... Coding._code [ :myCodeExtension "bar" ] ;
];
<Zakim> hsolbrig, you wanted to say that there still has to be an explicit assertion of the :code and :_code relationship (:_code ex:extends :code)
<Zakim> dbooth, you wanted to say that we can make different, related URIs for the value and the extension data and to say we have multiple issues here: 1. how to handle modifying
# With extensions:
fhir: CodeableConcept.coding [
a fhir:Coding;
fhir: Coding.system <http://snomed.info/sct>;
... Coding._system [ myext:moreSysInfo "foo" ] ;
... Coding.code "66493003"^^fhir:code;
... Coding._code [ myext:moreCodeInfo "bar" ] ;
];
and in an ontology:
fhir: Coding.code fhir:hasExtensionProperty fhir:Coding._code
# SPARQL to select all code extensions:
select * {
?something a fhir:Coding ;
fhir: Coding._code ?ext .
}
eric: How often are IDs and other things attached to these?
lloyd: Infrequently. usually to attach narrative.
eric: I would expect IDs to be most often used on complex types, rather than on simple datatypes.
lloyd: Not necessarily. Might point to display name.
eric: Want good practice to be terse, and bad practice still accommodated.
lloyd: Wide variety of reasons
for putting IDs on things.
... IDs are not commonly used, but when used are usually for
sophisticated things.
eric: Let's try going with the underbar/JSON style.
# SPARQL to select all code extensions:
select * {
?something a fhir:Coding ;
fhir: Coding.code ?code ;
... Coding.code fhir:hasExtensionProperty ?underbar ;
... Coding._code ?ext .
}
trying again:
# SPARQL to select all code extensions:
select * {
?something a fhir:Coding ;
fhir: Coding.code ?code ;
... Coding.code fhir:hasExtensionProperty ?underbar ;
?underbar ?ext .
}
# SPARQL to select all code extensions:
select * {
?something a fhir:Coding ;
fhir: Coding.code ?code ;
... Coding.code fhir:hasExtensionProperty ?underbar ;
?underbar ?ext .
}
lloyd: This would mean two
different ways of finding extensions. Same as in JSON.
... But you're typically not doing queries as much in
JSON.
... Possible to do a property chain?
... Would it be possible to have the same query structure for
both datatype extensions and object extensions?
eric: we could also decide what is needed for serialization vs what is inferred by an ont.
With an extra bnode, queries would say '?foo fhir:Coding.code / fhir:value ?value' instead of '?foo fhir:Coding.code ?value'
Eric: Could have fhir:Coding.code be both a datatype property and a datatype property.
dbooth: That would force the query to use a FILTER clause to distinguish between an object value and a literal value.
<ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use
lloyd: Saving an extra node seems
insignificant. It feels like the underbar approach interferes
with the elegance of query.
... Will it feel more natural to have the extra bnode and value
property, or the underbar approach?
... I suspect the extra bnode would be more natural to RDF
people.
eric: Lots of people will ask why the extra bnode is there.
lloyd: And they ask that in XML,
and we say that it is because of extensions, and they they move
on.
... I'm less concerned with questions that people saying 'that
is totally unnatural'.
... Underbar will be harder for people to wrap their heads
around.
tony: extra blank node aligns better with FHIR
<Zakim> dbooth, you wanted to agree with lloyd
lloyd: Not a violation of our approach, because JSON does that, but from a class model perspective it should be there in RDF because that's what's going on. RDF should better reflect the class semantics than JSON.
<rhausam_> +q
rob: Agree with blank node approach.
eric: Net pain seems lower with
underbar approach, but I understand the other arguments
expressed.
... Also cannot reused things from RIM.
lloyd: My leaning on that, is that when we get into ORIM alignment, I'm happy to change ORIM to align with FHIR.
eric: If these cases are rare,
then there will be more pain with the blank node
approach.
... Also, need to handle modifying extensions.
AGREED: Go ahead with blank node and 'value' property approach
<ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use
<ericP> http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR#Use
ADJOURNED
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 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: Tony_Mallia EricP_Harold_Solbrig Lloyd_McKenzie Rob_Hausam Found Date: 10 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/10-hcls-minutes.html People with action items:[End of scribe.perl diagnostic output]