Spaces running over multiple storeys

[mathib]

If a bot:Space runs over multiple storeys (e.g. a stairwell), it could be useful if, besides the bot:hasSpace relation from the lowest bot:Storey to the bot:Space, an extra object property (e.g. bot:intersectsSpace) can be defined from the higher bot:Storeys that intersect with the bot:Space.

Example:

inst:storey1 rdf:type bot:Storey ;
             bot:hasSpace inst:spaceA .
inst:storey2 rdf:type bot:Storey ;
             bot:intersectsSpace inst:spaceA .

[GeorgFerdinandSchneider]

Indeed thats a good point. Anyway to use the bot:Interface concepts and relationships for this?

[mathib]

I think there are three methods possible for a situation with a space that runs over multiple storeys:

1. If one space can be assigned to two storeys (atm there is no cardinality constraint in BOT for this) using bot:hasSpace:

inst:storey1 bot:hasSpace inst:spaceA .
inst:storey2 bot:hasSpace inst:spaceA .

In this case, one has to take care while querying with reasoning that a certain space can occur multiple times as containedZone of the site and building. There's also no difference in order between the two storeys of the space. A bot:Element that is contained in spaceA (e.g. a stair) and runs over multiple storeys will also be inferred to be a containedElement of the multiple storeys that contain the space. An element that is contained in spaceA, but in fact is only contained in one storey of the spaceA (e.g. a desk), will be wrongly inferred to be contained in all the storeys of the space.

2. A first alternative method:

inst:spaceA bot:containsZone inst:spaceA-1, inst:spaceA-2 .
inst:storey1 bot:hasSpace inst:spaceA-1 .
inst:storey2 bot:hasSpace inst:spaceA-2 .

Problem here would be that inst:spaceA would not be contained in the building and site by inferencing, so the relation would have to be made explicit:
inst:buildingA bot:containsZone inst:spaceA .
A bot:Element (e.g. a stair) contained in the space, and running over two storeys, has to be modeled as:
inst:spaceA bot:containsElement inst:stairA .
The stair in the above example is also not contained by any storey while reasoning in this way, so this has to be modeled explicitly if needed:

inst:storey1 bot:containsElement inst:stairA .
inst:storey2 bot:containsElement inst:stairA .

A bot:Element contained in the space and contained in one storey (e.g. inst:storey1) is modeled as:
inst:spaceA-1 bot:containsElement inst:desk1 .
=> inferres correctly that inst:storey1 bot:containsElement int:desk1

3. An alternative for method 1 and 2 would be to define the main storey with bot:hasSpace and the other storeys with a new BOT property bot:hasSpaceOther (= similar as the proposal in the first comment, but with a more clear naming):

inst:storey1 bot:hasSpace inst:spaceA .
inst:storey2 bot:hasSpaceOther inst:spaceA.

A bot:Element contained in spaceA and running over two storeys would then be modelled as:
inst:spaceA bot:containsElement inst:stairA .
A bot:Element contained in spaceA, but only contained in one of the two storeys, can only be modeled correctly if the element is contained in the main storey (in the above example this is inst:storey1). If it is contained in spaceA and inst:storey2 only, it will be wrongly inferred to be contained in storey1 AND one has to explicitly model the element as contained by storey2:

inst:spaceA bot:containsElement inst:lightA .
inst:storey2 bot:containsElement inst:lightA .

=> first triple wrongly inferres that inst:storey1 bot:containsElement inst:lightA

@MadsHolten : what would be the preferred way to model this? Or methods that are disapproved? I think only method 2 can be used in all cases. Method 1 and 3 will infer wrong results and are disapproved, I think. It would be useful to somehow formally express for method 2 in the ontology, that any space that consists of sub-spaces, is also contained in the storeys of these sub-spaces. This is probably only possible by defining a new property bot:hasSuperSpace with domain and range a bot:Space. Then an additional propertyChainAxiom on bot:hasSpace for (bot:hasSpace bot:hasSuperSpace) would make things easier. See the next example triples:

inst:spaceA-1 bot:hasSuperSpace inst:spaceA . # replaces in method2 inst:spaceA bot:containsZone inst:spaceA-1
inst:spaceA-2 bot:hasSuperSpace inst:spaceA . # replaces in method2 inst:spaceA bot:containsZone inst:spaceA-2
inst:spaceA bot:containsElement inst:stairA .

=> this would infer via the new propertyChainAxiom:

inst:storey1 bot:hasSpace inst:spaceA ;
   bot:containsElement inst:stairA .
inst:storey2 bot:hasSpace inst:spaceA ;
   bot:containsElement inst:stairA .
inst:buildingA bot:containsZone inst:spaceA .
inst:siteA bot:containsZone inst:spaceA .

EDIT: this additional property (bot:hasSuperSpace) and propertyChainAxiom cannot be used, as bot:containsElement and bot:containsZone defines that an element, resp. a zone has to be contained completely in the other zone. This is not the case for a stairwell space, which is only partially contained in both storeys.

[mathib]

If the order of the storeys is important (= which storey is above/below the other), I think of four methods:

1. add a datatype property for the elevation of the lowest point of each storey. This property can be defined in PROPS or in BOT, but I think BOT is better suited as it also involves the building topology? It is then possible to query for each storey and this elevation property, which can then be sorted. This solution is probably not ideal in the case of one building that exists of two towers that are connected at the base: let's say storey1 is the storey both towers have in common and storey2-A is the next storey in towerA, while storey2-B is the next storey in towerB. In this case, the first method would probably fail, because storey2-A and storey2-B are in fact not below/above each other

2. use bot:interfaceOf or bot:adjacentZone between two storeys. In this way, there is no order between the connected storeys. I think bot:adjacentZone is preferred over bot:interfaceOf, as this deals more with the topology of the storeys and it is shorter to model (no bot:Interface instance needed in between)

3. A third way would be to combine method 1) en 2)

4. a fourth way, would be to define a new subproperty of bot:adjacentZone, being bot:hasStoreyAbove/bot:hasStoreyBelow (or bot:hasZoneAbove/bot:hasZoneBelow). In this way, the data modeler does not have to know or guess the height of every storey to express that one storey is above/below the other.

@MadsHolten : I think it would be worthwhile to add something as bot:hasStoreyAbove/bot:hasStoreyBelow?

[MadsHolten]

Actually, from the BOT definitions, you cannot say that it is contained in any of the storeys as it only intersects with them. The stairwell is only contained in the building.

The main problem here is that you understand Storey as a level with an elevation, which it is not. It is just a zone. It has adjacencies to all the corridors contained in the levels. Can you use this fact for your use case?

[MadsHolten]

I have to admit that I strongly agree with @pipauwel that we should not include too many terms in BOT as it is only supposed to be the core. Feel free to extend the concepts as you wish, but to me, it seems like you have a very specific use case in mind here.

[mathib]

Actually, from the BOT definitions, you cannot say that it is contained in any of the storeys as it only intersects with them. The stairwell is only contained in the building.

But can't you say that the stair is contained (or at least related) to the two spaces it intersects with? Otherwise, the stairs is not connected to any storeys and spaces at all and just 'somewhere' in the building.

Feel free to extend the concepts as you wish, but to me, it seems like you have a very specific use case in mind here.

I think a stairs is not so uncommon in buildings? I really think we should gather some best modeling practices related to BOT, without defining too much restrictions in the ontology

[MadsHolten]

I think we could challenge the bot:containsZone to also be applicable for intersecting zones. In that case, I prefer your modelling approach 1. If you query for distinct spaces your query will not return a wrong result.

In the docs there is a section for examples. It would be awesome if you implement the staircase example there. https://github.com/w3c-lbd-cg/lbd/blob/gh-pages/bot/index.html

[MadsHolten]

I have given it a shot using interfaces. Tell me what you think.

Stairwell example

[mathib]

Overall, I think this is an interesting approach. Some suggestions for the text:

• make clear that 'stairwell' is meant as a space ("Modeling the space inside a stairwell ..." sounds confusing)
• I would suggest to use 'storey' for the Abox samples' names (instead of 'Levels', which I associate with conventional BIM Levels = horizontal planes)
• The demo query: I would explicitly query for a bot:Space and bot:Storey (more generic query), instead of using the FILTER

From your earlier comment:

Actually, from the BOT definitions, you cannot say that it is contained in any of the storeys as it only intersects with them.

I would suggest to make the definition in the BOT ontology of bot:containsZone and bot:containsElement more clear, by defining that this can only be used when the complete zone, respectively the element is contained in the other zone (partially is not allowed).

For the demo, it would be good to also have a second part, where you place bot:Elements contained in or adjacent to the stairwell zone (e.g. a stair object in the stairwell running between two storeys and another object (e.g. a lamp) that is only contained in one storey of the stairwell).

[mathib]

I think the approach with bot:Interface is good, but we could also make separate object properties that don't require an intermediate bot:Interface instance that is not used for something else (<=> pipes where you need the interface to declare the amount of surface that can exchange heat). This could be something like bot:intersectsZone and bot:intersectsElement

[mathib]

I think we could challenge the bot:containsZone to also be applicable for intersecting zones. In that case, I prefer your modelling approach 1. If you query for distinct spaces your query will not return a wrong result.

No, approach 1 cannot be used, as it would wrongly infer that the desk object is contained in all the storeys that contain the space

[MadsHolten]

@mathib will you update the docs with the modeling approach we discussed during the W3C call (subzones of stairwell zone defining vertical stratification)?

[mathib]

working on a sparql-vis example. You want me to add it to the docs too? We could also wait for LDAC and discussions there, before we further update the docs?

[mathib]

This is the sparql-vis sample:
https://madsholten.github.io/sparql-visualizer/?file=https://www.dropbox.com/s/e5vmgovtg9rfsk6/LDAC2018_spacesOverMultipleStoreys_componentA.json?dl=0

[mathib]

As discussed at LDAC2018 (and documented in issue #30), we go for the second approach covered in the above sparql-vis.