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

Calendars are for dates and times, not durations. On 21/03/2018 13:47, Bert Verhees wrote: 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

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

Chairos time has fussiness (uncertainty) as attribute. Actually any topic needs a fussiness/uncertainty attribute. Either a range of something or a subjective qualification Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 21 Mar 2018, at

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

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?

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?

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?

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?

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?

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?

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

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

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?

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?

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: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

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?

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

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

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?

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?

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

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

That is true, but I think it would be good if it would find its way in the RM, for two reasons 1) misusing the duration does not seem right, and I think the ISO string representing a duration must change. That is, I know, a long way, so the part before the 'T' should represent a calendar datatype,

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

Nothing restricts you to create a "data type pattern"/specialized cluster that has exactly this semantics El mar., 20 mar. 2018 23:34, A Verhees escribió: > One last remark. > > There is in medical context need of a datatypes to express: "do this one > time a month, for

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

A Calendar datatype. Op 20 mrt. 2018 23:33 schreef "A Verhees" : > 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

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

Nanoseconds are probably not needed many times in medical context, but they are not in the way of using them as seconds or minutes. Op 20 mrt. 2018 23:27 schreef "Diego Boscá" : > We can revisit all the types we want, but we shouldn't forget that types > will be used for

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

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 duration for this may be a handy shortcut in

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

We can revisit all the types we want, but we shouldn't forget that types will be used for medical data, and maybe we don't really need nanosecond precision. El mar., 20 mar. 2018 23:09, A Verhees escribió: > Now you say, you are right. > > The Java 8 duration is indeed

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

Now I come to think about it, I remember reading somewhere that conversion durations to number of years or months is no longer desired because years and months do not have always the same number of nanoseconds. Of course conversions to days and weeks is easy, although they are also not always the

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

Now you say, you are right. The Java 8 duration is indeed diffrent, but you can still use the Joda duration, or you can write your own duration class. In Golang the duration class is also limited, it is build around nanoseconds, but I wrote my own which is conform the OpenEhr specs, which was not

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

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 :) On the other hand... (re)thinking: assumed types should not be considered

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

Java 8 has a Duration for hours, minutes and seconds, and Period for years, months and days. Both implement a few interfaces with which you can abstract them. No idea why they chose this, it’s quite annoying to work with. You can relatively easily implement your own variant of ChronoPeriof that

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

Thanks Thomas, will create the PR! Also will double check if the same happens with other types, but I think the only "odd" one that might not be correct to assume, is the Duration. For instance, Java 8 added the Duration as a base type, but it only handles day to seconds duration expressions,

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

On 19/03/2018 22:25, Pablo Pazos wrote: Hi Thomas, the definition of DV_DURATION is clear to me :) The issue is on the 1.0.2 specs, I guess they used DV_DURATION in C_DURATION because the referenced Duration class in C_DURATION was not included on the specs. _This is the issue I'm pointing

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

Hi Thomas, the definition of DV_DURATION is clear to me :) The issue is on the 1.0.2 specs, I guess they used DV_DURATION in C_DURATION because the referenced Duration class in C_DURATION was not included on the specs. *This is the issue I'm pointing to, the missing class.* Clarifying that on an

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

a cleaner programmer journey would be AOM2/ADL2, even if you stick to RM 1.0.2 ;) - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

On 19/03/2018 18:33, Pablo Pazos wrote: Thanks Thomas, I see the Duration class on the baseline BASE model http://openehr.org/releases/BASE/latest/docs/foundation_types/foundation_types.html#_overview_5 But I'm a 1.0.2 implementer and I guess there are others. As far as I can see, there is

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

Thanks Thomas, I see the Duration class on the baseline BASE model http://openehr.org/releases/BASE/latest/docs/foundation_types/foundation_types.html#_overview_5 But I'm a 1.0.2 implementer and I guess there are others. As far as I can see, there is no Duration class for 1.0.2. I would be good

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

On 19-03-18 16:16, Thomas Beale wrote: On 19/03/2018 08:57, GF wrote: Again my thoughts Duration is not a Data Type in many computer languages. So we need to model it in an Archetype (Chairos) that's true, but in databases and XML it is, and it is mostly treated like a primitive data type

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

Duration must be modelled using Archetype and not as part of the RM or AOM. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Mar 2018, at 15:55, Pablo Pazos wrote: > > Hi Gerard, this is about the current specs,

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

On 19/03/2018 08:57, GF wrote: Again my thoughts Duration is not a Data Type in many computer languages. So we need to model it in an Archetype (Chairos) that's true, but in databases and XML it is, and it is mostly treated like a primitive data type - i.e. a non-identified, instance-only

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

Hi Gerard, this is about the current specs, not about what is supported by programming languages. On Mon, Mar 19, 2018, 05:57 GF wrote: > Again my thoughts > > Duration is not a Data Type in many computer languages. > So we need to model it in an Archetype (Chairos) > > Gerard

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

Again my thoughts Duration is not a Data Type in many computer languages. So we need to model it in an Archetype (Chairos) Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Mar 2018, at 06:24, Pablo Pazos wrote: >

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

Hi, Looking at CDuration http://www.openehr.org/releases/1.0.2/architecture/am/aom.pdf page 46, the range constraint is defined with a Duration class. On the support specs http://www.openehr.org/releases/1.0.2/architecture/rm/support_im.pdf page 30 we have the ISO8601_DURATION class. Should AOM