Semantic Web Health Care and Life Sciences Interest Group Teleconference

23 Feb 2016

See also: IRC log


Dale_Nelson, David_Booth, EricP, Julie_M, Rob_Hausam, Sajjad_Hussain, Thomas_Lukasik, Tony_Mallia, 5PM:_David_Booth, Grahame_Grieve, Lloyd_McKenzie
David Booth and Dale Nelson


Deliverables documents


Rob: Working on section 4. Hopefully finish this afternoon.

Approval of minutes















Motion to approve minute as a block.

Seconded by Tony.

Minutes approved unanimously.

Reconsider fhir:index to start at 0 instead of 1


Motion to change fhir:index to start at 0 instead of 1 (to be consistent with other parts of FHIR).

Seconded by Tony

RESOLUTION: change fhir:index to start at 0 instead of 1 (to be consistent with other parts of FHIR)

Revisiting fhir:ConceptBase and fhir:CodingBase


david: difficult to explain the fhir:ConceptBase and fhir:CodingBase way of representing

fhir: Code, fhir:Coding and fhir:CodeableConcept, using fhir:ConceptBase and fhir:CodingBase

tony: fundamental problem is that fhir:code has different rules and behavior when it appears inside a fhir:coding
... a fhir:coding.code is distinct from fhir:code

rob: agreed. should create fhir:coding.code as a separate type

tony: that would be the minimal problem to fix

dbooth: we normally use fully qualified names, reflecting the nesting structure, so fhir:coding.code would make sense.

tony: I propose we do that as a compromise: split code into two properties: fhir:code and fhir:coding.code
... In the rest of sec 4 we're applying types to the individuals.

<scribe> ACTION: Tony to try using fhir:code and fhir:coding.code in the ontology [recorded in http://www.w3.org/2016/02/23-hcls-minutes.html#action01]

<trackbot> Error finding 'Tony'. You can review and register nicknames at <http://www.w3.org/2014/HCLS/track/users>.

Should the rdf:types be explicit on the wire or inferred?


tony: Not sure it is a global decision. The root element must have its type.
... The XML and JSON are strange. The XML looks like a substitution group, but it is not in the schema. There is an unenforced rule that the tag name is the type name. But in RDF we must have the type of the top level resource.
... The root type must be declared. The rest could be dropped, but are implied by the ontology from the range declarations.

sajjad: I think the subjects of RDF triples should have types, but the objects do not need types.
... We cannot enforce the object part of the triple to have types.

tony: If we have qualified the properties with the subject class (fhir:classProperty) then the range statement would indicate the subject type.

sajjad: But when the domain is a union you want to make sure that the subject part of the triple is the particular type.
... Also there can be restrictions on properties.

dbooth: Do we have union types that apply to a subject part of the triple?

tony: i don't think so.
... We'll have fhir:Observation.status so the domain is unique

sajjad: we cannot force the object part of the triple to be typed, because sometimes it will be a union

tony: We have that for datatypes
... We have not qualified fhir:value because it appears in so many places

sajjad: The ranges may also have intersections

tony: I haven't seen that yet.

eric: That exists in the structure definitions
... If I typo a URL then I dont' get any error from OWL, but if I typo a literal I get an error from OWL

sajjad: for round tripping back to XML it is best to have everythign typed. Also for a union range.

eric: Union only appears on one place: references
... The structure definintions expressivity requires properties to be renamed to avoid ambiguity.

dbooth: Is it enough to rely on using a reasoner to determine the types of subjects (other than the root) from the ontology, or should the types be explicit on the wire.

eric: I don't think we need to include explicit types on the subjects (except for the root)

RESOLUTION: The FHIR RDF should explicit indicate the rdf:type of the root element, but not other subject.

5pm call

tony cannot join

dbooth: we'll see who is able to join at 5pm ET.


<trackbot> Meeting: Semantic Web Health Care and Life Sciences Interest Group Teleconference

<trackbot> Date: 23 February 2016

----------- 5PM CALL ------------


<scribe> Topic: Revisiting fhir:ConceptBase and fhir:CodingBase

lloyd: The challenge is that you have lots of external vocabs and you need to link them into FHIR.
... You need a binding concept such that when a code is seen, a particular concept applies.
... We can have SNOMED symbols, and where the SNOMED concept applies differs for each of Code, Coding and CodeableConcept
... We end up with a concept represented by a code symbol living at different levels. That's problematic, and I don't knwo how to get around it.

Example from lloyd:





      <system value="http://snomed.info/sct"/>

      <code value="123456789"/>






    <system value="http://snomed.info/sct"/>

    <code value="123456789"/>




  <pretendCode value="123456789"/>**



lloyd: What happens if we want to add another attribute that also wants to draw from SNOMED?
... sometimes the concept shows up in one place, sometimes in another, sometimes in a third place
... We have a snomed ont that is defined externally -- we don't control it.
... The binding ont will have to say 'if you have a CodeableConcept with a system of bar and a code of foo, then that implies that the Codeable concept has a concept ID'
... And you do that for every concept.
... Not pleasant, but automatable.
... Pretty manageable for most code systems.
... But if we need to set distinct rules for every single datatype, every single terminology, that becomes untenable.

grahame: There's only three patterns here. Why is it hard to deal with them?

lloyd: The three patterns live all over the place.

grahame: I don't think the case of putting a SNOMED code inside a code will be an issue.
... For every code element, you'll need custom logic. No way around it. You don't know what the system is.

lloyd: We know what the bindings are. They allow us to infer the code system.
... We can infer the system.

grahame: How can you do that, but not handle the other two patterns?

lloyd: OWL is good at the other two, but not that one.
... The concept lives at condition.code

eric: We could push harder on the example, but there will be some use cases where we want to have an OWL inference that allows us to say someone has sniffles
... lloyd's concern is that if we need to handle kinds of diseases including the ways they can show up, then we multiply the cases.

lloyd: Pursue it as two different resources, each with three attributes: codeableConcept, Coding, code; and all 6 have valueset from the same code system. Figure out the binding ontology that links FHIR structures to code system ont.
... It's possible to have codes from code systems that are either directly bound or have identify mapping, with Code, CodeableConcept or Coding.
... We need to design the ont to handle all of them.

grahame: Counter proposal: I've implemented ConceptBase twice (once for each ref impl). Hope to gen RDF tomorrow. I think I got ConceptBase wrong the first time around. The problem that lloyd's having is that he wants the concepts to live at the binding level.
... But the concepts arise with the system+code pair.
... So the RDF representation for the underlying concepts for CoceableConcept, Coding and Code should make life simpler for all.
... You can also add a statement to the ont, and we can discuss where that goes as well as restructuring the coding structure.
... That might make the process of determining the ont link more difficult.

lloyd: The concept for condition.code lives at condition.code, not condition.code.coding. If I have 5 codings present, it applies to all.

grahame: Each of the codings establishes the semantic link, so each establishes the concept.

lloyd: No, if you have 5 codings present, you don't have 5 indep concepts, you have 1 that is a specialization of all 5.

grahame: you have 5 that are concept links in their own right, plus one one combined concept.
... It's work marking up each one with its own concept, plus one for the combined concept.

lloyd: If we declare that the concept lives at all three levels (code, coding, codeableConcept) then ...
... the problem is we can't have the concept not try to live at all three levels simultaneously.

thomas: is this all just related to inference?

lloyd: yes.
... Suppose we create a linking ont that says the concept lives at all three levels, and see what happens in OWL
... My concern: I want to see how this will work where you don't declare the concepts -- all you have is the instance, the binding declaration, the SNOMED ont and the binding ont. I.e., no preprocessing done to link in the specific concept URL, because in general we cannot do that, because there will be so many code systems.

dbooth: Specific examples that should be tried?

lloyd: What I described covers my concerns.

<scribe> ACTION: David to point tony to this discussion so that he can try the cases [recorded in http://www.w3.org/2016/02/23-hcls-minutes.html#action02]

<trackbot> 'David' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., dbooth, dderour, dhansen2, dnewman, dshotton).

Build process

grahame: I'll add turtle generation to the build, along with JSON and XML. Existing turtle is not fully in line with your latest design.

<ericP> http://www.w3.org/2016/FHIR-tutorial/Constellations?logical -> Constellations doc

Our deliverables: http://wiki.hl7.org/index.php?title=RDF_for_Semantic_Interoperability#Deliverables_and_Editors

Constellations doc (describes FHIR RDF)


dbooth: suggest using only two columns

grahame: I have types on all things.

eric: Not needed except on root element

grahame: Need fhir:value under fhir:Reference.reference
... Is fhir:value viable, instead of fhir:Reference.reference.value?

eric: Things like fhir:value are generic properties, with no constraints on their object type. Their semantics are entirely contextual.

dbooth: If fhir:value is always a literal value, should be fine for OWL I think


<scribe> Chair: David Booth

Summary of Action Items

[NEW] ACTION: David to point tony to this discussion so that he can try the cases [recorded in http://www.w3.org/2016/02/23-hcls-minutes.html#action02]
[NEW] ACTION: Tony to try using fhir:code and fhir:coding.code in the ontology [recorded in http://www.w3.org/2016/02/23-hcls-minutes.html#action01]

Summary of Resolutions

  1. change fhir:index to start at 0 instead of 1 (to be consistent with other parts of FHIR)
  2. The FHIR RDF should explicit indicate the rdf:type of the root element, but not other subject.
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/23 23:07:49 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/What/lloyd: What/
No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth
Present: Dale_Nelson David_Booth EricP Julie_M Rob_Hausam Sajjad_Hussain Thomas_Lukasik Tony_Mallia 5PM:_David_Booth Grahame_Grieve Lloyd_McKenzie
Found Date: 23 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/23-hcls-minutes.html
People with action items: david tony

[End of scribe.perl diagnostic output]