hasPart, Brick, and RealEstateCore

[epaulson]

We've talked about this a couple of times but I think it's worth coming back to. Both Brick and RealEstateCore have a hasPart/isPartOf set of relationships. To be a little imprecise but hopefully descriptive, they're both mostly only used as composition in the same type subtree, e.g. rec:Floor F1 rec:hasPart rec:Room R1, or brick:Chiller C1 brick:hasPart brick:Pump P2 - if you go "across types" we have specialized relations for those - brick:Chiller C1 rec:IsLocatedIn rec:Room R1.

The tentative plan was to just leave both rec:hasPart and brick:hasPart in the ontology and use the brick or rec version as you need, but I think it's a bit confusing/bad developer experience to leave both in, especially because when querying you have to use the "right" one from the right namespace to find anything - I think a very common "why won't my query return anything" is going to be 'because your SPARQL is asking for brick:hasPart, you needed to use rec:hasPart there instead"

So I think at a minimum we should just verify that the semantics of brick:hasPart and rec:hasPart are the same and go ahead and add some rules to say that they're equivalent relationships and maybe have the reasoner add the other one to graphs, and probably deprecate one and just tell folks to consistently use hasPart from only one of the namespaces, regardless of type.

One area of conflict - brick uses hasPart for collection membership, rec uses includes.

@gtfierro @hammar @jbkoh

[hammar]

Agree. Re. the conflict on collections, I'd naturally propose the use of REC semantics over current Brick ones, the former being more precise. Maybe take a call with both our respective TC:s to discuss, after the holidays?

[gtfierro]

Hi @hammar!

@epaulson, @ektrah and I were discussing this today during one of the Brick working groups. Looking through how rec:hasPart is defined in https://github.com/RealEstateCore/rec/blob/main/Source/SHACL/RealEstateCore/rec.ttl, it doesn't seem like there is much semantic difference between rec:hasPart and brick:hasPart. Using the terminology from this paper, we have the following notions of parthood:

• component-integral: for "Equipment hasPart Equipment"
• place-area for "Location hasPart Location"
• member-collection for "Collection hasPart Thing"

These are all baked into the definition of rec:hasPart and brick:hasPart, per my interpretation.

In terms of a path forward, one idea we had was to mark brick:hasPart as deprecated in a future point release (1.3.x) of Brick in favor of rec:hasPart. We do not want to remove this property immediately as this would break essentially every existing Brick model :). The deprecation notice will include a SHACL rule for adding rec:hasPart where necessary, and warning of the deprecated use of brick:hasPart. In the meantime, we should probably mark the two properties as "equivalent" so that they can be used interchangeably.

How does this sound? Do you agree that the semantics are equivalent between the two properties?

[hammar]

Aside from the collection case, I think the semantics are interchangeable. There, my concern is less an ontological one and more a practical one: it can be quite convenient to navigate the parthood hierarchy, drilling down or up, knowing that any query that traverses rec:hasPart will return an entity of the same type. That assumption breaks if we use hasPart for collection inclusion, which is why I would prefer a separate property be used for that if possible. If not possible... well, at the very least it would warrant more discussion at a REC TC call.

[gtfierro]

Ah, yes -- I agree with you on Collections. We do have more permissive restrictions on brick:hasPart for that case.

One idea to preserve both semantics is to have brick:hasPart be a super-property of rec:hasPart. Another idea is to go where I think you're heading and introduce a separate member-collection parthood relation for putting assets and other things into collections. I think introducing that would be further down the line for us, but we can consider that (maybe for Brick 1.4?)

[epaulson]

I don't mind Brick switching to use a new 'membership' relation instead of 'hasPart' for collection. The one place where I think it feels a little unnatural is PV_Array and PV_Panel - I think hasPart is more natural there than hasMember, but it's not the end of the world and there are certainly other places where making more clear the difference between a 'component-integral object' type relationship and a 'member-collection' relationship makes sense and you can't say that in Brick today.

My big worry is figuring out a backwards compatibility plan for Brick.