Proposal to Enhance Test Cases with Detailed Semantic Models

[LiMingchen159]

Description :The current bacnet.ttl file used in our test cases defines points with limited semantic details, primarily focusing on superclasses. It lacks critical information such as units and boundary values, which makes it difficult to fully utilize the data in various scenarios.

Current Issue:

For example, the existing definition for a point in bacnet.ttl is:

bldg:con_oveTSetCoo_u a brick:Point ;
	ref:hasExternalReference [
		bacnet:object-identifier "analog-output,32" ;
		bacnet:object-type "analog-output" ;
		bacnet:object-name "con_oveTSetCoo_u" ;
		bacnet:objectOf bldg:boptest-proxy-device
	] .

This definition includes basic references like the object identifier and name, but it doesn’t include additional semantic information like units or boundary values.

Proposed Enhancement:

I suggest adding richer semantic details for each test case, such as units, boundary values, and more specific point definitions. The enhanced model would look like this:

bldg:con_oveTSetCoo_u a brick:Zone_Air_Cooling_Temperature_Setpoint ;
	ref:hasExternalReference [
		bacnet:object-identifier "analog-input,32" ;
		bacnet:object-type "analog-input" ;
		bacnet:object-name "con_oveTSetCoo_u" ;
		bacnet:objectOf bldg:boptest-proxy-device
	] ;
	brick:hasUnit unit:K ;
	brick:Max_Limit "308.15"^^xsd:float ;
	brick:Min_Limit "278.15"^^xsd:float .

In this updated definition:

• The point is more specifically defined as a brick:Zone_Air_Cooling_Temperature_Setpoint.

• It includes the unit (unit:K for Kelvin).

• It also includes boundary values for the point (Max_Limit and Min_Limit), represented in xsd:float.

Limitations:

• The current bacnet.ttl only defines points at a high level (using superclasses), and it lacks unit and boundary information, making it harder to apply this data effectively in certain contexts, particularly when modeling specific system behaviors or enforcing constraints.

• The Max_Limit and Min_Limit values are just examples. The usage and appropriateness of these limits need to be confirmed with the Brick team.

• The information for the semantic_model.ttl will be derived from:

  1. The bacnet.ttl file associated with each test case.

  2. The relevant documentation related to each test case.

Proposed Changes:

• Create a new semantic_model.ttl for each test case.

• Include units, boundary values, and additional semantic details for each point, improving the clarity and usability of the models.

Since I do not have administrative privileges to make these changes directly, I would like to request approval from the repository maintainers for this proposal. If the proposal is accepted, I will proceed with implementing these changes over the next few days.

[dhblum]

Thanks @LiMingchen159 for proposing this issue. Indeed, the bacnet.ttl are meant to be a convenient way to store bacnet information for the bacnet interface for the time being. A more comprehensive approach to adding and making available semantic models in BOPTEST is ongoing in issue #591 and associated PR #709. We are hoping to have initial semantic models for bestest_air and multizone_office_simple_air available in the coming months.

[LiMingchen159]

Thank you @dhblum for providing the update and for the valuable information! I'm excited to see the progress on the ongoing work, especially with the semantic models for bestest_air and multizone_office_simple_air coming soon. I took a closer look at the semantic models generated in PR #709, and I have a few additional suggestions:

1. Visibility of Max/Min Values :
   In the current model, the maximum and minimum values are still not visible. For example, in the following model:

bldg:con_oveTSetHea_Reference a ref:BOPTestReference ;
    ref:activate literal:con_oveTSetHea_activate ;
    ref:description literal:description ;
    ref:isWritable true ;
    ref:max literal:max ;
    ref:min literal:min ;
    ref:name literal:con_oveTSetHea_u ;
    ref:unit literal:K .

The max and min values are present, but they do not seem to be fully defined or visible. It would be great if these values could be explicitly included and available for reference.

2. Clarification of Input/Output for Each Point :
   It would be helpful to explicitly specify whether each point is a simulated input or output. This additional context will improve the clarity and utility of the models, particularly when dealing with control systems or simulation setups.

I hope these suggestions are helpful, and I look forward to seeing the continued progress. Thank you again for the hard work on this!

[dhblum]

Thanks @LiMingchen159 for the suggestions. I agree it would be good for the values to be present for min/max, I can pass this feedback to the team. I think the "isWritable" would indicate whether it is an available input.

[LiMingchen159]

Thanks @LiMingchen159 for the suggestions. I agree it would be good for the values to be present for min/max, I can pass this feedback to the team. I think the "isWritable" would indicate whether it is an available input.

You're welcome! Glad I could help. And thanks for the explanation!