BAUML - Building Augmentation Utility Modeling Language

This schema describes a XML language to build a world model used for Augmented Reality and Ubiquitous Computing research projects at the Vienna University of Technology. It provides the structures to describe geometry and spatial relations between buildings and rooms contained within building. in addition to that it allows to store locations of markers used for optical tracking within the building.

Its is also designed to be very extensible. A hierarchy of types defines the basic semantics of elements. Elements then further specialize these to provide more application specific information. Therefore additional content can be embedded in structures already built with this format.

This should be a basis for discussion and extension towards a larger schema for our world model. Currently we plan to store the data for Signpost 2.0 and the OCAR application in this format. Please contact Gerhard Reitmayr <reitmayr@ims.tuwien.ac.at> with any remarks you have.

Version 2.1 - 18.1.2003

Global Simple Types

UnitSphereValue

Syntax

 <simpleType name="UnitSphereValue"> 
   <restriction base="xs:double"> 
     <maxInclusive value="1" fixed="false"/> 
     <minInclusive value="-1" fixed="false"/> 
   </restriction>
 </simpleType>

Description

double values in the interval [-1,1] which is a handy type for quaternion representation.

DoubleList

Syntax

 <simpleType name="DoubleList"> 
   <list itemType="xs:double"/> 
 </simpleType>

Description

list of double values, base type for restricted data types like vectors, rotations, etc.

IntegerList

Syntax

 <simpleType name="IntegerList"> 
   <list itemType="xs:integer"/> 
 </simpleType>

Description

list of integer values, useful for list of indices.

UnitSphereValueList

Syntax

 <simpleType name="UnitSphereValueList"> 
   <list itemType="xs:double"/> 
 </simpleType>

Description

list of UnitSphereValue, base type for restricted data types like Quaternions etc.

Vec3

Syntax

 <simpleType name="Vec3"> 
   <restriction base="DoubleList"> 
     <length value="3" fixed="false"/> 
   </restriction>
 </simpleType>

Description

a simple type storing three double values separated by spaces.

Quaternion

Syntax

 <simpleType name="Quaternion"> 
   <restriction base="UnitSphereValueList"> 
     <length value="4" fixed="false"/> 
   </restriction>
 </simpleType>

Description

a simple type storing four double values in the interval [-1,1] separated by spaces.

Global Complex Types

AnnotationType

Syntax

 <complexType name="AnnotationType" mixed="false" abstract="false"> 
   <complexContent> 
     <extension base="xs:anyType"/> 
   </complexContent>
 </complexType>

Description

Annotation data for all objects. The idea is to add any meta-data of objects here. This could also included application specific data. Therefore we specify so far no further content model, but allow any content here.
RDF might be a good way to specify annotation data.

RepresentationType

Syntax

 <complexType name="RepresentationType" mixed="false" abstract="false"> 
   <choice minOccurs="1" maxOccurs="1"> 
     <sequence minOccurs="1" maxOccurs="1"> 
       <element name="Vertex" maxOccurs="unbounded" minOccurs="1" nillable="false"> 
         <complexType mixed="false" abstract="false"> 
           <attribute name="position" type="Vec3" use="optional"> 
           </attribute>
           <attribute name="id"/> 
         </complexType>
       </element>
       <element name="Polygon" minOccurs="0" maxOccurs="unbounded" nillable="false"> 
         <complexType mixed="false" abstract="false"> 
           <attribute name="vertices" type="IntegerList" use="required"> 
           </attribute>
           <attribute name="type" use="required"> 
             <simpleType> 
               <restriction base="xs:string"> 
                 <enumeration value="wall"/> 
                 <enumeration value="floor"/> 
                 <enumeration value="portal"/> 
                 <enumeration value="ceiling"/> 
                 <enumeration value="special"/> 
               </restriction>
             </simpleType>
           </attribute>
           <attribute name="name" type="xs:NCName" use="optional"> 
           </attribute>
         </complexType>
       </element>
     </sequence>
   </choice>
 </complexType>

Description

Geometrical representation of SpatialObjects. Any kind of representation could be possible. So far we support the simple vertex list, polygon model for BAUML.

Sub elements

Vertex

Attributes

position
The position attribute specifies the vertex position as x y z.
id

Description

This element stores a single vertex of a polygon based geometrical representation. At least one point is necessary for a non empty representation.

Polygon

Attributes

vertices
list of vertices the polygon is built from
type
The polygon can be of one of the following types :
  • wall
  • floor
  • portal
  • ceiling
  • special
name
a polygon can also have a name. This is for example used to relate the portal polygons to certain portals.

Description

A polygon specifies a list of vertices it is built from. In addition to that it can specify a certain type.

PoseType

Syntax

 <complexType name="PoseType" mixed="false" abstract="false"> 
   <choice minOccurs="1" maxOccurs="1"> 
     <element name="Transformation" minOccurs="1" maxOccurs="1" nillable="false"> 
       <complexType mixed="false" abstract="false"> 
         <attribute name="translation" type="Vec3" use="optional" default="0 0 0"> 
         </attribute>
         <attribute name="rotation" type="DoubleList" use="optional" default="0 0 1 0"> 
         </attribute>
         <attribute name="rotationType" use="optional" default="axisangle"> 
           <simpleType> 
             <restriction base="xs:string"> 
               <enumeration value="axisangle"/> 
               <enumeration value="quaternion"/> 
               <enumeration value="matrix"/> 
               <enumeration value="euler"/> 
             </restriction>
           </simpleType>
         </attribute>
         <attribute name="scale" type="Vec3" use="optional" default="1 1 1"> 
         </attribute>
       </complexType>
     </element>
     <element name="MatrixTransform" nillable="false" abstract="false"> 
       <complexType mixed="false" abstract="false"> 
         <attribute name="matrix" use="optional"> 
           <simpleType> 
             <restriction base="DoubleList"> 
               <length value="16" fixed="false"/> 
             </restriction>
           </simpleType>
         </attribute>
       </complexType>
     </element>
   </choice>
 </complexType>

Description

specifies pose of SpatialObjects. different ways to specify pose will be derived from that.

Sub elements

Transformation

Attributes

translation
This attribute gives a translation of the transformation.
rotation
gives the rotational part of the transformation. The format itself is specified by the rotationType attribute.
rotationType
this attribute specifies the format of the rotation attribute. It allows the following choices :
  • axisangle - gives the rotation as four doubles. The first three describe the axis of rotation and the fourth the angle in radians.
  • quaternion - gives the rotation as a quaternion. The first three entries specify the x, y, z components of the vectorial part. The fourth entry is the homogenous part of the quaternion.
  • matrix - gives the rotation as a 3x3 orthogonal matrix with determinant 1.
  • euler - gives the rotation as Euler angles around x, y and z.
scale
gives the non-uniform scale of the transformation.

Description

This specifies a simple affine transformation consisting of a scale, a rotation and a translation in that order.

MatrixTransform

Attributes

matrix
an arbitrary 4x4 transformation matrix.

Description

This specifies a general 4x4 transformation matrix. Use at your own risk :).

ObjectType

Syntax

 <complexType name="ObjectType" mixed="false" abstract="false"> 
   <sequence minOccurs="1" maxOccurs="1"> 
     <element name="annotation" type="AnnotationType" minOccurs="0" maxOccurs="1" nillable="false"/> 
   </sequence>
   <attribute name="id" type="xs:ID" use="optional"> 
   </attribute>
 </complexType>

Attributes

id
The id attribute allows to define a unique identifier for any object of this type.

Description

Everything is represented as an object. Objects generally will follow this type. There is some discussion needed about this type system (see note).
The type system is based on the following idea :

Important conceps get codified into a type system. Actual instance types are derived from one of these main types and can extend these or other instances types. This allows to have application dependend extensions to the main types.

At the same time, every instance type carries an attribute baseType that identifies the main type it is derived from. This allows applications that do not know anything about the instance type to revert to some default behaviour.

Sub elements

annotation

Description

SpatialObjectType

Syntax

 <complexType name="SpatialObjectType" mixed="false" abstract="false"> 
   <complexContent> 
     <extension base="ObjectType"> 
       <sequence minOccurs="1" maxOccurs="1"> 
         <element name="pose" type="PoseType" minOccurs="0" maxOccurs="1" nillable="false"/> 
         <element name="representation" type="RepresentationType" minOccurs="0" nillable="false" abstract="false"/> 
       </sequence>
     </extension>
   </complexContent>
 </complexType>

Description

Any object that represents something at a location. It includes a pose and a geometric representation. Abstract objects at a location simply have no representation.

Sub elements

pose

Description

representation

Description

SpatialContainerType

Syntax

 <complexType name="SpatialContainerType" mixed="false" abstract="false"> 
   <complexContent> 
     <extension base="SpatialObjectType"> 
       <sequence minOccurs="1" maxOccurs="1"> 
         <element name="children" minOccurs="0" maxOccurs="1" nillable="false"> 
           <complexType mixed="false" abstract="false"> 
             <sequence minOccurs="0" maxOccurs="unbounded"> 
               <element ref="Object" minOccurs="1" maxOccurs="1" nillable="false"/> 
             </sequence>
           </complexType>
         </element>
       </sequence>
     </extension>
   </complexContent>
 </complexType>

Description

An object that is also a container of other spatial objects. It adds a children element to the general SpatialObject. The childrens pose is interpreted relative to the SpatialContainerType parent object. This allows us to build the ususal hierarchical spatial models.So far this is the only concept that we codify in our ontology. We also use the hierarchical structure of the XML format to express the relationship of containment implicitly.
Does this make sense ? The hierarchical structure gives one relationship that we can implicitly define. Should this be the containment relationship ?

Sub elements

children

Description

This subelement stores the list of children of the container type node. It allows all elements in the same substitution group as Object.

Global Elements

Object

Syntax

 <element name="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="ObjectType"> 
         <attribute name="baseType" type="xs:NCName" fixed="ObjectType" use="optional"> 
         </attribute>
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

baseType
The baseType attribute allows to describe the type of the element/object. Because we do not have to specifiy the actual content type in the XML file, we add it here. This should allow applications to deal with unknown elements by defaulting to the subset of fixed default content types.

Description

This element describes any object. It can be used everywhere

SpatialObject

Syntax

 <element name="SpatialObject" substitutionGroup="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="SpatialObjectType"> 
         <attribute name="baseType" type="xs:NCName" fixed="SpatialObjectType" use="optional"/> 
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

baseType

Description

This element describes a spatially located object with or without a spatial representation

SpatialContainer

Syntax

 <element name="SpatialContainer" substitutionGroup="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="SpatialContainerType"> 
         <attribute name="baseType" type="xs:NCName" fixed="SpatialContainerType" use="optional"/> 
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

baseType

Description

This element describes a spatially located object that contains other objects. If these are spatial objects their location is relative to this object.

Building

Syntax

 <element name="Building" substitutionGroup="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="SpatialContainerType"> 
         <attribute name="baseType" type="xs:NCName" fixed="SpatialContainerType" use="optional"/> 
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

baseType

Description

A building in the BAUML part of the format. Note that the Building element is derived from SpatialContainerType and exports this fact in the fixed baseType attribute. This allows applications that do not know about Buildings to fall back on a default behaviour for SpatialContainerType objects.
Together with Markus Jobst, we identified that entry and exit points of buildings are an interesting feature to describe. These typically relate to addresses in existing data sets. Should we model these with a fixed sub element or rather as general children objects of a building ?

Room

Syntax

 <element name="Room" substitutionGroup="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="SpatialContainerType"> 
         <sequence minOccurs="1" maxOccurs="1"> 
           <element name="portals" minOccurs="0" maxOccurs="1" nillable="false"> 
             <complexType mixed="false" abstract="false"> 
               <sequence minOccurs="1" maxOccurs="1"> 
                 <element name="Portal" maxOccurs="unbounded" minOccurs="1" nillable="false"> 
                   <complexType mixed="false" abstract="false"> 
                     <attribute name="room" type="xs:string" use="required"> 
                     </attribute>
                     <attribute name="polygon" type="xs:string" use="required"> 
                     </attribute>
                     <attribute name="polygonnb" type="xs:string" use="optional"> 
                     </attribute>
                   </complexType>
                 </element>
               </sequence>
             </complexType>
           </element>
         </sequence>
         <attribute name="baseType" type="xs:NCName" fixed="SpatialContainerType"/> 
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

baseType

Description

A room in the BAUML part of the format. It is also a SpatialContainerType and in addition to that also specifies portals. These are special polygons that are connected to other polygons in other rooms. The portals are specified in a special Portal child element and reference polygons of the representation by name.

Sub elements

portals

Description

This element lists the portals of the room.

Portal

Attributes

room
the id of the target room.
polygon
the name of the polygon in this room.
polygonnb
The name of the target polygon in the target room. This is not required.

Description

A portal defines directed link to another room (and a portal therein).

ARToolkitMarker

Syntax

 <element name="ARToolkitMarker" substitutionGroup="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="SpatialObjectType"> 
         <attribute name="number" type="xs:integer" use="required"/> 
         <attribute name="baseType" type="xs:NCName" fixed="SpatialObjectType"/> 
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

number
baseType

Description

A marker is a spatial object. Its representation defines the four corners of a rectangular maker. It must contain 3 or 4 vertices in this order: top-left, top-right, bottom-left, and optional: bottom-right.
This is only a first kind of tracking reference object. We probably want to define a whole set of such object types, structured somehow ? Or simply have a super type to allow some kind of default semantics across all kinds of tracking references.

Waypoint

Syntax

 <element name="Waypoint" substitutionGroup="Object" nillable="false" abstract="false"> 
   <complexType mixed="false" abstract="false"> 
     <complexContent> 
       <extension base="SpatialObjectType"> 
         <sequence minOccurs="1" maxOccurs="1"> 
           <element name="neighbors" minOccurs="0" maxOccurs="1" nillable="false"> 
             <complexType mixed="false" abstract="false"> 
               <attribute name="neighbors" type="xs:string" use="required"> 
               </attribute>
             </complexType>
           </element>
         </sequence>
         <attribute name="baseType" type="xs:NCName" fixed="SpatialObjectType"/> 
       </extension>
     </complexContent>
   </complexType>
 </element>

Attributes

baseType

Description

A waypoint is a node in a street skeleton graph for outdoor navigation. It has a pose and probably an empty representation. In addition it adds links to all its neighbor nodes to build a navigation graph.

Sub elements

neighbors

Attributes

neighbors
This attribute stores a list of ids of the neighbor waypoints.
This should probably be restricted to a list of NCNames

Description

This element stores references to all neighbor waypoints.
Is it ok to define this relation this way ? Or should we rather have an explicit element to do that ? It would avoid having the neighborhood relation stored in two places. On the other hand this allows a directed version of the graph.

Comments

some type definitions for attributes

complex types for actual element declarations. we use these types to document the derivation hierarchy of elements and the objects they represent.

the following types define base types for parts of objects.

The following types represent the actual object hierarchy, describing the ontology of our format

the declarations of actual elements used. these define the names and more detailed content models depending on the types defined in above section