OWL-based location ontology for context-aware services

Document Sample
OWL-based location ontology for context-aware services Powered By Docstoc
					  OWL-based location ontology for context-aware services
                                      Thibaud Flury, Gilles Privat, Fano Ramparany
                                                   France Telecom, R&D Division

                                                                             appliances…). It has proved to be a never-ending, thankless en-
Diverse location-sensing technologies must be integrated to meet
the requirements of generalized location-awareness in ubiquitous             To escape this modelling dead-end, the physical grounding inherent
computing environments. A formal and comprehensive ontology -                in context information, as used in ubiquitous computing, provides
based modelling of location makes it possible to derive and inte-            a natural common denominator. Physical context information,
grate consistent high-level location information from sparse, het-           among which location is prominent, is potentially shared between
erogeneous location data. Defined this way, location information             the widest variety of devices, making it possible to both circum-
may provide a contextual common denominator for the semantic                 scribe the scope and raise the level of generality of the correspond-
modelling of services in a service-oriented architecture.                    ing semantic modelling. Whereas regular software service or device
                                                                             ontologies are necessarily domain-specific, ontologies describing
                                                                             the generic concepts of physical context information, such as loca-
Location-based services, context-awareness, ontology, semantic               tion, are potentially shared among a large spectrum of services that
modelling, service-oriented architecture                                     may take this physical context information into account for opti-
                                                                             mally adapting to it. For this, specific service features relevant to
                                                                             concepts defined in domain-specific ontologies have to be mapped,
Beyond its established use in run-of-the-mill location-based ser-
                                                                             cross-referenced and integrated with more generic location informa-
vices for mobile telecommunications, location provides the pri-
                                                                             tion based on the proposed generic ontology. Our view is that this
mary source of context data for ubiquitous computing environ-
                                                                             mapping is best addressed at the most general level of relevant
ments. This expanded use of location information sets stronger
                                                                             ontologies, by drawing inferences based on generic rules attached
requirements on the integration of location data, making it neces-
                                                                             to these ontologies.
sary 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 ubiq-
A flurry of interest around the semantic web [1] and semantic web
                                                                             uitous computing environments.
services [2] has made it superfluous to advocate the relevance of
semantic modelling and ontology-based languages. This interest               We first define a review of the common location models then pro-
arose from the original Web when machine-based (rather than hu-              ceed to show how they can be formally defined within the frame-
man-centered) understanding of information was addressed. It has             work of ontology languages and applied to the integrated manage-
since spread into the realm of service-oriented-architectures [3]            ment of heterogeneous location information, to be used by various
(SOA), to address similar concerns with networked services having            location-aware applications.
to “understand” what other services may provide before they are
                                                                             ABSTRACTING AND INTEGRATING LOCATION
able to work together, if not preconfigured to do so.
The SOA paradigm has already made inroads into the domain of                 Location-determination solutions are numerous and highly hetero-
ubiquitous computing, being applied to the inter-operation of net-           geneous [5][6]. They may use measurements from such physical
worked devices .                                                             modalities as sound, visible light, radio frequencies, or acceleration.
Whether hardware devices or purely software services are a          d-       They may retain the raw data provided by physical sensors as an
dressed, ontology -based modelling is best used when circumscribed           all-or-nothing detection, or apply such numeric estimation tech-
within simple and neatly bounded universes of discourse, which               niques as multi-lateration or scene analysis with temporal particle
may limit its practical applicability. Early service-                        filtering [7].
advertisement&discovery architectures, such as UPnP or Saluta-               Our approach is to categorize these solutions based on some ab-
tion[4] have tackled the apparently mundane task of pre-defining,            stract mathematical model of space according to which they do,
at a level that cannot even begin to be called semantic, all potential       implicitly or explicitly, define the location information that they
features of any computer peripheral (not mentioning consumer                 provide as an output.

This level of abstraction makes it possible to uncover common               Model integration for location management
denominator aspects between various location-sensing technolo-              The neat separation described between these different models is
gies, but also between the needs of various location-based applica-         for the sake of this introductory explanation. In all actual cases,
tions                                                                       location information relevant to these models is tightly interwoven,
                                                                            creating a complex web of location information where the graph-
Location models                                                             based model is actually a meta-model : all location information
We draw a bottom-line distinction between four basic models of              may, at the end of the day, be defined a relation between “location
space [8].                                                                  entities”.

Geometric models                                                            Relations attached to the set-based model may correspond to a
The first category is based on affine or affine-euclidean geometry          hierarchy of inclusion between sets.
and defines location by way of coordinates, usually chosen as               A graph-based model may also be attached to the affine Euclidean
orthogonal (a.k.a. cartesian) coordinates relative to a given Coordi-       model Transformations from one CRS to another may be attached
nate Reference System. Technologies such as multi-lateration or             to this model, defining a set of relations where one CRS may con-
scene analy sis will usually provide their output according to such a       ventionally be considered “absolute” and the other “relative” when
model.                                                                      the corresponding graph is a tree with the “absolute” CRS at its
Set-theoretic models
                                                                            Conversely, metric or geometric location information may be at-
In this model, location is boiled down to a mere notion of an ele-
                                                                            tached to a location network, corresponding to another mapping
ment (entity to be located) being a member of a set (entity with
                                                                            between the graph-based model and a metric or affine-euclidean
reference to which location is defined), without any metric infor-
mation 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               The process of abstracting raw location measurements into either
such as union, intersection or complement may be used to define             of these separate models is thus only the first stage of a compre-
reference location sets with respect to one another.                        hensive location management policy. A complete location man-
                                                                            agement system should be able to match and maintain up-to-date
Graph-based models                                                          relations between separate pieces of location information pertain-
In generic graph-based models, any relation between entities may            ing to these different models in a given environment. This compre-
be construed as relevant to some more or less abstract concept of           hensive location information will be the result of aggregating loca-
« location ». This does include all well-known cases of location            tion information from several technologies, possibly corresponding
relative to physically-grounded networks such as telecom net-               to different models of space, to make it available to location-aware
works (be they infrastructure-based or ad hoc networks), road               applications that may also provide queries and expect responses
networks, water-pipe networks, or any relation of physical prox-            relevant to different models of space.
imity abstracted from its metric dimension. This may also corre-
spond to more abstract networks such as virtual networks overlaid           DEFINING A BASIC LOCATION ONTOLOGY
on physical networks, social networks, graphs describing possible           We map here the models defined above informally to the meta-
routes within a building, etc.                                              model and classes of a formal ontology .
An ad hoc location system detecting exclusively relative connec-
tivity or proximity between located entities, without any quantita-
                                                                            Geometric model
tive information attached, could provide its output as defining              The geometric model is based upon three elementary co n-
                                                                                                      cepts (
edges in a relative location graph.
                                                                            Figure 1):
Semantic models
                                                                            Shapes are 2D or 3D manifolds defining geometrically the physical
In this model, location concepts are defined relatively to a given
                                                                            locus, by way of a contour, of something that may be either a lo-
universe of discourse such as architecture, physical geography,
                                                                            cated object (e.g. a PDA) or an entity with regard to which other
political geography, city planning, etc.
                                                                            objects are located
The perspective is to link a mathematical definition of position (as
                                                                            Coordinate Reference Systems are used to define these shapes in a
in the geometric, the set or the structural model) to a more human
                                                                            relative fashion. As already mentioned, a CRS is defined relative to
friendly notion of place as in [9]. And the goal is to automate the
                                                                            another CRS and ultimately by reference to a primary, supposedly
process with an explicit definition of the semantics for the com-
                                                                            “well-known” CRS, by way of a chain of transitive Geometric
puters to understand it in an ubiquitous environment.
                                                                            Transformations. The “ultimate” reference CRS may be a projec-
Examples of these semantic concepts are given in                            tion-based Cartesian CRS (such as the Lambert System used in
Figure 5.                                                                   France) or an oblate spheroidal geodetic coordinate system such as
                                                                            used with the WGS84 system.

                                                                            Properties of concepts (classes) in the ontology are basically de-
                                                                            fined by relations (such as the subsumption relation) correspond-
                                                                            ing to a meta-meta level.
                                                                            At a slightly less general level, all location information is defined
                                                                            by relations between “location entities”, corresponding to a meta-
                                                                            level of relations (e.g. the relation “isMemberOf” between an ele-
                    Ontology diagram legend                                 ment and a set, or the relations defined between coordinate refer-
                                                                            ence systems by way of geometrical transformations or their ma-
                                                                            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 struc-
                                                                            tural 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 non-
                                                                            directed 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 mathe-           .
matical Set Theory . An Element can be inside particular Sets, and              Figure 2 : Basic concepts of graph-based location ontologies,
a Set may contain any number of Elements. Two other concepts                                       with example instances
are linked to these primary ones, the Set-based Operation can de-
fine a Set by an operation (union, intersection, complement and
such) combining existing ones. The Set-based relation can be used
                                                                            Semantic models
to define the relation between two particular sets (a set could con-
                                                                            At this level; location concepts may no longer be derived from
tain another one; they could be disjoint or have a not null intersec-
                                                                            generic ontologies and have to be defined in a domain specific way,
                                                                            such as the knowledge base for geographic location information
Graph-based/structural location models                                      defined in [10].
As mentioned before, this model is used at three different levels,          Two meta-concepts are nonetheless defined: those of LocatedEn-
between which the distinction has to be made clear :                        tity and ReferentElement, respectively. A generic location concept
                                                                            (a defined above at the meta level) may correspond to a Location-
                                                                            Relation between two instances or two subclasses of these.

                                                                            on the environment with a meaning that the context management
                                                                            service and any client can agree with.
                                                                            <owl:Class rdf:ID="GeometricalConcept"/>

                                                                              <owl:Class rdf:ID="Shape">

                                                                            <owl:Class rdf:ID="ReferenceSystem ">
                                                                            </owl:Class >

                                                                            <owl:Class rdf:ID="Polygon">
                                                                                <rdfs:subClassOf >
                                                                                  <owl:Class rdf:about="#Shape "/>
 Figure 3 : Basic concepts of Semantic model, with example                      </rdfs:subClassOf>
                                                                            </owl:Class >
                                                                            <owl:Class rdf:ID="Rectangle">
                                                                                <rdfs:subClassOf >
                                                                                  <owl:Class rdf:about="#Shape "/>
RELATIONS BETWEEN MODELS AND ONTOLOGY                                           </rdfs:subClassOf>
INTEGRATION                                                                 </owl:Class >
By trying to define the semantic model, it appears that all other           <owl:Class rdf:ID="Reference2D ">
models can be structured in a hierarchical fashion with this model              <rdfs:subClassOf >
at the top. The semantic model will provide the basis for an inter-               <owl:Class
pretation and specialization of all generic concepts defined in other           </rdfs:subClassOf>
models. Thus a basic location set will become a room by incorpo-            </owl:Class >
rating c oncepts from the architecture semantic model, or a CRS
                                                                            <owl:ObjectProperty rdf:ID="is"/>
may become a geographical projection coordinate system by in-
corporating concepts from physical geography.                               <owl:ObjectProperty rdf:ID="defined_wrt ">
                                                                                <owl:domain rdf:resource="#Shape"/>
FORMAL ONTOLOGY SPECIFICATION                                                   <owl:range
As our discussion above suggests, location information is quite             </owl:ObjectProperty >
complex in terms of the number of concepts it requires to be cor-
rectly described, in terms of heterogeneity of domains these con-           <owl:ObjectProperty rdf:ID="shape_is">
                                                                                <owl:domain rdf:resource="#Room"/>
cepts belong to and in terms of interrelationship among these con-              <owl:range rdf:resource="#Shape"/>
cepts. Expressive modelling languages such as frame-based knowl-            </owl:ObjectProperty >
edge representations, logic-based representations or semantic net-          Figure 4 : Example serialization of geometrical concepts us-
works, are one step towards managing this complexity. Identifying                                    ing OWL
and modelling the appropriate ontologies as a foundation for ex-
pressing localisation information is a further step along the same          Example of specialized ontology
direction. We have used the OWL [12] language, recently adopted             Very general concepts are not useable directly, they should be
by W3C as a standard for the semantic Web and semantic Web                  specialized according to fields for which location information is
Services. Historically this language has resulted from an evolution         relevant. It is essential to particularize the top level ontology into
DAML+OIL ontology language[11], this one already extending                  sub-domains like urbanism, architecture, political geography, and
RDF and RDF Schema with richer primitives. OWL overruns                     so forth. In our case of indoor location, architectural division of
these languages in its ability to represent machine interpretable           space seems to be relevant.
content on the Web in an easier way. It builds upon XML by us-              The set-based division of an indoor space is related to architectural
ing the XML syntax as a possible serialization. In this first version       design. The architectural map is constituted of a set of 2D projec-
we've mainly focused on the modelling of indoor spaces, and more            tions corresponding to each floor of the building. On these projec-
specifically office buildings. Components of our indoor office              tions are drawn the walls and the door, space is naturally divided
building model include concepts such as corridors, rooms, floors,           into rooms and corridors. The doors on these map indicate the
buildings, staircases, elevators. The room concept has been special-        interconnections between these elements.
ized into sub concepts office, meeting room and conference room.
                                                                            This very first study can put into concrete form a specialization of
Instantiating these ontologies enables a structured representation          the location ontology. At the geometric level, space is described for
of location information, with a clear commitment about its seman-           each floor by a proper 2D rectangular coordinate reference system
tics. This is necessary for client applications to get a perspective        and a set of simple polygons. These are the specialization of the

generic coordinate reference system and the geometrical abstraction          underlying semantics, they can use the location service in the most
of shape. These 2D reference systems are the result of the projec-           effective way..
tion of 3D reference system related to the building, this is a spe-
cialization of the Affine Euclidean transformation.                          Implicit context information
                                                                              The information that can be inferred is far broader than that ex-
Polygons describing rooms and corridors are also a specialisation
                                                                             plicitly stored. Deriving this information and storing it explicitly
of the set concept. These sets are mutually exclusive and the result
                                                                             could reveal an efficient strategy as far as the time for retrieving
is that a floor can be defined as the union of all rooms and corridors
                                                                             this information is concerned, but will lead to consistency and
within it. More complex rooms (that cannot be described using a
                                                                             overloading problems as more and more information will be stored.
simple polygon) can also be described using constructive area ge-
                                                                             It is especially valid when it comes to location information, whose
ometry with set based operations. The building itself can also be
                                                                             can be huge.
described as the union of all the floors. Inference rules can be used
to deduce set based relations like non-void intersection, contain-           (inside car1 parking1)
ment or disjunction, a room might be inside the building but not             (inside suitcase1 car1)
inside a particular floor.
                                                                             (inside ?object parking1)
The architect map can also be used to infer some structural rela-
                                                                             ?object : {…., suitcase1,….}
tions of space. Each rooms and corridors can be interpreted as
nodes of a graph modelling their adjacency, when two of these                if (inside ?object1 ?object2) and (inside ?object2 ?object3) we can
elements are only separated by a wall (or when two sides of poly-            derive from these two propositions that (inside ?object1 ?object3)
gons have a part in common) the element are linked by an edge.
The drawing of the doors can be used to model route between
                                                                             Context information completion
                                                                             Context information is incomplete. We usually use as many sen-
rooms and corridors.
                                                                             sors as we need, but there are some cases where we need more
At the semantic level, the sets (currently rooms and corridors) may          sensors than are actually available. For example, some might be out
gain some sense, rooms may be office, meeting rooms or other                 of order or used by another application. There is also the case
points of interest like toilets using the symbols on the map. The            where there simply isn't any sensor available from which you can
rooms might also have a name, office rooms might have an owner.              directly draw the context information you actually need. For ex-
From the very simple architect map, an entire taxonomy of indoor             ample if the only location sensor you've got in a room is a weight-
space can be formalized in this way.                                         sensitive pad located at its doorstep, and we've been notified the
                                                                             event that somebody weighting less than 30 kgs has entered the
MODELLING OF RULES AND INFERENCES                                            room. We might infer that a child is probably inside the room,
Adding reasoning capabilities for enabling inference goes one step           although there aren't any indisputable evidence that the person is a
beyond the mere definition of taxonomies. By reasoning we refer              child. We've simply drawn this inference from the fact that chil-
to the ability to dynamically chain a sequence of inference steps            dren usually weigh less than 40 kgs.
that build intermediary results from existing information, which at
                                                                             Bridging of ontologies
the end of the day results into relevant new information. There are
                                                                             Ontology representation languages provide only limited reasoning
several reasons why we might need such functionality, and we
                                                                             mechanisms. These mechanisms might reveal insufficient for an-
now elaborate on these points.
                                                                             swering queries across different domains. Here is an example where
Needs for reasoning and inference rules                                      we need more than standard Ontology concept subsumption
Using these logical inference mechanisms to reason on the data is            mechanism to answer a query: suppose that we know that printer
the most useful aspect of the advocated semantic modelling of                LP150 is located at Cartesian coordinates (x=5, y=5), and that
location information. The primary goal of our study is to create a           office B215 has a rectangle shape which corner points have coordi-
software system to manage location information. The ontology                 nates (x=0, y=0), (x=0, y=10), (x=10, y=0), (x=10, y=10) in the
serves only as a repository for a knowledge base of location infor-          same cartesion reference system. Clearly printer LP150 is right in
mation. With inference rules and reasoning capability, the location          the middle of room B215. This information can be derived using
service can automate some essential processes to reuse the infor-            geometrical reasoning.
mation. 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 loca-          Context aggregation
tion management system can also use the reasoning capacities to               Aggregation is somewhat similar to completion with the difference
answer to the needs of client applications, it can understand and            that the inference is sound. Indeed, we get context information
respond to location requests, and generate events depending on               from disparate sensors measurements. We might be interested in
specific complex conditions. In fact, location sensing technologies          information that can be jointly built upon two or more sensors
and client applications each have their own personal, often im-              rather than in information drawn from each sensor individually.
plicit, representations of space. If they can expose and share the           For example, if we've been noticed by an identification sensor such

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
                                                                              We are currently in the process of implementing a location man-
sitting at a table in this room, we can conclude that John is sitting
                                                                              agement system based on these concepts of integrating joint mod-
at the table in room B215.
                                                                              els of space. It will be part of a service-oriented architecture for
While we've reviewed the situations where we might need to rea-               managing services provided by various devices in an indoor envi-
son about context, we now analyze the mechanisms needed to                    ronment, to enable semantic composition and adaptation of these
perform the reasoning. This will help us identify which reasoning             services to location-related information. The semantic modelling
or inference engine we could use for implementing our location                described here will be implemented in a separate layer to provide
context management system.                                                    context -adaptive service composition capabilities.

When reviewing the types of queries the localisation context man-             [1] Tim Berners-Lee, James Hendler, Ora Lassila. “The Semantic
agement services has to fulfil, we roughly identify two types of
                                                                              Web”. Scientific American. 17 mai 2001
queries:                                                                      [2] KnowledgeWeb NoE, http://knowledgeweb.semanticweb.org
Queries inquiring about the truth of some properties. Exa m-                  [3] M.P. Papazoglou, D. Georgakopoulos, “Service-Oriented
ples are: "Is there a printer in room H250?", "Is printer X340                Computing”, Communications of the ACM, October 2003
in building C?"                                                               [4] G Richard “Service advertisement and discovery, enabling
                                                                              universal device cooperation” IEEE Internet Computing, Septem-
Queries expecting an object to be returned. Examples are:
                                                                              ber-October 2000
"Where is John?", "Which room is printer X340?", "Which
                                                                              [5] Jeffrey Hightower, Gaetano Borriello, “Location Sy stems for
building is printer X340?" "Which (x,y,z) position is printer
                                                                              Ubiquitous Computing” , IEEE Computer, August 2001
X340?", "Which printer is the closest to position (x=300,
                                                                              [6] Mike Hazas, James Scott, John Krumm, “Location-Aware
y=200, z=400)?", "Which rooms have a printer?", "Which
                                                                              Computing comes to Age” , IEEE Computer, February 2004
printer is in room H250?", "Which rooms have both a printer
                                                                              [7] Gilles Privat, Thibaud Flury et al. Position-Based Interaction
and a telephone?"
                                                                              for Indoor Ambient Intelligence Environments. Proceedings of
Handling such types of queries can be efficiently supported by a              EUSAI 2003. 3-4 novembre 2003, Eindhoven Pays-Bas.
theorem prover or backward reasoning strategy. More specifically,             [8] Gilles Privat, Thibaud Flury.” An infrastructure template for
a theorem prover organizes the control of the reasoning process               scalable location-based services”. Proceedings of SOC 2003, p214-
this way: In trying to establish the truth of a property, it looks            217. 15-17 mai 2003, Grenoble France.
into the knowledge at hand, whether this property is explicitly               [9] Jeffrey Hightower. “From Position to Place”. Proceedings of
there or not. If it is there, the property is true. If not, it attempts       the Workshop on Location Aware Computing (Ubicomp 2003),
to derive it from knowledge at hand using a basic inference step.             October 2003, Seattle, USA.
Eventually, if a promising inference step requires a property not             [10] Dimitar Manov, Atanas Kiryakov, Kalina Bontcheva et al.
explicitly stored, it tries to establish its truth (this is a recursive       «”Experiments with geographic knowledge for information extrac-
process).                                                                     tion”. 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) Ref-
                                                                              erence Description.

Figure 5 : Semantic location concepts with domain-specific derivations

Figure 6 : Full example with relations between different models