Hi Heather,
In general, anyone is welcome to participate in the work; you don't need to be
one of the small number of Advisory Group members. That helps with travel
costs, but most of the real work is done on teleconferences, not so much at the
face to face meetings.
I would be very intere
Hi Mikael,
What efforts are being made to resolve the boundary problem?
I applied to get involved with the SNOMED information modelling group but
wasn’t successful, to try to engage on exactly that point.
I’m not aware of any work going on. I’d be very pleased to get involved if I
could. It’
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,
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 m
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
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 on
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
__
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 se
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 *C
Hi Tom,
I believe that you proposal to ”move / remove the pre-coordinated codes out of
SNOMED” is very appealing in theory. However it is very difficult in reality to
agree on where the line between a suitable pre-coordinated concept and a
concept that is better to post-coordinate or handle in
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 Frerik
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 durati
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 d
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
Nevertheless, I think it would have been good to move / remove the
pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable
core, which would actually look a lot more like Philippe's (much
smaller) terminology.
This relates to the old debate on reference v interface terminolo
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 R
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 dur
Hi Philippe,
I think that you have missed that SNOMED CT is created for multiple use cases.
Your use case that you describe as "a modern approach" is a good use case that
I like. In that use case SNOMED CT can be used in the way you describe using
SNOMED CT's concepts a little higher up in the
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
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,
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 shee
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 mete
22 matches
Mail list logo
