Thanks for the suggestion, @blip2! Locations is definitely an area that we need to expand out a bit. Looks like BOT has space, floor and building as the base classes, with a couple space subclasses such as garage, which is a good start. We should have a little discussion about what we need to handle space-wise in Brick.

Some issues we should think about:

• is building -> floor -> room and zone -> room enough? Do we need other spatial composition idioms?
• need a basic listing of "types" of rooms. I think Brick now has laboratory, office, basement.
• do we want to capture connections between rooms? Just adjacentTo, or hasWallTo/hasNoWallTo/etc?
• do we want to capture orientation of the room? myroom hasOrientation WestFacing?

Thanks for the pointer, Ben!

I looked a bit into BOT's literature. This must be its core design:

• Basically the only difference so far seems to be "adjacentZone" and "adjacentElement".
  • While Element can be anything other than space, there is an example using it to describe Wall<->Room relationship. It is an interesting concept and probably scale well by putting more properties to Wall if needed. Other than that, I can't think of adjacentElement's usage.
  • Whether adjacentZone is needed or not should be discussed. I do not know when to stop putting more detailed location information but I am fine with adjacency. Unfortunately, I could not find their logistics on why adjacency is needed.
• Relying on an existing schema should be carefully considered. We do not know how much BOT will last as people worry about Brick with the same reason. As a first step, we can just provide an alignment as an extension. I saw the alignment they did, but we may be able to put it more comprehensively.
• I saw that they are using IFC vocabularies but not relationships. What relationships does IFC have for spaces/locations? How much location information is needed for applications? -> Need to study.
• In building -> floor -> room and zone, I think zone is generic enough to model many things. Additionally, Hall and Corridor were often needed in my experiences.
• (I believe Basement is a Floor.)

I think the key element missing is a set of solid use cases for expanding the spatial elements. Once we have that, then we can make a solid decision about what to include from BOT. I think the best way to do the inclusion is to provide the "alignment" or "mapping" from Brick to BOT, rather than cross our fingers that BOT retains its structure.

For most applications involving space, I imagine the relevant attributes are:

• nesting/composition of spaces (floor/room/building/etc)
• generic types of spaces: kitchen, laboratory, garage, storage, etc
• the name/type of the space (probably a literal)
• the volume of the space (probably a literal)
• the orientation of the space (probably a literal)
• possibly the adjacent rooms (probably a relationship)

From this information, we could derive things like adjacent zones and the like. If we're going to get into describing windows/doors/walls/etc then there's a whole rats nest of details regarding the materials and composition of those barriers. I don't think this fits within the purview of Brick, but we can offer examples of how properties can be attached to elements in a Brick graph to support that information.

Lets focus on the list of features I've mentioned above to start. I can take point on this unless one of you want to

Dear all!

I see this discussion has stalled for some months now. I would like to pick it up and see if we can contribute here.

I am part the BOT development team as well as being in contact with @jbkoh about some things in BRICK. Also I am heavily reusing BRICK in EU H2020 research project context .

It would be very interesting to investigate the reuse of BOT within the context of BRICK. A initial alignment has been proposed by me as noted by @jbkoh Link to Github.

The following items might be interesting towards reusing BOT:

• While reusing BRICK (v1.0.2) I came across the concepts Room, Space as rdfs:subClassOf Location. Also there is the concept of Zone which can be specialised to HVAC_Zone or Lighting_Zone. To me it is not clear why there is the need of a concept Space in contrast to Zone. Also in the BRICK documentation I see Room and Zone frequently use but not Space. Here the definitions made in BOT might help in reducing this ambiguity.
• In terms of aligning to BOT it would be very interesting to discuss this possibility. The main interest here to me is if the generality claim of BOT to be easily extended to domain ontologies such as BRICK holds.

Best

Georg

P.S.: Please find further documentation of BOT here:

• BOT Reasearch gate project site
• Most recent paper documenting BOT
• Developers involved (amongst others): @MadsHolten, @pipauwel, @maximelefrancois86

HI Georg,

Thanks for bringing this up again.

• We could remove Space. I think it was added while we were thinking about Space Heater. I agree with you that Zone can replace it in most cases. I think Zone in BOT has more general concepts that ours.
• For BOT, Brick has hasPart as a generic concept of hasBuilding, hasStorey, etc. in BOT. I think connecting them in your ontology should not be a problem.
• For Brick, probably the most interesting part in BOT would be the capability of describing structural components such as walls and windows. Could you detail the usage of such notions?
  • What are the example applications using such notions?
  • How much is it compatible with IFC (asking because I see the conversion tool) and how much is the abstraction useful for applications?
  • Just curious about the model, is a window not a part of the room but adjacent object? Is it common in the building industry? I get the reasoning behind this to describe something like heat dissipation, but it's just counter-intuitive to me.

• would we want to reconsider brick:Zone as a subclass of brick:Space? "Zone" to me means a logical grouping of space for use by some building subsystem (lighting, HVAC, fire, etc). "Space" seems important to keep then because it is a superset of that.

• Brick currently takes a stance against representing higher granularity spatial data in the model: we can basically tie equipment/spaces to which logical or physical space they are in (equipment) or a part of (location). Some welcome extensions in my view would be

  • support for GIS or other coordinate systems. A representation of polygons and points could suffice to determine if rooms are next to each other or what side of the building they are on. Currently this needs to be explicitly annotated, but one could imagine deriving this from Revit or SketchUp models of the building.
  • support for descriptions of the materials in the walls/windows/etc bounding the physical spaces, which would be helpful for more detailed modeling

v0.3.2 of BOT has been released -- something to keep an eye on a we move forward. The Brick-BOT alignment is pretty old now (uses v1.0.2), so we should try to update that at a future date.

@gtfierro Thanks for pointing this out!

Actually @jbkoh and me have prepared already an update of the alignment as of the discussion here.

Would be very great to put our heads together and release the latest alignment asap. A problem we had at that time is that version IRIs of BOT and BRICK did not resolve.
@jbkoh Do you know if this has changed on the side of BRICK? Unfortunately on BOT side it is not yet working.

Best

Awesome to hear! @GeorgFerdinandSchneider I fixed the namespace resolution a couple days ago, so the versioned IRI for Brick should now direct to the Brick.ttl file

Would you be able to submit the BOT-Brick alignment as a PR to this repository? We have an alignment directory in the root of the repo

OK sounds good. Unfortunately we did not succeed with the version IRI resolution - I will keep you updated and create a PR as soon as this is fixed on our end.

Hi @gtfierro !

I prepared a PR w3c-lbd-cg/bot#104 to finally merge the revised alignment in to bot master branch. As you seem to have some code-based approach for filing alignments I am not sure how you prefer a PR into BRICK. I suggest you implement it using the defined alignments in w3c-lbd-cg/bot#81 (comment)

Maybe @jbkoh can have a look here as well?

Thanks @GeorgFerdinandSchneider! We use code to generate the alignments, but the BOT one looks straightforward enough that we can probably just merge the Turtle in directly.

Integrated with Brick in #220