Closed anandkp92 closed 1 year ago
Adding the major takeaways from recent discussions on this topic.
There are two main approaches to extracting metadata from Modelica models
Inference of semantic information (as was done in the Shepherding paper). This work would involve building upon the work done in that paper.
Addition of semantic data annotations to the Modelica file (be it a energy model or just CDL sequences or both).
Diving into the second approach:
annotation(__cdl(type="application/type", content="content"))
text/strings
or application/rdf+xml
or make one up?__cdl
type in the annotation - it does not provide any new information. Instead we could either have a generic __metadata
annotation or specific __brick
or __ashrae223p
or __haystack
or a combination of theseconnect
statements so that we can infer relationships between entities as well. multiplex
block which in turn is connected to a TRooAir
output of a control block. However, multiplex
has no equivalent in brick and we have to traverse two connect statements to see that the temperature values are outputs of a control sequence.content
?
rdf:type
or equivalent tagcontent={type=Brick:Supply_Fan, hasPoint=Brick:Supply_Air_Flow_Setpoint, isPartOf=ahu1}
Some additional questions/comments that came up during the discussion:
annotation
tags within one model, metadata extract using method 1 v/s method 2 etc.?
annotation
tags as the ground truth could be an approach we take. Tagging: @mwetter @gtfierro @marcopritoni @JayHuLBL for comments and thoughts.
I couldn't find anything exactly that we could use here, but we could use a text/strings or application/rdf+xml or make one up?
I like the __brick
or __haystack
style better. Then the MIME type can be text/turtle
or whatever.
One question is whether the role of these annotations is to (a) assist in the production of a metadata model from the Modelica/CDL, or to (b) point to the corresponding entities in an existing semantic metadata model that is distributed along with the Modelica/CDL model. This could even be the full Turtle file in some annotation somewhere in the Modelica code. Then, the annotation just needs to indicate which entity it corresponds to. This sidesteps most of the design issues above.
The benefit of the first use-case is that one can distribute self-contained RDF graph descriptions for common, reusable Modelica components. Building the RDF graph from the Modelica model could be as "simple" as stitching those RDF subgraphs together using interpretations of the connect
statements between them
Most of the questions are best to discuss briefly. Here are some short answers. We certainly need use case (a) but (b) is also of interest and likely relevant. If we can handle (a), maybe (b) is a special case where we reconcile the two semantic models similar than in the Shepherding paper.
The tags should be on the block
level (and outside of just CDL can also be on the model
level) and on the connector level. But not on the connect
statements as it can be inferred what connectors are connected by a connect statement.
Each class and each instance can only have one annotation
. So there cannot be two annotation tags within one model. But a model (block) can extend another model (block) in which case the higher-level annotation should take precedence if present.
I agree that __brick
(or __haystack
or _semanticData
or whatever we end up calling it) should not be inside the __cdl
annotation as a fan model can also have such an annotation but is outside the scope of CDL. (This is a change to the current specification that we have for CDL which we will need to update as we converge.)
I don't think there is a case where we have to "combine metadata models if the CDL model and energy models are two separate Modelica files": We either have only a CDL model, or this CDL model is part of a model that also contains the HVAC system. Some of the HVAC system may be in different files but there is always a top-level .mo
file, and that is the file that should be parsed.
Summarizing the recent discussions here.
Buildings.*
Buildings.Controls.OBC.CDL.Interfaces.RealInput TZon(unit="K", displayUnit="degC")
"Zone temperature"
annotation (Placement(transformation(extent={{-140,-30},{-100,10}}),
iconTransformation(extent={{-140,-40},{-100,0}})),
__brick(mimetype="text/turtle", content=":TZon rdf:type Brick:Zone_Air_Temperature_Sensor"));
shacl
shape to restrict what type of points can be connected. We are still working on testing each of these. Closing with 2 updates:
Develop software to extract Brick representations from Modelica. Build on the work presented here by:
Buildings.Controls.OBC.CDL.Interfaces.BooleanOutput ySupFan "Supply fan on status" annotation (__Brick__(class=Fan_Status), Placement(transformation(extent={{140,50},{180,90}})