This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Datatypes R2 Issue 12"

From HL7Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by 2 users not shown)
Line 11: Line 11:
  
 
== Discussion ==
 
== Discussion ==
 +
 +
Outcomes from the long R2 skype thread below:
 +
 +
* change HIST to extend LIST not SET. Set sort order on HIST (DONE)
 +
* Define ComparableSet and make Set specialise Comparable set with default equality comparator.
 +
* Define some other common comparators
 +
* Define Equality for every single datatype
 +
* Define identical property to assist with uniqueness constraint definitions
 +
* clarify even more the definition of HIST and HXIT and take this up with MnM facilitators & HDF authors
 +
* clarify about the implications of comparing null flavors in an implementation note (and relevance for IVL)
 +
 +
Issues to follow
 +
* SET<CE> not allowing nulls
 +
 +
 +
 +
== Disposition ==
 +
 +
== Status ==
 +
 +
Proposed
 +
 +
== Links ==
 +
Back to [[Data Types R2 issues]]
 +
 +
== Archives ==
  
 
'''DataTypes BOF May 2005''': Proposed action: Accept and add  
 
'''DataTypes BOF May 2005''': Proposed action: Accept and add  
Line 16: Line 42:
  
 
This is a very far-reaching thing to do. I can agree to EN and AD
 
This is a very far-reaching thing to do. I can agree to EN and AD
but it should not be done for PQ and CD. --[[User:Gschadow|Gschadow]] 01:23, 25 Jun 2006 (CDT)
+
but it should not be done for PQ and CD. The proposal is not
 +
correctly titled, as the whole point about data types is that
 +
identity is not different from equality. Anything that looks
 +
different between two values and does not factor into the
 +
equality relation is logically irrelevant. I am O.K. with
 +
revising this, but a sweeping change without further looking
 +
at the specific cases is a very bad idea. --[[User:Gschadow|Gschadow]] 01:23, 25 Jun 2006 (CDT)
  
== Links ==
+
BOF: Accept and add equivalence definitions for EN, AD, PQ, CD, possibly others
Back to [[Data Types R2 issues]]
+
 
 +
I am against this change. It is very destructive. The ISO ballot has surfaced it and I logged a bunch of negative items on these issues. It is impossible to replace the equal rules with a simple thing that checks for equalness of all properties. Besides our equal definition is backed by ISO 11404. You need to realize that we put in some "properties" which have no semantics (e.g., CD.displayName, II.assigningAuthorityName, etc), they can't factor into the equality, that would be a contradiction. This is just the tip of the iceberg. I oppose any sweeping changes to this. I can only agree to specific fixes of specific issues with the present equal. Even EN/AD is not quite sold for me. [[User:Gschadow|Gschadow]] 18:07, 5 May 2007 (CDT)
 +
 
 +
To read the skype chat, look at the source
 +
 
 +
== Long Long Skype (welcome to the show...) ==
 +
 
 +
[9:51:02 AM] Grahame Grieve says: Hello Everyone, and welcome to HL7 Street.
 +
[9:51:19 AM] Grahame Grieve says: Today's show is brought to you by the letter Null and the words "equality" and "identity"
 +
[9:51:55 AM] Gunther Schadow says: zap (smirk)
 +
[9:52:25 AM] Grahame Grieve says: and our special guest is Dennis. Dennis works for me and has spent a couple of weeks writing an implementation of the ISO datatypes, and has been writing an implementation of the javaSIG datatype interfaces against the ISO datatypes
 +
[9:53:15 AM] Grahame Grieve says: so, my intention today is to drive a truck through the holes in the abstract standard. In the end, I have to deal with Gunther's comments about equals and matches in the ISO datatypes, but the abstract is where we start (as always)
 +
[9:54:06 AM] Gunther Schadow says: a truck (whew)
 +
[9:54:15 AM] Grahame Grieve says: so, does anyone disagree with the following invariant:
 +
[9:55:08 AM] Grahame Grieve says: invariant(ANY a, b, c)
 +
      where a.nonNull.and(b.isNull).and(c.isNull) {
 +
  a.equal(b).isNull;
 +
  b.equal(a).isNull;
 +
  c.equal(b).isNull;
 +
  b.equal(c).isNull;
 +
};
 +
[9:55:59 AM] Grahame Grieve says: null = null, (anything else = null), (null = anything else) - all these are null
 +
[9:56:47 AM] Dale Nelson says: so far, so good
 +
[9:57:23 AM] Grahame Grieve says: this has some unexpected consequences. take for example:
 +
[9:59:33 AM] Grahame Grieve says: this is the equality definition for CD:
 +
[9:59:33 AM] Grahame Grieve says: invariant(CD x, y)
 +
      where x.nonNull.and(y.nonNull) {
 +
  x.equal(y).equal(x.code.equal(y.code)
 +
            .and(x.codeSystem.equal(y.codingSystem))
 +
            .and(x.qualifier.equal(y.qualifier)));
 +
};
 +
[10:00:18 AM] Lee Coller says: I think the CD definition is broken for the very reason you imply
 +
[10:00:43 AM] Grahame Grieve says: hey, I'm just warming up. I've got more in mind than you do. but we will go there
 +
[10:00:50 AM] Lee Coller says: I think our "default" definition of equality of any two type instances should be all the non-null properties are equivalent
 +
[10:00:58 AM] Lee Coller says: make that "equal"
 +
[10:01:11 AM] Gunther Schadow says: I disagree
 +
[10:01:35 AM] Grahame Grieve says: I'm with Gunther in that respect - it's broken. But what we have is badly broken for CD and generally broken in a few other places
 +
[10:01:52 AM] Grahame Grieve says: take these two CD's:
 +
 
 +
<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
 
 +
<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
[10:01:58 AM] Grahame Grieve says: these are equal no?
 +
[10:01:59 AM] Gunther Schadow says: I don't see the broken-ness. Can you point out for the slow people like me?
 +
[10:02:17 AM] Gunther Schadow says: these are equal. Yes.
 +
[10:02:18 AM] Grahame Grieve says: I'm going to. Don't worry about that
 +
[10:02:56 AM] Grahame Grieve says: Now, take these two CE's:
 +
 
 +
<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
 
 +
<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
[10:03:08 AM] Gunther Schadow says: equal
 +
[10:03:19 AM] Grahame Grieve says: are these equal? No, it is unknown whether they are equal, because CE.qualifier is null
 +
[10:03:37 AM] Gunther Schadow says: CE.qualifier is NA, yes.
 +
[10:03:57 AM] Kevin M Coonan, MD says: not NI?
 +
[10:04:09 AM] Grahame Grieve says: yes. unexpected, but true in a formal sense. counter-intuitive, certainly
 +
[10:04:12 AM] Gunther Schadow says: For CE qualifier does not apply. Which means that qualifier is disregarded.
 +
[10:04:29 AM] Grahame Grieve says: semantically, yes, but not by the formal definitions.
 +
[10:04:46 AM] Grahame Grieve says: so the formal definition would be better to say:
 +
[10:05:31 AM] Grahame Grieve says: invariant(CE x) {
 +
  x.qualifier.length.equal(0);
 +
};
 +
instead of
 +
invariant(CE x) {
 +
  x.qualifier.notApplicable;
 +
};
 +
[10:06:48 AM] Gunther Schadow says: The two should seem like the same thing. If something does not apply it's not there.
 +
[10:06:59 AM] Grahame Grieve says: I could even argue that is semantically more correct - we are not saying that the concept of qualifiers is disallowed, but that there are not allowed to be any.
 +
[10:07:17 AM] Grahame Grieve says: I agree that they are nearly the same thing. But by the formalism, they aren't.
 +
[10:07:36 AM] Grahame Grieve says: Don't mind if the outcome of this discussion is that we agree that the dtdl's a broken and we won't try to fix them.
 +
[10:07:42 AM] Gunther Schadow says: As you go down the null flavor hierarchy, you can get more than null for equals.
 +
[10:08:00 AM] Grahame Grieve says: yes, but it's all still x.isNull(), so that's not germane to this discussion
 +
[10:08:00 AM] Gunther Schadow says: For example, PINF.equal(NINF) is false, not null.
 +
[10:08:12 AM] Grahame Grieve says: hey. what? I don't think so.
 +
[10:08:29 AM] Grahame Grieve says: null.equal(null).isNull. You can't break that in a specialization
 +
[10:08:43 AM] Grahame Grieve says: do I need to quote the definition of specialization?
 +
[10:09:01 AM] Gunther Schadow says: When we say that a.equal(b) is null, then, just like with any property, null is not a proper value. It means we can't tell.
 +
[10:09:30 AM] Grahame Grieve says: so?
 +
[10:09:46 AM] Gunther Schadow says: If you have patient.birthTime.isNull you are not saying that the patient never has a birth time. You just say you have not enough information to say anything more specific.
 +
[10:10:15 AM] Gunther Schadow says: So, NI.equal(NI) is NI, but PINF equal NA seems false.
 +
[10:10:32 AM] Grahame Grieve says: agree. In fact, (fortunately) we don't have a way to say the patient was never been
 +
[10:10:46 AM] Grahame Grieve says: agree. In fact, (fortunately) we don't have a way to say the patient never has a birth time.
 +
[10:10:48 AM] Grahame Grieve says: duh
 +
[10:11:13 AM] Grahame Grieve says: agree that PINF.equal(NINF).equals(false) is semantically reasonable. But you either have a formalism or you don't.
 +
[10:11:40 AM] Gunther Schadow says: The formalism needs to be interpreted right :)
 +
[10:12:00 AM] Gunther Schadow says: You are making the following syllogism:
 +
[10:12:03 AM] Grahame Grieve says: oh. right. why didn't you say so.
 +
[10:14:01 AM] Gunther Schadow says: 1: a.isNull.and(b.isNull).implies(a.equal(b.isNull))
 +
2: a.isPINF.implies(a.isNull)
 +
3: a.isNINF.implies(b.isNull)
 +
therefore you say a.equals(b).isNull
 +
[10:14:40 AM] Grahame Grieve says: btw, this particular issue is not confined to CD. take these two:
 +
<example xsi:type="ST" lang="en">This is an example</example>
 +
<example xsi:type="ST" lang="en">This is an example</example>
 +
 
 +
definitely the same. But these:
 +
 
 +
<example xsi:type="SC" lang="en">This is an example</example>
 +
<example xsi:type="SC" lang="en">This is an example</example>
 +
 
 +
unknown whether they are the same
 +
[10:15:07 AM] Gunther Schadow says: but that amounts to saying that if for a patient.birthTime(isNull) must be inconsistent with patient.birthTime.equals(19690219), but it's not.
 +
[10:15:12 AM] Lee Coller says: Center-only interval also suffers from this problem.  Arguably some forms of open-ended intervals to as well
 +
[10:15:28 AM] Grahame Grieve says: no. I am not saying that a.isPINF.implies(a.isNull) - I am saying that PINF is a specialisation of NI, and therefore everything that is true of NI is true of PINF
 +
[10:15:51 AM] Grahame Grieve says: implication is much weaker than specialization
 +
[10:15:55 AM] Gunther Schadow says: But that cannot be so.
 +
[10:16:24 AM] Gunther Schadow says: There can be more true about PINF than about NI, and that which is more true about PINF can make a difference.
 +
[10:16:37 AM] Grahame Grieve says: what cannot be so? I think this is why PINF cannot be a specialisation of NI. But maybe we are working from different definitions of specialization?
 +
[10:16:56 AM] Gunther Schadow says: null is not a proper value.
 +
[10:17:20 AM] Gunther Schadow says: Null is the absence of a value. It does not preclude there being a value, given more information is considered.
 +
[10:17:27 AM] Grahame Grieve says: I agree that there can be more true about PINF than NI, but what is true about PINF cannot falsify what is true about PINF treated as NI, else it is not specialisation
 +
[10:17:39 AM] Grahame Grieve says: agree, but so?
 +
[10:17:47 AM] Dale Nelson says: Is Null specializable? If so, why?
 +
[10:18:02 AM] Gunther Schadow says: We are talking about specialization of null flavors, not specialization of null-values.
 +
[10:18:24 AM] Grahame Grieve says: well, explain the difference. Is it like the difference between specialisation of instances and classes?
 +
[10:18:38 AM] Gunther Schadow says: not sure, don't think so.
 +
[10:19:09 AM] Gunther Schadow says: We should be able to clarify that with simple codes...
 +
[10:19:16 AM] Gunther Schadow says: for example,
 +
[10:19:22 AM] Gunther Schadow says: green is a color
 +
[10:19:26 AM] Gunther Schadow says: red is a color
 +
[10:20:09 AM] Gunther Schadow says: with Color a and b, a.equal(b) isNull, right?
 +
[10:20:27 AM] Gunther Schadow says: But green.equal(red) is false, right?
 +
[10:21:03 AM] Grahame Grieve says: certainly agree with this.
 +
[10:22:08 AM] Gunther Schadow says: then you have to also agree with this:
 +
[10:22:18 AM] Gunther Schadow says: PINF is a Null
 +
[10:22:24 AM] Gunther Schadow says: NA is a NULL
 +
[10:22:38 AM] Gunther Schadow says: with Null a and b, a.equal(b) isNull, right?
 +
[10:22:50 AM] Gunther Schadow says: But PINF.equal(NA) is false, right?
 +
[10:23:06 AM] Grahame Grieve says: ok I get it. I'm forced to agree. PINF.equals(NINF).equals(false) is an acceptable specialisation to null.equals(null).isNull
 +
[10:24:00 AM] Grahame Grieve says: but it still bothers. OTH.equals(UNK).equals(?)?
 +
[10:24:34 AM] Grahame Grieve says: and MSK.equals(UNK).equals(?)?
 +
[10:24:37 AM] Gunther Schadow says: OTH.equals(UNK) is null
 +
[10:25:02 AM] Grahame Grieve says: I think there's special case rules for PINF and NINF based on their semantic properties. I don't like the way this is going.
 +
[10:25:08 AM] Dale Nelson says: I would think the specialization of null flavors is a static property and PINF.equal(NA) is false is equlaity of the datatype, not the values. If you are comparing values PINF and NA, it has to be NULL, not FALSE
 +
[10:26:06 AM] Grahame Grieve says: and TRC.equals(TRC) .equals(?)?
 +
[10:26:10 AM] Gunther Schadow says: "Consider a being something I'm not allowed to tell you, consider b is unknown, then is it true that what I can't tell you is the same as that which is unknown?" - Answer: "I don't know, you gotta f@#$n tell me more."
 +
[10:26:45 AM] Gunther Schadow says: TRC.equals(TRC) is not decidable either.
 +
[10:26:53 AM] Grahame Grieve says: agree. so what combinations of null = null give anything but null?
 +
[10:26:56 AM] Lee Coller says: But 0 < TRC?
 +
[10:27:05 AM] Gunther Schadow says: Yes.
 +
[10:27:26 AM] Grahame Grieve says: semantically obvious, but not at all true from the formalisms.
 +
[10:27:50 AM] Gunther Schadow says: the formalism must be interpreted right :)
 +
[10:28:01 AM] Gunther Schadow says: Even if we say today that
 +
[10:28:02 AM] Grahame Grieve says: huh. so you said.
 +
[10:28:45 AM] Grahame Grieve says: I want to go back to PINF.equals(NINF).isNull is a specialisation of null.equals(null).isNull
 +
[10:28:53 AM] Gunther Schadow says: a.isZero.and(b.isTRC).implies(a.lessThan(b).isNull)
 +
[10:28:54 AM] Dale Nelson says: Why is TRC a flavor of Null and not =defined as R | R > 0
 +
[10:29:22 AM] Grahame Grieve says: that implies that false is a specialisation of null. I don't think that this true.
 +
[10:29:23 AM] Lee Coller says: Because it is
 +
[10:29:25 AM] Gunther Schadow says: ... that does not mean we are wrong to say tomorrow that we can know a little bit more than that, i.e. that a.lessThan(b) is in fact true.
 +
[10:29:47 AM] Grahame Grieve says: but a.isZero.and(b.isTRC).implies(a.lessOrEqual(b).isNotNull)
 +
[10:29:57 AM] Gunther Schadow says: false is indeed a specialization of null, in a way.
 +
[10:29:57 AM] Grahame Grieve says: duh. can't think.
 +
[10:30:21 AM] Gunther Schadow says: everything is a specialization of NI, in a way.
 +
[10:30:21 AM] Grahame Grieve says: > false is indeed a specialization of null, in a way.
 +
[10:30:31 AM] Grahame Grieve says: yeah, true is false, for a given value of true, too
 +
[10:30:35 AM] Dennis Nguyen says: sorry to be slowed, but I think Gunther example of Color a and b is wrong
 +
It means a and b is null, right
 +
So for Color, a.equals(b) can be true/false/null flavor
 +
[10:30:51 AM] Gunther Schadow says: no, true is never false the way that true and false are defined.
 +
[10:31:25 AM] Grahame Grieve says: I was quoting Terry Pratchett, actually. but never mind
 +
[10:31:28 AM] Dennis Nguyen says: but as null.equals(null) is already confined to null flavor, we can say true/false any longer
 +
[10:31:43 AM] Lee Coller says: if false is a specialization of null, so is true
 +
[10:31:45 AM] Dennis Nguyen says: can't say
 +
[10:32:50 AM] Dale Nelson says: how is false a specializatiuon of null?
 +
[10:33:03 AM] Dennis Nguyen says: In that sense, PINF and INF is not null flavor, but in a superset of value including null flavor
 +
[10:33:19 AM] Gunther Schadow says: NI means we have no information, we don't even know if something is there or not. But we are not saying nothing is there.
 +
[10:33:36 AM] Gunther Schadow says: NA has a little more information, here we know that nothing can in fact be there.
 +
[10:33:43 AM] Grahame Grieve says: So now we have two ideas that I don't like, but I could see that they might be true.
 +
* all values are specialisations of unknown value
 +
* the outcome of operations on nullFlavors is entirely driven by the semantics and there is not formal definition of the outcome
 +
[10:34:03 AM] Gunther Schadow says: OTH has more information, it means we know that something is there, but we have no word for it.
 +
[10:34:05 AM] Grahame Grieve says: these are real implementation challenges
 +
[10:34:35 AM] Gunther Schadow says: UNK means that we do not know something is there or not
 +
[10:34:54 AM] Gunther Schadow says: Color means that what any color could be there, but we don't know which.
 +
[10:35:44 AM] Gunther Schadow says: In a way, an implementation is always allowed to return NI on any operation.
 +
[10:36:05 AM] Gunther Schadow says: It does not violate the truth, it might just be utterly unusable.
 +
[10:36:15 AM] Gunther Schadow says: I mean, useless.
 +
[10:36:41 AM] Gunther Schadow says: 2 + 2 = I dunno, is not a wrong answer.
 +
[10:36:45 AM] Grahame Grieve says: but would it be conformant?
 +
[10:37:06 AM] Gunther Schadow says: 2 + 2 = I dunno is not conformant with my job description.
 +
[10:37:29 AM] Gunther Schadow says: But I did accept my little son with that answer.
 +
[10:37:32 AM] Grahame Grieve says: anyhow, back to my original example:
 +
[10:37:35 AM] Gunther Schadow says: k
 +
[10:37:41 AM] Grahame Grieve says: take these two:
 +
 
 +
<example xsi:type="ST" lang="en">This is an example</example>
 +
<example xsi:type="ST" lang="en">This is an example</example>
 +
 
 +
definitely the same. But these:
 +
 
 +
<example xsi:type="SC" lang="en">This is an example</example>
 +
<example xsi:type="SC" lang="en">This is an example</example>
 +
 
 +
unknown whether they are the same
 +
[10:37:51 AM] Grahame Grieve says: take these two CD's:
 +
 
 +
<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
 
 +
<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
 
 +
We all agree that these are equal.
 +
 
 +
Now, take these two CE's:
 +
 
 +
<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
 
 +
<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
 +
</example>
 +
 
 +
 
 +
are these equal? No, it is unknown whether they are equal
 +
[10:38:03 AM] Gunther Schadow says: Depends on what we know about SC, actually.
 +
[10:38:28 AM] Grahame Grieve says: I checked. code is null. equality definition is not narrowed to exclude code. possibly should be
 +
[10:38:28 AM] Gunther Schadow says: The CEs are equal.
 +
[10:38:41 AM] Grahame Grieve says: but what's the formalism to make the CE's equal?
 +
[10:38:55 AM] Grahame Grieve says: we can't just claim it's true because we want it to be, we have to earn that it's true
 +
[10:39:06 AM] Gunther Schadow says: I like to say even the CDs are equal, provided you told me everything.
 +
[10:39:21 AM] Dale Nelson says: shallow equal vs deep equal?
 +
[10:39:27 AM] Gunther Schadow says: Actually, this drives my favorite point about the uselessness of using equal on CD.
 +
[10:39:46 AM] Gunther Schadow says: It's like asking whether 2.0000000000000000000000000000000001 equals 2.000
 +
[10:40:36 AM] Grahame Grieve says: well, this also drives my point about the uselessness of trying to redefine equals on CD too then
 +
[10:40:47 AM] Gunther Schadow says: It can never be decided. Is "Jamaican Roast" equal Coffe?
 +
[10:41:20 AM] Grahame Grieve says: implies is more meaningful, we agree.
 +
[10:42:15 AM] Gunther Schadow says: So, strictly speaking, the two CDs you showed as unknown to be equal if we can assume that there is more information about them.
 +
[10:42:52 AM] Gunther Schadow says: Is my disease the same as the other guy's disease? We can never tell.
 +
[10:43:18 AM] Gunther Schadow says: But is my disease diabetes mellitus (no qualifiers)? We might say yes.
 +
[10:44:23 AM] Grahame Grieve says: but we could make the same argument about address. Two people who live on the same road and give the same address, only including road, because they're mates with the postie - are those addresses equal?
 +
[10:44:56 AM] Gunther Schadow says: We can't say for sure.
 +
[10:45:19 AM] Grahame Grieve says: no but we define it anyway - so exactly what are we trying to achieve?
 +
[10:45:33 AM] Grahame Grieve says: but this is not really about CD. it's about the definition of equality. if null=null is null, then what is the status of comparing things with null properties
 +
[10:45:46 AM] Grahame Grieve says: I think that generally this issue slipped under the radar
 +
[10:46:08 AM] Grahame Grieve says: I can keep making examples up, but I think that the two I made showed that issue
 +
[10:46:17 AM] Gunther Schadow says: Strict equality for addresses is not a very useful operation.
 +
[10:46:29 AM] Grahame Grieve says: Is it true that in this regard, we can act consistently, xor reasonably?
 +
[10:47:16 AM] Grahame Grieve says: what is a useful operation? I haven't turned my attention to BAD<AD> yet, though I'm going to. But later, haven't finished comparing values with null properties yet
 +
[10:47:17 AM] Gunther Schadow says: I  am an optimist, we can act consistently and reasonably. We just have to be careful about what we think is consistent.
 +
[10:47:47 AM] Gunther Schadow says: We can act consistently and reasonably, we just have to be reasonable about what we think is consistent.
 +
[10:48:27 AM] Grahame Grieve says: ok, what's reasonable? am I unreasonable to think that the formal definition should say what we mean and be internally consistent?
 +
[10:48:59 AM] Grahame Grieve says: I think that what this means is that we have to define equality for every single datatype, never leaving it to the implementor
 +
[10:49:12 AM] Grahame Grieve says: we've done about half what we have to do.
 +
[10:49:24 AM] Gunther Schadow says: no, you are reasonable. But, it is also reasonable to accept the limitations of what we can say at all given limited time, limited patience by the balotters, etc.
 +
[10:50:00 AM] Grahame Grieve says: I would be willing to fix this by doing the work of defining it for everything.
 +
[10:50:11 AM] Grahame Grieve says: given we can resolve my other issues that we haven't talked about yet.
 +
[10:50:32 AM] Gunther Schadow says: I think when we specify equal constraints, we make necessary statements, but they might not be sufficient.
 +
[10:50:47 AM] Lee Coller says: Can we agree that the determination of equality shouldn't be a function of the type of null flavor on an attribute?
 +
[10:51:03 AM] Grahame Grieve says: hmm. no?
 +
[10:51:37 AM] Gunther Schadow says: I'm with Grahame here, I think we showed that that is not possible if you want to enumerate more possible cases.
 +
[10:51:40 AM] Grahame Grieve says: maybe you need to clarify, which equality? and don't use the word attribute, makes me come out in spots
 +
[10:53:54 AM] Grahame Grieve says: my second issue was going to be about CD, OTH, and equality. But CD is so broken anyway, who cares. It's certainly not an illuminative discussion with regard to null,equality and identity. So I'll move on to my third point in a sec.
 +
[10:54:05 AM] Lee Coller says: Take for example an open ended interval.  Should we take into the account the null flavor used on the high property?
 +
[10:54:15 AM] Gunther Schadow says: Since the earliest days I hated to put equal on REAL. I'd much rather have said that it's not useful and instead one should spefiy equals with a parameter, epsilon, such that r.equal(s, epsilon).equal(r.minus(s).lessOrEqual(epsilon)).
 +
[10:54:26 AM] Grahame Grieve says: ok, IVL is 4, let's take that now
 +
[10:55:16 AM] Dale Nelson says: The old programming language APL used a "fuzz" factor to decide whether two reals were equal. The factor was user specifiable.
 +
[10:55:35 AM] Gunther Schadow says: yup, cool.
 +
[10:55:36 AM] Lee Coller says: Yes, but I could code the entire RIM in APL in one line :D
 +
[10:55:41 AM] Grahame Grieve says: a prpoer language will have both. there's a use case for both, if you know waht you are doing
 +
[10:56:17 AM] Grahame Grieve says: Lee, I'm confused. you can code the entire RIM?
 +
[10:56:40 AM] Lee Coller says: You can do anything in APL in one line
 +
[10:56:52 AM] Gunther Schadow says: just needs a long line I guess :)
 +
[10:56:58 AM] Grahame Grieve says: but you can code the RIM at all? ;)
 +
[10:57:25 AM] Dale Nelson says: except for the coded bits
 +
[10:57:27 AM] Lee Coller says: IF you talk about implement the classes in java, persist and retreive them from the database, yes.
 +
[10:57:39 AM] Lee Coller says: I can't to Role Link though
 +
[10:57:52 AM] Gunther Schadow says: :D
 +
[10:58:04 AM] Lee Coller says: Back to IVL
 +
[10:58:33 AM] Grahame Grieve says: yes, back to IVL: If an interval is unknown on one (or both) boundaries, the center can still be asserted
 +
[10:58:48 AM] Grahame Grieve says: huh? how could you not know the one boundary, and know the center?
 +
[10:59:06 AM] Gunther Schadow says: how not?
 +
[10:59:20 AM] Gunther Schadow says: you just don't know the width.
 +
[10:59:22 AM] Grahame Grieve says: I can understand - maybe- knowing the center and not both the boundaries
 +
[10:59:25 AM] Lee Coller says: Don't yo mean width only?
 +
[10:59:34 AM] Grahame Grieve says: how can you know low and center and not width?
 +
[11:00:02 AM] Gunther Schadow says: But I would argue it is unreasonable to claim you know the center if you don't know everything. In most cases it would be better to say "I know some value in the interval".
 +
[11:00:17 AM] Gunther Schadow says: In Java SIG code, I introduced the "any" property for SETs.
 +
[11:00:20 AM] Gunther Schadow says: any is nice
 +
[11:00:36 AM] Grahame Grieve says: hey yes, I agree. in fact, IVL with only a center is actually a CIVL thingy?
 +
[11:00:42 AM] Grahame Grieve says: and any is what?
 +
[11:00:58 AM] Gunther Schadow says: It's not even a civil thing.
 +
[11:01:19 AM] Lee Coller says: You might know how long it is, but not when it starts of finishes
 +
[11:01:20 AM] Dale Nelson says: Datatypes R1 constrains IVL to any 2 of {low, high, center, width} doesnt it?
 +
[11:01:40 AM] Gunther Schadow says: only the XML its does.
 +
[11:01:44 AM] Grahame Grieve says:  You can have any of these combinations of children:
 +
 
 +
    * low
 +
    * width
 +
    * high
 +
    * low, width
 +
    * width, high
 +
    * low, high
 +
    * center
 +
    * center, width
 +
[11:01:58 AM] Dale Nelson says: But others default when you do that
 +
[11:02:01 AM] Gunther Schadow says: only for the XML its, it's an arbitrary decision.
 +
[11:02:44 AM] Grahame Grieve says: agree, in the XML. the relationship between the XML and the abstract is not simple. Bu I was quoting the xml. I think that the sentence I quoted should be changed from
 +
 
 +
If an interval is unknown on one (or both) boundaries, the center can still be asserted
 +
 
 +
to
 +
 
 +
If an interval is unknown both boundaries, the center can still be asserted
 +
 
 +
or omitted altogether
 +
[11:03:02 AM] Gunther Schadow says: Any is nice because when people give a point in time for an Act.effectiveTime, they really mean that any point in that effectiveTime was that point they provide. They don't know start and end, and they don't know about center either.
 +
[11:03:24 AM] Dale Nelson says: if a property like width is unknown (null) woudnt the entire value of the IVL be unknown (null)
 +
[11:03:25 AM] Gunther Schadow says: It is very useful to state any and an approximate width. That is how we know about most events.
 +
[11:04:04 AM] Gunther Schadow says: I think one can say that that would be an incompletely specified intereval.
 +
[11:04:10 AM] Grahame Grieve says: I don't really follow this any. "really mean that any point in that effectiveTime was that point they provide"? I've tried to make sense of that several times and failed
 +
[11:04:14 AM] Gunther Schadow says: And one could say that that is a flavor of null.
 +
[11:04:38 AM] Gunther Schadow says: We define Act.effectiveTime as a SET.
 +
[11:05:40 AM] Gunther Schadow says: We know that for a single event the effectiveTime is a continuous IVL .
 +
[11:05:55 AM] Gunther Schadow says: Yet most people in real HL7 would rarely want to state the IVL completely.
 +
[11:06:11 AM] Gunther Schadow says: They like to send a single point in time instead.
 +
[11:06:51 AM] Grahame Grieve says: so, the operation"happened" at 0930, and we know it would take 60 minutes.
 +
[11:07:08 AM] Grahame Grieve says: and if we have to, we assume that "happened" means "started around about"?
 +
[11:07:24 AM] Gunther Schadow says: Call that point they only care about t. Now we currently give them no choice but to say:
 +
 
 +
(1) the event went from t till t, or
 +
(2) the event was centered in t and extended symmetrically from t.
 +
[11:07:37 AM] Gunther Schadow says: both of these statements are more than people would really want to claim.
 +
[11:08:11 AM] Gunther Schadow says: It would be better if we gave them a chance to claim that the event extended over some unspecified time and t was an element of that set.
 +
[11:08:35 AM] Grahame Grieve says: ok, that makes sense. but how would we do that?
 +
[11:09:11 AM] Grahame Grieve says: is this a GTS thing or an IVL<TS> thing - smells like a GTS thing to me
 +
[11:09:13 AM] Gunther Schadow says: In other words, there exists some t_i in the interval that satisfied t_i = t. That's what <effectiveTime xsi:type="IVL_TS" any="{$t}"/> would mean.
 +
[11:09:25 AM] Gunther Schadow says: Not GTS.
 +
[11:09:29 AM] Gunther Schadow says: well
 +
[11:09:33 AM] Gunther Schadow says: not really.
 +
[11:09:53 AM] Gunther Schadow says: You can send any one value out of any set.
 +
[11:10:14 AM] Gunther Schadow says: GTS === SET<TS>, so, you can have an any out of a GTS. But it's not the same issue as GTS.
 +
[11:10:21 AM] Gunther Schadow says: only some similarities.
 +
[11:10:34 AM] Grahame Grieve says: well, it's pretty partially specified, that's for sure. So let's go back to partially specified intervals.
 +
[11:10:38 AM] Grahame Grieve says: is >10 = >10?
 +
[11:10:51 AM] Gunther Schadow says: we can't tell.
 +
[11:11:16 AM] Grahame Grieve says: so, PINF.equals(PINF).isNull?
 +
[11:11:17 AM] Gunther Schadow says: well ... depends if your upper bound is PINF in both cases or not.
 +
[11:11:48 AM] Gunther Schadow says: [10; PINF[  = [10; PINF[, yes
 +
[11:12:01 AM] Gunther Schadow says: [10; NI[ = [10; NI[, don't know
 +
[11:12:04 AM] Grahame Grieve says: lets assume that it's PINF, since we cannot really say >10, we have to say 10->PINF
 +
[11:12:09 AM] Grahame Grieve says: even though that's not what we mean
 +
[11:12:25 AM] Gunther Schadow says: we can say [10; NI[
 +
[11:12:46 AM] Grahame Grieve says: yes, that's unknown. sure.
 +
[11:12:59 AM] Gunther Schadow says: [sorry, want to get the kids to bed, quality time ya know ... later]
 +
[11:13:06 AM] Grahame Grieve says: k
 +
[11:13:16 AM] Grahame Grieve says: fun time later, when we look at BAG<AD>
 +
[11:34:53 AM] Grahame Grieve says: I'm confused. Why is there a reference to datatypes-base in the xml its source? what is supposed to be in existence for datatypes-base.xsd? I don't have one, and the makefile doesn't make one
 +
[12:09:36 PM] Gunther Schadow says: That datatypes-base was done afterwards, I think by Dale. We create datatypes.gst and datatypes.xsd and templates-instantiations.xsd, they didn't like that "templates-instantiations" name, and rather called it datatypes and the original datatypes was renamed to datatypes- base.xsd.
 +
[12:10:48 PM] Grahame Grieve says: so we're in a mess right now, with half made changes?
 +
[12:13:13 PM] Gunther Schadow says: I think it's not so much of a problem. We can simply do the same renaming from the source.
 +
[12:15:32 PM] Grahame Grieve says: which should I rename - the files and the names in the make files?
 +
[12:15:35 PM] Grahame Grieve says: and why .txt?
 +
[12:16:18 PM] Gunther Schadow says: Dennis "but as null.equals(null) is already confined to null flavor, we can say true/false any longer" - yes we can, just as we can say red if the thing.color is "already confined to colored".
 +
[12:17:08 PM] Gunther Schadow says: In some early draft of data types I had a picture of the tree of null values ... let's see if I can find it ...
 +
[12:21:17 PM] Gunther Schadow says: Here it is: http://aurora.rg.iupui.edu/v3dt/show-38.html
 +
[12:21:46 PM] Dennis Nguyen says: Grahame explained to me that null in this case is the superset of all types
 +
So does that mean red is a specific null flavor (some flavor like "specific information supplied" kind of ?)
 +
[12:38:19 PM] Gunther Schadow says: I don't think it's helpful to say "red is a null flavor". And it's not right, becasue red for color is expressly not null.
 +
[12:40:55 PM] Gunther Schadow says: Is this an extended commercial block? Did people zap out your show? And when is the part of the show when the  truck will come in and drive through a hole? (smirk)
 +
[12:41:07 PM] Grahame Grieve says: you went to put the kids to bed.
 +
[12:41:13 PM] Grahame Grieve says: so we had a long intermission.
 +
[12:41:22 PM] Grahame Grieve says: we had one hole.
 +
[12:41:37 PM] Gunther Schadow says: Didn't mean to stop the show. The show must go on, you know, always.
 +
[12:41:54 PM] Grahame Grieve says: we decided to plug it, but I regard it as a rearguard action
 +
[12:42:13 PM] Grahame Grieve says: and I don't think it's right to exclude qualifier from the check for CE, so I don't really know how to fix taht
 +
[12:42:42 PM] Grahame Grieve says: anyhow, lets move on.
 +
[12:43:29 PM] Gunther Schadow says: I agree with you if you compare if a CE == CD, you cannot suddenly exclude qualifiers.
 +
[12:43:40 PM] Grahame Grieve says: say I want to write a constraint that says that for my BAG<AD>, I don't want you to send me an address with the same validTime range more than once.
 +
[12:44:37 PM] Gunther Schadow says: AD a, b : a.validTime.equal(b.validTime).not
 +
[12:44:55 PM] Grahame Grieve says: ahh, no
 +
[12:44:59 PM] Grahame Grieve says: the full constraint
 +
[12:45:31 PM] Gunther Schadow says: what am I missing?
 +
[12:46:48 PM] Gunther Schadow says: invariant(BAGGIE<AD> ba, AD a, AD b) where(ba.contains(a).and.ba.contains(b)) {
 +
  a.validTime.equal(b.validTime).not
 +
}
 +
[12:46:50 PM] Gunther Schadow says: ?
 +
[12:47:27 PM] Grahame Grieve says: ah. let me rephrase the english. it was ambiguous
 +
[12:47:38 PM] Grahame Grieve says: I don't want you to send me the same address with the same validTime range more than once.
 +
[12:50:35 PM] Gunther Schadow says: this is just compounding the issue we discussed. What does "same address" mean? What does "same time range mean", when it comes to the edge cases.
 +
[12:50:53 PM] Grahame Grieve says: it's not about the semantic issues. This is about the technical issues
 +
[12:51:19 PM] Gunther Schadow says: Let's say, for sameness here we consider pairwise elements that are specified to the same level of completeness. Then it is all easy.
 +
[12:52:03 PM] Grahame Grieve says: I don't know what that means
 +
[12:52:04 PM] Grahame Grieve says: invariant(BAG<AD> x) where x.nonNull {
 +
  forAll(AD p) where AD.contains(p) {
 +
    forAll(AD q) where AD.contains(q) {
 +
    p.equals(q).not.implies(p.equals(q).implies(p.validTime.equals(q.validTime).not)
 +
  }
 +
};
 +
[12:52:54 PM] Grahame Grieve says: for each element p, for all the elements in the list q, if p is not q, and p = q, then the valid times must be different.
 +
[12:53:05 PM] Grahame Grieve says: but we can't say that, but we stole the assertion of identity away
 +
[12:53:21 PM] Grahame Grieve says: we say,
 +
[12:53:48 PM] Grahame Grieve says: One can think of data values as immutable objects where identity does not matter (identity and equality are the same.)
 +
[12:54:09 PM] Grahame Grieve says: so, AD with the same parts, but different use codes, these are not only equal, but they are the same identity
 +
[12:54:43 PM] Grahame Grieve says: to me, this is like the other issue - we know what we mean, but we don't say what we mean, and we invite people to "understand" what we mean instead of what we say
 +
[12:55:44 PM] Gunther Schadow says: So, we are saying the use code factors not in equal? That would seem strange to me (now anyway).
 +
[12:55:53 PM] Grahame Grieve says: we said that.
 +
[12:56:06 PM] Gunther Schadow says: That seems not right.
 +
[12:56:19 PM] Gunther Schadow says: Except
 +
[12:56:35 PM] Grahame Grieve says: so, I pick another example. We said that equality for a CD includes code, codeSystem and qualifiers.
 +
[12:56:52 PM] Gunther Schadow says: if we say that if two addresses are equal but you have different use codes for them, we can just merge the address and take the union of the use code set.
 +
[12:57:11 PM] Grahame Grieve says: so two CD's are equal, whatever their translations and original text, and whatever, they are the *same* CD
 +
[12:57:13 PM] Lee Coller says: not if their valid times are different
 +
[12:57:41 PM] Gunther Schadow says: Well, CDs don't have valid time.
 +
[12:57:51 PM] Grahame Grieve says: I think it's worth defining semantic equality. But we are completely confused here, because we lie. either equality and identity are the same, or they are not
 +
[12:58:01 PM] Lee Coller says: I was referring to AD
 +
[12:58:02 PM] Gunther Schadow says: But yes, whatever their translations. BUT we know very well that translations cause issues.
 +
[12:58:30 PM] Gunther Schadow says: The problems come with annotations.
 +
[12:58:43 PM] Grahame Grieve says: I'll pick a different example then. it doesn't matter. The principle is, semantic equality is not the same as technical identity.
 +
[12:58:47 PM] Gunther Schadow says: Good hard example is "codeSystemVersion".
 +
[12:58:58 PM] Grahame Grieve says: sure. let's go with that. who cares about it right.
 +
[12:59:22 PM] Gunther Schadow says: Many people say they care, that's why I say "hard" example.
 +
[1:00:28 PM] Grahame Grieve says: ok. we surely agree that
 +
<code code="AUS" codeSystem="2.16.840.1.113883.11.171" codeSystemName="ISO 3166 / 3" displayName="Australia"/>
 +
<code code="AUS" codeSystem="2.16.840.1.113883.11.171" codeSystemName="ISO 3 letter characters"
 +
refer to the same code
 +
[1:00:52 PM] Gunther Schadow says: Yes.
 +
[1:00:56 PM] Grahame Grieve says: duh, missed the end of the example but it doesn't matter
 +
[1:01:10 PM] Gunther Schadow says: That's an easy one.
 +
[1:01:22 PM] Gunther Schadow says: It's a useless annotation. Like a comment in program code.
 +
[1:01:42 PM] Gunther Schadow says: I mean, not useless but without effect.
 +
[1:01:50 PM] Grahame Grieve says: sure. they are not meaningfully different. and we don't want to think about them when we compare two CD's to see if they can go into a SET together
 +
[1:02:37 PM] Gunther Schadow says: So that's the lowest point where your proposed pairwise comparison of non-null properties breaks down.
 +
[1:02:59 PM] Grahame Grieve says: what proposed comparison?
 +
[1:04:16 PM] Grahame Grieve says: I haven't proposed anything quite yet, except that we should have a difference between semantic equivalence and technical equality
 +
[1:04:41 PM] Grahame Grieve says: are these equal?
 +
[1:04:41 PM] Grahame Grieve says: <code code="AUS" codeSystem="2.16.840.1.113883.11.171" codeSystemName="ISO 3166 / 3" displayName="Australia">
 +
  <originalText>Australia</originalText>
 +
</code>
 +
<code code="AUS" codeSystem="2.16.840.1.113883.11.171" codeSystemName="ISO 3 letter characters" displayName="Australia">
 +
  <originalText>South from Indonesia</originalText>
 +
</code>
 +
[1:05:18 PM] Grahame Grieve says: though I shouldn't really, we shouldn't be arguing about the meaning of semantic equality for CD, that's no the point
 +
[1:07:00 PM] Grahame Grieve says: This is all in reference to proposal 12.
 +
[1:08:47 PM] Grahame Grieve says: there's some strong comments there. But we are broken. So what I would like to do is to define technical equality strictly based on all properties, as simple as possible, widen the definitions of semantic equality to define it explicitly for everything, and then allow explicit statements of uniqueness for SETs
 +
[1:08:59 PM] Grahame Grieve says: the last is where it breaks down - that's HARD to implement
 +
[1:09:43 PM] Grahame Grieve says: but that's the thing that needs fixing. We are cheating and avoiding the hard problem. And then we do something really stupid like have BAG<AD> to work around the constraint we tried to create in the first place. dumb.
 +
[1:10:43 PM] Gunther Schadow says: The two with the different original text are equal in my view. Technically as well as semantically. The technology needs to implement semantics.
 +
[1:11:04 PM] Grahame Grieve says: so they are also identical then?
 +
[1:11:53 PM] Grahame Grieve says: java knows about this issue. it's why = and .equal() are different. can catch you out if you aren't aware, of course, but there's a useful reason for it.
 +
[1:11:54 PM] Gunther Schadow says: There is no identity with values. What does it mean? Where does it matter?
 +
[1:12:28 PM] Grahame Grieve says: you still haven't explained how to implement that constraint that I talked about
 +
[1:12:40 PM] Grahame Grieve says: > I don't want you to send me the same address with the same validTime range more than once.
 +
[1:13:00 PM] Gunther Schadow says: Why do I even care about that constraint?
 +
[1:13:03 PM] Grahame Grieve says: in a single BAG - though I guess that was implicit
 +
[1:13:18 PM] Gunther Schadow says: Some of these constraints are useless, why should one even check for that?
 +
[1:13:51 PM] Grahame Grieve says: I don't think that one is useless. It came from a user trying to make sense of why entity.address is BAG not SET
 +
[1:14:07 PM] Gunther Schadow says: You send me two addresses where one is awfully similar to the other and I will decide to lump them, or keep them both (and pick one or the other at random).
 +
[1:14:26 PM] Grahame Grieve says: but the point is the underlying one, that a constraint like that will use equals to decide whether two things have the same identity
 +
[1:14:43 PM] Grahame Grieve says: how will you keep them both while conforming the spec? you can't even tell them apart from each other
 +
[1:14:57 PM] Gunther Schadow says: I don't need to keep them both.
 +
[1:15:07 PM] Grahame Grieve says: well, you brought that up.
 +
[1:15:25 PM] Grahame Grieve says: Lee - what does Oracle think about this - would you be happy to not tell them apart?
 +
[1:16:24 PM] Lee Coller says: In that case we probably would ignore the differences, if you sent me two similar addresses with the same valid time, we'd just use both of them
 +
[1:16:38 PM] Lee Coller says: The problem comes when someone tries to remove an addresss, which one do we remove?
 +
[1:16:42 PM] Grahame Grieve says: what about the converse - same address with two different valid times
 +
[1:17:04 PM] Lee Coller says: That's legitimate unless they overlap
 +
[1:17:26 PM] Lee Coller says: right now we don't check for that overlap though, so we'd just keep both of them
 +
[1:17:31 PM] Grahame Grieve says: you would keep them both and consder them different?
 +
[1:17:38 PM] Lee Coller says: yes
 +
[1:17:52 PM] Grahame Grieve says: but you're not supposed to, because validTime doesn't differentiate them
 +
[1:18:48 PM] Lee Coller says: It's not a constraint we check right now.  I'd have to check our underlying model to see if it could become an issue.
 +
[1:20:21 PM] Lee Coller says: We have another oracle product we integrate with on this.  It may care, I'll have to check (I can't right now).  As I think about it it probably will for some addresses (i.e., if I need to mail something to you, where do I mail it).
 +
[1:21:19 PM] Gunther Schadow says: One can argue that anything collection of a HIST<T> is really a LIST. I think that's what we say.
 +
[1:22:02 PM] Gunther Schadow says: Since AD implements the HIST interface if validTime is IVL<TS>, then this SET should be considered a LIST really.
 +
[1:22:26 PM] Grahame Grieve says: ? HIST is a set
 +
[1:22:56 PM] Grahame Grieve says: and it's kind of a fun outcome, that SET is really a LIST
 +
[1:23:56 PM] Gunther Schadow says: Sloppy thinking, eh? O.K. then the issue applies for any HIST<T>. I'm not saying you have no point that something needs fixes, I'm just not sure it has to do with your new simple minded definition of equality.
 +
[1:24:40 PM] Gunther Schadow says: Rather than getting all upset over "constraints" perceived on the definition of SET etc., I'd like to ask: so what do we mean, what do we want?
 +
[1:25:00 PM] Gunther Schadow says: Then we make technology that works like what we mean and does what we want.
 +
[1:26:24 PM] Grahame Grieve says: well, I think that we want equality to be identity. and we want to define semantic equality without the constraint that that's tied to identity - things that are not identical may be semantically equal. and we want the flexibility to define how a set is unique
 +
[1:27:05 PM] Gunther Schadow says: The idea of a set is that it imposes no order and no replication of elements. But there is nothing preventing you from making a union of one set with a set of a single element. What exactly happens to meaningless annotations in that case is simply undefined.
 +
[1:27:15 PM] Grahame Grieve says: which get's to the HIST issue. a HIST<AD> may actually contain a number of identical entries differing only by their validTime - and that makes perfect sense
 +
[1:27:32 PM] Grahame Grieve says: so?
 +
[1:27:48 PM] Gunther Schadow says: " I think that we want equality to be identity" - I don't know that.
 +
[1:27:57 PM] Grahame Grieve says: where as a SET<AD> - that is really saying, send me a list of different addresses
 +
[1:28:06 PM] Grahame Grieve says: we say that
 +
[1:28:55 PM] Gunther Schadow says: "which get's to the HIST issue. a HIST<AD> may actually contain a number of identical entries differing only by their validTime - and that makes perfect sense" - O.K. agreed,
 +
 
 +
"where as a SET<AD> - that is really saying, send me a list of different addresses" - then there's something wrong here.
 +
[1:29:12 PM] Grahame Grieve says: ?
 +
[1:29:19 PM] Gunther Schadow says: If we really say "send me a list of different addresses" then why do we like validTime in address?
 +
[1:29:51 PM] Grahame Grieve says: cause people are allowed to move. Stupid really, but there you go
 +
[1:30:15 PM] Gunther Schadow says: When they move, it's just a HIST<AD>. No problem then. I think, what we really mean here is "a bunch of addresses"
 +
[1:30:17 PM] Gunther Schadow says: ...
 +
[1:30:49 PM] Gunther Schadow says: there was once a difference between a simple HXIT<T> where validTime was just IVL<TS> and an AD and TEL where validTime was SET<T> (alias "GTS").
 +
[1:31:19 PM] Gunther Schadow says: that extension of HIST is where the problem comes from. It is valid use case for addresses and telephone numbers.
 +
[1:31:27 PM] Gunther Schadow says: But it
 +
[1:31:45 PM] Gunther Schadow says: 's solution with the SET<T> is causing grief.
 +
[1:31:46 PM] Grahame Grieve says: yes, I was going to get around to pointing out that only EN conforms to HXIT, and it doesn't do that anymore in R2
 +
[1:32:12 PM] Gunther Schadow says: Has someone changed EN.validTime to GTS???
 +
[1:32:23 PM] Grahame Grieve says: no, someone's added to HXIT
 +
[1:32:35 PM] Gunther Schadow says: added what?
 +
[1:32:46 PM] Grahame Grieve says: so EN.validTime still conforms to HXIT.validTime, but we added controlActIdRef to HXIT
 +
[1:33:00 PM] Grahame Grieve says: sure you knew this? we discussed it somewhere
 +
[1:33:03 PM] Gunther Schadow says: That can apply back to EN and AD no problem.
 +
[1:33:24 PM] Grahame Grieve says: sure, but it doesn't make sense as a property of the datatype, unlike validTime
 +
[1:34:01 PM] Gunther Schadow says: it does make sense in so far as we are talking about the history.
 +
[1:34:14 PM] Grahame Grieve says: in fact, I was thinking of moving controlActIdRef to the same section as updateMode and flavorId, since it's not really a semantic property of the datatype
 +
[1:34:29 PM] Grahame Grieve says: of course- when we talk about history it makes sense
 +
[1:34:31 PM] Gunther Schadow says: AD is a history AND this wild snowbird-and-business-hours issue.
 +
[1:35:02 PM] Grahame Grieve says: so, maybe we just have a harmonisation proposal to change address and name to HIST<?> everywhere in the RIM and the models?
 +
[1:35:26 PM] Grahame Grieve says: though we are avoiding the real issue
 +
[1:35:43 PM] Gunther Schadow says: With the difference that AD and TEL's .... no, wait, usablePeriods it is no. So we really only talk about EN these days?
 +
[1:36:19 PM] Gunther Schadow says: Isn't AD's validTime called "usablePeriods" now?
 +
[1:36:34 PM] Grahame Grieve says: well, in terms of auto being a HXIT, yes, but hey, why not make EN.validTime a GTS to be consistent?
 +
[1:37:16 PM] Grahame Grieve says: and there's still the issue with HXIT.validTime and EN.validTime - is one validTime the period when *I knew* what the value was, and is the other when it actually was?
 +
[1:37:19 PM] Gunther Schadow says: HL7 - consistency over intelligence .... or what was this bumper sticker you had there?
 +
[1:37:35 PM] Lee Coller says: EN.validTime as a GTS, absolutely not
 +
[1:37:44 PM] Grahame Grieve sent file "hl7_consistency.jpg" to members of this chat
 +
[1:39:26 PM] Lee Coller says: TShirts?
 +
[1:40:14 PM] Grahame Grieve says: maybe. Would be funny to go to the meeting wearing t-shirts like that. though HQ would NOT BE AMUSED
 +
[1:40:29 PM] Gunther Schadow says: agree with Lee, no EN.validTime should be GTS.
 +
[1:41:24 PM] Gunther Schadow says: I would not wear it. Out of loyalty to my colleagues with whom I disagree.
 +
[1:42:29 PM] Grahame Grieve says: well, that whole EN.validTime as a GTS was a brick in the conversation. Was a joke, really (almost completely)
 +
[1:43:06 PM] Lee Coller says: Good, I feel better now
 +
[1:43:07 PM] Grahame Grieve says: and there's still the issue with HXIT.validTime and EN.validTime - is one validTime the period when *I knew* what the value was, and is the other when it actually was?
 +
[1:43:11 PM] Gunther Schadow says: So, EN.validTime conforms to HIST. Except, perhaps, that we also have alias names. It's two dimensions, aliases and history.
 +
[1:43:37 PM] Grahame Grieve says: two dimensions - use and history - same for AD and TEL too
 +
[1:44:10 PM] Lee Coller says: The current definition of HIST implies when it actually was (The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item.)
 +
[1:45:09 PM] Lee Coller says: And from HXIT Definition:      The time interval during which the given information was, is, or is expected to be valid. The interval can be open or closed infinite or undefined on either side.
 +
[1:45:20 PM] Grahame Grieve says: yeah, but then you do read the audit trail stuff in HDF, and they are not thinking what way.
 +
[1:45:34 PM] Grahame Grieve says: hey - inconsistency and lack of intelligence
 +
[1:46:07 PM] Lee Coller says: I always thought it was audit too.  The addition of controlActRefII implies that it's audit, but the current definition says otherwise.
 +
[1:49:23 PM] Lee Coller says: That may be because my first exposure to this was when we talked about adding controlActID two years ago
 +
[1:50:41 PM] Grahame Grieve says: yes, well, here's the definition we agree for that:
 +
The identifier of the ControlAct associated with setting the datatype to its specified value. By referencing a particular ControlAct, the property links to all of the information surrounding that ControlAct, such as who made the change, when it was made, why it was made, what system originated the change, etc.
 +
[1:50:47 PM] Grahame Grieve says: kind of screwed up, really
 +
[1:50:56 PM] Grahame Grieve says: at least it hasn't gone to ballot yet
 +
[2:00:16 PM] Grahame Grieve says: LLoyd - we have you to blame for controlActIdRef - any comment?
 +
[2:21:19 PM] Lloyd McKenzie says: Why kind of screwed up?
 +
[2:21:53 PM] Lloyd McKenzie says: We need to be able to tie every change to every attribute to a specific person and reason and possibly supervisor and location
 +
[2:22:03 PM] Lloyd McKenzie says: Can't think of a more elegant way to do this
 +
[2:22:17 PM] Grahame Grieve says: The current definition of HIST implies when it actually was (The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item.)
 +
[2:22:27 PM] Grahame Grieve says: but the definition of controlActIdRef implies differently
 +
[2:22:35 PM] Grahame Grieve says: in fact, the concept of it implies something different
 +
[2:37:33 PM] Lloyd McKenzie says: HIST allows you to look at past values
 +
[2:37:50 PM] Lloyd McKenzie says: HXIT tells you a little bit about the specific change
 +
[2:37:59 PM] Lloyd McKenzie says: However, it doesn't tell you enough
 +
[2:38:51 PM] Lloyd McKenzie says: We need more information, than just the time
 +
[2:39:20 PM] Grahame Grieve says: ?
 +
[2:39:36 PM] Lloyd McKenzie says: HXIT gives you the time of the change
 +
[2:39:44 PM] Grahame Grieve says: say I changed my name - why do you need more information than the time I did this?
 +
[2:39:44 PM] Lloyd McKenzie says: We need the author, reason and other information too
 +
[2:39:57 PM] Lloyd McKenzie says: Because that's the use-case
 +
[2:39:59 PM] Grahame Grieve says: I'm the author, I don't care to give you my reason
 +
[2:40:03 PM] Lloyd McKenzie says: We need to know who changed it and why
 +
[2:40:16 PM] Lloyd McKenzie says: In our provider registry, if you don't give a reason, you can't make a change
 +
[2:40:38 PM] Lloyd McKenzie says: The requirement is definite
 +
[2:40:46 PM] Grahame Grieve says: I don't need a reason, I can just give myself an alias and start using it
 +
[2:40:51 PM] Lloyd McKenzie says: If you don't like the mechanism, propose a different one
 +
[2:41:03 PM] Grahame Grieve says: I'm still confused as to your use case
 +
[2:41:17 PM] Lloyd McKenzie says: Reasons might be "legal change", "error", "change in preference", etc.
 +
[2:41:52 PM] Grahame Grieve says: HIST is the history of names I have used. HXIT is the time that I used the name. You're insisting that I have to notify everyone in the world to get permission to change my name?
 +
[2:42:21 PM] Lloyd McKenzie says: I'm saying that in order to make a change in the registry, you need to give a reason.
 +
[2:42:36 PM] Lloyd McKenzie says: It's not the provider's reason, it's the clerk's reason
 +
[2:43:31 PM] Grahame Grieve says: oh - but you are talking about something different. You are saying that the HIST<EN> is the registries history of when it knew that a given name was a assigned to a person?
 +
[2:44:39 PM] Lloyd McKenzie says: Which is what a registry cares about
 +
[2:45:14 PM] Lloyd McKenzie says: We care about the ControlAct that revised the registry entry - when did it happen, who did it, why did they do it.
 +
[2:45:16 PM] Grahame Grieve says: but that's not what HIST is about. check the definition again
 +
[2:45:25 PM] Grahame Grieve says: The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item.
 +
[2:45:49 PM] Lloyd McKenzie says: Why do you need a time then?
 +
[2:45:57 PM] Lloyd McKenzie says: time is one piece of metadata about the change
 +
[2:46:07 PM] Lloyd McKenzie says: We need more pieces of metadata
 +
[2:46:51 PM] Lloyd McKenzie says: Fundamentally, MnM reviewed and approved this, including roundtable discussion.  It's been balloted as part of the HDF.
 +
[2:47:03 PM] Lloyd McKenzie says: The use-case exists and has been accepted
 +
[2:47:59 PM] Grahame Grieve says: fine, but it causes a problem in the datatypes, a tension in the meaning of HXIT
 +
[2:48:04 PM] Lloyd McKenzie says: If you want to handle this some other way, please indicate how, but don't say we're not going to support it.
 +
[2:48:16 PM] Lloyd McKenzie says: I don't think it's inconsistent with HXIT
 +
[2:48:38 PM] Grahame Grieve says: the datatypes say it is about the value itself, but the MnM view says that it's about the observation of the value, rather than the value.
 +
[2:48:39 PM] Lloyd McKenzie says: HXIT says "this is a historical version"
 +
[2:49:15 PM] Grahame Grieve says: I think it is inconsistent, because if I used the name "bozo" from 2002 - 2004, and you found out about it in 2003, and found out I stopped using in 2005, which range applies?
 +
[2:49:16 PM] Lloyd McKenzie says: What's wrong with tying it to the ControlAct that caused that historical version to come into being?
 +
[2:49:49 PM] Grahame Grieve says: I'm not saying at all that I don't want to solve the problem. I'm just concerned about the definition of HXIT at this point
 +
[2:50:38 PM] Grahame Grieve says: if you bothered to read the screeds that went before (don't) you'd see that we got to here from another angle, talking about HIST and uniqueness. Gunther will dig in and fight for the existing definition of HXIT and HIST. It won't be pretty
 +
[2:52:37 PM] Lloyd McKenzie says: In the case of what you're looking for, the validTime is 2002-2004.  The effectiveTime on the ControlAct is 2003.
 +
[2:52:42 PM] Lloyd McKenzie says: (And we care about both :))
 +
[2:53:00 PM] Lloyd McKenzie says: I don't see how this is inconsistent
 +
[2:54:45 PM] Grahame Grieve says: it is when you say: HXIT gives you the time of the change
 +
[2:54:52 PM] Grahame Grieve says: only if you qualify this to say:
 +
[2:55:06 PM] Grahame Grieve says: HXIT.controlActIdRef gives you the time of the change if you go look at the control act (if you have it)
 +
[2:55:15 PM] Lloyd McKenzie says: Correct
 +
[2:56:41 PM] Grahame Grieve says: so, now it bothers me a lot that validTime and controlActIdRef are bunched together - it seems that the use case for them is rather different
 +
[2:57:46 PM] Lloyd McKenzie says: I don't see them as that diverse.  However, if you don't want it there, how on earth do we meet the use-case?
 +
[2:59:00 PM] Grahame Grieve says: well, we could do it rather more directly, like updateMode, but pulling controlActIdRef off HXIT, and declaring it with updateMode, and saying that it works the same way.
 +
[3:00:50 PM] Lloyd McKenzie says: If that makes people happier, I could live with it.
 +
[3:01:06 PM] Lloyd McKenzie says: To me, this is about history, and therefore HXIT is the most logical place
 +
[3:01:19 PM] Grahame Grieve says: adds a flag to the MIF, I know, but there you do. Doesn't deal with allowing a full history though - for that you need HIST<T> not HXIT<T>, but you can't just introduce HIST<T> - in fact, where could you use it?
 +
[3:01:28 PM] Lloyd McKenzie says: However, so long as we can meet the requirement (and control where it's allowed and where it's not), then I'm happy
 +
[3:01:38 PM] Lloyd McKenzie says: We will need to run any change past MnM though
 +
[3:03:24 PM] Grahame Grieve says: don'
 +
[3:03:58 PM] Grahame Grieve says: don't know. so far it pleases nearly one person - me. no hurry. but where could you use HIST<T>? only on things that are SETs already?
 +
[3:05:08 PM] Lloyd McKenzie says: As far as the methodology concerned it's one of those "magical inconsistencies"
 +
[3:05:34 PM] Lloyd McKenzie says: Apparently we're allowed to declare that any attribute (or association) is HIST, which automatically allows repetitions
 +
[3:08:25 PM] Grahame Grieve says: riiiight
 +
[3:09:26 PM] Grahame Grieve says: that's pretty magical all right
 +
[3:09:27 PM] Lloyd McKenzie says: The alternative was making all the RIM classes HIST<x>
 +
[3:09:40 PM] Lloyd McKenzie says: attributes I mean
 +
[3:09:43 PM] Grahame Grieve says: I could've come up with something better than that
 +
[3:10:23 PM] Lloyd McKenzie says: Also note that HIST (as defined) is currently used in balloted specs, which I believe have passed ballot
 +
[3:10:42 PM] Lloyd McKenzie says: (It was pre-adopted in the ITS 2 years ago)
 +
[3:11:01 PM] Grahame Grieve says: what's wrong with HXIT<T> having historical : SET<T> - much cleaner all round
 +
[3:12:27 PM] Grahame Grieve says: well, at least that screw up is out side the datatypes. anyhow, I assert that the mere fact that HIST can be used like that indicates that the use case is the validTime of the observation of the value, not the value itself
 +
[7:42:21 PM] Grahame Grieve says: Now that I have the xml its building, why do the examples and the xml representation sections lose their formatting in the build from the cvs files, but not in the normative build? does anyone know off the top of their heads?
 +
[8:14:13 PM] Grahame Grieve says: no comment from anyone on CO; I am removing the CO operations. Someone can ballot if they want them. I will put a comment in about them
 +
[8:18:55 PM] Grahame Grieve says: "      It has been proposed that some mathematical operations
 +
      should be defined on CO itself. Given the kinds of uses
 +
      for CO, addition and averaging appear to be candidate
 +
      operations. However defining these operations on CO implies
 +
      that these are operations upon the concept itself, not the
 +
      value assigned the concept. It is not clear that this is true,
 +
      and so not operations have been defined. This may be reviewed
 +
      if appropriately defined codeSystems are identified.
 +
"
 +
[11:23:42 PM] Gunther Schadow says: Quick recap: validTime is supposed to be the time this thing really was, not the time someone knew it. You can leave that unchanged. If you have controlActRef, then that control act will carry the time someone made the change to some system to accomodate new knowledge of things. So, the definition of HXIT validTime is correct and fine, and Lloyd's use case is taken care of by the controlActRef.
 +
[11:24:42 PM] Gunther Schadow says: If you expect a T and get a HIST<T> you'd pick the one with the current validTime. The XML spec could say that that has to be the first or last one.
 +
[11:26:28 PM] Gunther Schadow says: Whoever "preadopted" a reading of HXIT.validTime which violates the definition (i.e., marking system change time rather than real world time), need to fix their interpretation to come back in line with the clear statement in the spec.
 +
[11:28:40 PM] Gunther Schadow says: Finally, ControlAct.effectiveTime cannot be the time that some specific value had effect in the real world. ControlAct.effectiveTime must be the time at which whatever the ControlAct does, is to take effect, i.e., if the ControlAct says "change some data" then the effectiveTime would be as of what time this change should be made. Few should allow back-dating this..
 +
[11:29:50 PM] Gunther Schadow says: Finally, finally, you have some problems, i.e., what if the value did not actually change in the world, what if it was just entered wrong? Then you can't make a real history of the real value. That's why Grahame's pointing to update mode is considerable.
 +
[11:31:11 PM] Grahame Grieve says: fine, but if we work back, we haven't solved the prior problems. about uniqueness in a HIST, about equality/identity. I know you think the latter isn't a problem, but, well, we should get the formalisms right
 +
[11:41:15 PM] Gunther Schadow says: HIST was confusing. I'd be frustrated now that your truck show has been so fizzled out. How to regroup?
 +
 
 +
I agree that there is something about properties having different standing when it comes to equal that needs better explanation. I've started that long ago with calling some properties "mandatory" (if they always exists in a non-Null value) and "optional" if they needn't be there and "auxiliary" if they are just annotations, not contributing to the semantics.
 +
[11:42:09 PM] Grahame Grieve says: it hasn't fizzled out, we got diverted onto worthy subjects. I will regroup and get the show on the road again
 +
[11:42:35 PM] Gunther Schadow says: As soon as we have stuff haging on values that doesn't contribute to the semantics, but which people nevertheless put there and look up from there, it creates the sense of object with identities and value being distinguished. Like numbers with little notes attached. Even though 5 == 5, suddenly this 5 looks a little different than that 5.
 +
[11:42:56 PM] Lloyd McKenzie says: Gunght is correct - we should be talking about ControlAct.author.time, not ControlAct.effectiveTime
 +
[11:43:48 PM] Lloyd McKenzie says: If what you're dealing with is a registry entry, then what's in the system *is* the real world
 +
[11:44:36 PM] Lloyd McKenzie says: If something is entered, it's real, even if it's wrong
 +
[11:44:44 PM] Gunther Schadow says: [Sorry, I disagree to the registry entry == real world, but want to stick to the issue of annotational properties now.]
 +
[11:44:50 PM] Lloyd McKenzie says: Wrong values show up in history
 +
[11:45:39 PM] Grahame Grieve says: yes. we have something to do there. I am about to go to sleep, will pick it up tomorrow
 +
[11:46:52 PM] Gunther Schadow says: For some of these annotational properties, it is completely irrelevant. These properties should not even exist IMO. These include CD.codeSystemName, II.assigningAuthorityName. These properties are purely commentary and can be scrapped any time. They are in fact dangerous.
 +
[11:46:54 PM] Lloyd McKenzie says: If someone incorrectly enters your name as Joe Smith and later changes it to John Smith, both will show up in history
 +
[11:47:02 PM] Lloyd McKenzie says: They have to.
 +
[11:48:25 PM] Gunther Schadow says: There are more such dangerous properties, evene CD.displayName carries a danger, because people can use it unchecked, i.e., just displaying the displayName without making sure that it is consistent with the code. Still, displayName has a great use (and I'm using it like crazy), but it needs to be clear that you put a tremendous trust in your sender if you ever use their displayName to display to your users.
 +
[11:49:55 PM] Gunther Schadow says: displayName also is good to wonder about
 +
 
 +
<genderCode code="M" displayName="female" codeSystem="&hl7gendercodeoid;"/>
 +
 
 +
and
 +
 
 +
<genderCode code="M" displayName="male" codeSystem="&hl7gendercodeoid;"/>
 +
 
 +
are these equal?
 +
[11:51:59 PM] Grahame Grieve says: that's invalid. You can't ask valid questions about invalid data
 +
[11:52:41 PM] Grahame Grieve says: I think that they are "equal" though. I think the semantic equality rules for CD are fine.
 +
[11:53:10 PM] Grahame Grieve says: either the displayname counts or it doesn't. and we don't have the machinery to nail it down
 +
[8:43:58 AM] Grahame Grieve says: ok,back on the subject of null and equality, can anyone see anything wrong with this xml?
 +
<example xsi:type="CE" code="195967001" codeSystem="2.16.840.1.113883.19.6.96" codeSystemName="SNOMED CT">
 +
  <displayName value="Asthma"/>
 +
  <translation code="49390" codeSystem="2.16.840.1.113883.19.6.2" codeSystemName="ICD9CM">
 +
    <displayName value="ASTHMA W/O STATUS ASTHMATICUS"/>
 +
  </translation>
 +
  <translation nullFlavor="OTH" codeSystem="2.16.840.1.113883.19.6.45" codeSystemName="Something">
 +
  </translation>
 +
</example>
 +
[8:45:01 AM] Grahame Grieve says: ahh - it's not the xml that's wrong (not deliberately, that's the ISO datatypes format), it's the semantics. just move displayName back to being an attribute
 +
[8:46:15 AM] Grahame Grieve says: and since we're all busy, and what not, the problem is that this is illegal. You cannot have a set that contains a null value. While this is a problem for CD - something we'll take up next - this is generally a problem with a set definition. Particularly in regard to HIST
 +
[8:48:38 AM] Grahame Grieve says: it seems to me that HIST specialises SET is basically wrong. it should be HIST specialises LIST. LIST can contain nulls, LIST has a concept of order (though there's no rule that the HXIT<s> cannot overlap or have to be in order, it seems reasonable for HIST to sometimes have order significance), LIST has no uniqueness constraint (not that it makes sense for HIST to have duplicates, but trying to define a sensible workable uniqueness constraint for HIST is not going to be easy)
 +
[8:48:51 AM] Grahame Grieve says: but I've got diverted to HIST again....
 +
[8:53:25 AM] Grahame Grieve says: It makes sense that sets can't contain null values because if it did, you couldn't evaluate uniqueness. So we don't want to change that.
 +
[8:54:39 AM] Grahame Grieve says: But I think that the fact that SET cannot contain nulls is something that slips under the radar.
 +
[8:55:26 AM] Grahame Grieve says: looking at the RIM...
 +
[8:56:21 AM] Grahame Grieve says: a slight deviation before pursuing this. Act.priorityCode:: SET<CE> - how can it make sense for something to be a SET<CE>? a single act can have multiple different priorities that are not translations of each other - is that really the intent?
 +
[8:57:30 AM] Grahame Grieve says: I think that the idea that Act.interpretationCode cannot contain CD with nullFlavor OTH might be a surprise to some people. Whoops, I'm back on CD. More on that later
 +
[8:57:43 AM] Grahame Grieve says: (and methodCode, and targetSiteCode)
 +
[8:59:56 AM] Lee Coller says: There can be different kinds of priorities, look at the informative vocabulary for it
 +
[9:01:24 AM] Grahame Grieve says: hmm. ok, like useCode, I guess. UD doesn't seem to belong there, but whatever
 +
[9:03:05 AM] Grahame Grieve says: act.id bans null - ironically, this was probably perfectly reasonable until we add II.scope in R2, and now people will suddenly find a use case for sending null IIs (we didn't bother asking what the business identifier was)
 +
[9:16:16 AM] Grahame Grieve says: no takers. Ok. I propose changing HIST from SET to LIST.
 +
[9:19:33 AM] Grahame Grieve says: btw, Rik has pointed out this:
 +
RIM definition for InfrastructureRoot.nullFlavor:When valued in an instance, this attribute signals that the class instance is null, and that the remainder of the information for this class and its properties will not be communicated.
 +
[9:19:55 AM] Grahame Grieve says: different issue, because it's about class, but I point out that the structural attributes need to be communicated.
 +
[9:25:19 AM] Gunther Schadow says: " I propose changing HIST from SET to LIST." - I'm fine with it. If HXIT.validTime stays IVL<TS>, no problem. We should then also say that this list must be ordered in chronological order (ascending) with the effective prevailing value last. (Why not reverse chronology? Because simple minded systems can just keep reading the value of the attribute till the end and so the last assignment prevails.
 +
[9:26:06 AM] Gunther Schadow says: " the remainder of the information for this class and its properties" -- they mean object. Why do people say "class" if they mean object?
 +
[9:26:24 AM] Lee Coller says: It's actually worse than that (communicating structural attributes) in some cases.  You may need to also send the structural attributes of the other end of the relationship.  That's because sometimes the only thing that distinguishes two clones are the structural attributes of the navigated-to relationship
 +
[9:26:51 AM] Grahame Grieve says: chronological order - cool, maybe, but do we have to do a precise definition for overlaps - go by low, I guess, and start with any where low is null and then order by high, if both low and high are null?
 +
[9:27:16 AM] Grahame Grieve says: Lee, can you provide an example?
 +
[9:27:19 AM] Lee Coller says: "Why do people say "class" if they mean object?"  I agree, its gotten so bad even I slip up and do it sometimes
 +
[9:28:03 AM] Lee Coller says: Yes, let me bring up
 +
[9:33:52 AM] Lee Coller says: http://www.hl7.org/v3ballot/html/domains/uvct/editable/COCT_RM540000UV.htm
 +
[9:33:57 AM] Lee Coller says: A_GeneticLoci
 +
[9:35:07 AM] Lee Coller says: Has componet1 and component2 ActRelationship clones.  If one is null, to tell which one it is I need the structural attributes of the target class.
 +
[9:35:17 AM] Lee Coller says: Of course, this could be fixed by saying the target is null, not the relationship
 +
[9:35:54 AM] Grahame Grieve says: but you get the names component1 and component2 to tell them apart?
 +
[9:36:17 AM] Lee Coller says: But the clone names are not supposed to convey semantics
 +
[9:36:43 AM] Grahame Grieve says: agree; but they are supposed to convey the link into the model
 +
[9:37:56 AM] Lee Coller says: But that is a counter argument to the fact you need to send structural attributes on nulls, because you can always use the clone names
 +
[9:38:01 AM] Grahame Grieve says: so it doesn't seem like conveying semantics unless you are trying to work without specific knowledge of the model. Then you would need to know more; I guess that since we accept that kind of approach, we should therefore rule that you couldn't call the relationship null, but the target
 +
[9:38:34 AM] Grahame Grieve says: yes, agree, but sometimes the clone names only identify <= domain/x domain, not a specific code.
 +
[9:39:09 AM] Lee Coller says: then theoretically the domains across the clones should be disjoint (really hard if they are CWE)
 +
[9:40:09 AM] Lee Coller says: thow in null and I don't think it would work
 +
[9:40:56 AM] Grahame Grieve says: in templates parlance, this is known as model indeterminacy. It's impossible to prevent, hard to find, but I couldn't find any existing models like that, and trying to make one up that was reasonably coherent was a challenge
 +
[9:41:28 AM] Grahame Grieve says: but adding to the mix that the targets could be null considerably increases the likelihood and reasonableness
 +
[9:42:56 AM] Lee Coller says: I've seen them, I negative ballot them when I find them.  Genetic Locus used to be like that (all OBS)
 +
[10:16:26 AM] Gunther Schadow says: Lee, I don't think I would care, because in my world both would just be components. So one isn't there. I cannot tell which, and I don't need to use null flavor nuances here. If I needed to, then I would have to leave the act relationship and the distal object properly categorized and marked as null. I could get that out of the MIF I suppose. I need the MIF anyway in order to interpret the ideosyncratic names of tags.
 +
[10:18:09 AM] Grahame Grieve says:
 +
I was thinking as I was driving in to work today - Gunther and I (javaSIG and Eclipse) have a shared interface to the MIF, which could easily be declared in UML. I could define this as an underpinning framework for the abstract and UML ITS. This would give us a formal framework for making conformance statements in the datatypes
 +
[10:18:31 AM] Lee Coller says: In my world we claim that we can work without the model, and construct an instance based solely on structural attibutes without having to remember which clone class it tied back to.
 +
[10:19:02 AM] Grahame Grieve says: Aside to LLoyd: we could also use this as an XML format for the normative template format - avoids using the MIF directly, offers more interoperability in terms of dependence on UML type standards.
 +
[10:19:59 AM] Grahame Grieve says: Lee, under the HL7 rules, this cannot be true, because the structural attributes are defaulted. UK work differently, but in UV realm, you must read the model as you read the instance to connect the defaulted attributes up. Then you could interpret without the model. This is how Gunther works
 +
[10:20:56 AM] Lee Coller says: WE use the model to determine the defaults, but then we don't remember the model.  If the model is vague, we cannot then reconstruct it accurately
 +
[10:22:06 AM] Lee Coller says: That's the difference between what we do and what the UK does.  The UK says they don't need the model, we say we don't need to remember the model once we've populated defaults and fixed values.
 +
[10:22:43 AM] Grahame Grieve says: ok, you are the same as Gunther. And for the same reason, why would you care?
 +
[10:24:44 AM] Lee Coller says: For the null question I really don't becuase like Gunther, we don't use the null flavor nuances.  But if we did it would become an issue if I had multiple null relationships.
 +
[10:25:14 AM] Grahame Grieve says: but you can still link them up with the model and fill out these various thingies
 +
[10:32:54 AM] Lee Coller says: I started to write up my explanation, but hten I realized you are right its not an issue (actually I realize the problem is in our implementation but not the definition).  I can use the model to determine which is which -- I just need to make sure I keep that information when I save it.
 +
[12:42:41 PM] Grahame Grieve says: I have been thinking about equality vs identity. I think in the end, I have three real problems
 +
[12:43:30 PM] Grahame Grieve says: The first is that we claim that equality = identity, then we falsify that.This is an in principle issue, not one that has practical outworking issues for me, though I suspect it lies behind some of the problems with the mismatch between the definitions and the intentions
 +
[12:44:28 PM] Grahame Grieve says: The second turns on the definition of uniqueness of SET. I think that the second is not so much directly linked to identity vs equality as it is to the idea that different aspects of usage have different uniqueness constraints for different uses. HIST has demonstrated this well - HIST is really a SET where the (data+validTime) is unique, rather than SET where the data is unique
 +
[12:46:39 PM] Grahame Grieve says: The third may be linked to the first, and it relates to the definition of equality where some properties are null. We decided that I would go through and define equality explicitly for every data type, but it's still a blunt instrument. I can either include or exclude properties, but there is some properties that should be included if they are valued or have some kinds of null, else excluded.
 +
[12:59:30 PM] Grahame Grieve says: I don't think the third is amenable to a solution. We just have to suck it up.
 +
[1:01:22 PM] Grahame Grieve says: I don't think that the second is worth solving. One could do this by creating some kind of special SET that took an operation as a parameter, and insisted on uniqueness based on the parameter. Of course, uniquness isn't actually formally defined for a set, and could only possibly be defined for a DSET (if we had an identity function), but whoever heard of a class that takes an operation as a parameter.
 +
[1:02:15 PM] Grahame Grieve says: alternatively, we could just leave the things we really care about as BAGs, and write the constraint that we want for the few situations we really care - except that you do need the identity function in order to write those constraints.
 +
[1:03:10 PM] Grahame Grieve says: another alternative solution to the second problem is to create a whole series of different SETs and equals routines for different usages, pre-coordinating them... yeah ok, enough said. that's a spectacularly bad idea
 +
[1:04:45 PM] Grahame Grieve says: finally, we could take Gunther's head in the sand attitude to this problem. And that might be justified because not many people are aware of it - except when they ask why address is BAD<AD> not SET<AD>
 +
[1:05:05 PM] Grahame Grieve says: btw, Gunther, you didn't respond to my question about sorting HIST?
 +
[1:07:28 PM] Grahame Grieve says: would it hurt to turn a blind eye to identity vs equality, and define an .sameIdentity(other ANY) function, so we could write custom uniqueness constraints on BAGs?
 +
[1:07:50 PM] Grahame Grieve says: (if the answer to this is yes, then that's the end of the show, btw)
 +
[1:16:32 PM] Gunther Schadow says: "but whoever heard of a class that takes an operation as a parameter." -- not at all, great idea. It is simple, a Set that takes a Comparator as parameter. Makes perfect sense to me.
 +
[1:17:32 PM] Grahame Grieve says: k, we could do it that way. (duh). is it worth the investment?
 +
[1:19:33 PM] Gunther Schadow says: "btw, Gunther, you didn't respond to my question about sorting HIST?" -- sorting in IVL, o.k. would agree with your approach. Sort by low and secondly by high. So an interval starting earlier will be first, two intervals starting same time (oddly) the one running longer will be last.
 +
[1:19:38 PM] Grahame Grieve says: say, CSET (Comparable Set). SET extends CSET by binding to the equals based comparator. You can define other comparators by defining the type and making a constraint that expresses the uniqueness constraint
 +
[1:20:22 PM] Grahame Grieve says: ok. unless anyone objects, I'm going to rework HIST for R2 as discussed.
 +
[1:22:17 PM] Gunther Schadow says: "would it hurt to turn a blind eye to identity vs equality, and define an .sameIdentity(other ANY) function, so we could write custom uniqueness constraints on BAGs?" -- sameidentity ... interesting. Perhaps it's a good way out. Have the normal equal operation and another called identical. Identical would be defined in some very anal way, including displayName, codeSystemName, etc. And in some cases it would be used for some rules. Very few cases. I think less than you think, but worth giving a trial.
 +
[1:23:26 PM] Grahame Grieve says: actually, I think that the definition has to be in text rather than formal - it's a genuine primitive. and I think that the only use for it is making constraints within a list, where the difference between equality and identity happens to matter.
 +
[1:24:11 PM] Grahame Grieve says: cool. we have consensus. I will go with that, and we will see what happens at ballot
 +
[1:25:08 PM] Grahame Grieve says: and the ISO datatypes will be updated to be in sync with that too ;)
 +
[1:28:57 PM] Gunther Schadow says: Identical - "it's a genuine primitive." - I don't think it is a primitive. These things are still value objects without a pointable identity. You can only completely list it. There cannot be an id reference to a value. So, your total property comparison would make that effect.
 +
[1:29:47 PM] Grahame Grieve says: identical - all right, I'll play with it, and we can come back to that.

Latest revision as of 21:33, 25 May 2010

Data Types Issue 12: Drop identity-equality distinction

Introduction

Remove the artificial distinction between identity and equality. We do a whole lot of goofy things (like make addresses BAGs instead of SETs because we need to support duplicate addresses with different times.

This would not be backward compatible.

Discussion

Outcomes from the long R2 skype thread below:

  • change HIST to extend LIST not SET. Set sort order on HIST (DONE)
  • Define ComparableSet and make Set specialise Comparable set with default equality comparator.
  • Define some other common comparators
  • Define Equality for every single datatype
  • Define identical property to assist with uniqueness constraint definitions
  • clarify even more the definition of HIST and HXIT and take this up with MnM facilitators & HDF authors
  • clarify about the implications of comparing null flavors in an implementation note (and relevance for IVL)

Issues to follow

  • SET<CE> not allowing nulls


Disposition

Status

Proposed

Links

Back to Data Types R2 issues

Archives

DataTypes BOF May 2005: Proposed action: Accept and add equivalence definitions for EN, AD, PQ, CD, possibly others

This is a very far-reaching thing to do. I can agree to EN and AD but it should not be done for PQ and CD. The proposal is not correctly titled, as the whole point about data types is that identity is not different from equality. Anything that looks different between two values and does not factor into the equality relation is logically irrelevant. I am O.K. with revising this, but a sweeping change without further looking at the specific cases is a very bad idea. --Gschadow 01:23, 25 Jun 2006 (CDT)

BOF: Accept and add equivalence definitions for EN, AD, PQ, CD, possibly others

I am against this change. It is very destructive. The ISO ballot has surfaced it and I logged a bunch of negative items on these issues. It is impossible to replace the equal rules with a simple thing that checks for equalness of all properties. Besides our equal definition is backed by ISO 11404. You need to realize that we put in some "properties" which have no semantics (e.g., CD.displayName, II.assigningAuthorityName, etc), they can't factor into the equality, that would be a contradiction. This is just the tip of the iceberg. I oppose any sweeping changes to this. I can only agree to specific fixes of specific issues with the present equal. Even EN/AD is not quite sold for me. Gschadow 18:07, 5 May 2007 (CDT)

To read the skype chat, look at the source

Long Long Skype (welcome to the show...)

[9:51:02 AM] Grahame Grieve says: Hello Everyone, and welcome to HL7 Street. [9:51:19 AM] Grahame Grieve says: Today's show is brought to you by the letter Null and the words "equality" and "identity" [9:51:55 AM] Gunther Schadow says: zap (smirk) [9:52:25 AM] Grahame Grieve says: and our special guest is Dennis. Dennis works for me and has spent a couple of weeks writing an implementation of the ISO datatypes, and has been writing an implementation of the javaSIG datatype interfaces against the ISO datatypes [9:53:15 AM] Grahame Grieve says: so, my intention today is to drive a truck through the holes in the abstract standard. In the end, I have to deal with Gunther's comments about equals and matches in the ISO datatypes, but the abstract is where we start (as always) [9:54:06 AM] Gunther Schadow says: a truck (whew) [9:54:15 AM] Grahame Grieve says: so, does anyone disagree with the following invariant: [9:55:08 AM] Grahame Grieve says: invariant(ANY a, b, c)

     where a.nonNull.and(b.isNull).and(c.isNull) {
  a.equal(b).isNull;
  b.equal(a).isNull;
  c.equal(b).isNull;
  b.equal(c).isNull;

}; [9:55:59 AM] Grahame Grieve says: null = null, (anything else = null), (null = anything else) - all these are null [9:56:47 AM] Dale Nelson says: so far, so good [9:57:23 AM] Grahame Grieve says: this has some unexpected consequences. take for example: [9:59:33 AM] Grahame Grieve says: this is the equality definition for CD: [9:59:33 AM] Grahame Grieve says: invariant(CD x, y)

     where x.nonNull.and(y.nonNull) {
  x.equal(y).equal(x.code.equal(y.code)
            .and(x.codeSystem.equal(y.codingSystem))
            .and(x.qualifier.equal(y.qualifier)));

}; [10:00:18 AM] Lee Coller says: I think the CD definition is broken for the very reason you imply [10:00:43 AM] Grahame Grieve says: hey, I'm just warming up. I've got more in mind than you do. but we will go there [10:00:50 AM] Lee Coller says: I think our "default" definition of equality of any two type instances should be all the non-null properties are equivalent [10:00:58 AM] Lee Coller says: make that "equal" [10:01:11 AM] Gunther Schadow says: I disagree [10:01:35 AM] Grahame Grieve says: I'm with Gunther in that respect - it's broken. But what we have is badly broken for CD and generally broken in a few other places [10:01:52 AM] Grahame Grieve says: take these two CD's:

<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
</example>
<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
</example>

[10:01:58 AM] Grahame Grieve says: these are equal no? [10:01:59 AM] Gunther Schadow says: I don't see the broken-ness. Can you point out for the slow people like me? [10:02:17 AM] Gunther Schadow says: these are equal. Yes. [10:02:18 AM] Grahame Grieve says: I'm going to. Don't worry about that [10:02:56 AM] Grahame Grieve says: Now, take these two CE's:

<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
</example>
<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
</example>

[10:03:08 AM] Gunther Schadow says: equal [10:03:19 AM] Grahame Grieve says: are these equal? No, it is unknown whether they are equal, because CE.qualifier is null [10:03:37 AM] Gunther Schadow says: CE.qualifier is NA, yes. [10:03:57 AM] Kevin M Coonan, MD says: not NI? [10:04:09 AM] Grahame Grieve says: yes. unexpected, but true in a formal sense. counter-intuitive, certainly [10:04:12 AM] Gunther Schadow says: For CE qualifier does not apply. Which means that qualifier is disregarded. [10:04:29 AM] Grahame Grieve says: semantically, yes, but not by the formal definitions. [10:04:46 AM] Grahame Grieve says: so the formal definition would be better to say: [10:05:31 AM] Grahame Grieve says: invariant(CE x) {

  x.qualifier.length.equal(0);

}; instead of invariant(CE x) {

  x.qualifier.notApplicable;

}; [10:06:48 AM] Gunther Schadow says: The two should seem like the same thing. If something does not apply it's not there. [10:06:59 AM] Grahame Grieve says: I could even argue that is semantically more correct - we are not saying that the concept of qualifiers is disallowed, but that there are not allowed to be any. [10:07:17 AM] Grahame Grieve says: I agree that they are nearly the same thing. But by the formalism, they aren't. [10:07:36 AM] Grahame Grieve says: Don't mind if the outcome of this discussion is that we agree that the dtdl's a broken and we won't try to fix them. [10:07:42 AM] Gunther Schadow says: As you go down the null flavor hierarchy, you can get more than null for equals. [10:08:00 AM] Grahame Grieve says: yes, but it's all still x.isNull(), so that's not germane to this discussion [10:08:00 AM] Gunther Schadow says: For example, PINF.equal(NINF) is false, not null. [10:08:12 AM] Grahame Grieve says: hey. what? I don't think so. [10:08:29 AM] Grahame Grieve says: null.equal(null).isNull. You can't break that in a specialization [10:08:43 AM] Grahame Grieve says: do I need to quote the definition of specialization? [10:09:01 AM] Gunther Schadow says: When we say that a.equal(b) is null, then, just like with any property, null is not a proper value. It means we can't tell. [10:09:30 AM] Grahame Grieve says: so? [10:09:46 AM] Gunther Schadow says: If you have patient.birthTime.isNull you are not saying that the patient never has a birth time. You just say you have not enough information to say anything more specific. [10:10:15 AM] Gunther Schadow says: So, NI.equal(NI) is NI, but PINF equal NA seems false. [10:10:32 AM] Grahame Grieve says: agree. In fact, (fortunately) we don't have a way to say the patient was never been [10:10:46 AM] Grahame Grieve says: agree. In fact, (fortunately) we don't have a way to say the patient never has a birth time. [10:10:48 AM] Grahame Grieve says: duh [10:11:13 AM] Grahame Grieve says: agree that PINF.equal(NINF).equals(false) is semantically reasonable. But you either have a formalism or you don't. [10:11:40 AM] Gunther Schadow says: The formalism needs to be interpreted right :) [10:12:00 AM] Gunther Schadow says: You are making the following syllogism: [10:12:03 AM] Grahame Grieve says: oh. right. why didn't you say so. [10:14:01 AM] Gunther Schadow says: 1: a.isNull.and(b.isNull).implies(a.equal(b.isNull)) 2: a.isPINF.implies(a.isNull) 3: a.isNINF.implies(b.isNull) therefore you say a.equals(b).isNull [10:14:40 AM] Grahame Grieve says: btw, this particular issue is not confined to CD. take these two:

<example xsi:type="ST" lang="en">This is an example</example>
<example xsi:type="ST" lang="en">This is an example</example>

definitely the same. But these:

<example xsi:type="SC" lang="en">This is an example</example>
<example xsi:type="SC" lang="en">This is an example</example>

unknown whether they are the same [10:15:07 AM] Gunther Schadow says: but that amounts to saying that if for a patient.birthTime(isNull) must be inconsistent with patient.birthTime.equals(19690219), but it's not. [10:15:12 AM] Lee Coller says: Center-only interval also suffers from this problem. Arguably some forms of open-ended intervals to as well [10:15:28 AM] Grahame Grieve says: no. I am not saying that a.isPINF.implies(a.isNull) - I am saying that PINF is a specialisation of NI, and therefore everything that is true of NI is true of PINF [10:15:51 AM] Grahame Grieve says: implication is much weaker than specialization [10:15:55 AM] Gunther Schadow says: But that cannot be so. [10:16:24 AM] Gunther Schadow says: There can be more true about PINF than about NI, and that which is more true about PINF can make a difference. [10:16:37 AM] Grahame Grieve says: what cannot be so? I think this is why PINF cannot be a specialisation of NI. But maybe we are working from different definitions of specialization? [10:16:56 AM] Gunther Schadow says: null is not a proper value. [10:17:20 AM] Gunther Schadow says: Null is the absence of a value. It does not preclude there being a value, given more information is considered. [10:17:27 AM] Grahame Grieve says: I agree that there can be more true about PINF than NI, but what is true about PINF cannot falsify what is true about PINF treated as NI, else it is not specialisation [10:17:39 AM] Grahame Grieve says: agree, but so? [10:17:47 AM] Dale Nelson says: Is Null specializable? If so, why? [10:18:02 AM] Gunther Schadow says: We are talking about specialization of null flavors, not specialization of null-values. [10:18:24 AM] Grahame Grieve says: well, explain the difference. Is it like the difference between specialisation of instances and classes? [10:18:38 AM] Gunther Schadow says: not sure, don't think so. [10:19:09 AM] Gunther Schadow says: We should be able to clarify that with simple codes... [10:19:16 AM] Gunther Schadow says: for example, [10:19:22 AM] Gunther Schadow says: green is a color [10:19:26 AM] Gunther Schadow says: red is a color [10:20:09 AM] Gunther Schadow says: with Color a and b, a.equal(b) isNull, right? [10:20:27 AM] Gunther Schadow says: But green.equal(red) is false, right? [10:21:03 AM] Grahame Grieve says: certainly agree with this. [10:22:08 AM] Gunther Schadow says: then you have to also agree with this: [10:22:18 AM] Gunther Schadow says: PINF is a Null [10:22:24 AM] Gunther Schadow says: NA is a NULL [10:22:38 AM] Gunther Schadow says: with Null a and b, a.equal(b) isNull, right? [10:22:50 AM] Gunther Schadow says: But PINF.equal(NA) is false, right? [10:23:06 AM] Grahame Grieve says: ok I get it. I'm forced to agree. PINF.equals(NINF).equals(false) is an acceptable specialisation to null.equals(null).isNull [10:24:00 AM] Grahame Grieve says: but it still bothers. OTH.equals(UNK).equals(?)? [10:24:34 AM] Grahame Grieve says: and MSK.equals(UNK).equals(?)? [10:24:37 AM] Gunther Schadow says: OTH.equals(UNK) is null [10:25:02 AM] Grahame Grieve says: I think there's special case rules for PINF and NINF based on their semantic properties. I don't like the way this is going. [10:25:08 AM] Dale Nelson says: I would think the specialization of null flavors is a static property and PINF.equal(NA) is false is equlaity of the datatype, not the values. If you are comparing values PINF and NA, it has to be NULL, not FALSE [10:26:06 AM] Grahame Grieve says: and TRC.equals(TRC) .equals(?)? [10:26:10 AM] Gunther Schadow says: "Consider a being something I'm not allowed to tell you, consider b is unknown, then is it true that what I can't tell you is the same as that which is unknown?" - Answer: "I don't know, you gotta f@#$n tell me more." [10:26:45 AM] Gunther Schadow says: TRC.equals(TRC) is not decidable either. [10:26:53 AM] Grahame Grieve says: agree. so what combinations of null = null give anything but null? [10:26:56 AM] Lee Coller says: But 0 < TRC? [10:27:05 AM] Gunther Schadow says: Yes. [10:27:26 AM] Grahame Grieve says: semantically obvious, but not at all true from the formalisms. [10:27:50 AM] Gunther Schadow says: the formalism must be interpreted right :) [10:28:01 AM] Gunther Schadow says: Even if we say today that [10:28:02 AM] Grahame Grieve says: huh. so you said. [10:28:45 AM] Grahame Grieve says: I want to go back to PINF.equals(NINF).isNull is a specialisation of null.equals(null).isNull [10:28:53 AM] Gunther Schadow says: a.isZero.and(b.isTRC).implies(a.lessThan(b).isNull) [10:28:54 AM] Dale Nelson says: Why is TRC a flavor of Null and not =defined as R | R > 0 [10:29:22 AM] Grahame Grieve says: that implies that false is a specialisation of null. I don't think that this true. [10:29:23 AM] Lee Coller says: Because it is [10:29:25 AM] Gunther Schadow says: ... that does not mean we are wrong to say tomorrow that we can know a little bit more than that, i.e. that a.lessThan(b) is in fact true. [10:29:47 AM] Grahame Grieve says: but a.isZero.and(b.isTRC).implies(a.lessOrEqual(b).isNotNull) [10:29:57 AM] Gunther Schadow says: false is indeed a specialization of null, in a way. [10:29:57 AM] Grahame Grieve says: duh. can't think. [10:30:21 AM] Gunther Schadow says: everything is a specialization of NI, in a way. [10:30:21 AM] Grahame Grieve says: > false is indeed a specialization of null, in a way. [10:30:31 AM] Grahame Grieve says: yeah, true is false, for a given value of true, too [10:30:35 AM] Dennis Nguyen says: sorry to be slowed, but I think Gunther example of Color a and b is wrong It means a and b is null, right So for Color, a.equals(b) can be true/false/null flavor [10:30:51 AM] Gunther Schadow says: no, true is never false the way that true and false are defined. [10:31:25 AM] Grahame Grieve says: I was quoting Terry Pratchett, actually. but never mind [10:31:28 AM] Dennis Nguyen says: but as null.equals(null) is already confined to null flavor, we can say true/false any longer [10:31:43 AM] Lee Coller says: if false is a specialization of null, so is true [10:31:45 AM] Dennis Nguyen says: can't say [10:32:50 AM] Dale Nelson says: how is false a specializatiuon of null? [10:33:03 AM] Dennis Nguyen says: In that sense, PINF and INF is not null flavor, but in a superset of value including null flavor [10:33:19 AM] Gunther Schadow says: NI means we have no information, we don't even know if something is there or not. But we are not saying nothing is there. [10:33:36 AM] Gunther Schadow says: NA has a little more information, here we know that nothing can in fact be there. [10:33:43 AM] Grahame Grieve says: So now we have two ideas that I don't like, but I could see that they might be true.

  • all values are specialisations of unknown value
  • the outcome of operations on nullFlavors is entirely driven by the semantics and there is not formal definition of the outcome

[10:34:03 AM] Gunther Schadow says: OTH has more information, it means we know that something is there, but we have no word for it. [10:34:05 AM] Grahame Grieve says: these are real implementation challenges [10:34:35 AM] Gunther Schadow says: UNK means that we do not know something is there or not [10:34:54 AM] Gunther Schadow says: Color means that what any color could be there, but we don't know which. [10:35:44 AM] Gunther Schadow says: In a way, an implementation is always allowed to return NI on any operation. [10:36:05 AM] Gunther Schadow says: It does not violate the truth, it might just be utterly unusable. [10:36:15 AM] Gunther Schadow says: I mean, useless. [10:36:41 AM] Gunther Schadow says: 2 + 2 = I dunno, is not a wrong answer. [10:36:45 AM] Grahame Grieve says: but would it be conformant? [10:37:06 AM] Gunther Schadow says: 2 + 2 = I dunno is not conformant with my job description. [10:37:29 AM] Gunther Schadow says: But I did accept my little son with that answer. [10:37:32 AM] Grahame Grieve says: anyhow, back to my original example: [10:37:35 AM] Gunther Schadow says: k [10:37:41 AM] Grahame Grieve says: take these two:

<example xsi:type="ST" lang="en">This is an example</example>
<example xsi:type="ST" lang="en">This is an example</example>

definitely the same. But these:

<example xsi:type="SC" lang="en">This is an example</example>
<example xsi:type="SC" lang="en">This is an example</example>

unknown whether they are the same [10:37:51 AM] Grahame Grieve says: take these two CD's:

<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
</example>
<example xsi:type="CD" code="test" codeSystem="0.1.2.3.4">
</example>

We all agree that these are equal.

Now, take these two CE's:

<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
</example>
<example xsi:type="CE" code="test" codeSystem="0.1.2.3.4">
</example>


are these equal? No, it is unknown whether they are equal [10:38:03 AM] Gunther Schadow says: Depends on what we know about SC, actually. [10:38:28 AM] Grahame Grieve says: I checked. code is null. equality definition is not narrowed to exclude code. possibly should be [10:38:28 AM] Gunther Schadow says: The CEs are equal. [10:38:41 AM] Grahame Grieve says: but what's the formalism to make the CE's equal? [10:38:55 AM] Grahame Grieve says: we can't just claim it's true because we want it to be, we have to earn that it's true [10:39:06 AM] Gunther Schadow says: I like to say even the CDs are equal, provided you told me everything. [10:39:21 AM] Dale Nelson says: shallow equal vs deep equal? [10:39:27 AM] Gunther Schadow says: Actually, this drives my favorite point about the uselessness of using equal on CD. [10:39:46 AM] Gunther Schadow says: It's like asking whether 2.0000000000000000000000000000000001 equals 2.000 [10:40:36 AM] Grahame Grieve says: well, this also drives my point about the uselessness of trying to redefine equals on CD too then [10:40:47 AM] Gunther Schadow says: It can never be decided. Is "Jamaican Roast" equal Coffe? [10:41:20 AM] Grahame Grieve says: implies is more meaningful, we agree. [10:42:15 AM] Gunther Schadow says: So, strictly speaking, the two CDs you showed as unknown to be equal if we can assume that there is more information about them. [10:42:52 AM] Gunther Schadow says: Is my disease the same as the other guy's disease? We can never tell. [10:43:18 AM] Gunther Schadow says: But is my disease diabetes mellitus (no qualifiers)? We might say yes. [10:44:23 AM] Grahame Grieve says: but we could make the same argument about address. Two people who live on the same road and give the same address, only including road, because they're mates with the postie - are those addresses equal? [10:44:56 AM] Gunther Schadow says: We can't say for sure. [10:45:19 AM] Grahame Grieve says: no but we define it anyway - so exactly what are we trying to achieve? [10:45:33 AM] Grahame Grieve says: but this is not really about CD. it's about the definition of equality. if null=null is null, then what is the status of comparing things with null properties [10:45:46 AM] Grahame Grieve says: I think that generally this issue slipped under the radar [10:46:08 AM] Grahame Grieve says: I can keep making examples up, but I think that the two I made showed that issue [10:46:17 AM] Gunther Schadow says: Strict equality for addresses is not a very useful operation. [10:46:29 AM] Grahame Grieve says: Is it true that in this regard, we can act consistently, xor reasonably? [10:47:16 AM] Grahame Grieve says: what is a useful operation? I haven't turned my attention to BAD<AD> yet, though I'm going to. But later, haven't finished comparing values with null properties yet [10:47:17 AM] Gunther Schadow says: I am an optimist, we can act consistently and reasonably. We just have to be careful about what we think is consistent. [10:47:47 AM] Gunther Schadow says: We can act consistently and reasonably, we just have to be reasonable about what we think is consistent. [10:48:27 AM] Grahame Grieve says: ok, what's reasonable? am I unreasonable to think that the formal definition should say what we mean and be internally consistent? [10:48:59 AM] Grahame Grieve says: I think that what this means is that we have to define equality for every single datatype, never leaving it to the implementor [10:49:12 AM] Grahame Grieve says: we've done about half what we have to do. [10:49:24 AM] Gunther Schadow says: no, you are reasonable. But, it is also reasonable to accept the limitations of what we can say at all given limited time, limited patience by the balotters, etc. [10:50:00 AM] Grahame Grieve says: I would be willing to fix this by doing the work of defining it for everything. [10:50:11 AM] Grahame Grieve says: given we can resolve my other issues that we haven't talked about yet. [10:50:32 AM] Gunther Schadow says: I think when we specify equal constraints, we make necessary statements, but they might not be sufficient. [10:50:47 AM] Lee Coller says: Can we agree that the determination of equality shouldn't be a function of the type of null flavor on an attribute? [10:51:03 AM] Grahame Grieve says: hmm. no? [10:51:37 AM] Gunther Schadow says: I'm with Grahame here, I think we showed that that is not possible if you want to enumerate more possible cases. [10:51:40 AM] Grahame Grieve says: maybe you need to clarify, which equality? and don't use the word attribute, makes me come out in spots [10:53:54 AM] Grahame Grieve says: my second issue was going to be about CD, OTH, and equality. But CD is so broken anyway, who cares. It's certainly not an illuminative discussion with regard to null,equality and identity. So I'll move on to my third point in a sec. [10:54:05 AM] Lee Coller says: Take for example an open ended interval. Should we take into the account the null flavor used on the high property? [10:54:15 AM] Gunther Schadow says: Since the earliest days I hated to put equal on REAL. I'd much rather have said that it's not useful and instead one should spefiy equals with a parameter, epsilon, such that r.equal(s, epsilon).equal(r.minus(s).lessOrEqual(epsilon)). [10:54:26 AM] Grahame Grieve says: ok, IVL is 4, let's take that now [10:55:16 AM] Dale Nelson says: The old programming language APL used a "fuzz" factor to decide whether two reals were equal. The factor was user specifiable. [10:55:35 AM] Gunther Schadow says: yup, cool. [10:55:36 AM] Lee Coller says: Yes, but I could code the entire RIM in APL in one line :D [10:55:41 AM] Grahame Grieve says: a prpoer language will have both. there's a use case for both, if you know waht you are doing [10:56:17 AM] Grahame Grieve says: Lee, I'm confused. you can code the entire RIM? [10:56:40 AM] Lee Coller says: You can do anything in APL in one line [10:56:52 AM] Gunther Schadow says: just needs a long line I guess :) [10:56:58 AM] Grahame Grieve says: but you can code the RIM at all? ;) [10:57:25 AM] Dale Nelson says: except for the coded bits [10:57:27 AM] Lee Coller says: IF you talk about implement the classes in java, persist and retreive them from the database, yes. [10:57:39 AM] Lee Coller says: I can't to Role Link though [10:57:52 AM] Gunther Schadow says: :D [10:58:04 AM] Lee Coller says: Back to IVL [10:58:33 AM] Grahame Grieve says: yes, back to IVL: If an interval is unknown on one (or both) boundaries, the center can still be asserted [10:58:48 AM] Grahame Grieve says: huh? how could you not know the one boundary, and know the center? [10:59:06 AM] Gunther Schadow says: how not? [10:59:20 AM] Gunther Schadow says: you just don't know the width. [10:59:22 AM] Grahame Grieve says: I can understand - maybe- knowing the center and not both the boundaries [10:59:25 AM] Lee Coller says: Don't yo mean width only? [10:59:34 AM] Grahame Grieve says: how can you know low and center and not width? [11:00:02 AM] Gunther Schadow says: But I would argue it is unreasonable to claim you know the center if you don't know everything. In most cases it would be better to say "I know some value in the interval". [11:00:17 AM] Gunther Schadow says: In Java SIG code, I introduced the "any" property for SETs. [11:00:20 AM] Gunther Schadow says: any is nice [11:00:36 AM] Grahame Grieve says: hey yes, I agree. in fact, IVL with only a center is actually a CIVL thingy? [11:00:42 AM] Grahame Grieve says: and any is what? [11:00:58 AM] Gunther Schadow says: It's not even a civil thing. [11:01:19 AM] Lee Coller says: You might know how long it is, but not when it starts of finishes [11:01:20 AM] Dale Nelson says: Datatypes R1 constrains IVL to any 2 of {low, high, center, width} doesnt it? [11:01:40 AM] Gunther Schadow says: only the XML its does. [11:01:44 AM] Grahame Grieve says: You can have any of these combinations of children:

   * low
   * width
   * high
   * low, width
   * width, high
   * low, high
   * center
   * center, width

[11:01:58 AM] Dale Nelson says: But others default when you do that [11:02:01 AM] Gunther Schadow says: only for the XML its, it's an arbitrary decision. [11:02:44 AM] Grahame Grieve says: agree, in the XML. the relationship between the XML and the abstract is not simple. Bu I was quoting the xml. I think that the sentence I quoted should be changed from

If an interval is unknown on one (or both) boundaries, the center can still be asserted

to

If an interval is unknown both boundaries, the center can still be asserted

or omitted altogether [11:03:02 AM] Gunther Schadow says: Any is nice because when people give a point in time for an Act.effectiveTime, they really mean that any point in that effectiveTime was that point they provide. They don't know start and end, and they don't know about center either. [11:03:24 AM] Dale Nelson says: if a property like width is unknown (null) woudnt the entire value of the IVL be unknown (null) [11:03:25 AM] Gunther Schadow says: It is very useful to state any and an approximate width. That is how we know about most events. [11:04:04 AM] Gunther Schadow says: I think one can say that that would be an incompletely specified intereval. [11:04:10 AM] Grahame Grieve says: I don't really follow this any. "really mean that any point in that effectiveTime was that point they provide"? I've tried to make sense of that several times and failed [11:04:14 AM] Gunther Schadow says: And one could say that that is a flavor of null. [11:04:38 AM] Gunther Schadow says: We define Act.effectiveTime as a SET. [11:05:40 AM] Gunther Schadow says: We know that for a single event the effectiveTime is a continuous IVL . [11:05:55 AM] Gunther Schadow says: Yet most people in real HL7 would rarely want to state the IVL completely. [11:06:11 AM] Gunther Schadow says: They like to send a single point in time instead. [11:06:51 AM] Grahame Grieve says: so, the operation"happened" at 0930, and we know it would take 60 minutes. [11:07:08 AM] Grahame Grieve says: and if we have to, we assume that "happened" means "started around about"? [11:07:24 AM] Gunther Schadow says: Call that point they only care about t. Now we currently give them no choice but to say:

(1) the event went from t till t, or (2) the event was centered in t and extended symmetrically from t. [11:07:37 AM] Gunther Schadow says: both of these statements are more than people would really want to claim. [11:08:11 AM] Gunther Schadow says: It would be better if we gave them a chance to claim that the event extended over some unspecified time and t was an element of that set. [11:08:35 AM] Grahame Grieve says: ok, that makes sense. but how would we do that? [11:09:11 AM] Grahame Grieve says: is this a GTS thing or an IVL<TS> thing - smells like a GTS thing to me [11:09:13 AM] Gunther Schadow says: In other words, there exists some t_i in the interval that satisfied t_i = t. That's what <effectiveTime xsi:type="IVL_TS" any="{$t}"/> would mean. [11:09:25 AM] Gunther Schadow says: Not GTS. [11:09:29 AM] Gunther Schadow says: well [11:09:33 AM] Gunther Schadow says: not really. [11:09:53 AM] Gunther Schadow says: You can send any one value out of any set. [11:10:14 AM] Gunther Schadow says: GTS === SET<TS>, so, you can have an any out of a GTS. But it's not the same issue as GTS. [11:10:21 AM] Gunther Schadow says: only some similarities. [11:10:34 AM] Grahame Grieve says: well, it's pretty partially specified, that's for sure. So let's go back to partially specified intervals. [11:10:38 AM] Grahame Grieve says: is >10 = >10? [11:10:51 AM] Gunther Schadow says: we can't tell. [11:11:16 AM] Grahame Grieve says: so, PINF.equals(PINF).isNull? [11:11:17 AM] Gunther Schadow says: well ... depends if your upper bound is PINF in both cases or not. [11:11:48 AM] Gunther Schadow says: [10; PINF[ = [10; PINF[, yes [11:12:01 AM] Gunther Schadow says: [10; NI[ = [10; NI[, don't know [11:12:04 AM] Grahame Grieve says: lets assume that it's PINF, since we cannot really say >10, we have to say 10->PINF [11:12:09 AM] Grahame Grieve says: even though that's not what we mean [11:12:25 AM] Gunther Schadow says: we can say [10; NI[ [11:12:46 AM] Grahame Grieve says: yes, that's unknown. sure. [11:12:59 AM] Gunther Schadow says: [sorry, want to get the kids to bed, quality time ya know ... later] [11:13:06 AM] Grahame Grieve says: k [11:13:16 AM] Grahame Grieve says: fun time later, when we look at BAG<AD> [11:34:53 AM] Grahame Grieve says: I'm confused. Why is there a reference to datatypes-base in the xml its source? what is supposed to be in existence for datatypes-base.xsd? I don't have one, and the makefile doesn't make one [12:09:36 PM] Gunther Schadow says: That datatypes-base was done afterwards, I think by Dale. We create datatypes.gst and datatypes.xsd and templates-instantiations.xsd, they didn't like that "templates-instantiations" name, and rather called it datatypes and the original datatypes was renamed to datatypes- base.xsd. [12:10:48 PM] Grahame Grieve says: so we're in a mess right now, with half made changes? [12:13:13 PM] Gunther Schadow says: I think it's not so much of a problem. We can simply do the same renaming from the source. [12:15:32 PM] Grahame Grieve says: which should I rename - the files and the names in the make files? [12:15:35 PM] Grahame Grieve says: and why .txt? [12:16:18 PM] Gunther Schadow says: Dennis "but as null.equals(null) is already confined to null flavor, we can say true/false any longer" - yes we can, just as we can say red if the thing.color is "already confined to colored". [12:17:08 PM] Gunther Schadow says: In some early draft of data types I had a picture of the tree of null values ... let's see if I can find it ... [12:21:17 PM] Gunther Schadow says: Here it is: http://aurora.rg.iupui.edu/v3dt/show-38.html [12:21:46 PM] Dennis Nguyen says: Grahame explained to me that null in this case is the superset of all types So does that mean red is a specific null flavor (some flavor like "specific information supplied" kind of ?) [12:38:19 PM] Gunther Schadow says: I don't think it's helpful to say "red is a null flavor". And it's not right, becasue red for color is expressly not null. [12:40:55 PM] Gunther Schadow says: Is this an extended commercial block? Did people zap out your show? And when is the part of the show when the truck will come in and drive through a hole? (smirk) [12:41:07 PM] Grahame Grieve says: you went to put the kids to bed. [12:41:13 PM] Grahame Grieve says: so we had a long intermission. [12:41:22 PM] Grahame Grieve says: we had one hole. [12:41:37 PM] Gunther Schadow says: Didn't mean to stop the show. The show must go on, you know, always. [12:41:54 PM] Grahame Grieve says: we decided to plug it, but I regard it as a rearguard action [12:42:13 PM] Grahame Grieve says: and I don't think it's right to exclude qualifier from the check for CE, so I don't really know how to fix taht [12:42:42 PM] Grahame Grieve says: anyhow, lets move on. [12:43:29 PM] Gunther Schadow says: I agree with you if you compare if a CE == CD, you cannot suddenly exclude qualifiers. [12:43:40 PM] Grahame Grieve says: say I want to write a constraint that says that for my BAG<AD>, I don't want you to send me an address with the same validTime range more than once. [12:44:37 PM] Gunther Schadow says: AD a, b : a.validTime.equal(b.validTime).not [12:44:55 PM] Grahame Grieve says: ahh, no [12:44:59 PM] Grahame Grieve says: the full constraint [12:45:31 PM] Gunther Schadow says: what am I missing? [12:46:48 PM] Gunther Schadow says: invariant(BAGGIE<AD> ba, AD a, AD b) where(ba.contains(a).and.ba.contains(b)) {

 a.validTime.equal(b.validTime).not

} [12:46:50 PM] Gunther Schadow says: ? [12:47:27 PM] Grahame Grieve says: ah. let me rephrase the english. it was ambiguous [12:47:38 PM] Grahame Grieve says: I don't want you to send me the same address with the same validTime range more than once. [12:50:35 PM] Gunther Schadow says: this is just compounding the issue we discussed. What does "same address" mean? What does "same time range mean", when it comes to the edge cases. [12:50:53 PM] Grahame Grieve says: it's not about the semantic issues. This is about the technical issues [12:51:19 PM] Gunther Schadow says: Let's say, for sameness here we consider pairwise elements that are specified to the same level of completeness. Then it is all easy. [12:52:03 PM] Grahame Grieve says: I don't know what that means [12:52:04 PM] Grahame Grieve says: invariant(BAG<AD> x) where x.nonNull {

 forAll(AD p) where AD.contains(p) {
   forAll(AD q) where AD.contains(q) {
    p.equals(q).not.implies(p.equals(q).implies(p.validTime.equals(q.validTime).not)
 } 

}; [12:52:54 PM] Grahame Grieve says: for each element p, for all the elements in the list q, if p is not q, and p = q, then the valid times must be different. [12:53:05 PM] Grahame Grieve says: but we can't say that, but we stole the assertion of identity away [12:53:21 PM] Grahame Grieve says: we say, [12:53:48 PM] Grahame Grieve says: One can think of data values as immutable objects where identity does not matter (identity and equality are the same.) [12:54:09 PM] Grahame Grieve says: so, AD with the same parts, but different use codes, these are not only equal, but they are the same identity [12:54:43 PM] Grahame Grieve says: to me, this is like the other issue - we know what we mean, but we don't say what we mean, and we invite people to "understand" what we mean instead of what we say [12:55:44 PM] Gunther Schadow says: So, we are saying the use code factors not in equal? That would seem strange to me (now anyway). [12:55:53 PM] Grahame Grieve says: we said that. [12:56:06 PM] Gunther Schadow says: That seems not right. [12:56:19 PM] Gunther Schadow says: Except [12:56:35 PM] Grahame Grieve says: so, I pick another example. We said that equality for a CD includes code, codeSystem and qualifiers. [12:56:52 PM] Gunther Schadow says: if we say that if two addresses are equal but you have different use codes for them, we can just merge the address and take the union of the use code set. [12:57:11 PM] Grahame Grieve says: so two CD's are equal, whatever their translations and original text, and whatever, they are the *same* CD [12:57:13 PM] Lee Coller says: not if their valid times are different [12:57:41 PM] Gunther Schadow says: Well, CDs don't have valid time. [12:57:51 PM] Grahame Grieve says: I think it's worth defining semantic equality. But we are completely confused here, because we lie. either equality and identity are the same, or they are not [12:58:01 PM] Lee Coller says: I was referring to AD [12:58:02 PM] Gunther Schadow says: But yes, whatever their translations. BUT we know very well that translations cause issues. [12:58:30 PM] Gunther Schadow says: The problems come with annotations. [12:58:43 PM] Grahame Grieve says: I'll pick a different example then. it doesn't matter. The principle is, semantic equality is not the same as technical identity. [12:58:47 PM] Gunther Schadow says: Good hard example is "codeSystemVersion". [12:58:58 PM] Grahame Grieve says: sure. let's go with that. who cares about it right. [12:59:22 PM] Gunther Schadow says: Many people say they care, that's why I say "hard" example. [1:00:28 PM] Grahame Grieve says: ok. we surely agree that <code code="AUS" codeSystem="2.16.840.1.113883.11.171" codeSystemName="ISO 3 letter characters" refer to the same code [1:00:52 PM] Gunther Schadow says: Yes. [1:00:56 PM] Grahame Grieve says: duh, missed the end of the example but it doesn't matter [1:01:10 PM] Gunther Schadow says: That's an easy one. [1:01:22 PM] Gunther Schadow says: It's a useless annotation. Like a comment in program code. [1:01:42 PM] Gunther Schadow says: I mean, not useless but without effect. [1:01:50 PM] Grahame Grieve says: sure. they are not meaningfully different. and we don't want to think about them when we compare two CD's to see if they can go into a SET together [1:02:37 PM] Gunther Schadow says: So that's the lowest point where your proposed pairwise comparison of non-null properties breaks down. [1:02:59 PM] Grahame Grieve says: what proposed comparison? [1:04:16 PM] Grahame Grieve says: I haven't proposed anything quite yet, except that we should have a difference between semantic equivalence and technical equality [1:04:41 PM] Grahame Grieve says: are these equal? [1:04:41 PM] Grahame Grieve says:

 <originalText>Australia</originalText>

 <originalText>South from Indonesia</originalText>

[1:05:18 PM] Grahame Grieve says: though I shouldn't really, we shouldn't be arguing about the meaning of semantic equality for CD, that's no the point [1:07:00 PM] Grahame Grieve says: This is all in reference to proposal 12. [1:08:47 PM] Grahame Grieve says: there's some strong comments there. But we are broken. So what I would like to do is to define technical equality strictly based on all properties, as simple as possible, widen the definitions of semantic equality to define it explicitly for everything, and then allow explicit statements of uniqueness for SETs [1:08:59 PM] Grahame Grieve says: the last is where it breaks down - that's HARD to implement [1:09:43 PM] Grahame Grieve says: but that's the thing that needs fixing. We are cheating and avoiding the hard problem. And then we do something really stupid like have BAG<AD> to work around the constraint we tried to create in the first place. dumb. [1:10:43 PM] Gunther Schadow says: The two with the different original text are equal in my view. Technically as well as semantically. The technology needs to implement semantics. [1:11:04 PM] Grahame Grieve says: so they are also identical then? [1:11:53 PM] Grahame Grieve says: java knows about this issue. it's why = and .equal() are different. can catch you out if you aren't aware, of course, but there's a useful reason for it. [1:11:54 PM] Gunther Schadow says: There is no identity with values. What does it mean? Where does it matter? [1:12:28 PM] Grahame Grieve says: you still haven't explained how to implement that constraint that I talked about [1:12:40 PM] Grahame Grieve says: > I don't want you to send me the same address with the same validTime range more than once. [1:13:00 PM] Gunther Schadow says: Why do I even care about that constraint? [1:13:03 PM] Grahame Grieve says: in a single BAG - though I guess that was implicit [1:13:18 PM] Gunther Schadow says: Some of these constraints are useless, why should one even check for that? [1:13:51 PM] Grahame Grieve says: I don't think that one is useless. It came from a user trying to make sense of why entity.address is BAG not SET [1:14:07 PM] Gunther Schadow says: You send me two addresses where one is awfully similar to the other and I will decide to lump them, or keep them both (and pick one or the other at random). [1:14:26 PM] Grahame Grieve says: but the point is the underlying one, that a constraint like that will use equals to decide whether two things have the same identity [1:14:43 PM] Grahame Grieve says: how will you keep them both while conforming the spec? you can't even tell them apart from each other [1:14:57 PM] Gunther Schadow says: I don't need to keep them both. [1:15:07 PM] Grahame Grieve says: well, you brought that up. [1:15:25 PM] Grahame Grieve says: Lee - what does Oracle think about this - would you be happy to not tell them apart? [1:16:24 PM] Lee Coller says: In that case we probably would ignore the differences, if you sent me two similar addresses with the same valid time, we'd just use both of them [1:16:38 PM] Lee Coller says: The problem comes when someone tries to remove an addresss, which one do we remove? [1:16:42 PM] Grahame Grieve says: what about the converse - same address with two different valid times [1:17:04 PM] Lee Coller says: That's legitimate unless they overlap [1:17:26 PM] Lee Coller says: right now we don't check for that overlap though, so we'd just keep both of them [1:17:31 PM] Grahame Grieve says: you would keep them both and consder them different? [1:17:38 PM] Lee Coller says: yes [1:17:52 PM] Grahame Grieve says: but you're not supposed to, because validTime doesn't differentiate them [1:18:48 PM] Lee Coller says: It's not a constraint we check right now. I'd have to check our underlying model to see if it could become an issue. [1:20:21 PM] Lee Coller says: We have another oracle product we integrate with on this. It may care, I'll have to check (I can't right now). As I think about it it probably will for some addresses (i.e., if I need to mail something to you, where do I mail it). [1:21:19 PM] Gunther Schadow says: One can argue that anything collection of a HIST<T> is really a LIST. I think that's what we say. [1:22:02 PM] Gunther Schadow says: Since AD implements the HIST interface if validTime is IVL<TS>, then this SET should be considered a LIST really. [1:22:26 PM] Grahame Grieve says: ? HIST is a set [1:22:56 PM] Grahame Grieve says: and it's kind of a fun outcome, that SET is really a LIST [1:23:56 PM] Gunther Schadow says: Sloppy thinking, eh? O.K. then the issue applies for any HIST<T>. I'm not saying you have no point that something needs fixes, I'm just not sure it has to do with your new simple minded definition of equality. [1:24:40 PM] Gunther Schadow says: Rather than getting all upset over "constraints" perceived on the definition of SET etc., I'd like to ask: so what do we mean, what do we want? [1:25:00 PM] Gunther Schadow says: Then we make technology that works like what we mean and does what we want. [1:26:24 PM] Grahame Grieve says: well, I think that we want equality to be identity. and we want to define semantic equality without the constraint that that's tied to identity - things that are not identical may be semantically equal. and we want the flexibility to define how a set is unique [1:27:05 PM] Gunther Schadow says: The idea of a set is that it imposes no order and no replication of elements. But there is nothing preventing you from making a union of one set with a set of a single element. What exactly happens to meaningless annotations in that case is simply undefined. [1:27:15 PM] Grahame Grieve says: which get's to the HIST issue. a HIST<AD> may actually contain a number of identical entries differing only by their validTime - and that makes perfect sense [1:27:32 PM] Grahame Grieve says: so? [1:27:48 PM] Gunther Schadow says: " I think that we want equality to be identity" - I don't know that. [1:27:57 PM] Grahame Grieve says: where as a SET<AD> - that is really saying, send me a list of different addresses [1:28:06 PM] Grahame Grieve says: we say that [1:28:55 PM] Gunther Schadow says: "which get's to the HIST issue. a HIST<AD> may actually contain a number of identical entries differing only by their validTime - and that makes perfect sense" - O.K. agreed,

"where as a SET<AD> - that is really saying, send me a list of different addresses" - then there's something wrong here. [1:29:12 PM] Grahame Grieve says: ? [1:29:19 PM] Gunther Schadow says: If we really say "send me a list of different addresses" then why do we like validTime in address? [1:29:51 PM] Grahame Grieve says: cause people are allowed to move. Stupid really, but there you go [1:30:15 PM] Gunther Schadow says: When they move, it's just a HIST<AD>. No problem then. I think, what we really mean here is "a bunch of addresses" [1:30:17 PM] Gunther Schadow says: ... [1:30:49 PM] Gunther Schadow says: there was once a difference between a simple HXIT<T> where validTime was just IVL<TS> and an AD and TEL where validTime was SET<T> (alias "GTS"). [1:31:19 PM] Gunther Schadow says: that extension of HIST is where the problem comes from. It is valid use case for addresses and telephone numbers. [1:31:27 PM] Gunther Schadow says: But it [1:31:45 PM] Gunther Schadow says: 's solution with the SET<T> is causing grief. [1:31:46 PM] Grahame Grieve says: yes, I was going to get around to pointing out that only EN conforms to HXIT, and it doesn't do that anymore in R2 [1:32:12 PM] Gunther Schadow says: Has someone changed EN.validTime to GTS??? [1:32:23 PM] Grahame Grieve says: no, someone's added to HXIT [1:32:35 PM] Gunther Schadow says: added what? [1:32:46 PM] Grahame Grieve says: so EN.validTime still conforms to HXIT.validTime, but we added controlActIdRef to HXIT [1:33:00 PM] Grahame Grieve says: sure you knew this? we discussed it somewhere [1:33:03 PM] Gunther Schadow says: That can apply back to EN and AD no problem. [1:33:24 PM] Grahame Grieve says: sure, but it doesn't make sense as a property of the datatype, unlike validTime [1:34:01 PM] Gunther Schadow says: it does make sense in so far as we are talking about the history. [1:34:14 PM] Grahame Grieve says: in fact, I was thinking of moving controlActIdRef to the same section as updateMode and flavorId, since it's not really a semantic property of the datatype [1:34:29 PM] Grahame Grieve says: of course- when we talk about history it makes sense [1:34:31 PM] Gunther Schadow says: AD is a history AND this wild snowbird-and-business-hours issue. [1:35:02 PM] Grahame Grieve says: so, maybe we just have a harmonisation proposal to change address and name to HIST<?> everywhere in the RIM and the models? [1:35:26 PM] Grahame Grieve says: though we are avoiding the real issue [1:35:43 PM] Gunther Schadow says: With the difference that AD and TEL's .... no, wait, usablePeriods it is no. So we really only talk about EN these days? [1:36:19 PM] Gunther Schadow says: Isn't AD's validTime called "usablePeriods" now? [1:36:34 PM] Grahame Grieve says: well, in terms of auto being a HXIT, yes, but hey, why not make EN.validTime a GTS to be consistent? [1:37:16 PM] Grahame Grieve says: and there's still the issue with HXIT.validTime and EN.validTime - is one validTime the period when *I knew* what the value was, and is the other when it actually was? [1:37:19 PM] Gunther Schadow says: HL7 - consistency over intelligence .... or what was this bumper sticker you had there? [1:37:35 PM] Lee Coller says: EN.validTime as a GTS, absolutely not [1:37:44 PM] Grahame Grieve sent file "hl7_consistency.jpg" to members of this chat [1:39:26 PM] Lee Coller says: TShirts? [1:40:14 PM] Grahame Grieve says: maybe. Would be funny to go to the meeting wearing t-shirts like that. though HQ would NOT BE AMUSED [1:40:29 PM] Gunther Schadow says: agree with Lee, no EN.validTime should be GTS. [1:41:24 PM] Gunther Schadow says: I would not wear it. Out of loyalty to my colleagues with whom I disagree. [1:42:29 PM] Grahame Grieve says: well, that whole EN.validTime as a GTS was a brick in the conversation. Was a joke, really (almost completely) [1:43:06 PM] Lee Coller says: Good, I feel better now [1:43:07 PM] Grahame Grieve says: and there's still the issue with HXIT.validTime and EN.validTime - is one validTime the period when *I knew* what the value was, and is the other when it actually was? [1:43:11 PM] Gunther Schadow says: So, EN.validTime conforms to HIST. Except, perhaps, that we also have alias names. It's two dimensions, aliases and history. [1:43:37 PM] Grahame Grieve says: two dimensions - use and history - same for AD and TEL too [1:44:10 PM] Lee Coller says: The current definition of HIST implies when it actually was (The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item.) [1:45:09 PM] Lee Coller says: And from HXIT Definition: The time interval during which the given information was, is, or is expected to be valid. The interval can be open or closed infinite or undefined on either side. [1:45:20 PM] Grahame Grieve says: yeah, but then you do read the audit trail stuff in HDF, and they are not thinking what way. [1:45:34 PM] Grahame Grieve says: hey - inconsistency and lack of intelligence [1:46:07 PM] Lee Coller says: I always thought it was audit too. The addition of controlActRefII implies that it's audit, but the current definition says otherwise. [1:49:23 PM] Lee Coller says: That may be because my first exposure to this was when we talked about adding controlActID two years ago [1:50:41 PM] Grahame Grieve says: yes, well, here's the definition we agree for that: The identifier of the ControlAct associated with setting the datatype to its specified value. By referencing a particular ControlAct, the property links to all of the information surrounding that ControlAct, such as who made the change, when it was made, why it was made, what system originated the change, etc. [1:50:47 PM] Grahame Grieve says: kind of screwed up, really [1:50:56 PM] Grahame Grieve says: at least it hasn't gone to ballot yet [2:00:16 PM] Grahame Grieve says: LLoyd - we have you to blame for controlActIdRef - any comment? [2:21:19 PM] Lloyd McKenzie says: Why kind of screwed up? [2:21:53 PM] Lloyd McKenzie says: We need to be able to tie every change to every attribute to a specific person and reason and possibly supervisor and location [2:22:03 PM] Lloyd McKenzie says: Can't think of a more elegant way to do this [2:22:17 PM] Grahame Grieve says: The current definition of HIST implies when it actually was (The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item.) [2:22:27 PM] Grahame Grieve says: but the definition of controlActIdRef implies differently [2:22:35 PM] Grahame Grieve says: in fact, the concept of it implies something different [2:37:33 PM] Lloyd McKenzie says: HIST allows you to look at past values [2:37:50 PM] Lloyd McKenzie says: HXIT tells you a little bit about the specific change [2:37:59 PM] Lloyd McKenzie says: However, it doesn't tell you enough [2:38:51 PM] Lloyd McKenzie says: We need more information, than just the time [2:39:20 PM] Grahame Grieve says: ? [2:39:36 PM] Lloyd McKenzie says: HXIT gives you the time of the change [2:39:44 PM] Grahame Grieve says: say I changed my name - why do you need more information than the time I did this? [2:39:44 PM] Lloyd McKenzie says: We need the author, reason and other information too [2:39:57 PM] Lloyd McKenzie says: Because that's the use-case [2:39:59 PM] Grahame Grieve says: I'm the author, I don't care to give you my reason [2:40:03 PM] Lloyd McKenzie says: We need to know who changed it and why [2:40:16 PM] Lloyd McKenzie says: In our provider registry, if you don't give a reason, you can't make a change [2:40:38 PM] Lloyd McKenzie says: The requirement is definite [2:40:46 PM] Grahame Grieve says: I don't need a reason, I can just give myself an alias and start using it [2:40:51 PM] Lloyd McKenzie says: If you don't like the mechanism, propose a different one [2:41:03 PM] Grahame Grieve says: I'm still confused as to your use case [2:41:17 PM] Lloyd McKenzie says: Reasons might be "legal change", "error", "change in preference", etc. [2:41:52 PM] Grahame Grieve says: HIST is the history of names I have used. HXIT is the time that I used the name. You're insisting that I have to notify everyone in the world to get permission to change my name? [2:42:21 PM] Lloyd McKenzie says: I'm saying that in order to make a change in the registry, you need to give a reason. [2:42:36 PM] Lloyd McKenzie says: It's not the provider's reason, it's the clerk's reason [2:43:31 PM] Grahame Grieve says: oh - but you are talking about something different. You are saying that the HIST<EN> is the registries history of when it knew that a given name was a assigned to a person? [2:44:39 PM] Lloyd McKenzie says: Which is what a registry cares about [2:45:14 PM] Lloyd McKenzie says: We care about the ControlAct that revised the registry entry - when did it happen, who did it, why did they do it. [2:45:16 PM] Grahame Grieve says: but that's not what HIST is about. check the definition again [2:45:25 PM] Grahame Grieve says: The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item. [2:45:49 PM] Lloyd McKenzie says: Why do you need a time then? [2:45:57 PM] Lloyd McKenzie says: time is one piece of metadata about the change [2:46:07 PM] Lloyd McKenzie says: We need more pieces of metadata [2:46:51 PM] Lloyd McKenzie says: Fundamentally, MnM reviewed and approved this, including roundtable discussion. It's been balloted as part of the HDF. [2:47:03 PM] Lloyd McKenzie says: The use-case exists and has been accepted [2:47:59 PM] Grahame Grieve says: fine, but it causes a problem in the datatypes, a tension in the meaning of HXIT [2:48:04 PM] Lloyd McKenzie says: If you want to handle this some other way, please indicate how, but don't say we're not going to support it. [2:48:16 PM] Lloyd McKenzie says: I don't think it's inconsistent with HXIT [2:48:38 PM] Grahame Grieve says: the datatypes say it is about the value itself, but the MnM view says that it's about the observation of the value, rather than the value. [2:48:39 PM] Lloyd McKenzie says: HXIT says "this is a historical version" [2:49:15 PM] Grahame Grieve says: I think it is inconsistent, because if I used the name "bozo" from 2002 - 2004, and you found out about it in 2003, and found out I stopped using in 2005, which range applies? [2:49:16 PM] Lloyd McKenzie says: What's wrong with tying it to the ControlAct that caused that historical version to come into being? [2:49:49 PM] Grahame Grieve says: I'm not saying at all that I don't want to solve the problem. I'm just concerned about the definition of HXIT at this point [2:50:38 PM] Grahame Grieve says: if you bothered to read the screeds that went before (don't) you'd see that we got to here from another angle, talking about HIST and uniqueness. Gunther will dig in and fight for the existing definition of HXIT and HIST. It won't be pretty [2:52:37 PM] Lloyd McKenzie says: In the case of what you're looking for, the validTime is 2002-2004. The effectiveTime on the ControlAct is 2003. [2:52:42 PM] Lloyd McKenzie says: (And we care about both :)) [2:53:00 PM] Lloyd McKenzie says: I don't see how this is inconsistent [2:54:45 PM] Grahame Grieve says: it is when you say: HXIT gives you the time of the change [2:54:52 PM] Grahame Grieve says: only if you qualify this to say: [2:55:06 PM] Grahame Grieve says: HXIT.controlActIdRef gives you the time of the change if you go look at the control act (if you have it) [2:55:15 PM] Lloyd McKenzie says: Correct [2:56:41 PM] Grahame Grieve says: so, now it bothers me a lot that validTime and controlActIdRef are bunched together - it seems that the use case for them is rather different [2:57:46 PM] Lloyd McKenzie says: I don't see them as that diverse. However, if you don't want it there, how on earth do we meet the use-case? [2:59:00 PM] Grahame Grieve says: well, we could do it rather more directly, like updateMode, but pulling controlActIdRef off HXIT, and declaring it with updateMode, and saying that it works the same way. [3:00:50 PM] Lloyd McKenzie says: If that makes people happier, I could live with it. [3:01:06 PM] Lloyd McKenzie says: To me, this is about history, and therefore HXIT is the most logical place [3:01:19 PM] Grahame Grieve says: adds a flag to the MIF, I know, but there you do. Doesn't deal with allowing a full history though - for that you need HIST<T> not HXIT<T>, but you can't just introduce HIST<T> - in fact, where could you use it? [3:01:28 PM] Lloyd McKenzie says: However, so long as we can meet the requirement (and control where it's allowed and where it's not), then I'm happy [3:01:38 PM] Lloyd McKenzie says: We will need to run any change past MnM though [3:03:24 PM] Grahame Grieve says: don' [3:03:58 PM] Grahame Grieve says: don't know. so far it pleases nearly one person - me. no hurry. but where could you use HIST<T>? only on things that are SETs already? [3:05:08 PM] Lloyd McKenzie says: As far as the methodology concerned it's one of those "magical inconsistencies" [3:05:34 PM] Lloyd McKenzie says: Apparently we're allowed to declare that any attribute (or association) is HIST, which automatically allows repetitions [3:08:25 PM] Grahame Grieve says: riiiight [3:09:26 PM] Grahame Grieve says: that's pretty magical all right [3:09:27 PM] Lloyd McKenzie says: The alternative was making all the RIM classes HIST<x> [3:09:40 PM] Lloyd McKenzie says: attributes I mean [3:09:43 PM] Grahame Grieve says: I could've come up with something better than that [3:10:23 PM] Lloyd McKenzie says: Also note that HIST (as defined) is currently used in balloted specs, which I believe have passed ballot [3:10:42 PM] Lloyd McKenzie says: (It was pre-adopted in the ITS 2 years ago) [3:11:01 PM] Grahame Grieve says: what's wrong with HXIT<T> having historical : SET<T> - much cleaner all round [3:12:27 PM] Grahame Grieve says: well, at least that screw up is out side the datatypes. anyhow, I assert that the mere fact that HIST can be used like that indicates that the use case is the validTime of the observation of the value, not the value itself [7:42:21 PM] Grahame Grieve says: Now that I have the xml its building, why do the examples and the xml representation sections lose their formatting in the build from the cvs files, but not in the normative build? does anyone know off the top of their heads? [8:14:13 PM] Grahame Grieve says: no comment from anyone on CO; I am removing the CO operations. Someone can ballot if they want them. I will put a comment in about them [8:18:55 PM] Grahame Grieve says: " It has been proposed that some mathematical operations

      should be defined on CO itself. Given the kinds of uses
      for CO, addition and averaging appear to be candidate 
      operations. However defining these operations on CO implies
      that these are operations upon the concept itself, not the
      value assigned the concept. It is not clear that this is true,
      and so not operations have been defined. This may be reviewed
      if appropriately defined codeSystems are identified.

" [11:23:42 PM] Gunther Schadow says: Quick recap: validTime is supposed to be the time this thing really was, not the time someone knew it. You can leave that unchanged. If you have controlActRef, then that control act will carry the time someone made the change to some system to accomodate new knowledge of things. So, the definition of HXIT validTime is correct and fine, and Lloyd's use case is taken care of by the controlActRef. [11:24:42 PM] Gunther Schadow says: If you expect a T and get a HIST<T> you'd pick the one with the current validTime. The XML spec could say that that has to be the first or last one. [11:26:28 PM] Gunther Schadow says: Whoever "preadopted" a reading of HXIT.validTime which violates the definition (i.e., marking system change time rather than real world time), need to fix their interpretation to come back in line with the clear statement in the spec. [11:28:40 PM] Gunther Schadow says: Finally, ControlAct.effectiveTime cannot be the time that some specific value had effect in the real world. ControlAct.effectiveTime must be the time at which whatever the ControlAct does, is to take effect, i.e., if the ControlAct says "change some data" then the effectiveTime would be as of what time this change should be made. Few should allow back-dating this.. [11:29:50 PM] Gunther Schadow says: Finally, finally, you have some problems, i.e., what if the value did not actually change in the world, what if it was just entered wrong? Then you can't make a real history of the real value. That's why Grahame's pointing to update mode is considerable. [11:31:11 PM] Grahame Grieve says: fine, but if we work back, we haven't solved the prior problems. about uniqueness in a HIST, about equality/identity. I know you think the latter isn't a problem, but, well, we should get the formalisms right [11:41:15 PM] Gunther Schadow says: HIST was confusing. I'd be frustrated now that your truck show has been so fizzled out. How to regroup?

I agree that there is something about properties having different standing when it comes to equal that needs better explanation. I've started that long ago with calling some properties "mandatory" (if they always exists in a non-Null value) and "optional" if they needn't be there and "auxiliary" if they are just annotations, not contributing to the semantics. [11:42:09 PM] Grahame Grieve says: it hasn't fizzled out, we got diverted onto worthy subjects. I will regroup and get the show on the road again [11:42:35 PM] Gunther Schadow says: As soon as we have stuff haging on values that doesn't contribute to the semantics, but which people nevertheless put there and look up from there, it creates the sense of object with identities and value being distinguished. Like numbers with little notes attached. Even though 5 == 5, suddenly this 5 looks a little different than that 5. [11:42:56 PM] Lloyd McKenzie says: Gunght is correct - we should be talking about ControlAct.author.time, not ControlAct.effectiveTime [11:43:48 PM] Lloyd McKenzie says: If what you're dealing with is a registry entry, then what's in the system *is* the real world [11:44:36 PM] Lloyd McKenzie says: If something is entered, it's real, even if it's wrong [11:44:44 PM] Gunther Schadow says: [Sorry, I disagree to the registry entry == real world, but want to stick to the issue of annotational properties now.] [11:44:50 PM] Lloyd McKenzie says: Wrong values show up in history [11:45:39 PM] Grahame Grieve says: yes. we have something to do there. I am about to go to sleep, will pick it up tomorrow [11:46:52 PM] Gunther Schadow says: For some of these annotational properties, it is completely irrelevant. These properties should not even exist IMO. These include CD.codeSystemName, II.assigningAuthorityName. These properties are purely commentary and can be scrapped any time. They are in fact dangerous. [11:46:54 PM] Lloyd McKenzie says: If someone incorrectly enters your name as Joe Smith and later changes it to John Smith, both will show up in history [11:47:02 PM] Lloyd McKenzie says: They have to. [11:48:25 PM] Gunther Schadow says: There are more such dangerous properties, evene CD.displayName carries a danger, because people can use it unchecked, i.e., just displaying the displayName without making sure that it is consistent with the code. Still, displayName has a great use (and I'm using it like crazy), but it needs to be clear that you put a tremendous trust in your sender if you ever use their displayName to display to your users. [11:49:55 PM] Gunther Schadow says: displayName also is good to wonder about

<genderCode code="M" displayName="female" codeSystem="&hl7gendercodeoid;"/>

and

<genderCode code="M" displayName="male" codeSystem="&hl7gendercodeoid;"/>

are these equal? [11:51:59 PM] Grahame Grieve says: that's invalid. You can't ask valid questions about invalid data [11:52:41 PM] Grahame Grieve says: I think that they are "equal" though. I think the semantic equality rules for CD are fine. [11:53:10 PM] Grahame Grieve says: either the displayname counts or it doesn't. and we don't have the machinery to nail it down [8:43:58 AM] Grahame Grieve says: ok,back on the subject of null and equality, can anyone see anything wrong with this xml? <example xsi:type="CE" code="195967001" codeSystem="2.16.840.1.113883.19.6.96" codeSystemName="SNOMED CT">

 <displayName value="Asthma"/>
 <translation code="49390" codeSystem="2.16.840.1.113883.19.6.2" codeSystemName="ICD9CM">
   <displayName value="ASTHMA W/O STATUS ASTHMATICUS"/>
 </translation>
 <translation nullFlavor="OTH" codeSystem="2.16.840.1.113883.19.6.45" codeSystemName="Something">
 </translation>

</example> [8:45:01 AM] Grahame Grieve says: ahh - it's not the xml that's wrong (not deliberately, that's the ISO datatypes format), it's the semantics. just move displayName back to being an attribute [8:46:15 AM] Grahame Grieve says: and since we're all busy, and what not, the problem is that this is illegal. You cannot have a set that contains a null value. While this is a problem for CD - something we'll take up next - this is generally a problem with a set definition. Particularly in regard to HIST [8:48:38 AM] Grahame Grieve says: it seems to me that HIST specialises SET is basically wrong. it should be HIST specialises LIST. LIST can contain nulls, LIST has a concept of order (though there's no rule that the HXIT cannot overlap or have to be in order, it seems reasonable for HIST to sometimes have order significance), LIST has no uniqueness constraint (not that it makes sense for HIST to have duplicates, but trying to define a sensible workable uniqueness constraint for HIST is not going to be easy) [8:48:51 AM] Grahame Grieve says: but I've got diverted to HIST again.... [8:53:25 AM] Grahame Grieve says: It makes sense that sets can't contain null values because if it did, you couldn't evaluate uniqueness. So we don't want to change that. [8:54:39 AM] Grahame Grieve says: But I think that the fact that SET cannot contain nulls is something that slips under the radar. [8:55:26 AM] Grahame Grieve says: looking at the RIM... [8:56:21 AM] Grahame Grieve says: a slight deviation before pursuing this. Act.priorityCode:: SET<CE> - how can it make sense for something to be a SET<CE>? a single act can have multiple different priorities that are not translations of each other - is that really the intent? [8:57:30 AM] Grahame Grieve says: I think that the idea that Act.interpretationCode cannot contain CD with nullFlavor OTH might be a surprise to some people. Whoops, I'm back on CD. More on that later [8:57:43 AM] Grahame Grieve says: (and methodCode, and targetSiteCode) [8:59:56 AM] Lee Coller says: There can be different kinds of priorities, look at the informative vocabulary for it [9:01:24 AM] Grahame Grieve says: hmm. ok, like useCode, I guess. UD doesn't seem to belong there, but whatever [9:03:05 AM] Grahame Grieve says: act.id bans null - ironically, this was probably perfectly reasonable until we add II.scope in R2, and now people will suddenly find a use case for sending null IIs (we didn't bother asking what the business identifier was) [9:16:16 AM] Grahame Grieve says: no takers. Ok. I propose changing HIST from SET to LIST. [9:19:33 AM] Grahame Grieve says: btw, Rik has pointed out this: RIM definition for InfrastructureRoot.nullFlavor:When valued in an instance, this attribute signals that the class instance is null, and that the remainder of the information for this class and its properties will not be communicated. [9:19:55 AM] Grahame Grieve says: different issue, because it's about class, but I point out that the structural attributes need to be communicated. [9:25:19 AM] Gunther Schadow says: " I propose changing HIST from SET to LIST." - I'm fine with it. If HXIT.validTime stays IVL<TS>, no problem. We should then also say that this list must be ordered in chronological order (ascending) with the effective prevailing value last. (Why not reverse chronology? Because simple minded systems can just keep reading the value of the attribute till the end and so the last assignment prevails. [9:26:06 AM] Gunther Schadow says: " the remainder of the information for this class and its properties" -- they mean object. Why do people say "class" if they mean object? [9:26:24 AM] Lee Coller says: It's actually worse than that (communicating structural attributes) in some cases. You may need to also send the structural attributes of the other end of the relationship. That's because sometimes the only thing that distinguishes two clones are the structural attributes of the navigated-to relationship [9:26:51 AM] Grahame Grieve says: chronological order - cool, maybe, but do we have to do a precise definition for overlaps - go by low, I guess, and start with any where low is null and then order by high, if both low and high are null? [9:27:16 AM] Grahame Grieve says: Lee, can you provide an example? [9:27:19 AM] Lee Coller says: "Why do people say "class" if they mean object?" I agree, its gotten so bad even I slip up and do it sometimes [9:28:03 AM] Lee Coller says: Yes, let me bring up [9:33:52 AM] Lee Coller says: http://www.hl7.org/v3ballot/html/domains/uvct/editable/COCT_RM540000UV.htm [9:33:57 AM] Lee Coller says: A_GeneticLoci [9:35:07 AM] Lee Coller says: Has componet1 and component2 ActRelationship clones. If one is null, to tell which one it is I need the structural attributes of the target class. [9:35:17 AM] Lee Coller says: Of course, this could be fixed by saying the target is null, not the relationship [9:35:54 AM] Grahame Grieve says: but you get the names component1 and component2 to tell them apart? [9:36:17 AM] Lee Coller says: But the clone names are not supposed to convey semantics [9:36:43 AM] Grahame Grieve says: agree; but they are supposed to convey the link into the model [9:37:56 AM] Lee Coller says: But that is a counter argument to the fact you need to send structural attributes on nulls, because you can always use the clone names [9:38:01 AM] Grahame Grieve says: so it doesn't seem like conveying semantics unless you are trying to work without specific knowledge of the model. Then you would need to know more; I guess that since we accept that kind of approach, we should therefore rule that you couldn't call the relationship null, but the target [9:38:34 AM] Grahame Grieve says: yes, agree, but sometimes the clone names only identify <= domain/x domain, not a specific code. [9:39:09 AM] Lee Coller says: then theoretically the domains across the clones should be disjoint (really hard if they are CWE) [9:40:09 AM] Lee Coller says: thow in null and I don't think it would work [9:40:56 AM] Grahame Grieve says: in templates parlance, this is known as model indeterminacy. It's impossible to prevent, hard to find, but I couldn't find any existing models like that, and trying to make one up that was reasonably coherent was a challenge [9:41:28 AM] Grahame Grieve says: but adding to the mix that the targets could be null considerably increases the likelihood and reasonableness [9:42:56 AM] Lee Coller says: I've seen them, I negative ballot them when I find them. Genetic Locus used to be like that (all OBS) [10:16:26 AM] Gunther Schadow says: Lee, I don't think I would care, because in my world both would just be components. So one isn't there. I cannot tell which, and I don't need to use null flavor nuances here. If I needed to, then I would have to leave the act relationship and the distal object properly categorized and marked as null. I could get that out of the MIF I suppose. I need the MIF anyway in order to interpret the ideosyncratic names of tags. [10:18:09 AM] Grahame Grieve says: I was thinking as I was driving in to work today - Gunther and I (javaSIG and Eclipse) have a shared interface to the MIF, which could easily be declared in UML. I could define this as an underpinning framework for the abstract and UML ITS. This would give us a formal framework for making conformance statements in the datatypes [10:18:31 AM] Lee Coller says: In my world we claim that we can work without the model, and construct an instance based solely on structural attibutes without having to remember which clone class it tied back to. [10:19:02 AM] Grahame Grieve says: Aside to LLoyd: we could also use this as an XML format for the normative template format - avoids using the MIF directly, offers more interoperability in terms of dependence on UML type standards. [10:19:59 AM] Grahame Grieve says: Lee, under the HL7 rules, this cannot be true, because the structural attributes are defaulted. UK work differently, but in UV realm, you must read the model as you read the instance to connect the defaulted attributes up. Then you could interpret without the model. This is how Gunther works [10:20:56 AM] Lee Coller says: WE use the model to determine the defaults, but then we don't remember the model. If the model is vague, we cannot then reconstruct it accurately [10:22:06 AM] Lee Coller says: That's the difference between what we do and what the UK does. The UK says they don't need the model, we say we don't need to remember the model once we've populated defaults and fixed values. [10:22:43 AM] Grahame Grieve says: ok, you are the same as Gunther. And for the same reason, why would you care? [10:24:44 AM] Lee Coller says: For the null question I really don't becuase like Gunther, we don't use the null flavor nuances. But if we did it would become an issue if I had multiple null relationships. [10:25:14 AM] Grahame Grieve says: but you can still link them up with the model and fill out these various thingies [10:32:54 AM] Lee Coller says: I started to write up my explanation, but hten I realized you are right its not an issue (actually I realize the problem is in our implementation but not the definition). I can use the model to determine which is which -- I just need to make sure I keep that information when I save it. [12:42:41 PM] Grahame Grieve says: I have been thinking about equality vs identity. I think in the end, I have three real problems [12:43:30 PM] Grahame Grieve says: The first is that we claim that equality = identity, then we falsify that.This is an in principle issue, not one that has practical outworking issues for me, though I suspect it lies behind some of the problems with the mismatch between the definitions and the intentions [12:44:28 PM] Grahame Grieve says: The second turns on the definition of uniqueness of SET. I think that the second is not so much directly linked to identity vs equality as it is to the idea that different aspects of usage have different uniqueness constraints for different uses. HIST has demonstrated this well - HIST is really a SET where the (data+validTime) is unique, rather than SET where the data is unique [12:46:39 PM] Grahame Grieve says: The third may be linked to the first, and it relates to the definition of equality where some properties are null. We decided that I would go through and define equality explicitly for every data type, but it's still a blunt instrument. I can either include or exclude properties, but there is some properties that should be included if they are valued or have some kinds of null, else excluded. [12:59:30 PM] Grahame Grieve says: I don't think the third is amenable to a solution. We just have to suck it up. [1:01:22 PM] Grahame Grieve says: I don't think that the second is worth solving. One could do this by creating some kind of special SET that took an operation as a parameter, and insisted on uniqueness based on the parameter. Of course, uniquness isn't actually formally defined for a set, and could only possibly be defined for a DSET (if we had an identity function), but whoever heard of a class that takes an operation as a parameter. [1:02:15 PM] Grahame Grieve says: alternatively, we could just leave the things we really care about as BAGs, and write the constraint that we want for the few situations we really care - except that you do need the identity function in order to write those constraints. [1:03:10 PM] Grahame Grieve says: another alternative solution to the second problem is to create a whole series of different SETs and equals routines for different usages, pre-coordinating them... yeah ok, enough said. that's a spectacularly bad idea [1:04:45 PM] Grahame Grieve says: finally, we could take Gunther's head in the sand attitude to this problem. And that might be justified because not many people are aware of it - except when they ask why address is BAD<AD> not SET<AD> [1:05:05 PM] Grahame Grieve says: btw, Gunther, you didn't respond to my question about sorting HIST? [1:07:28 PM] Grahame Grieve says: would it hurt to turn a blind eye to identity vs equality, and define an .sameIdentity(other ANY) function, so we could write custom uniqueness constraints on BAGs? [1:07:50 PM] Grahame Grieve says: (if the answer to this is yes, then that's the end of the show, btw) [1:16:32 PM] Gunther Schadow says: "but whoever heard of a class that takes an operation as a parameter." -- not at all, great idea. It is simple, a Set that takes a Comparator as parameter. Makes perfect sense to me. [1:17:32 PM] Grahame Grieve says: k, we could do it that way. (duh). is it worth the investment? [1:19:33 PM] Gunther Schadow says: "btw, Gunther, you didn't respond to my question about sorting HIST?" -- sorting in IVL, o.k. would agree with your approach. Sort by low and secondly by high. So an interval starting earlier will be first, two intervals starting same time (oddly) the one running longer will be last. [1:19:38 PM] Grahame Grieve says: say, CSET (Comparable Set). SET extends CSET by binding to the equals based comparator. You can define other comparators by defining the type and making a constraint that expresses the uniqueness constraint [1:20:22 PM] Grahame Grieve says: ok. unless anyone objects, I'm going to rework HIST for R2 as discussed. [1:22:17 PM] Gunther Schadow says: "would it hurt to turn a blind eye to identity vs equality, and define an .sameIdentity(other ANY) function, so we could write custom uniqueness constraints on BAGs?" -- sameidentity ... interesting. Perhaps it's a good way out. Have the normal equal operation and another called identical. Identical would be defined in some very anal way, including displayName, codeSystemName, etc. And in some cases it would be used for some rules. Very few cases. I think less than you think, but worth giving a trial. [1:23:26 PM] Grahame Grieve says: actually, I think that the definition has to be in text rather than formal - it's a genuine primitive. and I think that the only use for it is making constraints within a list, where the difference between equality and identity happens to matter. [1:24:11 PM] Grahame Grieve says: cool. we have consensus. I will go with that, and we will see what happens at ballot [1:25:08 PM] Grahame Grieve says: and the ISO datatypes will be updated to be in sync with that too ;) [1:28:57 PM] Gunther Schadow says: Identical - "it's a genuine primitive." - I don't think it is a primitive. These things are still value objects without a pointable identity. You can only completely list it. There cannot be an id reference to a value. So, your total property comparison would make that effect. [1:29:47 PM] Grahame Grieve says: identical - all right, I'll play with it, and we can come back to that.