Incorporating “Semantic Discovery” into a Ubiquitous Computing ...

1 downloads 0 Views 132KB Size Report
Department of Computer Science, University or Illinois Urbana-Champaign, ... A Ubiquitous Computing Environment is an open system, in which the compo-.
Incorporating “Semantic Discovery” into a Ubiquitous Computing Infrastructure Robert E. McGrath, Anand Ranganathan, M. Dennis Mickunas, and Roy H. Campbell Department of Computer Science, University or Illinois Urbana-Champaign, Urbana, Illinois 61801, USA {mcgrath, ranganathan, mickunas, rhc}@cs.uiuc.edu

Abstract. The fundamental standards and protocols of a Ubiquitous Computing System must define common interfaces and message formats. In addition to the common interfaces and message formats, the entities of the system must know or discover the “semantics” of the messages: the vocabulary of the messages, which includes the names and valid values of message elements. In this paper, we show how we have successfully used technologies from the Semantic Web to solve important aspects of this challenge. We have implemented “semantic queries”, as part of a semantic discovery process for a Ubiquitous Computing Environment. We argue that semantic discovery should be an integral part of the fundamental protocols for Ubiquitous Computing Systems.

1 Introduction Ubiquitous Computing Environments are physical environments saturated with computing and communication, yet gracefully integrated with human users [14]. These environments feature a large number of autonomous entities. These entities could be devices, applications, services, databases or users. Various types of middleware have been developed that enable communication between different entities. However, existing middleware have minimal facilities to ensure semantic interoperability. A Ubiquitous Computing Environment is an open system, in which the components are heterogeneous and autonomous. When two autonomous entities exchange messages they must have common interfaces and protocols, including a common message format. In addition, the parties must know or discover the “semantics” of the messages: the vocabulary of the messages, which includes the names and valid values of message elements, as well as the meaning of the messages. Essentially, the parties must have a shared grammar and vocabulary and a shared semantic understanding of the vocabulary for interpreting messages. We call this requirement semantic interoperability. Before entities can collaborate to deliver services, they must discover each other. Conventional object registries, such as the CORBA Naming Service [17], LDAP [28], or UDDI [25], provide a limited capability for object discovery. So-called discovery protocols (such as Salutation [20] or the JINI Discovery Service [22]), support limited ability to spontaneously discover entities on a network. For a Ubiquitous Computing Environment, these protocols must be enhanced to provide semantic dis-

covery: it must be possible to discover all and only the “relevant” entities, without knowing in advance what will be relevant. This process has also been termed “matchmaking” [1, 10, 15, 19, 23, 24]. We believe that “semantic discovery” will be one of the fundamental protocols of a Ubiquitous Computing Environment. The semantic discovery service will implement “semantic queries” that seek to match “conceptually equivalent” concepts: entities that may have different values describing equivalent concepts (i.e., different terminologies). Answering semantic queries requires some form of knowledge representation, automated reasoning, and question answering. In this paper, we discuss our prototype implementation of semantic queries in a Ubiquitous Computing ur experimental implementation, the semantic queries are implemented by queEnviro In onment. ries to a Knowledge Base (KB), which contains descriptions of classes and relationships. A class could represent any concept that is used in a Ubiquitous Computing Environment. A class could be an entity (an application, a service, or a person), context information (location, activity, or temperature) or any a physical or virtual concept (chairs, tables, data files, or network connectivity). We decompose the process of semantic discovery into three phases: 1. Discovery of all the classes that match (i.e. are logically related to) a query 2. Discovery of all the instances of these classes 3. Filtering the instances to match the exact query In this paper, we focus on the first step, which is the essential “semantic query.” The second and third steps are conventional retrievals from registries or databases. The “Semantic Web” is evolving to address this problem for Web Services [3, 26]. The DAML+OIL XML language [6]1 is being extended to enable semantic discovery and matchmaking [1, 7, 16, 19]. This technology is now being applied to Pervasive and Ubiquitous Computing Environments (e.g., [4, 21]). The main contribution of this paper is that we show why “semantic queries” should form an integral part of the fundamental protocols for Ubiquitous Computing Systems. We also describe our infrastructure for enabling the answering of semantic queries.

2 An Example Problem: Discovering a Service in a Ubiquitous Computing Environment In order to illustrate and motivate the discussion, this section presents a Ubiquitous Computing scenario that involves searching for print services. Imagine a Ubiquitous Computing Environment, in which a variety of network attached devices are present. Some of the devices provide I/O capabilities, including hard copy output and hard copy input (e.g., imaging and scanning). Different classes of devices provide alternative, but possibly overlapping, classes of service. When a device is introduced into the system, it will automatically register with the infrastructure so that applications and users can use it. The registration will advertise 1

The DAML+OIL language is now being standardized as the Web Ontology Language (OWL) [27]. This paper refers to DAML+OIL, but it should be understood that OWL will be used in the future.

the services that the device can provide, as well as the network address, software interfaces, physical location, and other important facts about the new device. Note that a multi-function device might be capable of providing several classes of service, which it may or may not explicitly advertise. User applications (or agents acting on behalf of users) need to discover services to implement their tasks. In this example, when the application needs a hard copy of a document, the application needs to discover some device that will print it. In a Ubiquitous Computing Environment, the application cannot know what devices are available, so it must query the system to request “a local print service” or equivalent. Ideally, one or more services will be identified, along with information about their address, physical location, interfaces, and capabilities. The application (or a broker) may select one that meets its needs, based on the attributes of the services. In a Ubiquitous Computing Environment, or any open, heterogeneous distributed system, there are several important constraints and requirements on this query. First, the application does not know what devices are in the environment, and the devices do not know what applications may request service from them. This means that the query and the response cannot be pre-determined they must be interpreted at run time. Second, the system is continuously changing, so the query and response must be robust in the face of new configurations, and new versions and models of devices and services. A query should be a description of the required service, rather than a request for a specific entity, or for a particular model or version. Third, in addition to heterogeneous implementations of devices and services, the classes of service may vary from location to location, and entirely new classes of service may be introduced. Therefore, the application query does not know in advance what the results might be, and the query answering system must give reasonable answers based on the current system. Assuming that there is a set of services that really can meet the user request, a “reasonable answer” should include all of and only that set. Furthermore, the same question may receive a different answer as the system changes over time. Considering the examples above, suppose a particular smart room has several devices, including a Scanner, a Printer, and a Copier. Each device is registered with the system and advertises its own service. Suppose an application requests a local “Printer”. What should the answer be? Minimally, the answer must include all devices that registered as a “Printer”. However, in this case, let’s assume that the “Copier” machine is also capable of printing the file, perhaps via a translator component (e.g., as in [12]). In this simple case, the answer should include any device of class “Printer” or “Copier”, but not, for instance, “Scanner”. The generic query should be answered with all classes that can deliver the “equivalent” service, regardless of their specific name, and whether or not they explicitly advertised the requested service. The system must also be robust when new devices are added. Suppose a new Fax machine is added to the smart space. This device is registered and advertises “Fax” service. Let’s assume that the Fax machine can accept a file and provide hard copy output, e.g., via transcoding services. Suppose the application repeats the query for “Printer”. The answer should now include all devices of class “Printer”, “Copier”, or “Fax”. But note that a query for “Fax” should return only instances of Fax devices,

however. While a Fax machine can provide print services, a printer cannot provide a Fax service. This last case illustrates how the discovery process must automatically incorporate a new device, to give a new answer to the same query. This discussion tried to capture the essence of a key discovery problem. However, the query need not be restricted to the name of a service class. In a realistic system, the query will need to describe several attributes of the desired service (physical location, quality of service, cost), advertisements will describe many attributes besides service class, and the response will need to match these attributes. The infrastructure needs a flexible and robust mechanism for managing descriptions and answering questions.

3 Service Class versus Service Instance The discovery or matchmaking process uses two related kinds of knowledge about the system: classifications (schemas for what can be in the system) and state (what currently is in the system). The classification defines a logical model of what entities and relations must and may occur, along with constraints on their properties. Semantic Web ontologies represent important aspects of this model, expressed in standard DAML+OIL XML. The running system is populated by entities (people, places, devices, software components, etc.). Each entity is modeled as an instance of one or more classes in the ontology, with specific values assigned to attributes and relations defined by the model. The description of the entity must conform to the classification schema. The Semantic Web implements these models as Resource Description Framework (RDF) “Description” records of DAML+OIL XML files. The “Description” records refer to the ontologies that define the terminology of the description. In summary, the DAML+OIL XML defines both the classification (the “grammar”) and instances that conform to the grammar. In the query and answer process, there is an important distinction between queries about classes and queries about instances. The former asks about “what kinds of entities match this request”, which is answered based on the logical design of the system. The latter asks about “what entities match this request (at this time and place)”, which is answered based on the state of the system. As the system evolves, the former question might give the same answer (the class of entities), while the latter gives completely different instances (the set of available entities). In our work we explicitly separate these two kinds of information and queries, in order to allow the possibility for different mechanisms for each kind of reasoning. The Knowledge Base manages information of the classes and relations, and answers questions about classes. System registries and other services manage the current state of the system, and answer questions about active entities. In the future, we may use a single automated reasoning system that manages both kinds of information, but we do not need to do so. In this hybrid approach, we decompose the query answering process into three phases. First, the set of classes that matches the query is discovered. Second, the instances of all the classes in the result set are discovered. Third, the instances are

filtered to match additional constraints of the query, such as specific values or ranges for attributes. In this decomposed process, the first step is the essence of the “semantic query”: from the specific request, the system deduces all answers that “conceptually” match the query. The subsequent steps are conventional retrievals, using the result of the first phase as the query.

4 Application of Semantic Web Technology In our experiments, we have integrated semantic services into a prototype Ubiquitous Computing Environment. We have implemented an Ontology Server that manages the different ontologies about software, hardware, context information, etc., in the environment. The Ontology Server implements algorithms to load and validate ontologies from DAML+OIL XML files, compose ontologies into a combined ontology for the entire system, and serve logical queries to a Knowledge Base (KB) representing. Other entities in the environment can access the various ontologies through the Ontology Server. The Ontology Server answers semantic queries using the “matchmaking” algorithm proposed by Gonzalez-Castillo, et al. [10]. A query is formed as a DAML XML document that describes the desired entity, which is (temporarily) entered into the KB. The algorithm defines the set of classes that are logically “similar” to the query. The Ontology Server uses the FaCT server [2] to performing logical reasoning to test subsumption and satisfiability of classes in the KB, following [10]. The result is a list of classes (from one or more DAML ontologies) that are logically consistent with and semantically similar to the query. The DAML descriptions of the classes can be retrieved to discover the attributes of the classes. System registries and services can be queried for all currently available instances of these classes. Initial experiments have demonstrated that this service correctly solves the problems described above. When a well-designed ontology is loaded into the KB, queries return the set of logically similar devices or services. Furthermore, the KB can be automatically updated with new classes of device or service, which are then discovered by generic queries.

5 Summary and Discussion One of the crucial requirements of Ubiquitous Computing Environments is that the discovery protocols employed should be able to handle the highly dynamic nature of these environments. That means that it should be able to take care of not only new instance of entities that enter the environment, but also new classes of entities. In our environment, the automated reasoning of the KB enables automated update of the system ontology with new classes when new types of services and devices enter the system. Future queries would then discover the new class as one of the candidate

output devices (if appropriate). Note that the user or application does not need to know about the introduction of the new device in order to discover it. The semantic query algorithm provides answers based on the logical relations, and not just on string or key word matching. This is important, because it is difficult or impossible for participants in the Ubiquitous Computing Environment to know the specific terms used in each environment it may enter. We believe that the use of ontologies and DAML (in the future, OWL) should be incorporated into middleware protocols, e.g., for registering devices. Our work suggests that the overall process of updating the system ontology can be entirely automatic, implemented as part of the registration protocol for recognizing new devices. In this approach, the registration protocol is augmented with the following steps: 1. The device registers and tells the system registry the classes needed to describe it. 2. If the classes are unknown to the system, the registry will download them (in DAML+OIL XML files) from the specified URL (or perhaps from the device itself), and updates the system ontology. 3. The device provides a description of itself, in DAML+OIL XML. The description file uses references to the definitions loaded above. After initialization with a set of very general concepts (an “upper ontology”), the KB of the system ontology can be constructed incrementally, with each new device adding its information to the ontology. We anticipate that there will be a “system ontology” for each local space, rather than a single universal ontology for all possible spaces. Each local ontology will have definitions of the entities that are in the space. The different spaces will share high level concepts from standard “upper” ontologies defining generic entities, services, context, and other aspects of Ubiquitous Computing Systems. Individual spaces, applications, and communities can create new ontologies, or specialize and extend generic ontologies. These can be used seamlessly in local system ontologies where the specialized service is used. The ontologies, KB, and protocols described here can be used for many similar purposes. Intelligent human interfaces can use the ontologies to adapt to the local environment. Similarly, context-aware services can discover and adapt to evolving context and events. Ontologies can be used to help “bridge” between multiple autonomous systems, e.g., by mapping logically equivalent services. In the future, the DAML Query Language (DQL) will be used as a universal format for semantic queries. The DAML Query Language (DQL) is a specification for question-answer dialogue using knowledge represented in DAML+OIL [8, 9]. The model of queries uses DAML+OIL sentences in which some literals and URLs have been replaced by variables. An answer provides bindings of terms to variables such that the answer is entailed by the answer KB. The DQL specification includes a formal description of the semantic relationship between the query, the query answer, and the KB(s) used to provide the answer. The DQL specification is under development, initial implementations will appear soon. Other Semantic Web standards will be important in the future, as well. When fully developed, the DAML-S standard will be the framework for service description [1]. DAML-Rule (which evolved from ‘RuleML’) will be an important standard for ex-

pressing predicates, e.g., for context-aware services [11]. The DAML-Time standard defines concepts related to time, duration, and temporal relations, which will be very important for managing events and context [5]. We conclude that these emerging semantic services should be a part of the standard infrastructure of Ubiquitous Computing Systems.

Acknowledgements This research is supported in part by the National Science Foundation grant NSF 9870736, NSF 9970139, and NSF infrastructure grant NSF EIA 99-72884. Important aspects of this study used software from Iona [13] and University of Manchester [2, 18].

References 1. Ankolekar, A., Burnstein, M., Hobbs, J.R., Lassila, O., Martin, D., McDermott, D., McIlraith, S.A., Narayanan, S., Paolucci, M., Payne, T., Sycara, K.: DAML-S: Web Service Description for the Semantic Web. First International Semantic Web Conference (ISWC), Sardinia (2002) 2. Bechhofer, S., Horrocks, I., Patel-Schneider, P.F., Tessaris, S.: A proposal for a description logic interface. International Workshop on Description Logics (DL'99), Las Vegas (1999) 3. Berners-Lee, T., Hendler, J., Lassila, O.: The Semantic Web. Scientific American. 284: 5 (2001) 35-43 4. Chen, H., Finin, T., Joshi, A.: Using OWL in a Pervasive Computing Broker. Workshop on Ontologies in Agent Systems (OAS'03) at Autonomous Agents and Multi-Agent Systems, Melbourne (2003) 5. daml.org: A DAML Ontology of Time. http://www.cs.rochester.edu/~ferguson/daml/damltime-29jul02.txt 6. daml.org: The DARPA Agent Markup Language Homepage. http://www.daml.org 7. Fensel, D., Bussler, C., Maedche, A.: Semantic Web Enabled Web Services. International Semantic Web Conferences, Sardinia (2002) 8. Fikes, R., Hayes, P., Horrocks, I.: DAML Query Language (DQL): Abstract Specification (April 2003). http://www.daml.org/2003/dql/dql 9. Fikes, R., Hayes, P., Horrocks, I.: DQL-A Query Language for the Semantic Web. WWW 2003, Budapest (2003) 10. Gonzalez-Castillo, J., Trastour, D., Bartolini, C., Description Logics for Matchmaking Services. HP Laboratories Bristol, Bristol HPL-2001-265 (2002) 11. Grosof, B.N., Poon, T.C.: Representing Agent Contracts with Exceptions using XML Rules, Ontologies, and Process Descriptions. Workshop on Rule Markup Languages for Business Rules, at International Semantic Web Conference, Sardinia (2002) 12. Hess, C.K., Roman, M., Campbell, R.H.: Building Applications for Ubiquitous Computing Environments. International Conference on Pervasive Computing, Zurich (2002) IONA Technologies Inc.: ORBacus Trader, Version 13. 2.0.0. http://www.iona.com/products/orbacus_trader.html 14. Lyytinen, K., Yoo, Y.: Issues and Challenges in Ubiquitous Computing. CACM. 45: 12 (2002) 62-65

15. McGrath, R.E., Discovery and Its Discontents: Discovery Protocols for Ubiquitous Computing. Department of Computer Science University of Illinois Urbana-Champaign, Urbana UIUCDCS-R-99-2132 March 25 (2000) 16. McIlraith, S.A., Son, T.C., Zeng, H.: Semantic Web Services. IEEE Intelligent Systems. 16: 2 (2001) 46-53 17. Object Management Group, CORBAservices: Common Object Services Specification. Object Management Group (1999) 18. OilEd: OilEd. http://oiled.man.ac.uk/ 19. Paolucci, M., Kawamura, T., Payne, T.R., Sycara, K.: Semantic Matching of Web Service Capabilities. First International Semantic Web Conference, Sardinia (2002) 20. Pascoe, B., Salutation Architectures and the newly defined service discovery protocols from Microsoft and Sun. Salutation Consortium, White Paper June 6 (1999) 21. Ranganathan, A., McGrath, R., Campbell, R., Mickunas, D.: Ontologies in a Pervasive Computing Environment. Workshop on Ontologies in Distributed Systems at International Joint Conference on Artificial Intelligence, Acapulco (2003) 22. Sun Microsystems Inc., JINI (TM) Technology Core Platform Specification: Version 1.2. December (2001) 23. Sycara, K., Klusch, M., Widoff, S., Lu, J.: Dynamic Service Matchmaking Among Agents in Open Information Environments. ACM SIGMOD Record. 28: 1 (1999) 47-53 24. Trastour, D., Bartolini, C., Gonzalez-Castillo, J., A Semantic Web Approach to Service Description for Matchmaking of Services. HP Laboratories Bristol, Bristol HPL-2001-183 July 30 (2001) 25. uddi.org, UDDI Version 3.0. 19 July (2002) 26. W3C: The Semantic Web. http://www.w3.org/2001/sw 27. W3C, Web Ontology Language (OWL) Reference Version 1.0. , W3C Working Draft 31 March (2003) 28. Wahl, M., Howes, T., Kille, S., Lightweight Directory Access Protocol (v3). IETF RFC 2251 December (1997)

Suggest Documents