Modelling Location
The data generated by positioning systems generally falls into one of two categories: physical, and symbolic. Physical positions, such as GPS coordinates, take the form of a 2D or 3D numeric array:
e.g., [12.30, 13.56, 0.12]
while symbolic positions describe locations using names designed for human interpretation:
e.g., “office”, “Dublin”, or “kitchen”
Frequently, symbolic names are organised into a hierarchy, representing containment relations at different levels of granularity:
e.g., (country > city > region > building > floor > room)
In addition to the data provided by positioning systems, it is common to describe a position relative to another:
e.g., 10 kilometers north of Glasgow
e.g., within 6 metres of Alice’s office
Ontonym’s location ontology is an implementation of Juan Ye et al.’s work that captures each of these three types of representation in a unified model. For details, see Juan Ye et al. “A Unified Semantics Space Model“, Location- and Context-Awareness, Third International Symposium, LoCA 2007, LNCS vol. 4718, Springer, pp. 103-120.
In our implementation, Spaces are represented using the SymbolicRepresentation, GeometricRegion, and RelativeLocation ontology classes.
The SimpleRegion subclass of GeometricRegion defines a number of subclasses for 2D and 3D shapes (Circle, Rectangle, Triangle, Polygon, LineSegment, Sphere, and Cuboid). The boundary of each shape is defined by a list of coordinates. Another subclass of GeometricRegion, CompositeRegion, supports the definition of complex shapes using a combination of simpler parts.
A location may be represented as a combination of the above types. For example, consider a representation of Bob’s office which is both symbolic and geometric:
map:bobsCubicle
a location:Cuboid,
location:SymbolicRepresentation ;
rdfs:label "Bob's Cubicle" ;
location:granularity map:cubicle .
location:coordinate
(
[ a location:Coordinate ;
location:x "3.65"^^xsd:double ;
location:y "0.0"^^xsd:double ;
location:z "0.0"^^xsd:double ;
location:coordinateSystem :ubisenseCoorSystem
]
[ a location:Coordinate ;
location:x "6.44"^^xsd:double ;
location:y "5.34"^^xsd:double ;
location:z "2.7"^^xsd:double ;
location:coordinateSystem :ubisenseCoorSystem
]
) .
RelativeLocation has two subclasses, CompassLocation, which uses angle and distance to describe a coordinate relative to a base location, and CentredLocation, which describes a geometric region around a point. A typical use of a CentredLocation is to describe the coverage of a sensor. For example, a bluetooth sensor that has a radial coverage of 10 metres:
map:coverageOfBluetoothSensor
a location:CentredLocation ;
location:radius "10"^^xsd:double ;
location:baseLocation
[ a location:Coordinate ;
location:x "23.65"^^xsd:double ;
location:y "14.10"^^xsd:double ;
location:z "0.67"^^xsd:double ;
location:coordinateSystem :ubisenseCoorSystem
] .
Ontonym defines four types of spatial relationship: containment, adjacency, overlap, and connectedness. The first three are as per their suggested meaning, while connectedness is a particular case of adjacency, where it is possible to pass from one space to its adjacent space. For example, we might update the description of Bob’s cubicle to specify its relationship with other spaces:
map:bobsCubicle
a location:GeometricRegion,
location:SymbolicRepresentation ;
rdfs:label "Bob's Cubicle" ;
location:granularity map:cubicle .
location:adjacent map:alicesCubicle, map:corridor3f ;
location:connectedTo map:corridor3f ;
location:containedBy map:researchCubicles ;
location:contains map:bobsDesk ;
location:coordinate
(
[ a location:Coordinate ;
location:x "3.65"^^xsd:double ;
location:y "0.0"^^xsd:double ;
location:z "0.0"^^xsd:double ;
location:coordinateSystem :ubisenseCoorSystem
]
[ a location:Coordinate ;
location:x "6.44"^^xsd:double ;
location:y "5.34"^^xsd:double ;
location:z "2.7"^^xsd:double ;
location:coordinateSystem :ubisenseCoorSystem
]
) .
The examples above show Coordinates defined with reference to a particular coordinate reference system. Each coordinate system description specifies a unit measurement of distance, and may also identify its origin with reference to another coordinate system in the model. This is done using a combination of a coordinate (denoting the point of origin), and a rotation matrix, which defines the rotation of axes between the two coordinate systems. Although these details may be omitted from the model, they do allow software to translate between different representations where a mapping between coordinate systems exists.
As a somewhat trivial example, consider a coordinate system defined in relation to itself (i.e., an origin of [0, 0, 0] and whose rotation matrix is the identity matrix)
:ubisenseCoorSystem a location:CoordinateSystem ;
rdfs:comment "A coordinate system based on CASL Ubisense."@en ;
location:origin
[ a location:Coordinate
location:coordinateSystem :ubisenseCoorSystem ;
location:x "0"^^xsd:double ;
location:y "0"^^xsd:double ;
location:z "0"^^xsd:double
] ;
location:referenceCoordinateSystem :ubisenseCoorSystem ;
location:rotationMatrix
[ a location:RotationMatrix ;
location:xAxis
[ a location:Coordinate ;
location:coordinateSystem :ubisenseCoorSystem ;
location:x "1"^^xsd:double ;
location:y "0"^^xsd:double ;
location:z "0"^^xsd:double
] ;
location:yAxis
[ a location:Coordinate ;
location:coordinateSystem :ubisenseCoorSystem ;
location:x "0"^^xsd:double ;
location:y "1"^^xsd:double ;
location:z "0"^^xsd:double
] ;
location:zAxis
[ a location:Coordinate ;
location:coordinateSystem :ubisenseCoorSystem ;
location:x "0"^^xsd:double ;
location:y "0"^^xsd:double ;
location:z "1"^^xsd:double
] ;
location:unitDistance
[ a muo:QualityValue ;
muo:measuredIn ucum:meter ;
muo:numericalValue "1"
]
It can be seen that specifying a complete model of location for a given area can be a time consuming process. We are currently investigating techniques to reduce the workload of mappers in this regard.
No Comments Yet