The WAP and iMode architectures have great similarities. The WAP New Generation proposal also aligns WAP with the mainstream Internet. NTT DoCoMo has publicly declared that it will go with XHTML. The paper begins with a walkthrough of the converged architecture, pointing out any remaining issues in convergence with the fixed Internet. It then proceeds to analyze the consequences, answering questions such as e.g. What consequences will this have for the future design of services, especially for convergence with the fixed Internet? What new possibilities does it open for content developers and service providers?

WAP was developed by a consortium of companies from the mobile communications industries with the primary intent of bringing information from the Internet to mobile telephones. The mobile environment is different from the traditional Web environment. The network is slower, and mobile devices are expected to have a limited range of input and output capabilities, network connectivity, and levels of scripting language support.

iMode was developed based on much the same premises, but with a different use case in mind. Whereas WAP was intended primarily to be a businessmans' tool, iMode was created as an entertainment platform. WAP was intended to be a global standard; iMode nothing but a semiproprietary solution. Very different market preconditions in Japan, Europe and the USA has also helped shape the different technologies. [IMODE]

Today, WAP and iMode are both minimized versions of the World Wide Web, albeit in different ways. Where iMode is defined solely by one company, on the basis of HTML - which the W3C, its specifier, has stopped supporting - WML, the markup language in WAP, is an application of XML, the rule system for specifying markup languages defined by the W3C (HTML is based on SGML). The most recent version of iMode contains a number of non-supported elements, such as <BLINK> and <MARQUEE>, which makes it a superset of a standard subset - i.e. not an application of a standard. It also uses animated GIF images (another proprietary system). [HJELM]

Both the iMode and WAP 1.x are based on the browsing paradigm made popular by the Web. The architectures consisted of the origin server, gateway, and user-terminal environment. The server could be a WAP or HTTP server; the gateway translated the protocol layer and application information, and held the user information database. In iMode, this translation would be restricted to wireless adaption of TCP and HTTP, and stripping out pages which exceeded the size limit. By contrast, the second-generation WAP architecture consists of four conceptual components, namely the application environment; protocol framework; security services; and service discovery. All of those are converging with the Internet, although some adaptions to the wireless environment (e.g. in TCP) are still necessary. For the content provider and user, the application environment is the main focus as it contains the user interface, and so will be the focus of our discussion here.

The second-generation WAP architecture does not have strict divisions between the server, gateway, and user-terminal environment. And there is no longer any intermingling between transport and service. Modularity is one of the main features of the second-generation architecture (modules interact through well-defined interfaces). The modules come from the WAP 1.x architecture, and from Internet protocols and application environments. The application environment component resides on top of OSI layer 7; the protocol framework comprises everything from OSI layer 2 to 7.

Developers can select modules from different components and create new user services. In practice, devices and proxies will most likely implement either a dual stack or only the Internet stack. The WAP conformance profiles determine the configuration of the devices, and how they work together. [WAP]

However, there are still compatibility problems at the protocol level, where both architectures are different from the fixed Internet. iMode only supports HTTP over wireless optimized TCP. The WAP 1.x environment has its own protocol stack. The WAP new generation protocol framework solves this by introducing four modular layers, which can be combined: the session service layer; the transfer service layer; the transport service layer; and the bearer service layer. [IMODE][WAP]

2.1 WAP 2 features

Most protocol services in the WAP 1.x suite are also available in new Web protocols. But the WAP push service cannot be realized through existing Web protocols without significant changes to the existing Web architecture. Both the WAP 1.x stack and Internet protocols (such as hypertext and multimedia transfer services) can provide some services, but only WAP is capable of providing others, such as the WAP push service. [SINGHAL]

Among the unique features of WAP 1.x is Push, which can be used to send information to users (who need not initiate any action). As simple as it might sound, the push-service architecture has been a major item on the WAP Forum's agenda, both in the 1.x and WAP NG architectures.

The push solution also contains a session component. The push over-the-air (OTA) session service enables the establishment of push sessions across communication links that might not be persistent; and in instances when addresses are dynamically assigned. Push is not possible on the Web using standard HTTP [HTTP].

Multimedia messaging (MMS) was one of the highlights of this years GSM-UMTS Forum. The multimedia messaging service (MMS) is an e-mail-like mechanism for the transmission of multimedia messages (electronic postcards with sound), which are expected to become very popular applications, especially in third-generation networks.

Security on the Internet is currently a hot issue, and the WAP architecture has received a lot of criticism for a sub-optimal solution. The telecom industry has been a leader in the security area for a long time, and this experience has been transferred into the WAP 2.x architecture.

WAP security services span all layers of the WAP architecture, thus creating opportunities for users to set up extremely secure environments (in fact, much more so than what is currently possible on the Web). By combining application-layer, transfer-layer, transport-layer, and bearer-layer security, the possibilities become endless. Security services include mechanisms for signing and encrypting data as a WMLScript crypto library; authentication services; an identification service that uses the wireless identity module (WIM); a PKI system; transport layer security (TLS, previously called SSL); and WTLS, the WAP 1.x-adapted version of TLS.

Synchronization is another new service in WAP. The WAP Forum has been working with the SyncML Forum (another industry consortium) to create a language for data synchronization. The synchronization of data that has been updated in mobile and fixed environments can be a thorny issue. Occasionally, users need to resolve conflicts between their local updates and the networked data. This reconciliation operation (during which updates are exchanged and conflicts are resolved) is known as data synchronization. The data synchronization protocol synchronizes networked data with that on many different devices, including handheld computers, mobile phones, automotive computers, and desktop PCs.

There is no binding between the transport of data and the session on the Web. The data transport is transparent to the session. Once a hypertext transport transaction is finished, the state it created disappears. In the WAP 1.x stack, the wireless session protocol (WSP) and wireless transaction protocol (WTP) can be used in combination to create and maintain a state, and through it, sessions. This has several advantages (for example, to enable push). By including HTTP as a transport method, the WAP Forum now enables both stateful and stateless transports. Session services provide a "memory" of previous transactions (which does not exist in HTTP, since it is a stateless protocol), that enable the retention of terminal characteristics and make for faster initialization of complex transports (such as data streaming).

Apart from the transport of text documents, the WAP architecture has also been prepared for the next generation of messaging. It contains a multimedia transport mechanism for asynchronous message transport (messages are encapsulated for transmission between multimedia and WAP servers in a WAP-specific protocol). The data-transport mechanisms also include IETF data-streaming formats. Both IP version 4 and IP version 6 have been defined as bearers, as well as all the bearer networks that previously existed in WAP.

iMode also uses HTTP as a transfer protocol, running over TCP (although an optimized version), instead of the custom defined protocol stack in WAP.

Communication from WAP clients can take place directly with the server, but it will most likely take place through a proxy. Proxies are being established as one of the main points of control (for example, through firewalls) and as central points for resource interconnection. WAP clients support a proxy-selection mechanism that allows them to choose the most appropriate proxy for a specific task.

The new WAP environment will be transparent to content providers, while preserving the WAP added benefits.

The WAP application environment executes in the mobile terminal. It contains a subset of XHTML (for display formatting) and a subset of the cascading style sheet (CSS) language (for content formatting). It also contains user agents for WTA and programming interfaces for use in mobile devices. The WAE also supports ECMAscript (formerly Javascript). The application environment provides the user interface and other functions that display content. Because it is a flexible environment, modules can be added on an ad hoc basis (optional) or through the WAP Forum specification development process. [WAP]

While WMLScript will be retained, the next generation of WAP devices will also be conformant with MexE classmark 3. The MexE (Mobile Execution Environment) is defined by 3GPP, the body defining the standards for the IMT-2000 networks which are now being deployed across Europe. The 3rd generation networks, as they are often called, not only allows for a larger bandwidth to the user, they also allow for a direct data transmission over the air, just as GPRS in the GSM networks, and PDC Packet in the Japanese PDC networks (over which iMode is running).

MEXE classmarks define compatibility profiles, and classmark 3 defines a Java platform as part of the mobile execution environment, which will be the application environment in the terminal. There are two different Java environment, but classmark 3 in all essentials is the same as that of the iMode iAppli Kjava devices (iAppli being the DoCoMo brand name for the service). [MEXE]

XML is actually one of the parents of WML. When the WML (Wireless Markup Language) specification was first published, it was a markup language based on HTML (and HDML, the Handheld Device Markup Language, which was also based on HTML). Devices that use HDML are still marketed, but they do not follow any standards, nor do they enable the new applications that become possible if you use WML because HDML has nothing to do with XML.

In the second version of WML, published on April 30, 1998, it was redesigned as an XML application. In version 1.1, which was published in June 1999, it was reworked to conform to XML 1.0-and to map out a convergence path to XHTML. While formatting is very primitive in WML, several other things are worth taking advantage of, such as the variable handling and the event mechanisms.

XML is not intended to replace HTML. The W3C, though, has produced a replacement, which will also be used in the second generation of WAP and all the Japanese mobile information services: XHTML. It is an XML application, but also an XML version of HTML 4. This means your HTML browser can render XHTML documents, even if it is not an XML parser (because an HTML browser ignores unknown tags, such as the endtags in XHTML). [HJELM]

The new generation of WAP - as well as all Japanese operators of mobile information services - will be using XHTML, the Extensible Hypertext Markup Language; specifically XHTML Basic, the minimum module of XHTML. This means that the markup will not be a significant difference between the two architectures in the future.

Maybe it seems unclear why HTML needs to be replaced. After all, it is only five years old, and it works fine for the pages you look at, although people have felt that a few workarounds for features are missing-this is just the problem.

Reformulating HTML as an XML application makes it possible to extend or subset HTML for specialized purposes, without creating incompatible subsets (using the namespace mechanism in XML). Introducing the WML elements is just such an example. This reformulation, however, does not solve the needs of the content community for conformance. By gathering the HTML functions in modules in XHTML, the W3C is creating a means for product designers to specify which elements are supported by a device. The modules are still using standard HTML functions as building blocks and standard methods for specifying which building blocks are used. Any browser that supports XHTML will have to support a minimum set of elements, XHTML Basic. [XHTML-M]

It is possible, though, to create extensions to the modules. Using namespaces, a feature of XML that essentially creates a unique name for each new element, you can create your own private elements with names that are unique. XHTML provides the tools necessary for defining a modularized HTML language and for specifying how modules are defined, declared, and combined into meaningful systems.

Because the XHTML documents are both HTML 4 and XML, they will not contain any formatting. This will be done using the Cascading Style Sheet (CSS) standard of the W3C.

XHTML is built to be modular: There are modules for lists, for framesets, for tables, and so forth. There will be special modules for mobile systems, too. The XHTML modules are intended to make it easier to design for different devices. One of the modules that has been developed is XHTML Basic, which is intended to cover a minimum set of XHTML functionality, specifically for devices with poor presentation capabilities, like mobile devices. Using XHTML Basic as a lowest common denominator, it will be relatively easy to convert data to WML for rendering on mobile devices.

Using a common markup language, even with extensions, takes care of the compatibility problems with iMode at the presentation level. Indeed, since XHTML is an XML markup language, the extension using elements from other XML languages is not only possible - it is recommended in the specifications. [XHTML-M]

The WAP architecture contains a subset of the cascading style sheet language, which is the most widely used display language on the Web. Using cascading style sheets, an author can define how each element in a document is to be displayed. This gives authors greater control-compared to when the display is specified inside the markup. A style sheet need only be downloaded once from the network server. After that it can be retrieved from a local cache.

CSS can adapt automatically to the capabilities declared by a device's user-agent profile. This is particularly important because display capabilities vary significantly among devices. A display [format] that looks good on one device might look different on another. The user-agent profile ensures that the device gets the most appropriate style sheet. And because style sheets separate display from content, authors can use the same WML document for many different devices with significantly different display capabilities.

WAP 1.x versions contained the vCal and vCard data types, which are not part of the browsing environment. The Internet Mail Consortium standardized vCal and vCard as structured data types for displaying contact and calendar information. iCal, which was developed from vCal, is used in products such as Microsoft Outlook, and Lotus Organizer. It is also used in Ericsson's AirCalendar, which allows users to synchronize the electronic calendars they use in the fixed environment with the calendars on their mobile terminals. WAP also accommodates other data types, such as audio and video. [WAP]

Which modules a client supports, as well as other facts about it such as screen size and other functions, need to be declared when information is sent to a server, if any optimization of the presentation (for instance, by attaching a manufacturer-specific style sheet) is to take place. The CC/PP profile is a collection of the capabilities and preferences associated with a user and the agents used by the user in the device to access the World Wide Web. These user agents include the hardware platform, system software, and applications used by the user. User agent capabilities and references can be thought of as metadata or properties and descriptions of the user agent hardware and software [CCPP-EX][CCPP].

The Mobile Access Interest Group in the World Wide Web Consortium (W3C) first proposed such a framework in 1998. Originally designed for HTTP, the Composite Capabilities/ Preferences Profile (CC/PP) [CCPP], [CCPPWG] is based on the Resource Description Framework [RDF], [RDFS], a semantic metadata application encoded in XML. The CC/PP architecture model defines a machine understandable RDF schema upon which vocabularies can be independently developed and implemented. In the case of HTTP, a user agent generates, encodes and appends a profile1 onto an outgoing HTTP request at the requesting end [CCPP-EX]. Intermediate proxies along the path of the request can append additional descriptions of their capabilities or services.

An example of CC/PP in actual use is the WAP User Agent Profiles (UAProf), specified by the WAP Forum as part of its WAP1.2.1 specifications [HTTP]. UAProf has also defined resolution rules for servers to resolve the final values of properties asserted such as in the case of multiple assertions for the same attribute originating from different sources. Vendors of WAP gateway and browsers have already begun to offer commercial implementations of User Agent Profiles as a step towards enabling this convergence. In fact, the Mobile Execution Environment (MExE) group within ETSI has agreed to adopt UAProf for asserting device capabilities in future mobile devices. [UAPROF]

A vocabulary is analogous to a dictionary. It identifies all the possible attributes in a schema. A profile is an instance of the vocabulary. Different devices and user agents may refer to the same schema, support the same vocabulary, but communicate different profiles to the origin servers.

Origin servers, gateways, and proxies can use the CPI to ensure that the user receives content that is particularly tailored to the environment in which it will be presented. Moreover, this specification permits the origin server to select and deliver services that are appropriate to the capabilities of the requesting client.

At the origin server, the profile is dynamically composed from fragments of capability assertions (RDF documents) collected from various sources (e.g CC/PP repositories) indicated by a default URI, then parsed and interpreted to determine the features of the presentation environment. The content can be generated either by using filtering techniques specific to a device or user's preferences (the privacy aspects, while pertinent, are not discussed in this paper), or by selecting an appropriate presentation format with the content intact. Depending upon the application, a suitable variant of the content itself may also be selected (from a set) or dynamically generated. This is returned in the HTTP response, possibly further transformed by the intermediate network elements and finally rendered to the client.

Additionally, by using both RDF for profile transmission and XML namespaces, CC/PP inherently supports extension of the vocabularies used to describe the terminal and the situation of the user. Furthermore, user preferences relative to the use of the capabilities for presentation can also be included in the profile.

Using richer profiling mechanisms like CC/PP enables you to declare which modules your device can render and so let the system match them automatically against the modules the author has declared should be used in the document profile. These modules create a minimum level of conformance, which means that content developers can now target the installed base that supports a certain collection of modules, rather than worry about the installed base that supports this or that permutation of HTML elements.

Already in commercial use in Japan, the so called 3rd Generation networks promise more bandwidth, positioning, and a number of other features. Together, these will serve to enable a new generation of services, which have the potential of fundamentally changing the way we think about information access.

Most Web services cannot be used directly in a mobile terminal since they have been designed for larger screens and for use that is incompatible with mobile terminals. Despite these limitations, however, mobile terminals are positioned to become devices of ubiquitous information access.

The deployment of pre-3G services forces us to ask seriously how human communication works, and how it can be enhanced in the face of a steadily increasing flow of information. We have to review yet again the traditional models of communication, publishing, and information. This time, however, usage points to an actual paradigm shift: Towards information services as transactions.

The Shannon-Weawer model of communication explains communication between people in terms of messages passed from a sender to a reciever[SHANNON]. It has, however, enormous problems in explaining other communication formats, such as theatre, libraries, and indeed anything that allows for the storage of the message and its retrieval by an unknown recipient. Several models have been developed to address this, but it seems likely that the bias in the model reveals its origin in Bell Labs, then part of the largest telecommunications company in the world. The communications model is actually far simpler: Communication is not of necessity a dialogue, executed in realtime (or with a time delay), as the Shannon-Weawer model assumes. It is a collaborative process in a group, the smallest number of members of which is two.

This is doubly true for information services. Accessing information through an iMode or WAP phone still has more in common with opening a newspaper than it has with hanging out with friends in a coffe house. The paradigm of the World Wide Web is still that of the document [NELSON].

5.1 Personalization based on parametrization

If designers do not understand that the medium they are dealing with presents a fundamentally different set of rules from the previous media, they will design content which will give the user a less satisfying experience. It is, of course, true as McLuhan holds, that the content of a new medium is the old medium [MCLUHAN]. However, this does not mean that the FORM of the old medium translates into the new. Rather, it should be precisely the reverse!

With device types proliferating, there is an emerging need for content to be formatted for rendering on different devices and different modalities such as text, sound or a combination. Hardware and layout characteristics (for example, the display or input capabilities), as well as the software environments are as heterogeneous as the devices and device types themselves. In addition, presentation preferences varies between individual users. For content on the current World Wide Web to then be usable, the application server needs to be aware of the context[CCPP-EX] or situation in which the information is being presented.

Current techniques involve either explicitly using different URLs for different versions/ formats of the content or the use of HTTP1.1 User Agent headers to assert a limited set of information about the client [SINGHAL]. In the former case, users must remember and use different URLs. And while the User Agent header fields are sufficient for selecting from a set of variants, they do not enable a richer description of the characteristics of the device.

The abstract model of a user retrieving information from a Web server is well known today: A user agent issues a request, which results in a response. However, the process is more complicated in reality, with entities such as caches and proxies intervening on the behalf of the user. It is also often true that the information resulting from the request is individualized, using a parametrization of the request. Today, this takes the form of cookies (database keys that are used for database lookup in systems connected to the origin server) and browser sniffing (adaptations to the brand and model of the user agent -- the browser -- according to the user agent field in the HTTP header).

This parametrization can be extended vastly, creating a description set that describes the client to a much higher degree than is possible using cookies and the User Agent (UA) field [CCPP-EX][CCPP]. It can also be used to adapt the information in the request to the individual conditions of the user. One of the elements that can be contained in such an extended framework is the user's position. In the WAP Forum User Agent Profile (UAProf) specification, this is included as the TerminalLocation element.

5.2 Situation dependency

An application that adapts the content to be presented to the user based on his situation will require a description of what the situation looks like from the perspective of the user (i.e. the CC/PP profile). This implies profiles describing the facts presented by the user to the service, but also profiles describing the properties of the objects to be adapted (e.g. document profiles). However, given a set of profiles containing assertions of facts, drawing inferences requires a set of rules for how the inferences should be drawn.

Given that user satisfaction is largest when the use is consistent with the mental model of communication, we should try to leverage this in designing 3rd generation mobile services and terminals, as well as the generations after that. Mereley presenting services which work at the level of 19th century technology will not satisfy a 21st century teenager, the primary user group of mobile phones in Japan. [CARTOON]

Interestingly enough, the prevalence of social communication in language use (as demonstrated by recent work on the origins and use of language [DUNBAR]) points in exactly the same direction as that of the primary uses for iMode: Email within groups. Japan did not have its Internet revolution until web access became available on mobile phones, the use of the devices point to a different way of interacting with information than is prevalent in fixed devices. [LAGMOD].

Which XHTML modules are used in a document, along with other metadata about the information, are described in the document profile. The document profile of the XHTML document (which uses the Composite Capabilities/Preferences Profile framework, but a separate vocabulary) is expressed in the Resource Description Framework (RDF) of the W3C, as is the CC/PP. Profiles for documents are the converse of profiles for devices. They spell out what a document requires in the way of presentation and other support functions, using a standardized structure and vocabulary. The definition of the vocabulary is specified in the schema, which specifies the syntax of documents that conform to a document profile. There should also be a human-readable description of the profile, as well as information about who made it. The idea is to enable the reuse of profiles by allowing documents to point to already existing profiles, much in the same way that a document can point to an already existing DTD.

The document profile can be used by servers to determine whether an already existing version of a document can be delivered to the client or what transformations and adaptations are needed for the document to be adapted. The client should identify their capabilities to the server when requesting a document, and returned documents should be marked (in metadata) in such a way that it is clear to which profile the document conforms.

If the presentation of the content is too tightly bound to the markup, it may become impossible to display on some terminals. Abstracting the markup or style from the semantics allows for multiple styles to be associated and rendered with the same content. One such enabler is Cascading Style Sheets [CSS], which enables the declaration of the content rendering to be separated from the content markup. Tailored style sheets can be sent to the terminal, enabling a precise adaptation of the presentation. However, a customized presentation may involve a change in the application paradigm or modality itself. For instance, the "deck of cards" paradigm in WAP enabled small-screen devices is substantially different from the "infinite scroll" model of web pages. The optimal solution therefore is to model the navigation of the content in a device-independent way and then adapt the content based on the device profile [HJELM]. The content adaptation can be carried out using a transformation process, one for each type of device, through the use of XSLT [CLARK] on XML documents. The use of XML based languages for content management not only enables transformations, but also supports automatic exchange of content between applications and systems.

True "contextualization" or "situation adaption" would require information not only about the execution and presentation environment of the client, but also physical such as position, temperature and time, and logical parameters such as whether the device is docked on to a cradle. It may even include external parameters such as the traffic conditions and the weather. By defining new vocabularies, and implementing a trust mechanism5, the generic CC/PP framework can easily be used to convey the necessary contextual or situational information.

Situation-aware applications have come into focus with the event of the mobile Internet. Not particularly useful or interesting when clients are immobile and their situation fixed, this changes drastically when the situation of clients can change dynamically. Instead of receiving static documents, the user will desire to receive content which is adapted to his current situation [HJELM][SCHILIT].

The concept of situation-aware application is to provide the service automatically to the users in following way. "If the situation is A, then provide me service B". Of course this request has to be defined by users in advance and should be possible to be maintained by users or service providers (for instance in Transparent Content Negotiation in HTTP). Here we define the "if the situation is A, then provide me service B" itself as a rule. This can be generalized to "IF condition A, THEN action B", which is a classic rule [RULEML].

There are two ways to build up the relationship between A and B. First, you could put appropriate services under each siutation description. If the number of the siuations and services is limited, it might be a good solution, however the services available on the web today are a huge number and there are distributed.

The second way is to treat any situation as a special case of a system where the information needed for the application to be situation aware is extracted from other services. You define the situations and the services at the same level and structure them in some way to make them can be comparable, combinable and etc, in short, can be machine operable. In this case, even when the contexts are different, the services can be reused [GUSTAFSSON][KORTUEM][HJELM2].

Position relevance is expected to be one of the primary drivers for context-dependent information, as witnessed by experimental work at the universities of Kent and Lancaster [PASCOE]. The exact position of a user (or, more accurately, the terminal) is in itself, however, rarely relevant to the user; what is relevant is the information that relates to that position. Information is location relevant if it can provide the user or an agent acting on the user's behalf with information that can affect the situation of the user.

Adaptation of the content to the user's current situation can be seen as a special case of situational adaptation (or, indeed, the content adaptation as a special case of sitational adaptation, depending on the viewpoint). While content adaptation to a certain set of device capabilities is a fairly well described process (e.g., using style sheets with different resolutions and formatting parameters to match different device capabilities)[CONNEG], the adaptation of content to other parameters has so far been investigated mostly in isolated systems that do not attempt to aggregate content from different sites. Positioning has been the starting point for several trials with situation-aware mobile devices. Several methods exist for sensing the user's location, such as GPS, network-based positioning, active badges, and others. If, however, a topical search engine can discover content with certain properties in its metadata (e.g., that is relevant at a particular location), this content can be matched with the location preference of the user (real location or "pretended" location, as Pascoe points out).

An RDF representation of the document profile data will, generally speaking, be a converse of the RDF graph for the user device and preferences. If the profile information and the CC/PP information is provided with each request, the matching can be integrated with the Web server. This does not require an extensive amount of round-trip traffic; the CC/PP profile can be cached in the server and reused as long as it is valid. One simple way of changing the position attribute is to disallow caching, which forces retrieval of the entire profile for each request; this will, however, create a substantial amount of additional network traffic [CCPP-EX][RDF][CCPP].

Basing the encoding on XML enables references to objects which are stored externally (to the profile document) by including the Uniform Resource Identifier (URI), enabled by the fact that when an XML document arrives in an XML processor, references are resolved and the document composed before it is being presented to the next level of applications (the RDF processor, in this case). An analogy in the HTML world is the way that images are referenced, not included. The fragment that was requested is included in the resulting document [RDF][RDF-S].

An assertion about an object describes its properties, for instance the terminal screen size, etc. But it can also express other properties of the object, such as the situation of the user. Since the CC/PP profile formats is intended to convey a description of the situation of the user to the origin server, we have used it, and extended it with a section for environmental information, e.g. the ambient temperature or the weather, as derived from a weather service [SURA][YASUDA].

5.3 Inferencing Optimal Presentations

The adaption of information using markup to contain metainformation is one of the central tenets of the Semantic Web [SEMWEB], which aims to enable the markup of documents to be used as semantic information.

This implies a method to adapt content to the user situation, and a method of communicating the parameters of the situation to the server handling the adaptation. Such methods already exist, and have been standardized in the shape of CC/PP.

Different sets of facts and rules also can be formalized to represent different user situations. By using the rule-fact model, situation-aware applications can be defined and managed in a clear-cut way. It is also possible to reapply the rules, and change the information provided to the user by only changing the facts.

The facts describing the situation is only half the equation, however. Rules are policies, they describe what the services are to do as results of the profiles. A number of stakeholders in the application space can create the set of rules used to manage the facts - which comprises the application.

Rules can be represented in predicate logic (indeed, the body of work in Prolog research is considerable). However, Prolog suffers from being hard to use for the average user. If rule systems are to gain any acceptance, they will have to become as simple as the system for defining and managing facts. Multiple other formats, such as Frame Logic, exist and have been implemented.

Currently, work is underway in an ad-hoc group (the RuleML consortium [RULEML]) to define a rules language. The area is a work in progress, and the representation of rules will change as languages continue to develop.

The use of the XML namespace mechanism and RDF inherently provide UAProf with an extensibility mechanism. A profile can consist of attributes from multiple vocabularies. Extensions to the schema can be made, either by

* adding new attributes to an existing vocabulary or,

* creating a new standalone vocabulary.

Which method should be followed is left to the schema designer.

There is no central registry, and as long as the specification is followed and a schema is found at the URI identifying the name space, any elements defined in that schema can be included in the document. This means that content authors are free to invent their own markup, as long as they create their own schemas [RDF][RDF-S].

The vocabulary must be publicly available, not only for purposes of implementation, but also, for new designers who may either wish to leverage some of your work (attributes or components) as they develop their vocabularies.

In a situation-aware system, information which is stored externally to the profile can be automatically included, and used by an automated system to draw inferences on how information and presentation should be personalized. In this paper, we introduce a prototype architecture based on existing standards, and a use case for it.

The determination of which information objects are relevant in the current context of the user can take place in the same way as traditional content negotiation: The device reports its position to a server, which identifies documents relevant in that position, then forwards them to the user. The real problem is to determine the information objects that are relevant to the user in the position.

To declare what properties are used for inferencing, it is necessary to create a vocabulary describing the names of the properties, and the possible values they can take RDF statements are required to be expressed in the RDF data format. The definition of the elements is done in the RDF Schema. Creating a RDF Schema is tantamount to creating a vocabulary, which can be used for drawing inferences. [CCPP]

If the location relevance of the information, the time of update of the information, and the time the information is relevant were accessible in a structured format, as metadata or in a metafile, it would be possible for an indexing robot to create a metaindex that could be used to retrieve information that is relevant to the current context of the user. This would also enable the task of creating and updating the information set to be distributed to the owner of the Web site, which would mean that the creation of location-relevant information would take place in the same way as the creation of Web sites today, a method that has proved to scale extremely well. [HJELM2]

Position-relevant applications can also be situation-dependent applications, where a script is triggered to perform an action as an event occurs, for instance as the user reaches a location. Simple applications can be tourist guides, where information is given about sights that the user is passing, and in maintenance, where the user is automatically given information about nearby equipment.

The triggering can be more related to the user's needs if it is dependent on several contextual elements. An example could be information presented to a tourist that depends not only on the location but on the time of day, the season of the year, and the current temperature (e.g., giving recommendations for museums if it is raining or if it is winter and giving recommendations for beaches if the weather is nice and or if it is summer).

The convergence of the WAP and iMode environments will result in an environment which is easier to manage for content providers, using one single markup language. The WAP architecture will also become a superset of the iMode architecture, enabling new possibilities such as situational services and inferencing of optimal presentations.

[CARTOON] Poll by Cartoon Network, reported at http://jin.jcic.or.jp/kidsweb/news/00-12/survey.html

[CCPP] Graham Klyne et al.: Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies. W3C Working Draft 15 March 2001. http://www.w3.org/TR/CCPP-struct-vocab/

[CCPP-EX] Hidetaka Ohto and Johan Hjelm, "CC/PP Exchange Protocol using HTTP 1.1 Extension Framework" W3C Note 06/99. Available at http://www.w3.org/TR/NOTE-CCPPexchange

[CCPPWG]. The CC/PP Working Group home page, http://www.w3.org/Mobile/CCPP/

[CLARK] Clark, "XSL Transformations Version 1.0", W3C Recommendation, 11/99, http://www.w3.org/TR/xslt

[CONNEG] IETF Content Negotiation Working Group, http://www.ietf.org/html.charters/conneg-charter.html.

[CSS] Cascading Style Sheets, http://www.w3.org/Style/CSS/

[DC] The Dublin Core Metadata Element Set, http://purl.org/metadata/dublin_core/.

[DUNBAR] Robin Dunbar: Grooming, Gossip, and the Evolution of Language. Harvard Univ Press, Cambridge, MA. USA.

[GUSTAFSSON] Henrik Gustafsson, Martin Jonsson, "Collaborative services using local and personal facts", PCC Workshop'99

[HJELM] Johan Hjelm: Designing Wireless Information Services, John Wiley & Sons, New York, June 2000.

[HJELM2] Johan Hjelm, Mikael Nilsson: Position-Dependent Services Using Metadata Profile Matching. In Proceedings from the iNet 2000 conference, Yokohama, Japan, July 2000. http://www.isoc.org/inet2000/cdproceedings/3a/3a_3.htm

[IMODE] The DoCoMo iMode home page at http://www.nttdocomo.com/i/index.html

[KORTUEM] Gerd Kortuem, Zary Segall, Thaddeus G. Cowan Thompson, "Close encounters: supporting mobile collaboration through interchange of use profiles", First International Symposium on Handheld and Ubiquitous Computing, HUC'99. Also in Lecture Notes in Computer Science vol. 1707, Springer Verlag 1999.

[LAGMOD] Japanese students' Internet usage - Current perceptions and attitudes. John Lagerling and Niklas Modig. Master's Thesis Research Project, Stockholm School of Economics

[MCLUHAN] Marshall McLuhan : Understanding Media : The Extensions of Man. MIT Press; Cambrige, MA, USA.

[MEXE] Terms of Reference for SWG1 Mobile Execution Environment (MExE), document T2-000500

[NELSON] See the home page of Ted Nelson at http://www.sfc.keio.ac.jp/~ted/

[PASCOE] Jason Pascoe, Nick Ryan, David Morse, "Issues in developing context-aware computing. , First International Symposium on Handheld and Ubiquitous Computing, HUC'99. Also in Lecture Notes in Computer Science vol. 1707, Springer Verlag 1999.

[QUACK] Quackenbush, Robert: Ahoy! Ahoy! Are You There?: A Story of Alexander Graham Bell. : Prentice Hall, 1981, Englewood Cliffs, NJ. USA.

[RDF-S] Dan Brickley, R.V. Guha, Resource Description Framework (RDF) Schema Specification, W3C Proposed Recommendation 3 March 1999, http://www.w3.org/TR/PR-rdf-schema/.

[RFC1958] B. Carpenter: Architectural Principles of the Internet. IETF Request for Comments: 1958. Available at http://www.isi.edu/in-notes/rfc1958.txt.

[RULEML] Rule Markup Language home page, http://www.dfki.uni-kl.de/ruleml/

[SCHILIT] Bill N. Schilit, Marvin M. Theimer, "Disseminating active map information to mobile hosts" IEEE Network, 8(5), pages 22-32, September/October 1994, IEEE Computer Society

[SCHILIT2] Bill N. Schilit, Norman Adams, Roy Want, "Context-aware computing applications" IEEE Network, 8(5), pages 22-32, September/October 1994, IEEE Computer Society

[SEMWEB] Tim Berners-Lee: The Semantic Web, presentation at www9, Amsterdam. http://www.w3.org/2000/Talks/0516-sweb-tbl/all

[SHANNON] Claude E. Shannon, Warren Weaver : Mathematical Theory of Communication. Univ of Illinois Press, Chicago, IL. USA.

[SINGHAL] Singhal, Bridgman, Suryanarayana, et. al., "WAP - Writing Applications for Mobile Devices", Addison Wesley, Sept 2000.

[SURA] Lalitha Suryanarayana, Johan Hjelm, "CC/PP for content negotiation and contextualization", Second International Conference on Mobile Data Management, MDM 2001. Also in Lecture Notes in Computer Science, vol. 1987, Springer Verlag 2001.

[UAPROF] WAP-174, User Agent Profiling Specification. http://www1.wapforum.org/tech/terms.asp?doc=WAP-174-UAProf-19991110-a.pdf

[WAP] Specifications for Wireless Application Protocol (WAP) Version 1.1, http://www.wapforum.org

[XHTML-M] Raggett, Stark and Wugofski, "XHTML Document Profile Requirements", W3C Working Draft, 09/99, http://www.w3.org/TR/xhtml-prof-req/

[YASUDA] Kinuko Yasuda, Takuya Asada, Tatsuya Hagino, "Effects and Performance of Content Negotiation Based on CC/PP", Second International Conference on Mobile Data Management, MDM 2001. Also in Lecture Notes in Computer Science, vol. 1987, Springer Verlag 2001.