Add additional ontology imports

[gtfierro]

Adds ref-schema import (was not included by mistake) and latest RealEstateCore ontology

• integrate brickpatches into Brick itself
• remove duplicate quantities (include resolving rec:value vs brick:value, rec:ElectricChargeObservation, etc)
• remove recimports.ttl (this should be fully covered by Brick's QUDT import)

[gtfierro]

@hammar I'm trying to import the RealEstateCore ontology into the Brick repo so that we have integration tests against it. One issue I'm running into is that REC requires that all assets have an associated location. We have tried to put these constraints into model-level shape graphs (e.g. "for the Brick model for building ABC, there should be 20 VAVs and all should have an associated HVAC zone...", etc) rather than the schema itself. I understand if there is some reluctance to relax or lift this shape requirement, but can I ask how you have handled adding a location to all of your assets? Do you just add assets to the Building entity directly?

Thanks!

[hammar]

@hammar I'm trying to import the RealEstateCore ontology into the Brick repo so that we have integration tests against it. One issue I'm running into is that REC requires that all assets have an associated location. We have tried to put these constraints into model-level shape graphs (e.g. "for the Brick model for building ABC, there should be 20 VAVs and all should have an associated HVAC zone...", etc) rather than the schema itself. I understand if there is some reluctance to relax or lift this shape requirement, but can I ask how you have handled adding a location to all of your assets? Do you just add assets to the Building entity directly?

Thanks!

This hasn't been a concern that's been raised on our issues or to our TC prior to now, so I'm not sure how common (or not) it would be among our users to not have that spatial knowledge re. their assets' placements.

My guess (but it really is just that) is that they would connect assets directly to the Building as you propose.

[gtfierro]

It would be great if we could relax this requirement in order to reduce the modeling burden for folks who aren't trying to model everything in their building (we've been talking to folks that start with just a meter + equipment and don't really touch any of the spatial elements of the building). I've raised the question on the Matrix/gitter(?) channel

[gtfierro]

There are some concepts deprecated in the brickpatches.ttl file that may be mistaken:

• brick:Collection --> this needs a substitute or needs to be un-deprecated so that we can support brick Systems and other non-REC concepts
• brick:PV_Array --> this should not be deprecated because even REC wants it to be defined in Brick (https://dev.realestatecore.io/ontology/Collection/PV_Array)

@epaulson were there any others you noticed? I'm clicking through the rdf-explorer interface. Latest Brick + the REC imports and patches can be found here: https://gist.github.com/gtfierro/a0556f7e5515cb3298df9459b033a8e4

[epaulson]

There were some relationships that we hadn't settled - I think we were going to go with rec for hasPart but i think the REC patch also deprecated brick:feeds/isFedBy and maybe some other things.

I'm not sure wha the right approach here is, having both just makes life hard for folks trying to query, but having a mix is equally confusing - "it's rec for hasPart and brick for feeds" is hard to explain to people why they're different and for folks to remember which relationship is in which namespace.

[gtfierro]

We are still discussing with the REC team about how to handle the Brick and REC hasPart relationships. We are waiting to hear back from the REC team on what their preferred approach is