bot:adjacentElement, bot:containsElement and bot:intersectingElement should be disjoint properties?

[mathib]

As one bot:Zone instance cannot have a bot:adjacentElement AND a bot:containsElement to the same bot:Element instance, it would make sense to define them as disjoint properties in the BOT ontology?

[MadsHolten]

Good point. DisjointObjectProperties( bot:adjacentElement bot:containsElement ) makes sense to me.

[pipauwel]

Okay, let's do that! Additional restriction. But then it must be clear in the documentation that an element is either one or the other.

…

________________________________ Van: Mads Holten Rasmussen <notifications@github.com> Verzonden: vrijdag 25 mei 2018 22:36 Aan: w3c-lbd-cg/bot CC: Subscribed Onderwerp: Re: [w3c-lbd-cg/bot] bot:adjacentElement and bot:containsElement should be disjoint properties? (#24) Good point. DisjointObjectProperties( bot:adjacentElement bot:containsElement ) makes sense to me. - You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#24 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABjr0jPKUsCCF42neSHS8CGoEwBGNXYzks5t2Gs2gaJpZM4T_spP>.

[maximelefrancois86]

In principle, OK with this addition.

What OWL profile is targeted for BOT ?
OWL EL disallows the use of disjoint object properties.

[pipauwel]

Hi, I would opt DL. As far as I know, reasoners can be set up in a number of other profiles, thereby "not considering" some of the restrictions that are in there. Pieter

…

________________________________ Van: Maxime Lefrançois <notifications@github.com> Verzonden: maandag 28 mei 2018 15:22 Aan: w3c-lbd-cg/bot CC: Pieter Pauwels; Comment Onderwerp: Re: [w3c-lbd-cg/bot] bot:adjacentElement and bot:containsElement should be disjoint properties? (#24) In principle, OK with this addition. What OWL profile is targeted for BOT ? OWL EL disallows the use of disjoint object properties. - You are receiving this because you commented. Reply to this email directly, view it on GitHub<#24 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABjr0pNKqXOlbiZgOBCxgwjJJEEkMnjqks5t2_odgaJpZM4T_spP>.

[maximelefrancois86]

(please try to close issues only after the resolution is voted and implemented ;-) )

[mathib]

@maximelefrancois86 We discussed it during the telco of last week!

[GeorgFerdinandSchneider]

There is a need to revise this discussion. @mathib @maximelefrancois86 is this still a topic to be discussed? Potentially for v0.4.0?

[mathib]

I still think it's a good idea to make bot:adjacentElement, bot:containsElement and bot:intersectingElement all disjoint. The same for bot:adjacentZone, bot:containsZone and bot:intersectsZone.

As it concerns formal logic, it should probably be discussed for v0.4.0 at the earliest!

[pchampin]

I still think it's a good idea to make bot:adjacentElement, bot:containsElement and bot:intersectingElement all disjoint.

It is not at all obvious from the definition that containsElement is disjoint with intersectingElement. In fact, one could argue on the contrary that any element contained in a zone also intersects this zone. That is, unless "intersecting" conveys a stricter meaning, like "intersecting without being entirely contained". In which case this should be made more explicit in the textual definition of that property.

The same applies to containsZone and intersectsZone by the way.

[mathib]

you're right, the textual definitions should be updated. As well as the examples in the documentation

[maximelefrancois86]

I disagree with the proposal to add these axioms:

From the reference article

BOT: the Building Topology Ontology of the W3C Linked Building Data Group. Mads Holten Rasmussen; Maxime Lefrançois; Georg Ferdinand Schneider; Pieter Pauwels. Semantic Web Journal, 12(1), 22pp, IOS Press. URL: http://www.semantic-web-journal.net/system/files/swj2279.pdf

It reads at p. 8 and 9:

• bot:containsZone is transitive, and links a zone to another one it fully contains.
• bot:adjacentZone is symmetric, and links two zones that share part of their boundary (in the topological sense);
• bot:intersectsZone is symmetric, and links two zones whose 3D spatial extent is partly shared (e.g. a stair well intersecting several storeys).

From these definitions, one could argue that a zone can be both adjacent to, and contained in, another zone. Also, a zone can be both adjacent to, and intersecting with, another zone.

If you wish, the only properties that, by these definitions, could be disjoint, are bot:containsZone and bot:intersectsZone.

However adding a disjonction axiom is a dangerous thing to do as it may break existing implementations.

[mathib]

Currently in BOT, the following properties are disjoint:

• bot:adjacentZone and bot:intersectsZone
• bot:adjacentElement and bot:intersectingElement

So according to the current version of BOT, resp. two zones or a zone and an element can be both adjacent and contained OR intersecting and contained, but NOT adjacent and intersecting. I'm in favor of updating the text definition of bot:containsZone and bot:containsElement to indicate the "entirely contained in" part (see new issue #116).

Can we list use cases (and competency questions) that justify a combined usage of these properties? It would be good if we can draw sketches (2D and 3D) to demonstrate all the combinations and add this to the HTML doc of BOT, similar as done for the region connection calculus (RCC) in case of geometry.

We can split up the discussion:

• disjointness needed between bot:containsElement and bot:intersectingElement?
• disjointness needed between bot:containsZone and bot:intersectsZone?
• disjointness needed between bot:containsElement and bot:adjacentElement?
• disjointness needed between bot:containsZone and bot:adjacentZone?

Personally, I think we can benefit from clearer definitions for these properties. Adding a disjunction axiom might indeed break stuff if people use reasoners, but unless we receive notion of anyone using these properties together (aka, providing the group with the use case for the combined use), we cannot really discuss this. For now, I would leave the issue open until the next github issues sprint.

[maximelefrancois86]

In the KG for our building, we do sometimes use:

• properties bot:containsZone and bot:adjacentZone together
• properties bot:intersectsZone and bot:adjacentZone together

is the following alignment to RCC8 correct ?

• DC(a,b) (disjoint): not bot:containsZone(a,b), not bot:adjacentZone(a,b) , not bot:intersectsZone(a,b)
• EC(a,b) (touches): not bot:containsZone(a,b) , bot:adjacentZone(a,b) , not bot:intersectsZone(a,b)
• PO(a,b) (overlaps): not bot:containsZone(a,b) , bot:intersectsZone(a,b) , can be bot:adjacentZone(a,b) or not bot:adjacentElement(a,b)
• EQ(a,b) (equivalent): bot:containsZone(a,b) and bot:containsZone(b,a), not bot:intersectsZone(a,b) , bot:adjacentZone(a,b)
• TPP(a,b) (contains + tangential): bot:containsZone(b,a), not bot:intersectsZone(a,b) , bot:adjacentZone(a,b)
• nTPP(a,b) (contains + not tangential): bot:containsZone(b,a), not bot:intersectsZone(a,b) , not bot:adjacentZone(a,b)

[mathib]

I'll make an attempt to continue this discussion :)

@maximelefrancois86 : I think I agree with most what you propose, considering BOT relations between two BOT zones. The parallel with RCC8 is also useful to see the different combinations, although our situation is 3D and not 100% geometrically (e.g. two spaces separated by a wall are also considered adjacent regarding BOT I believe). According to your explanation, you would propose to:

• lift the existing disjointness axiom between bot:adjacentZone - bot:intersectsZone (not between bot:adjacentElement - bot:intersectingElement?).
• A new disjointness axiom between bot:containsZone and bot:intersectsZone can be installed as these would not co-occur in the cases presented above (when the first relation means "entirely contains" as listed in issue update text definition of bot:containsElement and bot:containsZone #116). On the other side, adding a new disjointness axiom might prove difficult wrt backwards compatibility as mentioned earlier (existing applications might break), so this option might not seem valid and perhaps not necessary unless we clearly want to state that this combination should not exist in a logically consistent dataset.

I'm less sure about the possible combinations of relations between BOT a zone and a BOT element, as this requires us to define clearly what the spatial extend is of each type of BOT zone (bot:Space is most clear I would say, but bot:Storey and bot:Building can be more problematic, e.g. is a bot:Storey adjacent to external walls on that floor or are these walls contained in the bot:Storey or are they both adjacent and contained?).

At this point in the development of BOT, I think we need full 3D examples to cover most common situations and the corresponding BOT relations (added to issue #76, documented in the comment #76 (comment)). When they are well defined, autogeneration of such relations from geometry might be implemented in a reliable/repeatable manner.

[mathib]

As decided in the LBD call of 29th of June:

Remove disjointness axioms, close the issue and raise a new one that moves those restrictions into SHACL shapes.

All disjointness axioms in BOT between the properties discussed in this thread are removed in the v0.4.0 branch.

A new issue is started, to see if SHACL can be used to help indicating users of potentially erroneous combinations of properties. This new issue is available here: #118