rec:substance

[ektrah]

(Re-opening this issue here so it doesn't get lost.)

rec.ttl currently defines the rec:substance property like this:

rec/Ontology/SHACL/RealEstateCore/rec.ttl

Lines 2039 to 2048 in 39b9076

	rec:substance
	a owl:AnnotationProperty ;
	rdfs:domain rec:feeds ;
	rdfs:domain rec:isFedBy ;
	rdfs:label "substance" ;
	rdfs:range [
	a rdfs:Datatype ;
	owl:oneOf (
	"ACElec"
	"Air"

This turns the rec:feeds and rec:isFedBy properties implicitly into classes and makes every subject in a rec:substance statement an instance of both the rec:feeds and rec:isFedBy class, which seems rather odd.

I'd propose to model this in one of the ways shown here (e.g., N-ary Relations):

(source)

/cc @gtfierro

[hammar]

Thanks for keeping this issue alive! I'll set aside some time this week to look into options either in REC or possibly in collaboration with Brick.

[hammar]

Hi again,

After sync w/ Brick, their approach is likely to be to fall back to ASHRAE 223P for representing details of connections between equipments, such as substances being fed. That leaves RealEstateCore with two options:

1. Removing substances from the ontology as out-of-scope, also referring to the Brick/223P solution for those use cases where such modelling is needed.
2. In REC implementing a custom SHACL/RDF-compliant representation of substances fed by/to Brick equipment. In that case, the simplest solution with the least impact on the current model is likely to add substance-specific subproperties to feeds, e.g., "feedsAir", "feedsWater", etc.

Any thoughts on the above, @ektrah? Also pinging @PeteHart for visibility, I know you've worked with this type of thing.

Karl

[ektrah]

I think both options are valid. My preference would be to align with Brick and ASHRAE 223P as much as possible and not invent the wheel in multiple places.

[PeteHart]

Not familiar with ASHRAE 223P so uncertain what it implies. Can say that in the implementations I've been part of it's been important to understand media (air vs water) which can be done with the different classes of Brick loops. Also important to understand how different equipments are connected, which is done by the Loop. And finally to be able to express that a Loop serves a Space, which I belive is the Brick feeds relationship. The substances you mention seem to be on a more granular level and I at least havent seen the need for them. Also agree generally that its better to align with Brick on these issues. Best Peter.

[hammar]

Thanks for the feedback on this @ektrah, @PeteHart ! We have one more stakeholder who is probably interested in this thread, @rszcodronski. Rick, I'll send you an email detailing this issue early next week, but am pinging you here for visibility/reference, in case you want to think on it before then. See also RealEstateCore/REC4#15.

[hammar]

After syncing with @rszcodronski it is evident that Willow makes use of substance modelling on feeds/isFedBy already today, and that removing it would be a blocker for REC4 adoption for them. Consequently we will have to look into how to support that use case in the DTDL models while also remaining compliant w/ Brick on the SHACL side. I'll look into this and bring something to the table here and/or at REC TC meeting next week.

[hammar]

Haven't had time to resolve this matter but it is still high on our agenda and will be resolved before REC4 GA (hopefully within a week or two).

[hammar]

Having hacked on this for a bit, it has become clear that implementing alignment between DTDL and SHACL on this will be too invasive in the translation tooling for us to get it done by 4.0 GA. Given the relatively minor impact, I'm marking this for 4.1 instead. By that time we should have flipped the translation around such that we can go DTDL->SHACL when needed, and thus simply filter out superfluous property graph:isms when there is no suitable SHACL representation available.