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

[Thomas Beale]

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 dealing with, and what the types DvDuration, 
DvDate etc correspond to.


For scientific durations, use DvQuantity, and then you have a Real + 
units, e.g. 205ms, 89ns, 4.5min etc


So I think it is quite right to standardise these two notions in the 
RM, and also if we can, a standard model of 'time specification' 
which is the '3 times/day' kind of idea. We still don't have a good 
solution for this last one.




What is the problem with the Calendar type?


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
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?

[GF]

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 17:17, Karsten Hilbert  wrote:
> 
> 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 months>
> 
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
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?

[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, to do Calendar calculations. You can calculate the first 
day (example 2004/1/1) and say, this date + 3 months, and then you get a 
new Date, which is a different number of days away then when the first 
date is 2005/1/1 + 3 months (because of Leap year)


For example, see here the Add function to Add months or weeks or years 
to a date

https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html#add(int,%20int)

That is what is needed when you calculate in the date range of the 
ISO8601 string.


When you do calculations in the time range, then you need to calculate 
with a Duration (which does in background everything in nanoseconds, but 
has convenience methods to use it for hours and minutes, etc)




Duration is the difference between points on the time line.

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


Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 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.



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 *Chairos-time* used for imprecise relative time as used by humans,

*Chrono-time* is one primitive data type.
*Chairos-time* is defined using archetype/patterns



Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 12:25, Bert Verhees > wrote:



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 
sheet of paper that was 2 by 1 meters?


Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because 
month is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration 
and a Calendar class.
Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right 
(I prefer this way),
or express months as if it is a stable time-indicator and ignore it 
is not (like it is now)


Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org 


http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
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?

[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 months>

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
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?

[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 points on the time line but 
use fussier terms like: begin of an event somewhere in 2015, or a duration of 
one month, or

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 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.
> 
> 
> 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 Chairos-time used for imprecise relative time as used by humans,
>> 
>> Chrono-time is one primitive data type.
>> Chairos-time is defined using archetype/patterns
>> 
>> 
>> 
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl 
>> 
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>> 
>>> On 21 Mar 2018, at 12:25, Bert Verhees >> > wrote:
>>> 
>>> 
>>> 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 sheet of paper that 
 was 2 by 1 meters?
 
 Is there one kind of duration?
 24 minutes, 5 seconds?
 For 2 hours past midnight?
 For 2 hours after (clinical) event x
 For 2 months after (clinical) event y
>>> 2 months cannot be technically represented in a duration, because month is 
>>> not a stable time-definition. It is a Calendar definition.
>>> It is therefor that most major programing languages have a Duration and a 
>>> Calendar class.
>>> Or you say that OpenEhr has no valid Duration-datatype, so always express 
>>> Duration in an archetype (your way),
>>> or say that OpenEhr has a valid Dv_Duration type, and do it right (I prefer 
>>> this way),
>>> or express months as if it is a stable time-indicator and ignore it is not 
>>> (like it is now)
>>> 
>>> Those are the three possible ways to solve this problem, I think
>>> I am curious to learn what the community will decide.
>>> 
>>> Bert
>> 
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org 
>> 
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>  
>> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
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?

[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 one class.
I must admit, days is a bit in between, although, when looking exact at 
it, one specific day can have in some years one second more or less.
I believe this is always December 31th. So days is more right to put in 
the Calendar class.


But I must leave this discussion, I notice I get involved too much. I 
have given my opinions, and others should give theirs


Best regards
Bert

On 21-03-18 15:52, Pieter Bos wrote:

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 set, it's 
either very exact or a bit less exact notion of duration.

You should not expect to always to the same calculations with all recorded 
values. How you should exactly handle durations, or dates, or date times, or 
intervals of date times, and if and how you need to split classes, depends on 
the context (archetypes are a very nice tool to define and standardize 
context). The standard ISO8601 types are very useful for having a standard way 
to record date, time, date+time, duration and intervals between fixed points in 
time, with varying precision. And I don't think we need anything else and 
certainly not anything less in the RM.


Also days are not always 24 hours. Next weekend in our time zone we have a 23 
hour day...
That is one reason why some libraries make a different split between the 
concepts than what you call 'calendar' and 'duration'. Also every library and 
standard has its own term for those concepts.

  
Regards,


Pieter Bos

On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" 
 wrote:

 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 cannot express
 a month in a Duration type. For many software, this uncertainty is not
 acceptable. Maybe it is for medical purposes, but OpenEhr also has an
 Admin_Entry, and there this uncertainty is not always acceptable. How do
 you bill someone who was one month in a clinic? Make it 28 days or 31 days?
 
 And the solution is easy, and it has advantages.
 
 If we split the Dv_Duration in a Calendar part and in a Duration part,

 then both have their own merits. If you want to bill a stay of a month
 in a clinic, you express it by days (which are always 24 hours) P30D
 (represented by the Duration class) and if you want the patient to
 return every month, you can use the first part, P1M (represented by the
 Calendar class).
 
 I don't think this is complex or requires complex algorithms, even

 opposite, it makes it more simple and more certain to process and all
 the troubles and bad feelings when converting a month to 30 days, and
 then find out it was 28 days, are gone. I think Joda was a complex
 solution for a simple problem.
 
 Bert
 
 
 
 
 On 21-03-18 13:47, Pieter Bos wrote:

 > 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 can all be combined. 
It cannot be fully modelled using a single nanosecond field - you would run into 
trouble with years, months, and even days, plus you cannot express for example a 
duration of 1 hour with no precision in the minutes and seconds fields mentioned. 
I think  https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation 
of the concept.
 >
 > The golang Duration type in the time package is _not_ an ISO8601 
duration, but just a duration in nanoseconds, explicitly omitting the definition 
of days. There are libraries available for golang that do model the full iso8601 
duration.
 >
 > Of course, I agree that we should not have a far too big reference 
model. There is a point at which it no longer makes sense to add something to the 
reference model because it is better modelled in an archetype. But I think the 
concept of a duration can be very useful. You could use it to model the examples 
Gerard Freriks mentions for example:
 >
 > - 24 minutes, 

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

[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

___
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?

[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 set, it's 
either very exact or a bit less exact notion of duration.

You should not expect to always to the same calculations with all recorded 
values. How you should exactly handle durations, or dates, or date times, or 
intervals of date times, and if and how you need to split classes, depends on 
the context (archetypes are a very nice tool to define and standardize 
context). The standard ISO8601 types are very useful for having a standard way 
to record date, time, date+time, duration and intervals between fixed points in 
time, with varying precision. And I don't think we need anything else and 
certainly not anything less in the RM.


Also days are not always 24 hours. Next weekend in our time zone we have a 23 
hour day... 
That is one reason why some libraries make a different split between the 
concepts than what you call 'calendar' and 'duration'. Also every library and 
standard has its own term for those concepts.

 
Regards,

Pieter Bos

On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:

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 cannot express 
a month in a Duration type. For many software, this uncertainty is not 
acceptable. Maybe it is for medical purposes, but OpenEhr also has an 
Admin_Entry, and there this uncertainty is not always acceptable. How do 
you bill someone who was one month in a clinic? Make it 28 days or 31 days?

And the solution is easy, and it has advantages.

If we split the Dv_Duration in a Calendar part and in a Duration part, 
then both have their own merits. If you want to bill a stay of a month 
in a clinic, you express it by days (which are always 24 hours) P30D 
(represented by the Duration class) and if you want the patient to 
return every month, you can use the first part, P1M (represented by the 
Calendar class).

I don't think this is complex or requires complex algorithms, even 
opposite, it makes it more simple and more certain to process and all 
the troubles and bad feelings when converting a month to 30 days, and 
then find out it was 28 days, are gone. I think Joda was a complex 
solution for a simple problem.

Bert




On 21-03-18 13:47, Pieter Bos wrote:
> 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 can all be combined. It cannot be fully modelled using a single nanosecond 
field - you would run into trouble with years, months, and even days, plus you 
cannot express for example a duration of 1 hour with no precision in the 
minutes and seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.
>
> The golang Duration type in the time package is _not_ an ISO8601 
duration, but just a duration in nanoseconds, explicitly omitting the 
definition of days. There are libraries available for golang that do model the 
full iso8601 duration.
>
> Of course, I agree that we should not have a far too big reference model. 
There is a point at which it no longer makes sense to add something to the 
reference model because it is better modelled in an archetype. But I think the 
concept of a duration can be very useful. You could use it to model the 
examples Gerard Freriks mentions for example:
>   
> - 24 minutes, 5 seconds can be modelled as a single Element with a 
DV_Duration value. The ISO8601 text representation of the dv_duration.value 
field would be PT24M5S.
> - For 2 hours past midnight can be modeled with two Elements, for example 
a 'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
> - A duration after a specific clinical event can be modelled as however 
you want to model the reference to the clinical event, plus a single 
DV_DURATION field. In the first example the  value field of the DV_DURATION 
would be P2M, the second PT2H
>
> Say you want to model the duration after which to resume a specified 
daily activity 

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

[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 *Chairos-time* used for imprecise relative time as used by humans,

*Chrono-time* is one primitive data type.
*Chairos-time* is defined using archetype/patterns



Gerard   Freriks
+31 620347088
gf...@luna.nl 

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 12:25, Bert Verhees > wrote:



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 
sheet of paper that was 2 by 1 meters?


Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because 
month is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration 
and a Calendar class.
Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right (I 
prefer this way),
or express months as if it is a stable time-indicator and ignore it 
is not (like it is now)


Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
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?

[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 durations, use DvQuantity, and then you have a Real + 
units, e.g. 205ms, 89ns, 4.5min etc


So I think it is quite right to standardise these two notions in the 
RM, and also if we can, a standard model of 'time specification' which 
is the '3 times/day' kind of idea. We still don't have a good solution 
for this last one.




What is the problem with the Calendar type?
___
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?

[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 datatype to express this.


Using the duration for this may be a handy shortcut in specs, but it 
is not right. It is in fact misusing a datatype which does not 
support this expression. The ISO string should also be changed 
accordingly.


we don't really use Duration to represent 3 times / day. There are old 
HL7 data types which we included in openEHR to do this, called GTS and 
its children 
. 
It seems that noone uses these. THere have been many other attempts to 
define either types or structures, like iCal and other 
calendar-related structures. But I don't see a clear winner in terms 
of standards.


THe medication archetypes solve it by using multiple fields, and in 
Task Planning we had to create some new time specification types as 
well - CLOCK_TIME, CALENDAR_TIME, and CUSTOMARY_TIME 
.


You can need Duration for many purposes
Which comes to mind. How long was the patient feeling bad? How long did 
the patient sleep? How long was he staying in the hospital. These are 
all Durations. How long was the pregnancy time, How much time is their 
between two named phases of a heartbeat



___
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?

[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 cannot express 
a month in a Duration type. For many software, this uncertainty is not 
acceptable. Maybe it is for medical purposes, but OpenEhr also has an 
Admin_Entry, and there this uncertainty is not always acceptable. How do 
you bill someone who was one month in a clinic? Make it 28 days or 31 days?


And the solution is easy, and it has advantages.

If we split the Dv_Duration in a Calendar part and in a Duration part, 
then both have their own merits. If you want to bill a stay of a month 
in a clinic, you express it by days (which are always 24 hours) P30D 
(represented by the Duration class) and if you want the patient to 
return every month, you can use the first part, P1M (represented by the 
Calendar class).


I don't think this is complex or requires complex algorithms, even 
opposite, it makes it more simple and more certain to process and all 
the troubles and bad feelings when converting a month to 30 days, and 
then find out it was 28 days, are gone. I think Joda was a complex 
solution for a simple problem.


Bert




On 21-03-18 13:47, Pieter Bos wrote:

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 can all be 
combined. It cannot be fully modelled using a single nanosecond field - you 
would run into trouble with years, months, and even days, plus you cannot 
express for example a duration of 1 hour with no precision in the minutes and 
seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.

The golang Duration type in the time package is _not_ an ISO8601 duration, but 
just a duration in nanoseconds, explicitly omitting the definition of days. 
There are libraries available for golang that do model the full iso8601 
duration.

Of course, I agree that we should not have a far too big reference model. There 
is a point at which it no longer makes sense to add something to the reference 
model because it is better modelled in an archetype. But I think the concept of 
a duration can be very useful. You could use it to model the examples Gerard 
Freriks mentions for example:
  
- 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration value. The ISO8601 text representation of the dv_duration.value field would be PT24M5S.

- For 2 hours past midnight can be modeled with two Elements, for example a 
'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
- A duration after a specific clinical event can be modelled as however you 
want to model the reference to the clinical event, plus a single DV_DURATION 
field. In the first example the  value field of the DV_DURATION would be P2M, 
the second PT2H

Say you want to model the duration after which to resume a specified daily 
activity after a specified clinical event . You could model it by creating an 
archetype with a reference to the clinical event, a model of a description of 
the activity, and then a single DV_DURATION field, describing the time between 
the event and the start of the daily activity.
The person entering the data with this archetype now has the freedom of 
choosing any detail level he or she wants - whether that is in terms of years, 
months, weeks, days, hours, minutes, seconds, or any combination of any of 
these terms.

And the nice thing is, you would use a standards based duration concept that is 
readily available in many off the shelf languages, libraries, serialization 
tools, UI components and databases, instead of defining your own. And it's 
already defined in the OpenEHR models, so you can start using it right away.

Regards,

Pieter Bos
Nedap Healthcare


On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" 
 wrote:

 
 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 sheet of
 > paper that was 2 by 1 meters?
 >
 > Is there one kind of duration?
 > 24 minutes, 5 seconds?
 > For 2 hours past midnight?
 > For 2 hours after (clinical) event x
 > For 2 months after (clinical) 

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

[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 Real + 
units, e.g. 205ms, 89ns, 4.5min etc


So I think it is quite right to standardise these two notions in the RM, 
and also if we can, a standard model of 'time specification' which is 
the '3 times/day' kind of idea. We still don't have a good solution for 
this last one.


- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
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?

[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 duration for this may be a handy shortcut in specs, but it 
is not right. It is in fact misusing a datatype which does not support 
this expression. The ISO string should also be changed accordingly.


we don't really use Duration to represent 3 times / day. There are old 
HL7 data types which we included in openEHR to do this, called GTS and 
its children 
. 
It seems that noone uses these. THere have been many other attempts to 
define either types or structures, like iCal and other calendar-related 
structures. But I don't see a clear winner in terms of standards.


THe medication archetypes solve it by using multiple fields, and in Task 
Planning we had to create some new time specification types as well - 
CLOCK_TIME, CALENDAR_TIME, and CUSTOMARY_TIME 
.


- 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?

[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 can all be 
combined. It cannot be fully modelled using a single nanosecond field - you 
would run into trouble with years, months, and even days, plus you cannot 
express for example a duration of 1 hour with no precision in the minutes and 
seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.

The golang Duration type in the time package is _not_ an ISO8601 duration, but 
just a duration in nanoseconds, explicitly omitting the definition of days. 
There are libraries available for golang that do model the full iso8601 
duration.

Of course, I agree that we should not have a far too big reference model. There 
is a point at which it no longer makes sense to add something to the reference 
model because it is better modelled in an archetype. But I think the concept of 
a duration can be very useful. You could use it to model the examples Gerard 
Freriks mentions for example:
 
- 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration 
value. The ISO8601 text representation of the dv_duration.value field would be 
PT24M5S.
- For 2 hours past midnight can be modeled with two Elements, for example a 
'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
- A duration after a specific clinical event can be modelled as however you 
want to model the reference to the clinical event, plus a single DV_DURATION 
field. In the first example the  value field of the DV_DURATION would be P2M, 
the second PT2H

Say you want to model the duration after which to resume a specified daily 
activity after a specified clinical event . You could model it by creating an 
archetype with a reference to the clinical event, a model of a description of 
the activity, and then a single DV_DURATION field, describing the time between 
the event and the start of the daily activity. 
The person entering the data with this archetype now has the freedom of 
choosing any detail level he or she wants - whether that is in terms of years, 
months, weeks, days, hours, minutes, seconds, or any combination of any of 
these terms.

And the nice thing is, you would use a standards based duration concept that is 
readily available in many off the shelf languages, libraries, serialization 
tools, UI components and databases, instead of defining your own. And it's 
already defined in the OpenEHR models, so you can start using it right away.

Regards,

Pieter Bos
Nedap Healthcare


On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" 
 
wrote:


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 sheet of 
> paper that was 2 by 1 meters?
>
> Is there one kind of duration?
> 24 minutes, 5 seconds?
> For 2 hours past midnight?
> For 2 hours after (clinical) event x
> For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because month 
is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration and 
a Calendar class.

Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right (I 
prefer this way),
or express months as if it is a stable time-indicator and ignore it is 
not (like it is now)

Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
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?

[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 background, 'Duration' was always intended to 
represent a data type that could be considered like the ISO601 Duration 
type (also the ISO8601 Date type etc), which is also a W3C type 
(duration, gdate etc) - regardless of internal representation. For Java 
programmers, the joda library provided this; recent Java and C# have 
more modern things built in.


The Foundation Types spec now has a types cross-ref datatypes here 
. 
No guarantee it is correct ;)




On the other hand... (re)thinking: assumed types should not be 
considered as "supported by a programming language", but "supported by 
a programming language or application" ***. For instance, it is not so 
difficult to create a Duration class ourselves on any programming 
language, or even use one of the many available libraries that deal 
with Duration types and are compatible with ISO8601 durations.


Considering that, we might need to clarify:

1. What "assumed type" really is (it seems most tend to think that 
should be supported by a programming language, need to double check 
the specs to see how this is defined, maybe is clearly defined but not 
highlighted enough).


we are moving away from this terminology 'assumed types', and just using 
'primitive types', but the idea is the same - that it is assumed that 
the programming environment has some equivalent that can be connected to 
e.g. Duration, String etc, as they appear in the openEHR specs.




2. Clarify the use of the Duration class from CDuration where Duration 
is not on the specs (we can say it is assumed considering assumed as 
the definition ***)



it is now - in the Foundation Types spec 
.




3. Complementing 2. we can propose support for Duration on many 
programming languages by recommending certain libraries or core types. 
This can be an ITS or just an addendum/errata to v1.0.2 specs.


right - that xref table referred to above is an attempt to do this. We 
can expand that table to include more languages/technologies, or do it 
some other way.  If we can use this table, it means we can avoid 
publishing another separate spec.


- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
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?

[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 meters?

Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 21 Mar 2018, at 00:22, A Verhees  wrote:
> 
> 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, and the other part 
> should be a duration. It is also worth considering to split the DV_DURATION 
> type in the same way.
> 2) If it find its formal way in the RM libraries will support it also, which 
> will help implementers to do it the right way.
> 
> Bert



signature.asc
Description: Message signed with OpenPGP
___
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?

[A Verhees]

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, and the other
part should be a duration. It is also worth considering to split the
DV_DURATION type in the same way.
2) If it find its formal way in the RM libraries will support it also,
which will help implementers to do it the right way.

Bert

Op 20 mrt. 2018 23:48 schreef "Diego Boscá" :

> 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 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 specs, but it is
>> not right. It is in fact misusing a datatype which does not support this
>> expression. The ISO string should also be changed accordingly.
>>
>> Bert
>>
>> Op 20 mrt. 2018 23:24 schreef "A Verhees" :
>>
>>> 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 same, but that can be ignored, it is one second every few
>>> years.
>>>
>>> Op 20 mrt. 2018 23:08 schreef "A Verhees" :
>>>
 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 that hard.

 https://golang.org/pkg/time/#Duration
 https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html

 Maybe it is a good idea for the OpenEhr community to study the duration
 type again to see why in two major programming languages there is another
 approach build around nanoseconds and having  conversions to hours, etc.
 Maybe there is another trend coming up. Maybe it is interesting to conform
 to these trends

 Bert

 Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :

 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, year, month, week are not
 supported. Each technology has it's own quirks :)

 On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale  wrote:

>
>
> 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 to, the
> missing class.*
>
>
> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
> constrained a same- or similarly named primitive type like Integer, 
> String,
> Date, Duration etc that are assumed to be part of the technology
> environment. THey are normally part of the programming language, DB, or
> serialisation formalisms.
>
> I think this probably was not as clear as it should have been in that
> spec.
>
> In the AOM2/ADL2 specs, we have clarified this so that the same types
> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
> of the BASE component.
>
>
> Clarifying that on an errata addendum would help to avoid such
> implementation mistakes, that are really caused by the missing information
> on the spec + interpretation to fill the gap.
>
>
> agree, we should do this - can you create a PR for this? Or add to an
> existing PR.
>
>
>
> BTW, this is one case that I detected because I'm doing research for a
> new course. There might be issues like this on other areas of 1.0.2, I 
> mean
> missing classes referenced from AOM or AOP. I didn't do a complete review
> of the specs.
>
> I would love to migrate everything to baseline 

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

[Diego Boscá]

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 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 specs, but it is
> not right. It is in fact misusing a datatype which does not support this
> expression. The ISO string should also be changed accordingly.
>
> Bert
>
> Op 20 mrt. 2018 23:24 schreef "A Verhees" :
>
>> 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 same, but that can be ignored, it is one second every few
>> years.
>>
>> Op 20 mrt. 2018 23:08 schreef "A Verhees" :
>>
>>> 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 that hard.
>>>
>>> https://golang.org/pkg/time/#Duration
>>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>>
>>> Maybe it is a good idea for the OpenEhr community to study the duration
>>> type again to see why in two major programming languages there is another
>>> approach build around nanoseconds and having  conversions to hours, etc.
>>> Maybe there is another trend coming up. Maybe it is interesting to conform
>>> to these trends
>>>
>>> Bert
>>>
>>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>>>
>>> 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, year, month, week are not supported.
>>> Each technology has it's own quirks :)
>>>
>>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
>>> wrote:
>>>


 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 to, the missing
 class.*


 Right - the ADL/AOM 1.4 specs made the assumption that each primitive
 constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
 constrained a same- or similarly named primitive type like Integer, String,
 Date, Duration etc that are assumed to be part of the technology
 environment. THey are normally part of the programming language, DB, or
 serialisation formalisms.

 I think this probably was not as clear as it should have been in that
 spec.

 In the AOM2/ADL2 specs, we have clarified this so that the same types
 (C_INTEGER etc) now refer to types that are defined in the Foundation spec
 of the BASE component.


 Clarifying that on an errata addendum would help to avoid such
 implementation mistakes, that are really caused by the missing information
 on the spec + interpretation to fill the gap.


 agree, we should do this - can you create a PR for this? Or add to an
 existing PR.



 BTW, this is one case that I detected because I'm doing research for a
 new course. There might be issues like this on other areas of 1.0.2, I mean
 missing classes referenced from AOM or AOP. I didn't do a complete review
 of the specs.

 I would love to migrate everything to baseline spec and use AOM2, but I
 can't afford the cost right now. I'm sure others are on my same position.


 hopefully that will change soon, because ADL2 is more regular and
 simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
 I'd be interested to know what the real costs are and to see what we can do
 to make the transition simpler, because staying with ADL1.4 is limiting
 system functionality for the future.


 BTW tried to check if the issue is also on 1.0.3 but the link to
 support is broken http://openehr.org/RM/Release-1.0.3/support.html


 the page where you got that link
  is 

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

[A Verhees]

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 need for another
> datatype to express this.
>
> Using the duration for this may be a handy shortcut in specs, but it is
> not right. It is in fact misusing a datatype which does not support this
> expression. The ISO string should also be changed accordingly.
>
> Bert
>
> Op 20 mrt. 2018 23:24 schreef "A Verhees" :
>
>> 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 same, but that can be ignored, it is one second every few
>> years.
>>
>> Op 20 mrt. 2018 23:08 schreef "A Verhees" :
>>
>>> 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 that hard.
>>>
>>> https://golang.org/pkg/time/#Duration
>>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>>
>>> Maybe it is a good idea for the OpenEhr community to study the duration
>>> type again to see why in two major programming languages there is another
>>> approach build around nanoseconds and having  conversions to hours, etc.
>>> Maybe there is another trend coming up. Maybe it is interesting to conform
>>> to these trends
>>>
>>> Bert
>>>
>>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>>>
>>> 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, year, month, week are not supported.
>>> Each technology has it's own quirks :)
>>>
>>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
>>> wrote:
>>>


 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 to, the missing
 class.*


 Right - the ADL/AOM 1.4 specs made the assumption that each primitive
 constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
 constrained a same- or similarly named primitive type like Integer, String,
 Date, Duration etc that are assumed to be part of the technology
 environment. THey are normally part of the programming language, DB, or
 serialisation formalisms.

 I think this probably was not as clear as it should have been in that
 spec.

 In the AOM2/ADL2 specs, we have clarified this so that the same types
 (C_INTEGER etc) now refer to types that are defined in the Foundation spec
 of the BASE component.


 Clarifying that on an errata addendum would help to avoid such
 implementation mistakes, that are really caused by the missing information
 on the spec + interpretation to fill the gap.


 agree, we should do this - can you create a PR for this? Or add to an
 existing PR.



 BTW, this is one case that I detected because I'm doing research for a
 new course. There might be issues like this on other areas of 1.0.2, I mean
 missing classes referenced from AOM or AOP. I didn't do a complete review
 of the specs.

 I would love to migrate everything to baseline spec and use AOM2, but I
 can't afford the cost right now. I'm sure others are on my same position.


 hopefully that will change soon, because ADL2 is more regular and
 simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
 I'd be interested to know what the real costs are and to see what we can do
 to make the transition simpler, because staying with ADL1.4 is limiting
 system functionality for the future.


 BTW tried to check if the issue is also on 1.0.3 but the link to
 support is broken http://openehr.org/RM/Release-1.0.3/support.html


 the page where you got that link
  is now
 fixed.

 - thomas


 

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

[A Verhees]

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 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 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 that hard.
>>
>> https://golang.org/pkg/time/#Duration
>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>
>> Maybe it is a good idea for the OpenEhr community to study the duration
>> type again to see why in two major programming languages there is another
>> approach build around nanoseconds and having  conversions to hours, etc.
>> Maybe there is another trend coming up. Maybe it is interesting to conform
>> to these trends
>>
>> Bert
>>
>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>>
>> 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, year, month, week are not supported.
>> Each technology has it's own quirks :)
>>
>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
>> wrote:
>>
>>>
>>>
>>> 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 to, the missing
>>> class.*
>>>
>>>
>>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>>> constrained a same- or similarly named primitive type like Integer, String,
>>> Date, Duration etc that are assumed to be part of the technology
>>> environment. THey are normally part of the programming language, DB, or
>>> serialisation formalisms.
>>>
>>> I think this probably was not as clear as it should have been in that
>>> spec.
>>>
>>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>>> of the BASE component.
>>>
>>>
>>> Clarifying that on an errata addendum would help to avoid such
>>> implementation mistakes, that are really caused by the missing information
>>> on the spec + interpretation to fill the gap.
>>>
>>>
>>> agree, we should do this - can you create a PR for this? Or add to an
>>> existing PR.
>>>
>>>
>>>
>>> BTW, this is one case that I detected because I'm doing research for a
>>> new course. There might be issues like this on other areas of 1.0.2, I mean
>>> missing classes referenced from AOM or AOP. I didn't do a complete review
>>> of the specs.
>>>
>>> I would love to migrate everything to baseline spec and use AOM2, but I
>>> can't afford the cost right now. I'm sure others are on my same position.
>>>
>>>
>>> hopefully that will change soon, because ADL2 is more regular and
>>> simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
>>> I'd be interested to know what the real costs are and to see what we can do
>>> to make the transition simpler, because staying with ADL1.4 is limiting
>>> system functionality for the future.
>>>
>>>
>>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>>
>>>
>>> the page where you got that link
>>>  is now
>>> fixed.
>>>
>>> - thomas
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-
>>> technical_lists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> pablo.pa...@cabolabs.com
>> +598 99 043 145 <+598%2099%20043%20145>
>> skype: cabolabs
>> 
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>> Subscribe to our newsletter 
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>>
>>
>> ___
>> openEHR-technical mailing list
>> 

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

[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 need for another
datatype to express this.

Using the duration for this may be a handy shortcut in specs, but it is not
right. It is in fact misusing a datatype which does not support this
expression. The ISO string should also be changed accordingly.

Bert

Op 20 mrt. 2018 23:24 schreef "A Verhees" :

> 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 same, but that can be ignored, it is one second every few
> years.
>
> Op 20 mrt. 2018 23:08 schreef "A Verhees" :
>
>> 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 that hard.
>>
>> https://golang.org/pkg/time/#Duration
>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>
>> Maybe it is a good idea for the OpenEhr community to study the duration
>> type again to see why in two major programming languages there is another
>> approach build around nanoseconds and having  conversions to hours, etc.
>> Maybe there is another trend coming up. Maybe it is interesting to conform
>> to these trends
>>
>> Bert
>>
>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>>
>> 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, year, month, week are not supported.
>> Each technology has it's own quirks :)
>>
>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
>> wrote:
>>
>>>
>>>
>>> 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 to, the missing
>>> class.*
>>>
>>>
>>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>>> constrained a same- or similarly named primitive type like Integer, String,
>>> Date, Duration etc that are assumed to be part of the technology
>>> environment. THey are normally part of the programming language, DB, or
>>> serialisation formalisms.
>>>
>>> I think this probably was not as clear as it should have been in that
>>> spec.
>>>
>>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>>> of the BASE component.
>>>
>>>
>>> Clarifying that on an errata addendum would help to avoid such
>>> implementation mistakes, that are really caused by the missing information
>>> on the spec + interpretation to fill the gap.
>>>
>>>
>>> agree, we should do this - can you create a PR for this? Or add to an
>>> existing PR.
>>>
>>>
>>>
>>> BTW, this is one case that I detected because I'm doing research for a
>>> new course. There might be issues like this on other areas of 1.0.2, I mean
>>> missing classes referenced from AOM or AOP. I didn't do a complete review
>>> of the specs.
>>>
>>> I would love to migrate everything to baseline spec and use AOM2, but I
>>> can't afford the cost right now. I'm sure others are on my same position.
>>>
>>>
>>> hopefully that will change soon, because ADL2 is more regular and
>>> simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
>>> I'd be interested to know what the real costs are and to see what we can do
>>> to make the transition simpler, because staying with ADL1.4 is limiting
>>> system functionality for the future.
>>>
>>>
>>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>>
>>>
>>> the page where you got that link
>>>  is now
>>> fixed.
>>>
>>> - thomas
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>
>>
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> 

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

[Diego Boscá]

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 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 that hard.
>
> https://golang.org/pkg/time/#Duration
> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>
> Maybe it is a good idea for the OpenEhr community to study the duration
> type again to see why in two major programming languages there is another
> approach build around nanoseconds and having  conversions to hours, etc.
> Maybe there is another trend coming up. Maybe it is interesting to conform
> to these trends
>
> Bert
>
> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>
> 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, year, month, week are not supported.
> Each technology has it's own quirks :)
>
> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
> wrote:
>
>>
>>
>> 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 to, the missing
>> class.*
>>
>>
>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>> constrained a same- or similarly named primitive type like Integer, String,
>> Date, Duration etc that are assumed to be part of the technology
>> environment. THey are normally part of the programming language, DB, or
>> serialisation formalisms.
>>
>> I think this probably was not as clear as it should have been in that
>> spec.
>>
>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>> of the BASE component.
>>
>>
>> Clarifying that on an errata addendum would help to avoid such
>> implementation mistakes, that are really caused by the missing information
>> on the spec + interpretation to fill the gap.
>>
>>
>> agree, we should do this - can you create a PR for this? Or add to an
>> existing PR.
>>
>>
>>
>> BTW, this is one case that I detected because I'm doing research for a
>> new course. There might be issues like this on other areas of 1.0.2, I mean
>> missing classes referenced from AOM or AOP. I didn't do a complete review
>> of the specs.
>>
>> I would love to migrate everything to baseline spec and use AOM2, but I
>> can't afford the cost right now. I'm sure others are on my same position.
>>
>>
>> hopefully that will change soon, because ADL2 is more regular and simpler
>> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
>> interested to know what the real costs are and to see what we can do to
>> make the transition simpler, because staying with ADL1.4 is limiting system
>> functionality for the future.
>>
>>
>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>
>>
>> the page where you got that link
>>  is now
>> fixed.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
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?

[A Verhees]

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 same, but that can be ignored, it is one second every few years.

Op 20 mrt. 2018 23:08 schreef "A Verhees" :

> 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 that hard.
>
> https://golang.org/pkg/time/#Duration
> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>
> Maybe it is a good idea for the OpenEhr community to study the duration
> type again to see why in two major programming languages there is another
> approach build around nanoseconds and having  conversions to hours, etc.
> Maybe there is another trend coming up. Maybe it is interesting to conform
> to these trends
>
> Bert
>
> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :
>
> 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, year, month, week are not supported.
> Each technology has it's own quirks :)
>
> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
> wrote:
>
>>
>>
>> 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 to, the missing
>> class.*
>>
>>
>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>> constrained a same- or similarly named primitive type like Integer, String,
>> Date, Duration etc that are assumed to be part of the technology
>> environment. THey are normally part of the programming language, DB, or
>> serialisation formalisms.
>>
>> I think this probably was not as clear as it should have been in that
>> spec.
>>
>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>> of the BASE component.
>>
>>
>> Clarifying that on an errata addendum would help to avoid such
>> implementation mistakes, that are really caused by the missing information
>> on the spec + interpretation to fill the gap.
>>
>>
>> agree, we should do this - can you create a PR for this? Or add to an
>> existing PR.
>>
>>
>>
>> BTW, this is one case that I detected because I'm doing research for a
>> new course. There might be issues like this on other areas of 1.0.2, I mean
>> missing classes referenced from AOM or AOP. I didn't do a complete review
>> of the specs.
>>
>> I would love to migrate everything to baseline spec and use AOM2, but I
>> can't afford the cost right now. I'm sure others are on my same position.
>>
>>
>> hopefully that will change soon, because ADL2 is more regular and simpler
>> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
>> interested to know what the real costs are and to see what we can do to
>> make the transition simpler, because staying with ADL1.4 is limiting system
>> functionality for the future.
>>
>>
>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>
>>
>> the page where you got that link
>>  is now
>> fixed.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
>
>
___
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?

[A Verhees]

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 that hard.

https://golang.org/pkg/time/#Duration
https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html

Maybe it is a good idea for the OpenEhr community to study the duration
type again to see why in two major programming languages there is another
approach build around nanoseconds and having  conversions to hours, etc.
Maybe there is another trend coming up. Maybe it is interesting to conform
to these trends

Bert

Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" :

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, year, month, week are not supported.
Each technology has it's own quirks :)

On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
wrote:

>
>
> 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 to, the missing
> class.*
>
>
> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
> constrained a same- or similarly named primitive type like Integer, String,
> Date, Duration etc that are assumed to be part of the technology
> environment. THey are normally part of the programming language, DB, or
> serialisation formalisms.
>
> I think this probably was not as clear as it should have been in that
> spec.
>
> In the AOM2/ADL2 specs, we have clarified this so that the same types
> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
> of the BASE component.
>
>
> Clarifying that on an errata addendum would help to avoid such
> implementation mistakes, that are really caused by the missing information
> on the spec + interpretation to fill the gap.
>
>
> agree, we should do this - can you create a PR for this? Or add to an
> existing PR.
>
>
>
> BTW, this is one case that I detected because I'm doing research for a new
> course. There might be issues like this on other areas of 1.0.2, I mean
> missing classes referenced from AOM or AOP. I didn't do a complete review
> of the specs.
>
> I would love to migrate everything to baseline spec and use AOM2, but I
> can't afford the cost right now. I'm sure others are on my same position.
>
>
> hopefully that will change soon, because ADL2 is more regular and simpler
> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
> interested to know what the real costs are and to see what we can do to
> make the transition simpler, because staying with ADL1.4 is limiting system
> functionality for the future.
>
>
> BTW tried to check if the issue is also on 1.0.3 but the link to support
> is broken http://openehr.org/RM/Release-1.0.3/support.html
>
>
> the page where you got that link
>  is now
> fixed.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145 <+598%2099%20043%20145>
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_
lists.openehr.org
___
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?

[Pablo Pazos]

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
as "supported by a programming language", but "supported by a programming
language or application" ***. For instance, it is not so difficult to
create a Duration class ourselves on any programming language, or even use
one of the many available libraries that deal with Duration types and are
compatible with ISO8601 durations.

Considering that, we might need to clarify:

1. What "assumed type" really is (it seems most tend to think that should
be supported by a programming language, need to double check the specs to
see how this is defined, maybe is clearly defined but not highlighted
enough).

2. Clarify the use of the Duration class from CDuration where Duration is
not on the specs (we can say it is assumed considering assumed as the
definition ***)

3. Complementing 2. we can propose support for Duration on many programming
languages by recommending certain libraries or core types. This can be an
ITS or just an addendum/errata to v1.0.2 specs.


I think those points will solve all the issues mentioned on this thread.


On Tue, Mar 20, 2018 at 5:10 PM, Pieter Bos  wrote:

> 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 supports
> all of the options.
>
> Regards,
>
> Pieter Bos
>
> Op 20 mrt. 2018 om 21:06 heeft Pablo Pazos  mailto:pablo.pa...@cabolabs.com>> het volgende geschreven:
>
> 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, year, month, week are not supported.
> Each technology has it's own quirks :)
>
> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale  mailto:thomas.be...@openehr.org>> wrote:
>
>
> 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 to, the missing class.
>
> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
> constrained a same- or similarly named primitive type like Integer, String,
> Date, Duration etc that are assumed to be part of the technology
> environment. THey are normally part of the programming language, DB, or
> serialisation formalisms.
>
> I think this probably was not as clear as it should have been in that spec.
>
> In the AOM2/ADL2 specs, we have clarified this so that the same types
> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
> of the BASE component.
>
>
> Clarifying that on an errata addendum would help to avoid such
> implementation mistakes, that are really caused by the missing information
> on the spec + interpretation to fill the gap.
>
> agree, we should do this - can you create a PR for this? Or add to an
> existing PR.
>
>
>
> BTW, this is one case that I detected because I'm doing research for a new
> course. There might be issues like this on other areas of 1.0.2, I mean
> missing classes referenced from AOM or AOP. I didn't do a complete review
> of the specs.
>
> I would love to migrate everything to baseline spec and use AOM2, but I
> can't afford the cost right now. I'm sure others are on my same position.
>
> hopefully that will change soon, because ADL2 is more regular and simpler
> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
> interested to know what the real costs are and to see what we can do to
> make the transition simpler, because staying with ADL1.4 is limiting system
> functionality for the future.
>
>
> BTW tried to check if the issue is also on 1.0.3 but the link to support
> is broken http://openehr.org/RM/Release-1.0.3/support.html
>
> the page where you got that link releases/RM/Release-1.0.3/docs/index> is now fixed.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org techni...@lists.openehr.org>
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> 

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

[Pieter Bos]

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 supports all 
of the options.

Regards,

Pieter Bos

Op 20 mrt. 2018 om 21:06 heeft Pablo Pazos 
> het volgende 
geschreven:

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, year, month, week are not supported. Each 
technology has it's own quirks :)

On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
> wrote:


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 to, the missing class.

Right - the ADL/AOM 1.4 specs made the assumption that each primitive 
constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc, constrained 
a same- or similarly named primitive type like Integer, String, Date, Duration 
etc that are assumed to be part of the technology environment. THey are 
normally part of the programming language, DB, or serialisation formalisms.

I think this probably was not as clear as it should have been in that spec.

In the AOM2/ADL2 specs, we have clarified this so that the same types 
(C_INTEGER etc) now refer to types that are defined in the Foundation spec of 
the BASE component.


Clarifying that on an errata addendum would help to avoid such implementation 
mistakes, that are really caused by the missing information on the spec + 
interpretation to fill the gap.

agree, we should do this - can you create a PR for this? Or add to an existing 
PR.



BTW, this is one case that I detected because I'm doing research for a new 
course. There might be issues like this on other areas of 1.0.2, I mean missing 
classes referenced from AOM or AOP. I didn't do a complete review of the specs.

I would love to migrate everything to baseline spec and use AOM2, but I can't 
afford the cost right now. I'm sure others are on my same position.

hopefully that will change soon, because ADL2 is more regular and simpler than 
ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be interested 
to know what the real costs are and to see what we can do to make the 
transition simpler, because staying with ADL1.4 is limiting system 
functionality for the future.


BTW tried to check if the issue is also on 1.0.3 but the link to support is 
broken http://openehr.org/RM/Release-1.0.3/support.html

the page where you got that 
link is now fixed.

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
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?

[Pablo Pazos]

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, year, month, week are not supported.
Each technology has it's own quirks :)

On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale 
wrote:

>
>
> 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 to, the missing
> class.*
>
>
> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
> constrained a same- or similarly named primitive type like Integer, String,
> Date, Duration etc that are assumed to be part of the technology
> environment. THey are normally part of the programming language, DB, or
> serialisation formalisms.
>
> I think this probably was not as clear as it should have been in that
> spec.
>
> In the AOM2/ADL2 specs, we have clarified this so that the same types
> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
> of the BASE component.
>
>
> Clarifying that on an errata addendum would help to avoid such
> implementation mistakes, that are really caused by the missing information
> on the spec + interpretation to fill the gap.
>
>
> agree, we should do this - can you create a PR for this? Or add to an
> existing PR.
>
>
>
> BTW, this is one case that I detected because I'm doing research for a new
> course. There might be issues like this on other areas of 1.0.2, I mean
> missing classes referenced from AOM or AOP. I didn't do a complete review
> of the specs.
>
> I would love to migrate everything to baseline spec and use AOM2, but I
> can't afford the cost right now. I'm sure others are on my same position.
>
>
> hopefully that will change soon, because ADL2 is more regular and simpler
> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
> interested to know what the real costs are and to see what we can do to
> make the transition simpler, because staying with ADL1.4 is limiting system
> functionality for the future.
>
>
> BTW tried to check if the issue is also on 1.0.3 but the link to support
> is broken http://openehr.org/RM/Release-1.0.3/support.html
>
>
> the page where you got that link
>  is now
> fixed.
>
> - thomas
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
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?

[Thomas Beale]

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 to, the missing 
class._


Right - the ADL/AOM 1.4 specs made the assumption that each primitive 
constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc, 
constrained a same- or similarly named primitive type like Integer, 
String, Date, Duration etc that are assumed to be part of the technology 
environment. THey are normally part of the programming language, DB, or 
serialisation formalisms.


I think this probably was not as clear as it should have been in that spec.

In the AOM2/ADL2 specs, we have clarified this so that the same types 
(C_INTEGER etc) now refer to types that are defined in the Foundation 
spec of the BASE component.




Clarifying that on an errata addendum would help to avoid such 
implementation mistakes, that are really caused by the missing 
information on the spec + interpretation to fill the gap.


agree, we should do this - can you create a PR for this? Or add to an 
existing PR.





BTW, this is one case that I detected because I'm doing research for a 
new course. There might be issues like this on other areas of 1.0.2, I 
mean missing classes referenced from AOM or AOP. I didn't do a 
complete review of the specs.


I would love to migrate everything to baseline spec and use AOM2, but 
I can't afford the cost right now. I'm sure others are on my same 
position.


hopefully that will change soon, because ADL2 is more regular and 
simpler than ADL1.4 - the ADL2 OPT for example is much easier to 
process. I'd be interested to know what the real costs are and to see 
what we can do to make the transition simpler, because staying with 
ADL1.4 is limiting system functionality for the future.




BTW tried to check if the issue is also on 1.0.3 but the link to 
support is broken http://openehr.org/RM/Release-1.0.3/support.html


the page where you got that link 
 is now fixed.


- 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?

[Pablo Pazos]

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 errata addendum would help to avoid such
implementation mistakes, that are really caused by the missing information
on the spec + interpretation to fill the gap.


BTW, this is one case that I detected because I'm doing research for a new
course. There might be issues like this on other areas of 1.0.2, I mean
missing classes referenced from AOM or AOP. I didn't do a complete review
of the specs.

I would love to migrate everything to baseline spec and use AOM2, but I
can't afford the cost right now. I'm sure others are on my same position.

BTW tried to check if the issue is also on 1.0.3 but the link to support is
broken http://openehr.org/RM/Release-1.0.3/support.html

On Mon, Mar 19, 2018 at 4:03 PM, Thomas Beale 
wrote:

>
>
> 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 no Duration class for 1.0.2. I would be good to add a
> disclaimer or errata comment for 1.0.2 maybe guiding to use ISO8601_DURATION
> or DV_DURATION in CDuration.
>
>
> DV_DURATION has never been the target type of C_DURATION - DV_DURATION is
> a complex type in the DV_ORDERED hierarchy (i.e. a sibling more or less of
> DV_QUANTITY).
>
>
> IMO that can generate a mismatch between implementations. For instance,
> the Java Ref uses DV_DURATION in CDuration https://github.com/
> wware/openehr-java/blob/master/openehr-aom/src/main/
> java/org/openehr/am/archetype/constraintmodel/primitive/
> CDuration.java#L186
>
>
> I don't know why they do that - that is not what the spec says.
>
> - thomas
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
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?

[Thomas Beale]

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?

[Thomas Beale]

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 no Duration class for 1.0.2. I would be good to add 
a disclaimer or errata comment for 1.0.2 maybe guiding to use 
ISO8601_DURATION or DV_DURATION in CDuration.


DV_DURATION has never been the target type of C_DURATION - DV_DURATION 
is a complex type in the DV_ORDERED hierarchy (i.e. a sibling more or 
less of DV_QUANTITY).




IMO that can generate a mismatch between implementations. For 
instance, the Java Ref uses DV_DURATION in CDuration 
https://github.com/wware/openehr-java/blob/master/openehr-aom/src/main/java/org/openehr/am/archetype/constraintmodel/primitive/CDuration.java#L186


I don't know why they do that - that is not what the spec says.

- thomas

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
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?

[Pablo Pazos]

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 to add a
disclaimer or errata comment for 1.0.2 maybe guiding to use ISO8601_DURATION
or DV_DURATION in CDuration.

IMO that can generate a mismatch between implementations. For instance, the
Java Ref uses DV_DURATION in CDuration
https://github.com/wware/openehr-java/blob/master/openehr-aom/src/main/java/org/openehr/am/archetype/constraintmodel/primitive/CDuration.java#L186



On Mon, Mar 19, 2018 at 12:13 PM, Thomas Beale 
wrote:

> Hi Pablo,
>
> you should use the specs on the main spec home page
> ; in this
> case I guess it is the AOM 1.4 spec
> 
> you want to refer to.
>
> We now have the basic time types in the Foundation types spec
> .
> Both Duration and Iso8601_Duration are defined. For the archetype spec, the
> former is assumed, because ISO8601 syntax representation is used in
> archetypes.
>
> The specification is much better (but different) in AOM2
> 
> .
>
> - thomas
>
> On 19/03/2018 05:24, Pablo Pazos wrote:
>
> 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 reference that class or we have another Duration class
> somewhere?
>
> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from
> ISO8601_DURATION). http://www.openehr.org/releases/1.0.2/architecture/
> rm/data_types_im.pdf page 54
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
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?

[Bert Verhees]

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 - i.e. a non-identified, instance-only type 
- in most language libraries. Note - here I am talking about a 
primitive type 'Duration' (also Iso8601_duration), not types like 
DV_DURATION. For AOM2, we treat it and the other date/time primitives 
as proper primitive types, also Uri, etc, and it makes life much easier.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 



My opinions:

First: I agree with the distinction in datatypes between AOM and RM. The 
AOM should live as much as possible independent from the RM (I prefer 
completely independent), the RM should only deal with data-constructions 
and datatypes to describe target-data in.


Second: The archetype should be independent from the used computer 
language to build the AOM in. In many languages Duration is a valid 
datatype.


Java has it, Golang has it, C++ has it. And if it is not in a 
programming language, that language should be extended by a library 
which delivers the datatype.


Best regards

Bert


___
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?

[GF]

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, 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   Freriks
> +31 620347088
>   gf...@luna.nl 
> 
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
> 
>> On 19 Mar 2018, at 06:24, Pablo Pazos > > wrote:
>> 
>> 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 reference that class or we have another Duration class somewhere?
>> 
>> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from 
>> ISO8601_DURATION). 
>> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf 
>>  
>> page 54
>> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org 
> 
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



signature.asc
Description: Message signed with OpenPGP
___
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?

[Thomas Beale]

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 type - 
in most language libraries. Note - here I am talking about a primitive 
type 'Duration' (also Iso8601_duration), not types like DV_DURATION. For 
AOM2, we treat it and the other date/time primitives as proper primitive 
types, also Uri, etc, and it makes life much easier.


- 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?

[Pablo Pazos]

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   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Mar 2018, at 06:24, Pablo Pazos  wrote:
>
> 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 reference that class or we have another Duration class
> somewhere?
>
> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from
> ISO8601_DURATION).
> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf page
> 54
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
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?

[GF]

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:
> 
> 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 reference that class or we have another Duration class somewhere?
> 
> Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from 
> ISO8601_DURATION). 
> http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf 
>  
> page 54
> 



signature.asc
Description: Message signed with OpenPGP
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Pablo Pazos]

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 reference that class or we have another Duration class somewhere?

Or should we use DV_DURATION in CDuration? (DV_DURATION inherits from
ISO8601_DURATION).
http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf
page 54


Thanks!

-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs

http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org