Adding automation groups

[gtfierro]

Addressing #722

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[fennibay]

This is the current validation error:

   Severity: sh:Violation
  Focus Node: <urn:example/collection#Ahu>
  Message: Value must have at least one of the following shapes: _:7ed7414772658c5d3453cd82915382c7, _:e07496e981cc2a35110fc89f8f65c0eb
  Path: brick:hasPart
  Value: <urn:example/collection#FrostDetection>
  Source Constraint: sh:OrConstraintComponent
  Source Shape: _:ne1f5e65888c64b61a1d5168bc478d3ddb3

My interpretation is that we're now running against the following constraint

Brick/bricksrc/root_class_shapes.ttl

Lines 49 to 54 in f7f0db9

	sh:property [
	sh:path brick:hasPart;
	sh:or (
	[ sh:class brick:Equipment ]
	[ sh:class brick:Automation_Group ]
	) ;

But urn:example/collection#FrostDetection is of type brick:AutomationGroup. So I don't understand what is going wrong here.

Could it be that the SHACL engine is using a cached version or a different format of this ttl file?

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[gtfierro]

Could it be that the SHACL engine is using a cached version or a different format of this ttl file?

It was actually a different constraint that was getting triggered! I had to add a feature to my SHACL engine to follow blank nodes in the report which let me see what the rest of the shape was.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[fennibay]

@gtfierro thank you for preparing this.

I think this is now good for the equipment part. The second aspect in #722 was collections within Zones, and I'd like address that part, as well.

A typical example is how we structure our room application. The points are organized in folders because they have some shared context, e.g.:

Z: Zone:

• C: HVAC
  • E: Radiant ceiling
• C: Room temperature setpoint determination
  • P: Room temperature setpoint
  • P: Room temperature setpoint shift
• C: Air volume flow tracking
  • P: Room supply air volume flow
  • P: Present setpoint for room extract air volume flow
• C: Ventilation control
  • P: Present ventilation setpoint
  • P: Setpoint room air quality for comfort
  • P: Setpoint room air quality for pre-comfort
  • P: Setpoint room air quality for economy

(Z: Zone, C: Collection, P: Point, E: Equipment)

Ref: https://sid.siemens.com/r/A6V11176325/6498277643__6.0_en-US_6419929099

So, can we apply the same principle to rec:Zone or rec:Space where an Automation_Collection can be included within them?

/cc @ektrah

[gtfierro]

I just implemented it, and added a quick example of your Room application:

https://github.com/BrickSchema/Brick/blob/79fab96de19cdf0d0d442a85ca22f754d9b2ac4c/examples/collection/room_application.ttl

Let me know what you think!

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[fennibay]

Thank you @gtfierro, looks great for me. I have one important and one non-important comment.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[github-actions]

The latest build of the Brick ontology on this PR is available here.

[fennibay]

Thanks for updating this.

I put some analysis on the last validation errors.

[fennibay]

I think this is colliding with the following rule:

Brick/bricksrc/rules.ttl

Lines 576 to 598 in b61d72a

	# if point group rec:includes a point or point group, add brick:hasPart relationship
	bsh:PointGroupIncludesHasPart a sh:NodeShape ;
	sh:targetClass brick:Point_Collection ;
	sh:rule [
	a sh:SPARQLRule ;
	sh:construct """
	CONSTRUCT {
	$this brick:hasPart ?part .
	}
	WHERE {
	$this rec:includes ?part .
	{
	?part rdf:type/rdfs:subClassOf* brick:Point .
	}
	UNION
	{
	?part rdf:type/rdfs:subClassOf* brick:Point_Collection .
	}
	}
	""" ;
	sh:prefixes <https://brickschema.org/schema/1.4/Brick> ;
	] ;
	.

That rule inserts a brick:hasPart relationship when there is a rec:includes relationship of a Point_Collection, and here we say that Automation_Collections may not have brick:hasPart relationships.

I would revisit rules.ttl. I think we should keep includes and hasPart separate.

[fennibay]

And this is colliding with

Brick/bricksrc/rules.ttl

Lines 500 to 526 in b61d72a

	# rule to add rec:includes when a brick:Collection contains a brick:Equipment
	bsh:CollectionIncludesEquipment a sh:NodeShape ;
	sh:targetClass brick:Collection, brick:System, brick:Equipment ;
	sh:rule [
	a sh:SPARQLRule ;
	sh:construct """
	CONSTRUCT {
	$this rec:includes ?eq .
	}
	WHERE {
	$this brick:hasPart ?eq .
	{
	?eq rdf:type/rdfs:subClassOf* brick:Equipment .
	}
	UNION
	{
	?eq rdf:type/rdfs:subClassOf* brick:Collection .
	}
	UNION
	{
	?eq rdf:type/rdfs:subClassOf* brick:System .
	}
	}
	""" ;
	sh:prefixes <https://brickschema.org/schema/1.4/Brick> ;
	] ;
	.

because that inserts rec:includes where there is a brick:hasPart and here we constrain rec:includes to brick:Automation_Collection only.

I would revisit rules.ttl