trackbot, start meeting

<trackbot> Date: 03 November 2015

ValueSets

<dbooth> (Tony showing Protege)

<dbooth> rob: Why is fhir:anAllergyStatusCodingBase a subclass in protege?

<dbooth> lloyd: when converting instances, we won't have the string "allergy-intolerance-status".

lloyd: when we're translating instance data we won't have the arbitrary code system url

<scribe> scribenick: ericP

<dbooth> ... So when we convert to RDF we'll have to do it using the property value.

tony: an instance of a FHIR URI as a value ...
... if you want to name the code system we can create named URIs

lloyd: we can do that ffor FHIR, but not at large because we won't know what they are

tony: put it in the bridging ontology

lloyd: we can't use the bridging ontology for the RDF->XML transform

tony: so we leave it as a string
... np

lloyd: the bridging onotlogy can declare these things as a convenience

tony: so how is this translated into the final form (not the one with a string)

dbooth: you have to look at both
... first we have to specify the RDF that's round-tripped with the XML
... it's good that you're looking ahead to see that it will work

tony: i'm working from both ends
... i.e. "these are the restriction on the payload; how do i get from there to something [inferencable]"
... CodingBase.system will always come across as an anonymous individual with the system URI as a string.
... per lloyd, the named individual will be in the bridging ontology, and the conversion can't see that.

there's a ConceptBase.coding that maps from concept to codeing

<dbooth> tony: CodingBase.concept is the inverse of ConceptBase.coding

tony: @@1 is the inverse

<dbooth> lloyd: How to you say that "these are the *only* codes that exist"?

lloyd: you need to definitively say that these 200k LOINC codes are the only legal codes

tony: if you define the allowed codes in a code system as a set of strings, you're duplicating what's in the concept tree

<dbooth> lloyd: Because codes are strings, they are automatically distinct from each other

tony: then you have to keep them in line

lloyd: it's easier to say these are the only codes that are allowed in the code system than to do it by concept
... SNOMED is a wonky beast because it's post-coordinated which makes enumeration impossible.
... most code systems are enumerable
... if you enumerate ICD-10 codes and you see a "foo", you can see it's not legal
... you have to enumerate or the reasoner will makes leaps that are not correct

tony: do we make the reasoner throw-up or do we declare the range that conflicts?
... i'd write a SWRL rule to conclude non-conformance

dbooth: i beleive that lloyd is advocating a tighter ontology which uses convenional OWL open-world to infer non-conformance when something claims to be a member of a value set but is not actually a member
... tony is advocating an ontology that won't catch that conflict but we would instead rely on an external, closed-world tool to detect non-conformance

tony: yes, we don't want the reasoner to just stop.

<dbooth> http://wiki.hl7.org/index.php?title=FHIR_Ontology_Requirements#11._Enable_Inference

dbooth: we weren't specific about this in our requirements.

rob: the pellet reasoner folks at C&P came up with ICV. i don't know if it's still available.
... i think it's common to take the two-layer approach
... (i.e. external valuset validator)

<dbooth> Option A: owl-validation: the owl reasoner barfs if instance data specifies a code does not match the valueset.

<dbooth> Option B: external valueset validator: Owl reasoner does not barf. Instead, an extra closed world inference step is use (perhaps using SWRL or other) to detect the problem.

Marc_Twagirumukiza: i like option A

dbooth: if someone provides instance data with a code that's supposed to be a member of a valueset and is not, how to we catch it?
... option A leverages the OWL reasoner
... option B means you don't stop the OWL reasoner from performing useful inference.

hsolbrig: having attempted to execute A several times, getting an OWL reasoner to barf is a painful and IMO not terribly fruitful exercise
... i think value sets are best treated as a datatype
... a la a valid XSD integer
... so option B

<dbooth> eric: the work needed for option A is easier than Harold experienced, becsue these are strings not URIs. But the diff between these options in the reasoning would be saying 'valueset A is one of (a giant list)'

<dbooth> ... and whether we want to set up the tooling to support that.

<dbooth> ... I'd like to test that, but know that most of the use would be that we would NOT provide it, and we use external validation (option B).

<dbooth> ... I.e., we should try to make our ont work for option A, but recognize that most of the use will be option B.

<dbooth> tony: If you do provide that ValueSet, do you want it to barf?

<dbooth> eric: yes, providing that ValueSet is telling it that you want it to barf if the code is wrong.

<dbooth> tony: For the FHIR internals, we will always have the ValueSets.

<dbooth> eric: If we were doing a complete model, there's some connection we would have to fail to make. If we supply those ValueSets and tell it enough, then it will fail if we give it a bad code.

dbooth: i like option B. I want to separate validation and inference.

Marc_Twagirumukiza: we'll have to add something about that in the requirements

dbooth: some validation can be done in OWL but much will require closed-world reasoning.

lloyd: i believe it's not an either/or
... the ontology should be capable of performing strict validation
... because sometimes we want a y/n and it would be impractical to write the code to do the external validation.
... there are other circumstances where you'll want to probe.
... we should design to support both and give implementors the guidance to choose.
... the decision should not affect the wire format; only the linking ontologies.

<rhausam> here are a couple of links to discussion of integrity constraint validation (from Clark & Parsia, some based on their proprietary tools):

<rhausam> http://docs.stardog.com/icv/icv-specification.html

<rhausam> http://docs.stardog.com/#_validating_constraints

Tony: so far, i've been taking a pragmatic approach given protege and the reasoner.
... so far i've had the reasoner barg in the t-box; haven't see it barf because of a-box inconsistencies

rhausam: practically, separating open and closed world makes sense
... do what you can in open world.
... but don't go crazy tightening up the ontology

Marc_Twagirumukiza: i'm still concearned about option A.
... it's kind of validation.
... but i agree that it's pragmatic to do B

<dbooth> Proposal: We should do both, but separate the base FHIR ontology (which would NOT cause the reasoner to barf if a wrong code is used) from an additional validation ontology (which WOULD cause the reasoner to barf if a wrong code is used).

hsolbrig: if tony sets off to make it barf, i caution you that it can take a long time.
... the answer will be in trying it.

-> http://www.cs.man.ac.uk/~rector/papers/Terminology-binding-final-revision-embedded-single-rector%20copy.pdf Alan Rector paper to which Harold referred

Tony: you're assuming these two approaches can co-exist

lloyd: they can. the tight one simply contains more assertions.

Marc_Twagirumukiza: i think we need some use cases.
... we can start with A and debug. then do B, then come back to A

lloyd: we need to do A first because it's the complicated beast

<dbooth> eric: lloyd work with me on option A?

<dbooth> dbooth: This may boil down to who steps up to do the work :)

<Marc_Twagirumukiza> Most likely, A will lead to inference fuse and the reasoner will stop

<Marc_Twagirumukiza> so trying to fix those inference fuse will be implementing B but at the end we need to re-do A to make sure we have a validation

<Marc_Twagirumukiza> some external reasoner like EYE allow to go beyond inference fuse (using a buil-in --ignore-inference-fuse)

<Marc_Twagirumukiza> but this is outside Protégé

<dbooth> ACTION: Eric to work with lloyd to show option A approach (making OWL barf if code is not in the stated valueset) [recorded in http://www.w3.org/2015/11/03-hcls-minutes.html#action01]

<trackbot> Created ACTION-32 - Work with lloyd to show option a approach (making owl barf if code is not in the stated valueset) [on Eric Prud'hommeaux - due 2015-11-10].

<dbooth> ACTION: Eric to convert tony's side-by-side doc to xhtml [recorded in http://www.w3.org/2015/11/03-hcls-minutes.html#action02]

<trackbot> Created ACTION-33 - Convert tony's side-by-side doc to xhtml [on Eric Prud'hommeaux - due 2015-11-10].

<dbooth> 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)

Succeeded: s/indivisual/individual/
Succeeded: s/code value/system URI/
Succeeded: s/implimenting/implementing/
Found ScribeNick: ericP
Inferring Scribes: ericP
Present: Harold_Solbrig David_Booth Tony_Mallia Eric_P Lloyd_McKenzie Rob_Hausam Marc Twagirumukiza
Found Date: 03 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/03-hcls-minutes.html
People with action items: eric