OWL-based location ontology for context-aware services Thibaud Flury, Gilles Privat, Fano Ramparany France Telecom, R&D Division Technologies/ONE/Grenoble [
[email protected]]
appliances…). It has proved to be a never-ending, thankless endeavour…
ABSTRACT Diverse location-sensing technologies must be integrated to meet the requirements of generalized location-awareness in ubiquitous computing environments. A formal and comprehensive ontology based modelling of location makes it possible to derive and integrate consistent high-level location information from sparse, heterogeneous location data. Defined this way, location information may provide a contextual common denominator for the semantic modelling of services in a service-oriented architecture.
To escape this modelling dead-end, the physical grounding inherent in context information, as used in ubiquitous computing, provides a natural common denominator. Physical context information, among which location is prominent, is potentially shared between the widest variety of devices, making it possible to both circumscribe the scope and raise the level of generality of the corresponding semantic modelling. Whereas regular software service or device ontologies are necessarily domain-specific, ontologies describing the generic concepts of physical context information, such as location, are potentially shared among a large spectrum of services that may take this physical context information into account for optimally adapting to it. For this, specific service features relevant to concepts defined in domain-specific ontologies have to be mapped, cross-referenced and integrated with more generic location information based on the proposed generic ontology. Our view is that this mapping is best addressed at the most general level of relevant ontologies, by drawing inferences based on generic rules attached to these ontologies.
Keywords Location-based services, context-awareness, ontology, semantic modelling, service-oriented architecture
INTRODUCTION Beyond its established use in run-of-the-mill location-based services for mobile telecommunications, location provides the primary source of context data for ubiquitous computing environments. This expanded use of location information sets stronger requirements on the integration of location data, making it necessary to define it in a much more general and formal way than has been done so far.
This paper attempts to define this semantic “common ground” of location information for device-based services encountered in ubiquitous computing environments.
A flurry of interest around the semantic web [1] and semantic web services [2] has made it superfluous to advocate the relevance of semantic modelling and ontology-based languages. This interest arose from the original Web when machine-based (rather than human-centered) understanding of information was addressed. It has since spread into the realm of service-oriented-architectures [3] (SOA), to address similar concerns with networked services having to “understand” what other services may provide before they are able to work together, if not preconfigured to do so.
We first define a review of the common location models then proceed to show how they can be formally defined within the framework of ontology languages and applied to the integrated management of heterogeneous location information, to be used by various location-aware applications.
ABSTRACTING AND INTEGRATING LOCATION INFORMATION
The SOA paradigm has already made inroads into the domain of ubiquitous computing, being applied to the inter-operation of networked devices .
Location-determination solutions are numerous and highly heterogeneous [5][6]. They may use measurements from such physical modalities as sound, visible light, radio frequencies, or acceleration. They may retain the raw data provided by physical sensors as an all-or-nothing detection, or apply such numeric estimation techniques as multi-lateration or scene analysis with temporal particle filtering [7].
Whether hardware devices or purely software services are addressed, ontology -based modelling is best used when circumscribed within simple and neatly bounded universes of discourse, which may limit its practical applicability. Early serviceadvertisement&discovery architectures, such as UPnP or Salutation[4] have tackled the apparently mundane task of pre-defining, at a level that cannot even begin to be called semantic, all potential features of any computer peripheral (not mentioning consumer
Our approach is to categorize these solutions based on some abstract mathematical model of space according to which they do, implicitly or explicitly, define the location information that they provide as an output.
1
Model integration for location management
This level of abstraction makes it possible to uncover common denominator aspects between various location-sensing technologies, but also between the needs of various location-based applications
The neat separation described between these different models is for the sake of this introductory explanation. In all actual cases, location information relevant to these models is tightly interwoven, creating a complex web of location information where the graphbased model is actually a meta-model : all location information may, at the end of the day, be defined a relation between “location entities”.
Location models We draw a bottom-line distinction between four basic models of space [8].
Relations attached to the set-based model may correspond to a hierarchy of inclusion between sets.
Geometric models The first category is based on affine or affine-euclidean geometry and defines location by way of coordinates, usually chosen as orthogonal (a.k.a. cartesian) coordinates relative to a given Coordinate Reference System. Technologies such as multi-lateration or scene analy sis will usually provide their output according to such a model.
A graph-based model may also be attached to the affine Euclidean model Transformations from one CRS to another may be attached to this model, defining a set of relations where one CRS may conventionally be considered “absolute” and the other “relative” when the corresponding graph is a tree with the “absolute” CRS at its root.
Set-theoretic models
Conversely, metric or geometric location information may be attached to a location network, corresponding to another mapping between the graph-based model and a metric or affine-euclidean space.
In this model, location is boiled down to a mere notion of an element (entity to be located) being a member of a set (entity with reference to which location is defined), without any metric information attached. Technologies based on proximity detection (such as RFID) or the simplest technologies based on cellular mobile networks (such as cell-ID) may be defined as such. Operations such as union, intersection or complement may be used to define reference location sets with respect to one another.
The process of abstracting raw location measurements into either of these separate models is thus only the first stage of a comprehensive location management policy. A complete location management system should be able to match and maintain up-to-date relations between separate pieces of location information pertaining to these different models in a given environment. This comprehensive location information will be the result of aggregating location information from several technologies, possibly corresponding to different models of space, to make it available to location-aware applications that may also provide queries and expect responses relevant to different models of space.
Graph-based models In generic graph-based models, any relation between entities may be construed as relevant to some more or less abstract concept of « location ». This does include all well-known cases of location relative to physically-grounded networks such as telecom networks (be they infrastructure-based or ad hoc networks), road networks, water-pipe networks, or any relation of physical proximity abstracted from its metric dimension. This may also correspond to more abstract networks such as virtual networks overlaid on physical networks, social networks, graphs describing possible routes within a building, etc.
DEFINING A BASIC LOCATION ONTOLOGY We map here the models defined above informally to the metamodel and classes of a formal ontology .
An ad hoc location system detecting exclusively relative connectivity or proximity between located entities, without any quantitative information attached, could provide its output as defining edges in a relative location graph.
Geometric model The geometric model is based upon three elementary co ncepts ( Figure 1):
Semantic models
Shapes are 2D or 3D manifolds defining geometrically the physical locus, by way of a contour, of something that may be either a located object (e.g. a PDA) or an entity with regard to which other objects are located
In this model, location concepts are defined relatively to a given universe of discourse such as architecture, physical geography, political geography, city planning, etc. The perspective is to link a mathematical definition of position (as in the geometric, the set or the structural model) to a more human friendly notion of place as in [9]. And the goal is to automate the process with an explicit definition of the semantics for the computers to understand it in an ubiquitous environment.
Coordinate Reference Systems are used to define these shapes in a relative fashion. As already mentioned, a CRS is defined relative to another CRS and ultimately by reference to a primary, supposedly “well-known” CRS, by way of a chain of transitive Geometric Transformations. The “ultimate” reference CRS may be a projection-based Cartesian CRS (such as the Lambert System used in France) or an oblate spheroidal geodetic coordinate system such as used with the WGS84 system.
Examples of these semantic concepts are given in Figure 5.
2
Properties of concepts (classes) in the ontology are basically defined by relations (such as the subsumption relation) corresponding to a meta-meta level. At a slightly less general level, all location information is defined by relations between “location entities”, corresponding to a metalevel of relations (e.g. the relation “isMemberOf” between an element and a set, or the relations defined between coordinate reference systems by way of geometrical transformations or their matrices.
Ontology diagram legend
Finally, specific relations such as proximity or connectivity define their own concepts of “structural location”. The meta concept for these are defined by the classes GraphEdge and Node of the structural location model in our location ontology (Figure 2). These defines what we call the structural location model. Sub-concepts may be derived from this by specialization according to the nature of the graph (e.g. a graph defining possible passages between rooms in a building), or to specify a directed or nondirected graph (in which case generic graph edges are specialize into arcs or non-directed edges.
Figure 1 : Basic concepts of geometrical location ontology, with example instances
Set-based model The set-theoretic model is quite naturally based upon the two key concepts of Set and Element, and is, for all practical purposes (foregoing theoretical technicalities) drawn directly from mathematical Set Theory . An Element can be inside particular Sets, and a Set may contain any number of Elements. Two other concepts are linked to these primary ones, the Set-based Operation can define a Set by an operation (union, intersection, complement and such) combining existing ones. The Set-based relation can be used to define the relation between two particular sets (a set could contain another one; they could be disjoint or have a not null intersection).
. Figure 2 : Basic concepts of graph-based location ontologies, with example instances
Semantic models At this level; location concepts may no longer be derived from generic ontologies and have to be defined in a domain specific way, such as the knowledge base for geographic location information defined in [10].
Graph-based/structural location models
Two meta-concepts are nonetheless defined: those of LocatedEntity and ReferentElement, respectively. A generic location concept (a defined above at the meta level) may correspond to a LocationRelation between two instances or two subclasses of these.
As mentioned before, this model is used at three different levels, between which the distinction has to be made clear :
3
on the environment with a meaning that the context management service and any client can agree with.
Figure 3 : Basic concepts of Semantic model, with example instances
RELATIONS BETWEEN MODELS AND ONTOLOGY INTEGRATION By trying to define the semantic model, it appears that all other models can be structured in a hierarchical fashion with this model at the top. The semantic model will provide the basis for an interpretation and specialization of all generic concepts defined in other models. Thus a basic location set will become a room by incorporating concepts from the architecture semantic model, or a CRS may become a geographical projection coordinate system by incorporating concepts from physical geography.
FORMAL ONTOLOGY SPECIFICATION As our discussion above suggests, location information is quite complex in terms of the number of concepts it requires to be correctly described, in terms of heterogeneity of domains these concepts belong to and in terms of interrelationship among these concepts. Expressive modelling languages such as frame-based knowledge representations, logic-based representations or semantic networks, are one step towards managing this complexity. Identifying and modelling the appropriate ontologies as a foundation for expressing localisation information is a further step along the same direction. We have used the OWL [12] language, recently adopted by W3C as a standard for the semantic Web and semantic Web Services. Historically this language has resulted from an evolution DAML+OIL ontology language[11], this one already extending RDF and RDF Schema with richer primitives. OWL overruns these languages in its ability to represent machine interpretable content on the Web in an easier way. It builds upon XML by using the XML syntax as a possible serialization. In this first version we've mainly focused on the modelling of indoor spaces, and more specifically office buildings. Components of our indoor office building model include concepts such as corridors, rooms, floors, buildings, staircases, elevators. The room concept has been specialized into sub concepts office, meeting room and conference room.
Figure 4 : Example serialization of geometrical concepts using OWL
Example of specialized ontology Very general concepts are not useable directly, they should be specialized according to fields for which location information is relevant. It is essential to particularize the top level ontology into sub-domains like urbanism, architecture, political geography, and so forth. In our case of indoor location, architectural division of space seems to be relevant. The set-based division of an indoor space is related to architectural design. The architectural map is constituted of a set of 2D projections corresponding to each floor of the building. On these projections are drawn the walls and the door, space is naturally divided into rooms and corridors. The doors on these map indicate the interconnections between these elements. This very first study can put into concrete form a specialization of the location ontology. At the geometric level, space is described for each floor by a proper 2D rectangular coordinate reference system and a set of simple polygons. These are the specialization of the
Instantiating these ontologies enables a structured representation of location information, with a clear commitment about its semantics. This is necessary for client applications to get a perspective
4
generic coordinate reference system and the geometrical abstraction of shape. These 2D reference systems are the result of the projection of 3D reference system related to the building, this is a specialization of the Affine Euclidean transformation.
underlying semantics, they can use the location service in the most effective way..
Implicit context information The information that can be inferred is far broader than that explicitly stored. Deriving this information and storing it explicitly could reveal an efficient strategy as far as the time for retrieving this information is concerned, but will lead to consistency and overloading problems as more and more information will be stored. It is especially valid when it comes to location information, whose can be huge.
Polygons describing rooms and corridors are also a specialisation of the set concept. These sets are mutually exclusive and the result is that a floor can be defined as the union of all rooms and corridors within it. More complex rooms (that cannot be described using a simple polygon) can also be described using constructive area geometry with set based operations. The building itself can also be described as the union of all the floors. Inference rules can be used to deduce set based relations like non-void intersection, containment or disjunction, a room might be inside the building but not inside a particular floor.
(inside car1 parking1) (inside suitcase1 car1) (inside ?object parking1)
The architect map can also be used to infer some structural relations of space. Each rooms and corridors can be interpreted as nodes of a graph modelling their adjacency, when two of these elements are only separated by a wall (or when two sides of polygons have a part in common) the element are linked by an edge. The drawing of the doors can be used to model route between rooms and corridors.
?object : {…., suitcase1,….} if (inside ?object1 ?object2) and (inside ?object2 ?object3) we can derive from these two propositions that (inside ?object1 ?object3)
Context information completion Context information is incomplete. We usually use as many sensors as we need, but there are some cases where we need more sensors than are actually available. For example, some might be out of order or used by another application. There is also the case where there simply isn't any sensor available from which you can directly draw the context information you actually need. For example if the only location sensor you've got in a room is a weightsensitive pad located at its doorstep, and we've been notified the event that somebody weighting less than 30 kgs has entered the room. We might infer that a child is probably inside the room, although there aren't any indisputable evidence that the person is a child. We've simply drawn this inference from the fact that children usually weigh less than 40 kgs.
At the semantic level, the sets (currently rooms and corridors) may gain some sense, rooms may be office, meeting rooms or other points of interest like toilets using the symbols on the map. The rooms might also have a name, office rooms might have an owner. From the very simple architect map, an entire taxonomy of indoor space can be formalized in this way.
MODELLING OF RULES AND INFERENCES Adding reasoning capabilities for enabling inference goes one step beyond the mere definition of taxonomies. By reasoning we refer to the ability to dynamically chain a sequence of inference steps that build intermediary results from existing information, which at the end of the day results into relevant new information. There are several reasons why we might need such functionality, and we now elaborate on these points.
Bridging of ontologies Ontology representation languages provide only limited reasoning mechanisms. These mechanisms might reveal insufficient for answering queries across different domains. Here is an example where we need more than standard Ontology concept subsumption mechanism to answer a query: suppose that we know that printer LP150 is located at Cartesian coordinates (x=5, y=5), and that office B215 has a rectangle shape which corner points have coordinates (x=0, y=0), (x=0, y=10), (x=10, y=0), (x=10, y=10) in the same cartesion reference system. Clearly printer LP150 is right in the middle of room B215. This information can be derived using geometrical reasoning.
Needs for reasoning and inference rules Using these logical inference mechanisms to reason on the data is the most useful aspect of the advocated semantic modelling of location information. The primary goal of our study is to create a software system to manage location information. The ontology serves only as a repository for a knowledge base of location information. With inference rules and reasoning capability, the location service can automate some essential processes to reuse the information. It can collect the raw data from heterogeneous sensing technologies, interpret the corresponding location information, check it or aggregate it with other sources of information. A location management system can also use the reasoning capacities to answer to the needs of client applications, it can understand and respond to location requests, and generate events depending on specific complex conditions. In fact, location sensing technologies and client applications each have their own personal, often implicit, representations of space. If they can expose and share the
Context aggregation Aggregation is somewhat similar to completion with the difference that the inference is sound. Indeed, we get context information from disparate sensors measurements. We might be interested in information that can be jointly built upon two or more sensors rather than in information drawn from each sensor individually. For example, if we've been noticed by an identification sensor such
5
as an RFID tag reader that John has entered the room B215 and a vision based detection and tracking sensor locate that a person is sitting at a table in this room, we can conclude that John is sitting at the table in room B215.
CONCLUSION We are currently in the process of implementing a location management system based on these concepts of integrating joint models of space. It will be part of a service-oriented architecture for managing services provided by various devices in an indoor environment, to enable semantic composition and adaptation of these services to location-related information. The semantic modelling described here will be implemented in a separate layer to provide context -adaptive service composition capabilities.
While we've reviewed the situations where we might need to reason about context, we now analyze the mechanisms needed to perform the reasoning. This will help us identify which reasoning or inference engine we could use for implementing our location context management system.
REFERENCES
When reviewing the types of queries the localisation context management services has to fulfil, we roughly identify two types of queries:
[1] Tim Berners-Lee, James Hendler, Ora Lassila. “The Semantic Web”. Scientific American. 17 mai 2001 [2] KnowledgeWeb NoE, http://knowledgeweb.semanticweb.org [3] M.P. Papazoglou, D. Georgakopoulos, “Service-Oriented Computing”, Communications of the ACM, October 2003 [4] G Richard “Service advertisement and discovery, enabling universal device cooperation” IEEE Internet Computing, September-October 2000 [5] Jeffrey Hightower, Gaetano Borriello, “Location Sy stems for Ubiquitous Computing” , IEEE Computer, August 2001 [6] Mike Hazas, James Scott, John Krumm, “Location-Aware Computing comes to Age” , IEEE Computer, February 2004 [7] Gilles Privat, Thibaud Flury et al. Position-Based Interaction for Indoor Ambient Intelligence Environments. Proceedings of EUSAI 2003. 3-4 novembre 2003, Eindhoven Pays-Bas. [8] Gilles Privat, Thibaud Flury.” An infrastructure template for scalable location-based services”. Proceedings of SOC 2003, p214217. 15-17 mai 2003, Grenoble France. [9] Jeffrey Hightower. “From Position to Place”. Proceedings of the Workshop on Location Aware Computing (Ubicomp 2003), October 2003, Seattle, USA. [10] Dimitar Manov, Atanas Kiryakov, Kalina Bontcheva et al. «”Experiments with geographic knowledge for information extraction”. Proceedings of the Workshop on the Analysis of Geographic References (HLT-NAACL 2003). May -June 2003. [11] DAML+OIL (March 2001) Reference Description. [12] http://www.w3.org/TR/owl-ref, OWL (February 2004) Reference Description.
Queries inquiring about the truth of some properties. Exa mples are: "Is there a printer in room H250?", "Is printer X340 in building C?" Queries expecting an object to be returned. Examples are: "Where is John?", "Which room is printer X340?", "Which building is printer X340?" "Which (x,y,z) position is printer X340?", "Which printer is the closest to position (x=300, y=200, z=400)?", "Which rooms have a printer?", "Which printer is in room H250?", "Which rooms have both a printer and a telephone?" Handling such types of queries can be efficiently supported by a theorem prover or backward reasoning strategy. More specifically, a theorem prover organizes the control of the reasoning process this way: In trying to establish the truth of a property, it looks into the knowledge at hand, whether this property is explicitly there or not. If it is there, the property is true. If not, it attempts to derive it from knowledge at hand using a basic inference step. Eventually, if a promising inference step requires a property not explicitly stored, it tries to establish its truth (this is a recursive process).
6
Figure 5 : Semantic location concepts with domain-specific derivations
Figure 6 : Full example with relations between different models
7
