SPOT Scene Graph

Abstract

Extension of the Space Types Ontology (SPOT) for quantitative spatial descriptions. It aligns SPOT with the Geometry Metadata Ontology (GOM), so that spaces can be read as coordinate systems and appearances as transformations between them, forming a scene graph. This enables quantitative location descriptions: the position of a space within another space can be stated and computed numerically. It also adds a compact bounding box for spaces.

Introduction back to ToC

The Space Types Ontology (SPOT) describes spaces and how entity spaces appear in reference spaces. SPOT-SG connects this structure to the Geometry Metadata Ontology (GOM): every SPOT Space is treated as a coordinate system and every SPOT Appearance as a coordinate system transformation, so that SPOT instance data can be read as a scene graph. In addition, SPOT-SG introduces a compact bounding box literal for spaces.

Namespace declarations

SPOT-Scene Graph Extension: Overview back to ToC

This ontology has the following classes and properties.

Classes

• Appearance
• Space

Object Properties

• appears In
• is appearance of

Data Properties

• has bounding box

SPOT-SG Ontology: Description back to ToC

Spaces as coordinate systems

Every spot:Space is a gom:CartesianCoordinateSystem. Every Space instance (Physical or Virtual) defines a local coordinate system with an origin and axes. The Physical/Virtual distinction concerns real-world mappability (metric groundability), not the existence of a coordinate system. Two-dimensional spaces are treated as degenerate 3D spaces where the corresponding third axis exists but is constrained to zero. The alignment is declared on the abstract superclass spot:Space, so it covers the entire Space hierarchy.

Note on units: The length unit of a Space is declared with qudt:hasUnit, using units from the QUDT vocabulary such as unit:M or unit:PIXEL. Units without a fixed physical length, such as pixels, are adopted into the reference space at a ratio of 1:1; the actual ratio is carried by the transformation matrix of the Appearance. The same Space can therefore appear at different scales in different reference spaces. A unit MUST NOT be assumed when none is declared: GOM's default of metre does not hold for SPOT spaces, since DocumentSpaces may use pixel coordinates.

Appearances as coordinate system transformations

Every spot:Appearance is a gom:AffineCoordinateSystemTransformation. An Appearance describes how an EntitySpace is positioned within a reference space. This allows gom:fromCoordinateSystem, gom:toCoordinateSystem and gom:hasTransformationMatrix to apply directly to Appearance nodes. This holds for every Appearance regardless of the type of the reference space, so the alignment is declared on the abstract superclass spot:Appearance.

Property alignment

• spot:appearsIn is a subproperty of gom:toCoordinateSystem.
• spot-sg:isAppearanceOf is the inverse of spot:hasAppearance and a subproperty of gom:fromCoordinateSystem.

Together, a complete GOM transformation pattern is derivable from standard SPOT instance data. Only the transformation matrix itself has to be asserted. For the example in Figure 1, the asserted data is:

ex:Damage a spot:EntitySpace ;
    spot:hasAssetAppearance ex:DamageAppearance .

ex:DamageAppearance a spot:EntityAppearance ;
    spot:appearsIn ex:FloorPlan ;
    gom:hasTransformationMatrix "[1,0,0,0, 0,1,0,0, 0,0,1,0, 0.21,-0.65,0,1]"^^gom:columnMajorArray .

ex:FloorPlan a spot:EntitySpace .

From this, it may be inferred:

ex:Damage a gom:CartesianCoordinateSystem .
ex:FloorPlan a gom:CartesianCoordinateSystem .
ex:DamageAppearance a gom:AffineCoordinateSystemTransformation .

ex:Damage spot:hasAppearance ex:DamageAppearance .              # hasAssetAppearance is a subproperty
ex:DamageAppearance spot-sg:isAppearanceOf ex:Damage .          # inverse of hasAppearance
ex:DamageAppearance gom:fromCoordinateSystem ex:Damage .        # via isAppearanceOf
ex:DamageAppearance gom:toCoordinateSystem ex:FloorPlan .       # via appearsIn

Single-use Appearances

Each Appearance links exactly one source space to exactly one target space, as gom:fromCoordinateSystem and gom:toCoordinateSystem are functional properties. An Appearance must therefore not be shared by multiple spaces, even if their transformations are identical: a reasoner would otherwise infer that the spaces involved are identical (owl:sameAs). A space that appears in several places gets its own Appearance for each of them.

Bounding box

spot-sg:hasBoundingBox relates a Space to its bounding box in the Space's local coordinate system, encoded as a spot-sg:boundingBoxArray literal: an array with exactly six elements:

[minX, minY, minZ, maxX, maxY, maxZ]

For a two-dimensional Space, the minimum and maximum value of one axis are set to 0. Which axis that is depends on the Space and is not restricted to Z.

Units are those of the Space's local coordinate system and are therefore heterogeneous across a dataset. Meaningful spatial comparison requires unit resolution and transformation matrix application on the client side.

Cross-reference for SPOT-Scene Graph Extension classes, object properties and data properties back to ToC

This section provides details for each class and property defined by SPOT-Scene Graph Extension.

Acknowledgments back to ToC

The authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment, which is used for representing the Cross Referencing Section of this document and Daniel Garijo for developing Widoco, the program used to create the template used in this documentation.