On 30-06-18 10:46, Thomas Beale wrote:
I would have thought the easiest way would be to machine convert the
RM BMM
<https://github.com/openEHR/reference-models/tree/master/models/openEHR/Release-1.0.3/BMM>
and the Abstract Platform UML model
<https://github.com/openEHR/specifications-SM/tree/master/computable/UML>
to the protobuf3 specification format. Note that when reading the BMM
files it is better to use existing tools or libraries to read them in
and convert the multiple files to a single model - this is what you
see in the ADL Workbench, and the new Archie project
<https://github.com/openEHR/archie> does this a well.
That is good, I look at the code, and see how it is done. Reading the
model should not be a problem then. When I have questions, I let you and
Pieter Bos on this list.
I think what would be most interesting is to develop a repeatable
mechanism / tool to do this.
Exactly my idea.
This would get us a generic protobuf3 service interface that
implements the Abstract Platform model.
If you wanted to have a more specialised service interface based on
particular archetypes or templates (I would have thought the latter),
then it seems to me that you want to generate template structures as
specialisations of their corresponding RM types. protobuf3 format
<https://developers.google.com/protocol-buffers/docs/reference/proto3-spec>
doesn't know about specialisation, so we would need to work out a way
to represent it, but this has to be a standard problem.
I have written a proto-file for ucum, because I have written an
ucum-micro-service. I do not have that open source (yet) but showing a
part of the proto file does not hurt.
Regarding to class hierarchy, when in the way, I take the widest class
which can have all possible attributes and add an enum to indicate which
class was meant.
(I call it "flattened", and put the word Derivates to the end, which, on
second thought, would not have been necessary, all derivates of the Ucum
Concept-class fit in this construct)
message FlattenedConcepterDerivates {
string Code =1;
string CodeUC =2;
enum ConceptKind {
PREFIX =0;
BASEUNIT =1;
UNIT =2;
}
ConceptKind Kind =3;
repeated string Names =4;
string PrintSymbol =5;
string Property =6;
string Class =7;
bool IsSpecial =8;
bool Metric =9;
bool IsArbitrary =10;
string Dim =11;
Value Value =12;
}
This works good, because the only purpose is to bring over the data and
reproduce them again to the original state as they were send.
It only needs to read the attributes which belong to the class indicated
in the enum.
In this way, the optimal use of the protobuf principle is used (having
everything in its own primitive datatype, and only read/write to the
buffer what is necessary).
But maybe there is a better way?
Note that in protobuf3 you can specify a message definition and a
service definition. This would enable the machine generation of
message definitions corresponding to any openEHR data - i.e. the
protobuf equivalent of Template Date Schema (TDS).
I am not sure what you mean here. Maybe it gets clear when I read the
code from Pieter.
In my current point of view in protobuf, the service-part represents the
functions (compare them with API-calls in REST), and the message parts
are the data.
This is how the service and message part look like. Some messages
represent classes out of the application-sphere (as seen in the previous
example), some represent data used as parameter-sets (I call them
Request and Response messages). I copy some example-lines from the
ucum-service-proto below.
syntax="proto3";
package ucum_service;
service UcumService{
rpc UcumIdentification(UcumVersionDetailsRequest) returns
(UcumVersionDetailsResponse){};
rpc ValidateUCUM(ValidateUCUMRequest) returns (ValidateUCUMResponse){};
rpc Search(SearchRequest) returns (SearchResponse){};
rpc GetProperties(GetPropertiesRequest) returns (GetPropertiesResponse){};
...........
...........
}
message UcumVersionDetailsRequest {
}
message UcumVersionDetailsResponse {
int64 releaseDate =1;
string version =2;
}
message ValidateUCUMRequest {
}
message ValidateUCUMResponse {
repeated string serviceStatus =1;
}
message SearchRequest {
enum ConceptKind {
PREFIX =0;
BASEUNIT =1;
UNIT =2;
}
ConceptKind Kind =1;
string text =2;
bool isRegex =3;
}
message SearchResponse {
repeated FlattenedConcepterDerivates results =1;
}
............
............
Best regards
Bert
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
