Re: SV: [Troll] Terminology bindings ... again

2018-03-21 Thread Michael.Lawley
Hi Heather, In general, anyone is welcome to participate in the work; you don't need to be one of the small number of Advisory Group members. That helps with travel costs, but most of the real work is done on teleconferences, not so much at the face to face meetings. I would be very

RE: SV: [Troll] Terminology bindings ... again

2018-03-21 Thread Heather Leslie
Hi Mikael, What efforts are being made to resolve the boundary problem? I applied to get involved with the SNOMED information modelling group but wasn’t successful, to try to engage on exactly that point. I’m not aware of any work going on. I’d be very pleased to get involved if I could.

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
On 21-03-18 16:32, GF wrote: When I’n not mistaken: Duration is not the same concept as Calendar. IsoTime and Calendar are both data types defining an absolute point on the time line, but in different ways. In the Java and Golang classes Calendar is also to indicate durations, it is in fact,

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Karsten Hilbert
On Wed, Mar 21, 2018 at 04:32:53PM +0100, GF wrote: > My point is that some times we can not/want not use points > on the time line but use fussier terms like: begin of an > event somewhere in 2015, or a duration of one month, or Which can be modelled as +/- such as +/- <3

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread GF
When I’n not mistaken: Duration is not the same concept as Calendar. IsoTime and Calendar are both data types defining an absolute point on the time line, but in different ways. Duration is the difference between points on the time line. My point is that some times we can not/want not use

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
Pieter, the problem are the conflicting semantics. You should avoid having conflicting semantics in one class, that is confusing. I think that is why Java and Golang have both in their standard libraries because of the conflicting semantics There is no good reason to have months and hours in

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
On 21-03-18 15:02, Bert Verhees wrote: I don't mind how you call it, programmers call it Duration and Calendar, both are well known datatypes, but they have other semantics. Sorry for my unpleasant tone, I guess we are talking about the same things. Bert

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Pieter Bos
I don't understand. You can implement a single class ISO8601 Duration, containing all the different fields, all optional, that directly maps to and from the string representation. You can also easily use it to model both P30D and P1M, which are indeed different things. Depending on the fields

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
I don't mind how you call it, programmers call it Duration and Calendar, both are well known datatypes, but they have other semantics. On 21-03-18 14:53, GF wrote: You gave proof that there are different kinds of time. *Chrono-time* as used fro time stamping at one exact point in time. And

SV: SV: [Troll] Terminology bindings ... again

2018-03-21 Thread Mikael Nyström
Hi Tom, I believe that you proposal to ”move / remove the pre-coordinated codes out of SNOMED” is very appealing in theory. However it is very difficult in reality to agree on where the line between a suitable pre-coordinated concept and a concept that is better to post-coordinate or handle in

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
On 21-03-18 13:57, Thomas Beale wrote: although 'month' is not a scientific notion (it's not constant), we do treat it as a data type or unit in /social date time types/, which is what we are mostly dealing with, and what the types DvDuration, DvDate etc correspond to. For scientific

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
On 21-03-18 13:51, Thomas Beale wrote: On 20/03/2018 23:33, A Verhees wrote: One last remark. There is in medical context need of a datatypes to express: "do this one time a month, for example on a specific date". But technically seen, this is not a duration, the maybe a need for another

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
No Duration type is a ISO8601 duration, ISO8601 is just a string representation of a duration. No programming language can, from its standard library safely express an ISO8601 in a class, because the ISO8601 is a combination of two types. Unless you are wiling to have an uncertainty of 10%, you

Re: SV: [Troll] Terminology bindings ... again

2018-03-21 Thread Thomas Beale
Nevertheless, I think it would have been good to move / remove the pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, which would actually look a lot more like Philippe's (much smaller) terminology. This relates to the old debate on reference v interface

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Thomas Beale
although 'month' is not a scientific notion (it's not constant), we do treat it as a data type or unit in /social date time types/, which is what we are mostly dealing with, and what the types DvDuration, DvDate etc correspond to. For scientific durations, use DvQuantity, and then you have a

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Thomas Beale
On 20/03/2018 23:33, A Verhees wrote: One last remark. There is in medical context need of a datatypes to express: "do this one time a month, for example on a specific date". But technically seen, this is not a duration, the maybe a need for another datatype to express this. Using the

SV: [Troll] Terminology bindings ... again

2018-03-21 Thread Mikael Nyström
Hi Philippe, I think that you have missed that SNOMED CT is created for multiple use cases. Your use case that you describe as "a modern approach" is a good use case that I like. In that use case SNOMED CT can be used in the way you describe using SNOMED CT's concepts a little higher up in the

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Pieter Bos
There seems to be some confusion regarding the concept of a ISO8601 Duration. You can definitely define a duration of 2 months in ISO8601 Durations. It has separate fields for years, months, weeks, days, plus an optional time with hours, minutes and seconds. All these fields are optional and

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Thomas Beale
On 20/03/2018 21:54, Pablo Pazos wrote: Yep, I know https://docs.oracle.com/javase/tutorial/datetime/iso/period.html But this is not about anything Java specific, just giving an example why Duration might not be good for an assumed type on the openEHR specs :) just to give some

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread Bert Verhees
On 21-03-18 10:50, GF wrote: Does including Duration in the RM fit with the scope for the RM? Why do we have archetypes? Why not include every thing in the RM? Do we want the HL7v3 Reference Model as it existed many years ago and that could not be inspected without a magnifying glass on a

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

2018-03-21 Thread GF
Does including Duration in the RM fit with the scope for the RM? Why do we have archetypes? Why not include every thing in the RM? Do we want the HL7v3 Reference Model as it existed many years ago and that could not be inspected without a magnifying glass on a sheet of paper that was 2 by 1