Point_Collection a subclass of Automation_Collection or not?

[ektrah]

Brick 1.5.0-rc1 defines:

• Automation_Collection as a collection class and a SHACL shape that constraints the collection members to be of type Equipment, Point, or Automation_Collection.
• Point_Collection as a collection class and a SHACL shape that constraints the collection members to be of type Point or Point_Collection.
• Point_Collection as a subclass of Automation_Collection.

Clearly, any instance of the Point_Collection class that satisfies the constraints of the Point_Collection shape also satisfies the constraints of the Automation_Collection class:

• If the Point_Collection member is of type Point, then the Point constraint of Automation_Collection is satisfied.
• If the Point_Collection member is of type Point_Collection and the reasoner infers that the Point_Collection instance is also an Automation_Collection instance (rdfs9), then the Automation_Collection constraint of Automation_Collection is satisfied.

So, from the RDF perspective, the set of all Point_Collections can be seen a subset of the set of all Automation_Collections.

However, any software dealing with these collections will most likely perform the operations on them that are typical for collections – such as reading and adding elements.

Reading is no problem:

• Reading the elements from a Automation_Collection where the software expects a Automation_Collection will yield elements of type Equipment, Point, and Automation_Collection – as expected. ✅
• Reading the elements from a Point_Collection where the software expects a Point_Collection will yield elements of type Point and Point_Collection – as expected. ✅
• Reading the elements from an Automation_Collection where the software expects a Point_Collection is problematic but can be prevented with a simple type check. ✅
• Reading the elements from a Point_Collection where the software expects a Automation_Collection will yield elements of type Point and Point_Collection – there will never be any Equipment yielded and all of the yielded Automation_Collection instances will be Point_Collection instances, but that's perfectly fine. ✅

Adding elements has a problem though:

• Adding elements to a Automation_Collection where the software expects a Automation_Collection is fine. ✅
• Adding elements to a Point_Collection where the software expects a Point_Collection is fine. ✅
• Adding elements to a Automation_Collection where the software expects a Point_Collection is fine. ✅
• Adding elements to a Point_Collection where the software expects a Automation_Collection breaks – the software might add Equipment or an Automation_Collection that is not a Point_Collection, meaning the Point_Collection instance will not satisfy the constraints of the Point_Collection shape. ❌

Therefore, if the SHACL shapes are not only intended to be used for validation, but also to guide software to construct collection instances that will pass the validation, then Point_Collection should not be a subclass of Automation_Collection.

What do you think?

[gtfierro]

We discussed briefly at the meeting and decided that these should be separate, i.e. that Point Collection is not a subclass of Automation Collection.