On 26-01-18 10:00, Thomas Beale wrote:
The thing I am not a fan of is that units themselves become part of
terminology. This is a SNOMED direction but I think a wrong one. The
reason is that the ontology of units isn't the same as the ontology of
findings, medications and so on. In fact they
Thanks, Pieter, very useful, good work
Best regards
Bert
On 31-01-18 16:18, Pieter Bos wrote:
Hi,
We’re pleased to announce Archie version 0.4! For those of you unfamiliar with
Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for
archetype modelling and EHR
Best regards
Bert Verhees
On 06-02-18 18:42, Ricardo Gonçalves wrote:
On the "putting together a web frontend and a Java backend" topic, it
may be interesting to look at Vaadin, which is an open source
framework to build web applications using Java (you code everything in
Java, an
fferent types of data structures but
both are necessary, we are not trying to waste each other's time. I
too need to know what the domain looks like to understand the
objectives that the models are trying to satisfy. I am not saying that
the clinicians are "lacking", I am "lac
can only be better for everyone.
Regards Heather
-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On
Behalf Of Bert Verhees
Sent: Friday, 16 February 2018 2:41 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.
I think, it would be good if the community who did this fantastic job,
should also divide a kernel in micro-services and having interfaces
between them, and let there be one entry-service to have the
micro-services expose themselve to the outside world over REST, for now.
There is knowledge
On 16-02-18 12:41, Thomas Beale wrote:
in openEHR terms...
On 16/02/2018 05:38, GF wrote:
Hi all,
In my opinion there are several types of ‘patterns’:
- Specific Local Templates/patterns used in a defined community for
specific purposes
specialisations of any archetype for local usage.
An interesting wiki from Heather Leslie
https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns
She concludes that pattern are necessary, I agree with that, and she
also concludes that clinicians are better modelers then technicians.
Well, that depends,
On 17-02-18 11:21, GF wrote:
That context/epistemology is defined by meta-data in COMPOSITION that
as committed to databases and documents.
That is why OpenEhr and SNOMED can be a strong combination.
___
openEHR-technical mailing list
On 17-02-18 16:39, Pablo Pazos wrote:
That is why SNOMED alone can't be used for querying.
I agree with that, else, you would not need OpenEhr at all ;-)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
On 17-02-18 16:33, Pablo Pazos wrote:
I think that is the expected behavior, also what is returned depends
on the operators in the SNOMED expression, like << will return all
descendants. The expression can be tuned to return just what you want,
and the process of the result should work
On 17-02-18 13:11, Diego Boscá wrote:
Maybe it is possible to generalize it in a way that it could be
external calls that return a value or list of values. Maybe this is
enough for SNOMED, CDSS, but also for queries to linked data such as
drug-drug interaction and other services availabe in
On 17-02-18 15:47, Diego Boscá wrote:
https://bioportal.bioontology.org/
It has tons of knowledge exposed as queriable web services. All
services have an RDF output, so is perfect to demonstrate linked data
Thanks, very interesting
___
On 17-02-18 16:22, Pablo Pazos wrote:
Just thinking out loud! But I'm working towards this with Diego :)
Ah, I didn't know that. I must read the mailing-lists more often.
Good luck with that. I am very interested to hear about proceedings and
plans
Bert
On 18-02-18 23:09, GF wrote:
Is it an idea to annotate nodes with instructions for display.
Personally I think having special templates/archetypes for display is
better. Templates are create per purpose, and mixing purposes in a
single template does seem good idea to me
sloppy English in my previous message, this time changing the
meaning, I changed the quote below, I am awake now, will not happen
again, excuse me)
2018-02-19 10:15 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>>:
On 18-02-18 23:
l likely
give enough to start with.
A (not so very thought through yet) possible example of annotation
use for application building is available in picture 40 (and
supported by picture 36 in
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing
//Erik
mån 19 feb. 201
Often Spanish is not always a big problem, let us try drag through
Google translate to make it al readable
Bert
On 19-02-18 17:37, David Moner wrote:
We also have a Final Degree Project where a student made a proposal
for a Visual Template Model. It's from 2012, for ISO 13606, and also
in
On 23-02-18 16:36, Pieter Bos wrote:
you would have to find a way to map all the inheritance in the OpenEHR model to
protocol buffers.
For Java I found this web-page which explains how to do it. It is about
a class with one nested class
On 23-02-18 17:17, Thomas Beale wrote:
On 23/02/2018 15:36, Pieter Bos wrote:
For microservices with enough traffic, or for devices with limited
processing power or limited bandwidth, a binary encoding makes sense.
However, GRPC would not be my first choice for OpenEHR - you would
have to
On 20-02-18 20:09, Thomas Beale wrote:
The terminology service also has dependencies to rm data types, only
because of codephrase. Wouldn't it be possible to avoid that?
Yes, there is a new class TERMINOLOGY_CODE that is used in BASE
instead of CODE_PHRASE; eventually, the RM should just
I must have missed new developments, I am still working with RM 1.0.3
which, I was thinking, is the production version
My remarks were for that version, and for my idea, there were some
inconveniences in it.
But I will study the new RM, and if I find some similar inconveniences,
I report
On 18-02-18 16:55, Thomas Beale wrote:
On 18/02/2018 11:16, Erik Sundvall wrote:
When designing this, perhaps some (2-5) existing currently popular
GUI frameworks could be initial targets for output from the process,
and the selection could be updated over time. Perhaps for example
Best regards
Bert
And sorry for the sloppy English (when reading back), on Sundays it is
worse then on weekdays when I am in working mode. But I think my message
is still understandable, so, have a nice Sunday-evening.
;-)
Bert
___
The problem with Ice is that it is not open source licensed when used in
a non GPLv2 product.
Another problem is that they do not publish the price of a commercial
license.
That are restrictions that cause many programmers not to use it.
https://zeroc.com/licensing
On 23-02-18 13:59, Thomas
will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web
Bert
Regards,
Pieter Bos
Op 23 feb. 2018 om 14:21 heeft Bert Verhees
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven:
The problem with Ice is that it is not open source l
On 26-07-18 09:57, Thomas Beale wrote:
Does it make sense to have an empty COMPOSITION.content?
Imagine a visit to a GP, and nothing clinical comes out of it. Nothing
worth mentioning, but still having had a composition and a consult to
pay for.
I cannot imagine how a folder structure can get lost except by data
corruption. In that case anything is lost anyway and a rollback from a
backup is needed.
In fact there should not be a folderstructure in the database. There are
folder objects which contain a list of references (data) to
As far as I understand, and I also implemented it like that, there should never
be functionality to delete data. Accidental deletion can only occur when you
pass the software and hack on the database directly. That should never occur
and if it does, the database should be restored to a safe
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Bert Verhees*
Software developer, architect
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com
her side is an
OpenEhr machine. Between two OpenEhr systems, OpenEhr is the center of
the universe.
Best regard
Bert Verhees
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com <mailto:i...@freshehr.com>
twitter: @i
On 16-07-18 16:59, Thomas Beale wrote:
well whether it is 'so good' is in the eye of the beholder, but it is
'good enough' for quite a lot of things, things for which we would
once have expected to be able to use XMI. Anyway, the BMM introduction
On 23-07-18 13:45, Diego Boscá wrote:
Units need to be (and will be) revamped, we also need other things
already discussed in other posts like rubric, long descriptions (which
could be language dependent), etc. This could be very useful for
better describing custom UCUM units too.
Several
://wiki.hl7.org/index.php?title=Representation_of_Units
Best regards
Bert Verhees
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
On 16-07-18 15:56, Bert Verhees wrote:
But again, the starting point must be the API's defined, maybe in a
transformerable language like swagger, which seems to connect well to
the OpenAPI initiative.(I never liked swagger much, but my last
experience with it was from years ago, maybe
On 16-07-18 14:55, Thomas Beale wrote:
On 16/07/2018 13:35, Bert Verhees wrote:
On 16-07-18 13:49, Thomas Beale wrote:
It seems to be a competitor to FHIR in some way, since it is not
using FHIR.
Aren't we all? ;-)
But serious, I don't think so, they don't use FHIR because their
target
On 16-07-18 16:59, Thomas Beale wrote:
well whether it is 'so good' is in the eye of the beholder, but it is
'good enough' for quite a lot of things, things for which we would
once have expected to be able to use XMI. Anyway, the BMM introduction
On 16-07-18 16:54, Ian McNicoll wrote:
Hi Bert,
Have a look at what Ripple is doing in terms of 'meaningful APIs'.
See
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2018-February/014799.html
I check it, thanks for the info
Bert
On 17-07-18 12:05, Ian McNicoll wrote:
This is harder for newbies to understand but
We don't write API's as learning material for newbies, but for
professional communication, so that is no problem.
Also for the rest I agree.
There is need for API's for interaction between two OpenEhr
On 17-07-18 12:15, Thomas Beale wrote:
One general thing to remember is that there will normally be multiple
levels of API, from data to domain to business to application.
Agree, good to list the levels.
Bert
___
openEHR-technical mailing list
OpenEhr does not really allow to delete data, only logical deletion (mark as
deleted), but GDPR demands the right of the patient to be forgotten.
Is there some change expected in the specs for compliance to GDPR, or was this
already implemented?
We had this discussion, slightly different,
There are good arguments in the discussion. I take this message to reply to
because it is the last for this subject at the moment.
I am thinking of following situation. This week, Microsoft, Google, Amazon and
IBM agreed that there must be a health data platform which exposes itself in
FHIR
Contsys will update some definitions. They are now the base of their thinking,
but I am sure that will change soon.
Thanks, Gérard, for giving me the opportunity to make my point again. :-)
We don't call war a peace problem. So why do we call illness a health problem?
Normally I would not
ailman/listinfo/openehr-technical_lists.openehr.org
--
*Bert Verhees*
Software developer, architect
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mo
513 622,* Fax: +351 *225 513 623*
Rua Dr. Plácido da Costa, s/n | 4200-450 Porto | *Portugal*
On Mon, Sep 3, 2018 at 2:26 PM Bert Verhees <mailto:bert.verh...@rosa.nl>> wrote:
In all other contexts the patient can never be forgotten or
deleted. Any legal transaction is
On 01-03-18 12:01, Diego Boscá wrote:
I believe that we need a way in standard AQL to call to arbitrary
external services, this seems like another use case for that \
I agree!
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
On 01-03-18 12:12, Diego Boscá wrote:
Assuming there is a service that provides the given value for a given
identified range (based on the parameters you provide like sex, age,
race... ) it would be allowing kind of namespaces that have defined
operations. This would also allow easy querying
that it will be a big step forwards for OpenEhr.
Best regards
Bert Verhees
On 13-03-18 00:04, Erik Sundvall wrote:
Hi!
I have also updated the
https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets
wikipage to include
* references to some previous GUI discussions
On 13-03-18 17:45, Philippe Ameline wrote:
in my own terms, it means that it is not the proper component for
modern applications.
Wasn't it Voltaire who said that the best is the enemy of the good?
___
openEHR-technical mailing list
sorry for the sloppy text, a bit in a hurry ;-)
On 24-04-18 10:34, Bert Verhees wrote:
Maybe it is interesting to facilitate a SMART API for OpenEhr (now
there is an API-definition effort in process for OpenEhr)?
Or is that to market specific and is it something more suitable for
vendors
Maybe it is interesting to facilitate a SMART API for OpenEhr (now there
is an API-definition effort in process for OpenEhr)?
Or is that to market specific and is it something more suitable for
vendors or other third parties to develop?
That reminds me of an other discussion which runs for
On 29-03-18 13:59, Pablo Pazos wrote:
this is a simple app, Java only.
Still very nice and useful and inspiring ;-)
It is just, I am working on micro-services, also for OpenEhr, which
makes it easy to have a cloud of modularity which can also interact.
But of course, it is work to create a
it more manageable. See for
> example NHS in England
> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .
>
>
>
> Regards
>
> Mikael
>
>
>
>
>
> *Fr?n:* openEHR-technical [
Maybe we should relate this thinking to CEN13606 because that Reference
Model allows more generic thinking.
(Thinking this because GF was the convenor of this CEN standard)
But even then some more explanation would be welcome.
Bert
On 31-03-18 10:37, GF wrote:
Dear Thomas,
There are two
...@luna.nl <mailto:gf...@luna.nl>
Kattensingel 20
2801 CA Gouda
the Netherlands
On 31 Mar 2018, at 11:04, Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> wrote:
Maybe we should relate this thinking to CEN13606 because that
Reference Model allows mor
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
of an event somewhere in 2015,
or a duration of one month, or
Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
Kattensingel 20
2801 CA Gouda
the Netherlands
On 21 Mar 2018, at 15:02, Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> wrote:
I
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
using it right away.
Regards,
Pieter Bos
Nedap Healthcare
On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees"
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> wrote:
On 21-03-18 10:50, GF wrote:
> Does including
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
r 2018, at 12:25, Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> 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
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"
<openehr-t
Diego, this is a wise thought!!!
It seems logical, but that is often in good ideas, they seem like: why
did no one ever think about this.
No clinician handles the complete medical science/SNOMED repository in
his profession. Some even use a very small sub-part, think about a
dentist, a
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
On 28-06-18 17:19, Bert Verhees wrote:
Never use REST/JSON/HTTP1.1 for stable models, it is throwing away a
lot of performance.
How about creating a protocol-buffer generation tool for archetypes, or
as a matter of fact, for the reference model would be sufficient.
Good idea, to remember
penEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
*Bert Verhees*
Software developer, architect
Profile: https://www.bertverhees.nl/
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: ber
ailman/listinfo/openehr-technical_lists.openehr.org
--
*Bert Verhees*
Software developer, architect
Profile: https://www.bertverhees.nl/
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mo
r covering all potential concepts, but there are a considerable number
> that are applicable for use by consumers and are not a bad starting point.
>
>
>
> Kind regards
>
>
>
> Heather
>
>
>
> *From:* openEHR-technical *On
> Behalf Of *Bert Verhees
>
ervice, just as for any other
> kind of data - it's just different archetypes. It may be that special
> services for e.g. performance tracking or whatever are needed, but for now
> I'm assuming all that stuff is done by applications, not services.
>
> - thomas
>
> On 23/
nd, though. I think getting
> these archetypes into good shape would be useful to many app developers.
>
>
>
> Would that be helpful to you?
>
>
>
> Cheers
>
>
>
> Heather
>
>
>
> *From:* openEHR-technical *On
> Behalf Of *Bert Verhees
> *Sent:* Thu
--
*Bert Verhees*
Software developer, architect
Profile: https://www.bertverhees.nl/
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28
On 12-11-18 16:13, Thomas Beale wrote:
On 12/11/2018 09:44, Bert Verhees wrote:
Sorry, I first replied to Pieter Bos only, now to the list. Pieter
already replied to me that the question was not about XSD to check
datasets was .
So, read my reply, for those interested in easy validating
On 12-11-18 18:40, Bert Verhees wrote:
>> Another very important restriction for using XML Schema, in my opinion,
>> is that you cannot have two or more elements with the same name but a
>> different data type. This data type must be in detail the same. XML Schema
>
On 12-11-18 17:59, Thomas Beale wrote:
On 12/11/2018 16:04, Bert Verhees wrote:
On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated
from the Template Designer and I think the new Marand ADL-designer.
Its intended exactly for checking
:
> On Mon, Sep 03, 2018 at 01:08:41PM +0200, Bert Verhees wrote:
>
> > So, on medico-legal purposes as Ian and Karsten and maybe others referred
> > to, a patient, if he maintains his own PHR, and he likes to delete it, he
> > can never sue a clinician, because, he, hims
It would be a bad thing to let all patients be restricted in their rights
because one patient, suffering in the past from depression and having a
recurring cancer can get into problems. Some people are emotionally
unstable, they need protection. I don't know the best way, but I would
think of
In all other contexts the patient can never be forgotten or deleted. Any
> legal transaction is subject to archiving laws. For tax purposes the time
> period is 5 years in the Netherlands, I think. Only after these periods as
> defined by law the transactions can/must be deleted.
>
It is true
4994>
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
&g
On 12-12-18 15:44, Diego Boscá wrote:
When I say official I refer to AOM. If AOM/ADL let's you say something
we try to support it. We always 'eat' what others tools produce, and
have implemented export mechanisms to be compatible with the things
other tools can handle. In this particular case
that commercial companies do not want to do this.
Their data-structures are often regarded as their crown-jewels.
Best regard
Bert Verhees
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr
On 13-12-18 16:13, Thomas Beale wrote:
They are already working on a local install version for that.
Good to hear, I think, that should be announced better, and with roadmap.
Bert
___
openEHR-technical mailing list
will create space to create these mappings.
I wonder, would templates be a good way to arrange this?
I am very interested in opinions about this
Best regards
Bert Verhees
Op ma 17 dec. 2018 19:27 schreef Pablo Pazos I also did some mapping work FHIR -> openEHR using Mirth, but this is
>
On 12-12-18 14:49, Diego Boscá wrote:
These are modifications on the parser, which parses more things than
your standard parser. In fact, the editor supports legal things in ADL
that other parsers don't (e.g. explicit node identifiers or
existence). The generated ADL is completely fine ADL.
On 12-12-18 12:53, Diego Boscá wrote:
We used that one as a basis and generalized mostly to allow the
special RM 'at' codes we created. I can send you the modified grammar
or the parser if you want.
Wouldn't that disturb interoperability processes? One could wonder:
Which one is the right
On 12-12-18 13:48, Diego Boscá wrote:
The official one, these are 'hacks' that allow you to handle
requirements and edge cases only present in these RM archetypes
Diego, I don't want to be harsh about LinkEhr, which is a very strong
product. But this situation raises questions. I already had
Don't know where to tell this, but there is something not okay on:
https://specifications.openehr.org/releases/ITS/latest/index
Many links don't work
Bert
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
Thanks :-)
Sent from my Xperia™ by Sony smartphone
Thomas Beale wrote
>Ths XSD and JSON repo folders did not have index files - we have added
>some simple ones to display everything. We'll improve these over time.
>
>- thomas
>
>On 04/01/2019 14:20, Bert Verhees wr
On 22-02-19 12:27, Georg Fette wrote:
Hello,
Thank you all. The .xsds are already very useful. And the Toolkit also
looks beneficial for what I want to do.
The toolkit is great, very impressive work.
Also, I found the API-exporer from Marand in which you can test and look
at API's
The question asked by George Fette is that he wants to see an example of an
OpenEhr dataset in XML or JSON containing demographics and commonly used
archetypes.
Best regards
Bert
Sent from my Xperia™ by Sony smartphone
Pablo Pazos wrote
>Adding to Thomas comments,
>
>1. Yes, XML
to experiment with the API and thus also see the JSON
datasets.
Best regard
Bert
Sent from my Xperia™ by Sony smartphone
Bert Verhees wrote
>The question asked by George Fette is that he wants to see an example of an
>OpenEhr dataset in XML or JSON containing demogr
Very important, I see as major advantage that gives predictability for
archetypepaths which is necessary for wild carding AQL queries on unknown
archetypes or groups of archetypes on different observations. In the field of
observations this is part of a major step forwards. Researchers and
was overseeing it all.
Now I am, and I understand that there are no technical objections, so
that makes me glad.
have a nice day
Bert
On 16-02-19 15:10, Thomas Beale wrote:
On 16/02/2019 14:00, Bert Verhees wrote:
On 16-02-19 13:20, Thomas Beale wrote:
Have a look at the Archie project
<ht
On 16-02-19 13:20, Thomas Beale wrote:
On 16/02/2019 01:38, Bert Verhees wrote:
A few last words on this.
It is easy for JSON based archetype repository to cooperate with an
ADL based repository. Serializing of an AOM structure to ADL is very
easy to do, this counts for the DADL and CADL
-guru, said: "Don't walk away from
complexity, RUN!!!"
But Einstein said: "Everything Should Be Made as Simple as Possible, But
Not Simpler"
So the question is: Are there any technical objections to express
archetypes and reference-models in JSON?
Best r
egular
formats, but it is nearly trivial. I am not sure if Archie or Marand's
ADL-designer tools do the same but I think it should be trivial for them to
implement as well.
I will look into this again...
- thomas
On 15/02/2019 18:51, Bert Verhees wrote:
I always admired OpenEhr for its ability to
your opinions.
Best regards
Bert
Sent from my Xperia™ by Sony smartphone
Bert Verhees wrote
>
>
>Sent from my Xperia™ by Sony smartphone
>
> Original Message
>Subject: Re: JSON for definitions-notation
>Sent: 15 Feb 2019 22:46
>From: Bert Verhe
> The folks doing CIMI use at least the JSON mode. It also generates XML, via
> custom serialiser.
> One of the jobs I never completed is a deserialiser for the 3 regular
> formats, but it is nearly trivial.
Exactly my point, I completely agree with this.
Bert
>
> Venkat Subramaniam, who
Sent from my Xperia™ by Sony smartphone
Original Message
Subject: Re: JSON for definitions-notation
Sent: 15 Feb 2019 22:46
From: Bert Verhees
To: Pieter Bos
Cc:
Not many people find archetypes readable. I can read them and I have done that
many times, but most modelers I know
how damn limiting pure json* is. Any attempt
>to introduce long-ints or annotation take you to vertical-specific json+.
>
>
>* json is javascript, so has type and other limitations.
>
>On Fri, Feb 15, 2019, 7:39 PM Bert Verhees
>> A few last words on this.
>>
>&
On 16-02-19 13:16, Thomas Beale wrote:
Bert,
if you serialise a AOM archetype to any object dump format, you need
typing information for the simple reason that there is polymorphism in
the model, mainly places where the static type is C_OBJECT,
C_DEFINED_OBJECT or C_PRIMITIVE_OBJECT but the
701 - 800 of 802 matches
Mail list logo