In the past two years, a large amount of technology has been developed in support of the Semantic Web. This is a proposal to implement the scenario described in the introduction to "The Semantic Web", by Berners-Lee, Hendler and Lassila. The scenario is divided into several main points about the semantic web. These include service discovery, trust and belief systems, planning and user interaction. I will present an outline of a solution that integrates existing protocols and standards under an OWL/RDF framework, including a Java implementation of a semantic web agent using freely available, open source technologies.
For purposes of the demo, we will only be concerned with local control through ad hoc networks. We will be working with the Zeroconf standard, through which we will use DNS Service Discovery to indicate presence of local web services. Since these devices are assigned network local IP addresses, there will not be an issue of authentication in order to change channels or control the volume. The only embedded devices specified in the example are the phone and the entertainment system. The phone is presumably a cell phone, although a wired phone is equally possible, and perhaps easier to set up, as the cell phone would more likely use Bluetooth than 802.11, making slightly it more difficult to get off-the-shelf components.
Construction of the entertainment system should be relatively simple; it can be built as a headless PC, a la TiVo. It will have a web server for administration and a Zeroconf daemon that registers with the local network. For our purposes it may as well be Pete's G4.
The phone can be built using a standard Bluetooth or 802.11b-enabled phone with J2ME installed. Jena, or a similar RDF toolkit, could be rebuilt for the phone. I do not know if J2ME supports DNS Services, but the specification is simple and it can be accomplished in a few days. The phone can have a few simple semantic web actions; it does not need an advanced planner, as it may be able to interact with Pete's agent located on the Internet (presumably at the access point in Pete's room, but this will be transparent to the phone). The phone would benefit from some understanding of description logics, but it does not require a Turing complete reasoner. This could be implemented as a subset of TRIPLE.
Lucy, Pete and Mom all have agents that support ACL functionality based on trust metrics. It would, for the most part, make sense to only allow explicit assignment of trust levels to given services; for example, Lucy could say "I give Pete these permissions" to her agent. However, a belief network could be used which would allow services with different levels of trust different amount of access, as described below; Lucy would be able to say "I trust Pete" and "People I trust completely have these permissions." This would also allow the system to give people who Pete trusts some permissions to access Lucy's data without Lucy making her agent aware of them explicitly.
Another type of trust is described in the demo as the belief that different services offer different levels of quality. This comes up in the demo as "trusted rating services." These services may be referred to Lucy's agent through the health care provider or automatically added by Lucy, but they can be discovered using belief networks. For example, Lucy can specify two trusted services, and those services may trust other trust services, allowing belief to flow to the others. Alternatively, she could trust all services that Pete or Mom trust. Such belief network assignment already exists in Foafbot and other open source code, such as advogato; all that needs to be added is signatures to prevent spoofing. The trust metrics can then be added to the ACL mechanism for the agents.
The ACL mechanism (perhaps misnamed, since there is no ACL but instead a list of rules) does not exist in any form that I have found today. It would have to be added as a set of rules to the agent. This would be a simple mapping between levels of trust and levels of access. A more advanced system would allow role-based permissions, such as granting people with trust in certain areas access to only certain sensitive information. However, this will have to be left for a later demonstration.
Lucy's agent is given a goal of achieving a schedule for Mom that is compatible with the disjunction of Pete and Lucy's free time. However, it is not that simple. The agent must know how to reschedule appointments and how to schedule the appointments so they meet Mom's prescription requirements and insurance provider requirements. In addition to the query, it can also be assumed to have the initial results of the search for possible appointments.
To support advanced queries such as this, it is unlikely that a forwards chaining system such as CWM or jess will succeed without additional help, although CWM may have some use in the demo to connect services. TRIPLE may allow better rules, but its current implementation does not support some of the necessary requirements. A reasonable alternative would be to use JSHOP, or some similar planning system. This would allow the agent the most flexibility. Since JSHOP is written in Java and a product of UMCP, it would be relatively easy to add some semantic web understanding to the system using Jena, or even TRIPLE.
Note that this would also require semantic wrappers for a number of services, including the calendar service (provided in the demo by an SW wrapper around the iCal standard), health care provider list (using CWM or other scraping tools to interact with, for example, aetna.com to look for providers), and location services (eg MapQuest). These can be described in a variety of methods, but the most straightforward would be DAML-S. There already exist service composition tools for DAML-S/WSDL services; some are written in SHOP, making the initial possible appointment query a simple matter for the demo.
Agents may interact in the most straightforward way, that is, through e-mail or existing IM networks such as AIM, Jabber, or msn. Lucy's agent requires interaction with Pete's agent, so it sends Pete's agent an e-mail asking if the given plan is valid. (It might not need to interact with Pete's agent for the initial schedule, as it will have access to Pete's calendar through a public service, such as .mac or an exchange server.) For the demo, I would support agent communication through e-mail, having the agent operate on an e-mail proxy, such as ZO, although it could be implemented at the client mail-program level. ZO is open source, allowing us to plug in JSHOP, Jena, TRIPLE, and even CWM over Jython with relative ease, plus its status as a proxy allows it to be used with any e-mail client. The agents may communicate by sending HTML mail with RDF embedded signatures attached. This will allow ZO to take the appropriate action, allowing messages to go to the user (Pete) when the agent requires interaction and allowing them to be filtered when Pete doesn't require it. In addition, since the messages may include HTML, the agent may interact directly with Pete if he did not have a semantic web agent, by sending him an appropriate form to complete.
In the demo, Pete's agent would first become aware of the situation upon receiving a request from Lucy's agent to adjust his schedule. Pete's agent knows this requires approval, and passes the message to him. The message must contain the prescription as well as the query that generated the plan. Pete may then alter the query, as described below. His agent knows to interact with Lucy's agent, who it requests for more information. Lucy's agent receives the e-mail, and the proxy filters it from her inbox; her agent responds with the requested information.
The other major point of the demo was an agent's ability to silently discover physical therapists not included on the health care provider's list. This could work due to many methods. Under most health care plans, however, an alternate provider is only allowed based on the Doctor's advice. In some semantic web future, the doctor's advice may be supplemented by the doctor's agent's advice. In this case, the doctor's agent would require assurance, although not full proof, that the patient would be unable to make appointments without an out-of-plan referral. This is an interesting use of agents, as it helps alleviate one of the most annoying things about health insurance: dealing with "approved medication" and "approved provider" lists, that are often too complex for the patient and about which the doctor knows nothing. In addition, it would be possible for the agent to schedule appropriate medicine and pharmacy pickups, look for drug interactions, and even suggest alternative treatments. For the demo, all that is required is a list of alternate providers and a signed referral from the doctor that will be acceptable to the insurance company.
Pete's agent realizes that it cannot make a plan that fits with the given list of providers and without rescheduling appointments. The agent then asks the doctor for an out-of-plan referral, and the doctor's agent provides a few possibilities. These possibilities augment the plan search space, but not enough to make a perfect fit. Pete's agent knows that it can reschedule appointments with permission, so it asks Pete for some guidance. Pete gives it, and ascents to the plan, which results in his calendar being changed. Pete's agent then sends the plan to Lucy with Pete's signed approval, and the requirement for a referral. When Lucy ascents, Lucy's agent acquires the referral and sends it to the insurance provider, while sending booking information to the physical therapists.
There are many required ontologies at work here. However, the main thrust of the system is getting the planning agents in place. The ontologies are mostly example data, and do not have to be complete.
First, Lucy receives the prescription via e-mail. Her agent filters the message and adds the prescription to its knowledge base. The agent appends a link to the bottom of the message, "Do you want to schedule appointments?" The link goes to Lucy's agent site, which is running on the same machine as her mail proxy, possibly her handheld. The URL has a query string that indicates that Lucy is visiting in regards to the prescription. It already has a query formatted in XHTML forms, but it does not say anything about Lucy, let alone Pete. Lucy's agent knew how to form the query based on health care knowledge it already has. The page is not unlike an advanced query page at Google, but supports adding additional fields like the FOAF-a-matic's [Add Friend] button. (Alternatively, the interface could be all Java/Swing or JavaScript/XUL, but XHTML provides several key advantages: ubiquity, standardization and ability to run in a low resource environment.)
As to plan revision, this requires that each question "Execute this plan?" requires an ability to rephrase the query. This implies that Lucy's agent and Pete's agent communicate using the same query ontology, or at least can reason about each other's ontologies. For our demo, the query will be phrased using an ontology for SHOE queries; an obvious choice for this would be the TRIPLE ontology, or some other form of RuleML. This can then be used to generate a "modify query" form for Pete when he clicks on "No".
As to the implementation, we will use a servlet type. I would suggest using Apache's Struts, which would integrate well with the Java agent architecture. The user interface can be presented as XHTML 1.0. Using this architecture, it would be possible to add voice markup as well, so that a user can control their agent over the phone.
As a C alternative, Redland and Parka-DB could communicate with SHOP2. This would require more engineering effort, while its result would be more efficient and scalable. However, the requirement is not for a shrink-wrapped system, and using the open tools described above listed will offer not only a reasonable demonstration of the technology, but also the amount of work that has already been accomplished towards the goal of a Semantic Web. Anyone will be able to install the agent by downloading a jar file (or, better yet, clicking on a Java Web Start link), whereas a C solution would require compilation for the user's target machine.