See also: IRC log
<trackbot> Date: 22 July 2015
lloyd: Code does not include a display property
david: I prefer to view Code as the *subset* of data that does not include a display property, but a display property may exist without violating the ontology
paul: display is not needed if the meaning of code is well known.
lloyd: concept vs coding. Concept
is the meaning that something has. Multiple codings can be tied
to a particular concept.
... I can know that this particular gender is a female, but
that doesn't mean that all of the code representations are
suddenly showing up.
david: question is whether we want to use the ont for *only* data that is FHIR RDF (in isolation -- with no other data), or it should be usable for FHIR RDF that has been combined with additional data.
lloyd: We want the ont to reflect
what's allowed in the instance. Valid RDF instance cannot have
any information that will not round trip. We may want other
ontologies for more than that.
... System is tricky, because it isn't transmitted, but it must
be know.
tony: If the ont cannot be formed correctly without Code . . . .
lloyd: You can have an ont that reflects exactly what goes over the wire, but without system we cannot support valueset. Wouldn't be able to understand the concept.
eric: one category we haven't
called out: the things that have exactly one code system and
code. (Lloyd: that's CodingThing.)
... Computably useful: A class of things that have code system
and code.
... A CodeThingy is in that category.
... Logically. So we can do useful things in them.
... Versus something that has a code and optional system, which
we can't do useful things with.
lloyd: A CodeThing requires a code, and the system is fixed (inferrable).
eric: ShEx description would capture the "must not be uttered" part, but it is in the category of being useful because the system is knowable.
tony: Does the system get declared in CodeThingy?
lloyd: When we define the ont,
the fact that it is a Code means there *must* be fixed binding
to a valueset.
... System can be inferred, because within the valueset the
code mnemonics must be unique.
... Valueset is an enumeration of CodingThingies.
eric: Re how do we infer the code system, if we see code M, then . . . .
lloyd: there will be an assertion
(CodeableConcepting, Coding or Code are all subtypes of
CodeableThingy). For Code, there will be exactly one
CodingThing. Binding says there must be a CodingThingy that
either has system X1 code Y1, or sytesm X2 code Y2.
... Then the instance data says "I am Y2". Given that they must
be unique, that implies that system is X2.
... If you have a CodingThing that is X2 Y2 then your
codebleConcept is C2.
... I've done this with V3 and it works.
paul: the valueset mnemonic is unique enough to infer the type?
lloyd: In the case where the datatype is Code, that is a rule: the mnemonic MUST be unique.
tony: If we can infer the system of the code, then will this be a type declaration?
lloyd: no, because there can be
circumstances with multiple codings tied to a single
concept.
... We cannot prohibit the existence of system when dealing
with a Code.
... The cardinality must be maxOccurs 1. The question is
whether to make minOccurs 1.
... My leaning is to say exact cardinality is 1, but in the
instance there will be 0.
eric: The point of having exactly
1 is that you can reason over having exactly 1.
... The fact that the ont says 1 but the ShEx says 0 indicates
where translation/inference will be needed
... Havng the ont different than the ShEx is a feature, not a
bug.
tony: Agreed that CodeThing will
have system property with cardinality exactly 1.
... CodingThing.system will have cardinality exactly 1
AGREE: CodingThing.system will have cardinality exactly 1
tony: what about version?
lloyd: anyone who makes the meaning change should be flogged
eric: +1
david: +1
tony: There are some ill-behaved systems that change meaning between versions.
lloyd: Suggest postponing this decision.
paul: I've been working with folks that do stem cell transplant. If we don't build in a way to merge in new science, it is a bear.
lloyd: the framework exists, and
there will be different versions. in a nicely behaved code
system, if the science changes you may invent new codes and
deprecate others, but you don't change the meaningn of
codes.
... But there are some that change the meaning of the same code
between versions, so you need the version to properly
understand them.
tony: What about the name? CodeableThing?
eric: Suggest "Base" instead of "Thing".
lloyd: if we're going with base, I suggest: ConceptBase, CodingBase and CodeBase
david: I suggest CodeableConceptBase instead of ConceptBase
tony: too long. you'll have CodeableConceptBase.system, etc.
lloyd: Suggest use ConceptBase, go to ballot, and see what the community thinks.
AGREED: Use ConceptBase (initially) as the superclass
david: What about cardinality of
display property?
... i.e., CodingBase.display
lloyd: And for fhir:Code, then cardinality will be 0.
david: That's at odds with the approach we're taking for CodingThing.system.
lloyd: it is. but system is needed for reasoning; display is not.
david: My concern is that i would not be able to use that ont if i merge in other data that adds a display. i would have to change the data to change the Code to a Coding.
eric: when we're describing
what's going across the wire, the are not allowed to have
display attached.
... If we're manipulating them from SPARQL update, then we're
changing Code to Coding. That would enable a tool to uniformly
look for display property.
david: But if we say system cardinality is 1, that is *not* going across the wire.
eric: Maybe there isn't much value in describing only what is on the wire.
david: For validation about what
should be on the wire, we want ShEx, not OWL.
... I'm very uncomfortable with the idea that we would not be
able to use the ont with merged data.
tony: want to combine ontologies and data.
david: Would be doing a disservice by saying that display property on Code must have cardinality 0.
tony: rdfs:labels may show up for users. you don't need the display property, because the human viewable description willl come from the class label.
david: Want to be able to uniformly query for display property. may want to add a display property to Codes.
tony: but you don't need the display. but a label would be available.
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/.Code// Succeeded: s/use/use the ont/ No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Present: EricP Tony_Mallia Lloyd_McKenzie Paul_Courtney David_Booth Found Date: 22 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/22-hcls-minutes.html People with action items:[End of scribe.perl diagnostic output]