RE: Description of mobile elements / building

My 2 cents...

Any form of (bot) generalization that would bring infra in scope would be very welcome!
(also for the balance with IFC, serving in future both building and infra).

You mentioned the traffic/vehicle examples but think also of 3D Corridor Spaces offered by transport networks like a rail network or a road network (ie INSPIRE modelling).

Gr, Michel




 
Dr. ir. H.M. (Michel) Böhms
Senior Data Scientist

T +31888663107
M +31630381220
E michel.bohms@tno.nl
Location

 

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. 







-----Original Message-----
From: Antoine Zimmermann <antoine.zimmermann@emse.fr> 
Sent: woensdag 30 januari 2019 15:25
To: public-lbd@w3.org
Subject: Description of mobile elements / building

Following my question on elevators, I would like to share thoughts that may (or may not?) lead to a small reform of the BOT ontology.

Consider boats: they can be true floating houses. They may have storeys, bedrooms, kitchen, bathrooms, electrical system, plumbing, heating system, and so on. They for sure qualify as entities that BOT would be good at modelling. Yet, they are mobile, and they are vehicles.

Going further, trains are vehicles that countain toilets, cabines, possibly retaurants, sometimes bedrooms, even storeys, etc. They should be zones with spaces.

Going further, an inter-terminal shuttle in an airport, being a train itself, could be modelled as a zone with spaces inside. But from the point of view of the airport, an inter-terminal shuttle is just like an
elevator: an element that moves along a space that crosses several zones. A terminal is like a storey, except that it's not physically on top or below other terminals.

Considering the answers I had about elevator, the shuttle should be modelled as a bot:Element of the airport. But as I said, it could equally be a zone. From the point of view of the airport topology, the train is an element, while from its own internal perspective, the train is a zone with its own spaces.

So, this leads to my prooposal: coudn't we remove the disjointess axiom that currently holds between bot:Element and bot:Zone?

BTW, from the perspective of a 3D simulation application, it makes sense to navigate larger zones with elements that are themselves zones, because as soon as one enters a local element, the element becomes the reference frame and everything external can be ignored until going out of the element. This allows the application to handle very large zones as well as fine grained areas without performance issues.

BTW (2nd), the encapsuation of zones within elements leas to a hierarchical model of the environment that matches very well an abstract model for indoor navigation that a former student of mine proposed in his PhD dissertation.

BTW (3rd): think of a doll-house. It is an element in a child's bedroom, and a building with storeys and rooms.
--
Antoine Zimmermann
Institut Henri Fayol
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://www.emse.fr/~zimmermann/

Member of team Connected Intelligence, Laboratoire Hubert Curien

Received on Thursday, 31 January 2019 08:33:29 UTC