1 Real-Time Search for Real-World Entities: A Survey Kay Römer, Benedikt Ostermaier, Friedemann Mattern, Michael Fahrmair, Wolfgang Kellerer Abstract—We are observing an increasing trend of connecting embedded sensors and sensor networks to the Internet and publishing their output on the Web. We believe that this de- velopment is a precursor of a Web of Things, which gives real- world objects and places a Web presence that not only contains a static description of these entities, but also their real-time state. Just as document searches have become one of the most popular services on the Web, we argue that the search for real- world entities (i.e., people, places, and things) will become equally important. However, in contrast to the mostly static documents on the current Web, the state of real-world entities as captured by sensors is highly dynamic. Thus, searching for real-world entities with a certain state is a challenging problem. In this paper we define the underlying problem, outline the design space of possible solutions, and survey relevant existing approaches by classifying them according to their design space. We also present a case study of a real-world search engine called Dyser designed by the authors. I. I NTRODUCTION Today, increasing numbers of sensors and sensor networks are being connected to the Internet and the World Wide Web, making it possible to observe an ever-increasing proportion of the real world with minimal delay using a standard Web browser. While webcams may currently be the most popular sensors on the Web, services like pachube.com and Microsoft SenseWeb [1] offer APIs for publishing structured sensor data in real-time, such as energy consumption, for example. Additionally, real-world services are starting to publish real- time data relevant to their operation on the Web. One example of this is Bicing [2], a public bicycle-sharing system in Barcelona, Spain, where users can see the number of bicycles available at each rental station in real-time on the Web. We believe that these trends are precursors of a Web of Things [3], [4], which will extend the original document- centric Web, making it a universal interface for the real world by giving real-world objects and places a Web presence that can be accessed using lightweight APIs (typically based on the REST principle). Representing real-world objects – including attached sensors and actuators – as Web resources gives rise to a range of novel application scenarios. For example, users might create private mash-ups, combining novel real-world services offered by sensor-augmented objects with existing Web services. An example of this might be indoor plants that send a message to their owner as soon as attached sensors report a critical state. K. Römer is with the Institute of Computer Engineering, University of Lübeck, Germany and with the Institute for Pervasive Computing, ETH Zurich, Switzerland. Email: roemer@iti.uni-luebeck.de. B. Ostermaier and F. Mattern are with the Institute for Pervasive Computing, ETH Zurich, Switzerland. Email: {ostermaier, mattern}@inf.ethz.ch. M. Fahrmair and W. Kellerer are with DOCOMO Euro-Labs, Munich, Germany. Email: {fahrmair, kellerer}@docomolab-euro.com. Just as the search for documents (Web pages, videos, blog entries, etc.) on the Web has become one of its most popular services, we expect the search for real-world entities to become equally important. The vast number of sensors that will be connected to the Web, the anticipated frequency of changes in sensor readings, and the requirement to search for the real- time state of real-world entities would all place huge demands on a real-world search engine. In this paper we explore the design space of real-world search engines and survey existing approaches. Most of the systems surveyed do not use Web protocols and standards, but their concepts could easily be translated into a Web language. Because existing approaches do not support searching for entities by their current state in a way that could be scaled up to a global Web of Things, we conclude this paper with a description of our own recently developed system called Dyser [5], [6]. In Dyser, real-world entities (persons, places, or things) are represented by virtual counterparts in the Web that can be accessed using their unique URL – similar to the well- known Cooltown project [7]. Entities have dynamic properties that are gathered by associated sensors or deduced from their readings. For example, a public place may have a property that reflects how busy it is, which is deduced from Bluetooth readings of pedestrians’ mobile phones [8]. Users can search the Web for entities not only by using keywords referring to their static descriptions, but also (and more importantly) by specifying dynamic properties that entities have to fulfill at the time of the query. For example, users could search for nearby bicycle rental stations that had enough bikes available, or for picnic places by the lake that were currently quiet. II. THE PROBLEM AND ITS DESIGN SPACE We consider the problem of entity discovery, i.e., the process of finding real-world entities with a given dynamic state. The problem refers to four architectural elements: (1) real-world entities, (2) sensors associated with them which perceive their state, (3) users posing queries to search for real-world entities with a certain state, and (4) a search engine that accepts queries and returns references to entities matching the query. In practice, it is often sufficient to return a subset of (the most relevant) entities matching the query. Note that this problem is related to, but different from, data stream query processing as implemented in TinyDB [9], for example. With data stream query processing, queries are posed to process sensory data streams generated by a given set of sensors monitoring the state of an entity. Our problem, in contrast, is concerned with the discovery of entities and their sensors. Data stream processing queries require commu- nication with all sensors (to send them queries or to retrieve their output data streams), while discovery typically requires