Hello,
> if you are thinking of specific querying language - I would agree - we
> can already see that the use of archetypes at runtime changes how
> queries are written and does require some new kind of language. We have
> been experimenting on this, and are working on it...
in our Framework, we try to keep communication as neutral as possible.
The aim is to enable two systems to talk to each other as simple as
question and answer - in Java:
Answer ask(Question q) {
...
return a;
}
Any message shall be encapsulatable. In thinking more about it, I came
to the result that the structure of human sentences suits this problem
the best. Sentences (at least in Latin-based languages but I guess
others, too) consist of:
- Subject (System)
- Predicate (Action)
- Object (Model)
- Adverbial (additional stuff, like time or place where something occurs)
That is the structure of the "Signal" which we use in our Framework.
Additionally to the four fields above, one field "Language" is added.
This Signal (hopefully) allows to encapsulate messages of all kinds,
Framework-internal, SQL, CORBA, SOAP, Streams, Sockets ... whatever.
(To be approved in practice, still.)
Example: SQL query "insert data into table"
- the Subject would be the (name or URL of the) sending (or receiving)
System (still unclear to me)
- the Predicate would be INSERT (an Action)
- the Object would be DATA (a Model)
- the Adverbial would be TABLE (or a second Object?)
That way, a whole library of possible Actions could be built. It doesn't
make sense to create one class per one action but perhaps all actions
could be sorted into something like a Terminology?
Not all things are clear to me yet, but in principle it seems fine.
If OpenEHR tries to find a rather neutral Signal Handling Mechanism
then I would be glad to think about it together. If OpenEHR rather wants
a querying specific to Archetypes, then we could perhaps still exchange
some ideas.
Rgds,
Christian
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
