Position-Dependent Services Using Metadata Profile Matching

Johan HJELM <hjelm@w3.org>
Ericsson Research / World Wide Web Consortium
USA

Mikael NILSSON <mikael.nilsson@ein.ericsson.se>
Ericsson Infotech
Sweden

Abstract

Mobile devices are able to report their position. While the implications on privacy are vast, so are the possibilities for new services that are more convenient for the user.

For instance, working in our own city, we may be interested in finding the restaurant that is closest to our work, but when we are tourists in a foreign city, we may be interested in the locations of all the city's museums. The location relevance is determined by many factors, not just one. Time can be a factor, for instance (we are more interested in museums in the morning, when planning our day, and interest in lunch increases around noon), as can the mode of locomotion (when travelling by car we will not be able to stop suddenly, as a walking person would, nor will we be able to use restaurants without finding a parking space first).

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. The user perceives physical objects as having different degrees of relevance depending on his or her current context and the distance between him- or herself and the object. Users may also make requests for information that is not currently relevant but will be at the time of the validity of the request.

If the location relevance of the information is 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. 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 in Hypertext Transfer Protocol (HTTP).

In this paper, we describe a general metadata-based system for context-based information exchange and adaptation, building on a standardized mechanism for preferences and capabilities representation, using the World Wide Web Consortium (W3C) Resource Description Format (RDF). We describe how this can be applied to match the user's position at the time of the request to the area for which the content author has declared the document to be of interest. Enabling access to information from the World Wide Web while maintaining the relevance in the current context is the goal of the systems described in this paper.

Keywords: Personalization, context negotiation, metadata, RDF, device characteristics, WAP, World Wide Web, position dependency, mobile communications

Contents

Introduction

In a mobile system, new information services will become possible (IMT-2000). One of the more salient features of mobility is that the user's position can change between requests for information. Different information sets can be generated for different positions, which is part of the personalization of the information set for the user (Kassing) (Meggers).

Location can thus be said to have a relevance to the user. While this relevance cannot be described by generalized means, being individual, the parameters of the location can be declared, and a rule-based system can determine the relevance of the location for the user, based on the user's input and the metadata declaration of the information object for the location. Position information is a key in this information set: 80% of all information has a relation to a location -- in other words, is position-dependent, according to the British National Geographical Data Framework (NGDF).

To take into account the user's position, we have defined a mechanism that includes the position as a property of the client in the content negotiation. The content negotiation can take place over a number of different protocols, using the W3C standardized Composite Capabilities/Preference Profile format (CC/PP). However, a number of problems are unresolved, most urgently the number of location metadata standards that exist in the world -- 30, by the latest count (OII).

Determining the position of the user

A number of methods exist to determine the position of a terminal (determining the position of the user is contingent on determining the position of the terminal, for several reasons; even if it were possible to determine the position of an individual [e.g., using interlinked closed-circuit television cameras], this would be undesirable for privacy reasons). These methods include:

The position of the user can be retrieved either into the user device or into a proxy in the network, depending on the method of positioning. GPS, user input, and beacons all deliver the position directly into the terminal. Network-based positioning delivers the position information to a proxy, from which the information can be retrieved to the terminal. Differential GPS is a hybrid, requiring the device to communicate with the network to retrieve some information, while the direct position information is retrieved from the terminal.

A variety of ways exist to download the position information from a device into an origin server; they are all problematic in that they create a new content type that is originated on the client. To bind this to the request is difficult, to say the least, especially if error handling is considered. In our work, it has turned out that the easiest way is to handle the information in the TerminalLocation attribute of the CC/PP profile, which can either be derived from the device and transmitted as a CC/PP Exchange override (Ohto)(Reynolds)(WAP); in case it is derived from the network, it can be referenced as a URI and resolved by the XML processor when the profile document arrives at the server.

But position information is nothing magical. In many ways it is no different than other sensor information. This means that the position information can be communicated in the same way as other information -- from sensors connected to the mobile device.

Position and privacy

As noted above, the privacy of the user's position is a contentious issue. By giving out their position, users will be giving up details on their movements, which they may consider private. However, no simple solutions exist, and several industry bodies such as the W3C and Wireless Application Protocol (WAP) Forum are looking at ways of solving this problem in the context of their technologies. This is currently a work in progress.

Context exchange and adaptation

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 (Ohto)(Reynolds). 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.

Metadata and context encoding

RDF was designed to describe the machine-understandable properties of Web content, metadata associated with documents or other objects that can be named via a URI. The RDF data model consists of a directed labeled graph, representing the resource, the statement, and the property. Visualized as a graph, an RDF statement consists of a node, a leaf, and an arc between them. Nodes are resources, arcs are properties, and leaf nodes are property values. These can then be further chained to create a graph representing an arbitrarily complex statement about a resource. The RDF graph is commonly encoded in XML, which makes it possible to manage it using the emerging XML software infrastructure.

An RDF statement representing a device and its capabilities is relatively straightforward, especially if it includes "default" properties for each major component (as shown in [Reynolds]). The introduction of defaults makes the graph of each major component more of a simple tree than a table. In this example the major components are associated with the current network session. In this case, the network session is serving as the root of a tree that includes the trees of each major component. The closest thing to a "document" associated with CC/PP is the current network session.

The original use envisioned for RDF was to encapsulate Dublin Core metadata to make the presentation of these machine understandable. Therefore, a considerable body of work exists on how to use RDF as a metadata format.

This also means that the Hypertext Markup Language (HTML) model of encapsulating metadata in the document itself no longer holds. This is primarily due to the fact that when the representation is device- and user-independent, it becomes possible to link in a multitude of style sheets as well as other relevance metadescriptors.

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.

The problem of providing the information that is relevant to the user cannot be solved with traditional full-text indexing. Full-text indices, while flexible, do not contain information about the location relevance of the information in a structured manner. If a file contains a location (in coordinates, as a place name, or in any other description format), how can it be determined what it refers to without retrieving the file? The same goes for the update frequency.

What the best user interface for a location-aware application is, is still not determined. How to represent the context visually is something for which there is no convention. For location, the established convention for representing position on a map is a polygon (dot, circle, rectangle). The marker should be dynamic, as it is depending on the context of the user. Placing one such marker at each position where information can be triggered makes the user aware that information is available. On the other hand, if there are too many dots on the map, this will in itself constitute an information overload. Using the context dependency to just represent the information objects that are in the vicinity of the user will help minimize the cognitive load of the user.

Position relevance in metadata

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.

However, this has not been applied to the problem space at hand. For instance, the parameters that were described by Jason Pascoe (Pascoe) for the FieldNote system are not available as RDF, even though they include position, time, and the entire problem set the relevance of a location comprises to a user. There is, however, an XML-based language that defines the elements. This language was created in a research setting, and some of the elements can be derived from other, standardized languages, as seen below.

The elements are map, FieldNote, person, dataitem, data, temporal, spatial, and comment. The map element provides basic georeferencing, defining the bounds of the area covered. The FieldNote element contains information about the note and when it was written and can contain person, temporal, spatial, and comment elements. A mandatory part of it is the timestamp. The person element can have a role attribute and first and last name attributes. The role attribute describes which role the user has in relation to the note. Dataitem is a string value. Temporal describes the temporal relevance of the element. The spatial element describes the geometric elements that bound the relevance for the note and may include a GPS element. And comment is a data string that contains information about its applicability.

Adaptation of the content to the user's current context can be seen as a special case of content adaptation (or, indeed, the content adaptation as a special case of context 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 context­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).

Layering of relevance

A location may not be relevant to a user at all times but take on a relevance at a certain time, for instance, when an event occurs. For instance, a rally takes place on a course that was not previously relevant to the audience but that takes on a heightened relevance when the event occurs -- only to become irrelevant (except to a few statistics buffs) when the rally is over.

Users may also make requests for information that is not currently relevant but will be at the time of the validity of the request. Planning is a feature of most calendaring systems, and the iCal system of the Internet Engineering Task Force (IETF) is intended to address this issue (SKI).

Relevance may also depend on the role of the user. For instance, office workers on a lunch break may want to find the restaurant closest to their work, while tourists want to know the location of all the museums in the city. This can also be time dependent (in the morning, when planning our day, we are more interested in which museums exist, and interest in lunch increases around noon) and dependent of the mode of locomotion (those traveling by car cannot stop as suddenly as a walking person could and will need to find parking before going to restaurants), but that topic will not be addressed in this paper.

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.

Position-relevant applications can also be context-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 concept of layering relevances can be applied to all metadata elements in the metafile, provided they relate to the user's perception of relevance structures. In all probability, a compromise will have to be achieved that relates the perceptions of the user to what is technically feasible. For instance, a two-dimensional coordinate set is probably the base for all representations of location relevance; the height, time, and other factors will be layered on top of this base. It is important that these different layers be expressed in a common data format, using common data types, to ensure that the different elements can be compared and analyzed by a server, which will produce the information set relevant for the user.

The relevance of the layers of information is not clear. Considerable research would be needed to understand how a user comprehends information about an event or a position. But this technology is being deployed now, and we do not have time to wait for the research. The pragmatic approach is to take what is available and fit it into the layered model of location information.

All these information layers may be expressed in different formats. If the formats were binary, it would be impossible to combine them. But given that the formats are all XML, it is relatively easy to combine them; using XML name spaces (XMLns), elements from several name spaces can be used in the same document, provided they are all expressed in an XML-based format.  

The position layer: Geographical Markup Language

The Geographical Markup Language (GML) has been developed by the Open GIS Consortium (OGC; GIS being an acronym for Geographical Information Systems) to serve as a common platform for applications that relate to geographical metadata. It is based on a common model of geography (OGC Abstract Specification) that has been developed and agreed upon by the vast majority of all GIS vendors in the world. More important, however, GML is based on XML and can be expressed as RDF.

There are already a host of encoding standards for geographic information, including COGIF, MDIFF, SAIF, DLG, and SDTS, to name only a few. GML is simple text-based encoding of geographic features. Some of these other formats are not text based. XML is more than text. To begin with, XML provides a method to verify data integrity. Second, any XML document can be read and edited using a simple text editor. Third, since there are an increasing number of XML languages, it will be easier and easier to integrate GML data with nonspatial data. And finally, XML is easy to transform. Using XSLT or almost any other programming language (VB, VBScript, Java, C++, Javascript), we can readily transform XML from one form to another. A single mechanism can thus be employed for a host of transformations, from data visualization to coordinate transforms, spatial queries, and geospatial generalization.

Being XML, GML is structured, and any of a variety of XML editors can be employed to display that structure. This makes viewing and navigating GML data very easy. It is also easy to integrate with other data formats. Binary data structures are typically very difficult to integrate with one another. A classic example is that of associating a text document, or a parameter list, with a separately developed and maintained spatial database of parcels or land tenure boundaries. With a binary data structure one must understand the file structure or database scheme and be able to modify it. In many legacy systems using flat files the data structure cannot be modified without breaking the applications that rely on the existing data structure. With GML it is comparatively easy to provide links to other XML data elements, and this will dramatically improve with the introduction of XLink and XPointer, techniques that enable pointing into a document from the outside without changing it. Even links to non-XML elements can be readily handled using URIs.

GML represents the OGC Abstract Specification Simple Features as XML. The Simple Features in turn describe an object model for geometry, as curves, surfaces, and geometry collections. Each object is associated with a Spatial Reference System, which describes the coordinate space in which the document is defined, such as a national coordinate system or the latitude-longitude coordinate system. All common encoding of a geographical item can be included.

Event markup: SKi Format for event presentation

An example of the representation of event information is the SKiCal format, developed by Svenska Kalenderinitiativet (SKI). The event information can already be expressed as RDF.

The SKi format is based on VEVENT, defined in the IETF standard RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). VEVENT was originally intended to be used for the exchange of information between desktop calendars, but using SKi, it can be extended to contain all those information sets needed to describe an event -- which are many more than those needed to describe a meeting. Besides VEVENT, there are a number of other events in the iCalendar format, such as VTODO and VALARM. They do not relate to descriptions of events, however.

The iCal format is based on a series of objects. The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. An iCalendar object is organized into individual lines of text, called content lines. Long lines have to be split into multiple lines. The object can have a set of properties, which can have parameters and attributes. Where properties and parameters allow a list of values, they must be separated by a comma character. There is no significance to the order of values in a list. Some property values, which are defined as multiple parts, must be separated by a semicolon. A property can have attributes associated with it. These "property parameters" contain meta-information about the property or the property value (e.g., the location of an alternate text representation for a property value, the language of a text property value, the data type of a property value). The general rule for encoding multivalued items is to simply create a new content line for each value, including the property name. Binary content information in an iCalendar object should be referenced using a URI within a property value (and indeed, when it is inline, it must be referenced this way).

Besides the elements (component properties) that are described in the iCalendar specification, the iCalendar files can contain information fields that are extensions to it -- which is what SKi is. This also means that SKi uses the same content type (text/calendar) as iCalendar. The file extension of "ics" is used to designate a file containing calendaring and scheduling information consistent with this MIME content type, although you might want to use "ski" as your file type if you are publishing it as metadata (although if it is part of an RDF metafile, it would be an XML document).

Typically, the information in an iCalendar file will consist of a single iCalendar object. The calendar properties are attributes that apply to the calendar as a whole, and calendar components are collections of properties that express a particular calendar semantic in a parameter-specific format. For example, the calendar component can specify an event, something to be done, a journal entry, time zone information, or an alarm. The first and last line of the iCalendar object must contain a pair of iCalendar object delimiter strings.

An example SKiCAL event description in RDF could look like this:

   <?xml version='1.0'?>
   <RDF
   xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax#"
   xmlns:ICAL="http://www.w3.org/TR/WD-ical-RDF#"
   xmlns:SKI="http://www.w3.org/TR/WD-skical-RDF#">
   <RDF:Bag>
   <RDF:Description about="VCALENDAR">
   <ICAL:vevent>
   <ICAL:dtstamp>200002012T120000Z</ICAL:dtstamp>
   <ICAL:uid>uid1@decaturapostlechurch.com</ICAL:uid>
   <ICAL:organizer_cn>Dean Walt Wittman</ICAL:organizer_cn>
   <ICAL:organizer_mailto>wittman@decaturapostlechurch.com
   </ICAL:organizer_mailto>
   <SKI:otheragents>Christian Concerts of America" Inc.
   </SKI:otheragents>
   <SKI:association>Catholic Church of North America, Diocese of
   Chicago</SKI:association>
   <SKI:title>Universal Salvation Tour</SKI:title>
   <SKI:performer>Cross Brothers</SKI:performer>
   <SKI:part_of>Decatur For Christ Week</SKI:part_of>
   <ICAL:attach>http://crossbrothers.org/salvationtour/</ICAL:attach>
   <ICAL:summary>Cross Brothers plays the hottest hits from heaven - and
   saves Decatur in the bargain! </ICAL:summary>
   <ICAL:dtstart>20000229T010000Z</ICAL:dtstart>
   <ICAL:dtend>20000229T050000Z</ICAL:dtend>
   <SKI:venue>Indoors</SKI:venue>
   <SKI:orientation>Christian</SKI:orientation>
   <ICAL:categories>CONCERT,ROCK</ICAL:categories>
   <SKI:directions>Parking behind the hall</SKI:directions>
   <ICAL:location>Masonic Hall, 10 Main St, Decatur,
   Ill.</ICAL:location>
   <SKI:price admission="true">5USD</SKI:price>
   <SKI:tickets-at dtstart="20000201T150000Z">Church Secretary Office,
   14 Main St. Decatur, Ill.</SKI:tickets-at>
   <SKI:reservations
   dtend="20000229T1500Z">tel://+1-800-CRO-BROS</SKI:reservations>
   <SKI:available dtstart="20000228T100000">10</SKI:available>
   <SKI:handicapfacilities
   facilities="TRUE">assistance</SKI:handicapfacilities>
   <SKI:paymentmethod>Check,credit card,cash</SKI:paymentmethod>
   <ICAL:class>PUBLIC</ICAL:class>
   <SKI:motivation>Saving the youth of this poor city for
   Christ</SKI:motivation>
   <SKI:advert>http://www.decaturapostlechurch.com/Christ_week_2000/crossbrothers/</SKI:advert>
   <SKI:review>http://www.Americanchristian.com/events/reviews/crossbrothers/tour99.html</SKI:review>
   </ICAL:vevent>
   </RDF:Description>
   </RDF:Bag>
   </RDF>

Note that in this example, the position is only given as the ICAL:location element, which is a street address. Presumably, Decatur is small enough for the citizens to keep track of where things happen. The alternative would be to provide a GML description of the position.

Matching metadata and profile parameters

Given that the position- and location-relevant information are expressed in the same format, it is possible to match them relatively easy, creating a set of parameters that represent the optimum for both the user and the service and that can be used to create the information to be presented to the user. However, this matching is more complicated than a simple matching of attributes to values, being multidimensional. This is one reason to use RDF. Another reason is that it is possible to create systems that conduct this multidimensional matching of user profiles with document profiles.

The matching algorithms for the system have not been standardized within the scope of the CC/PP working group, as this is not necessary for the standardization of the actual format and framework for the profile information. They will most likely be described in terms of the RDF Schema (RDFschema). In the IETF Conneg system, it is assumed that the matching between different capabilities and formats will take place using q values. However, it is safe to assume that different parameters will require different matching algorithms, depending on the data type. For instance, the geographic positioning will require different matching algorithms depending on whether it is represented in geographical coordinates or in country-specific map networks like Rikets Nät (the Swedish national geographic grid).

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 (Ohto)(RDF)(Reynolds).

Specifically, the SKi format expressed in RDF can easily be matched with the position and temporal preferences of the user. In the example above, the content of the ical:geo tag can be matched with TerminalLocation of the user profile, since the two will have the same datatype. If these are both expressed as GML, the matching will be more computationally efficient, an important consideration for the scalability of the system.

In the Dublin Core DC:Coverage-variable, the place name is used to designate the location relevance of the information (DC). Place names are ambiguous. The place "Stockholm" has many possible interpretations (polygons): the "greater Stockholm area"; the current city of Stockholm; the historic city (inside the city wall); and the cities of Stockholm, Minnesota and Stockholm, Papua New Guinea. This will lead to ambiguities and make it impossible to decide the relevance of the information properly, since there will most likely be several registers of place names, which means that the variable must designate which register it uses along with the place name. If the metainformation is presented as RDF, this is less of a problem, since the name space has to be declared anyway; if a text format is used, it will be more difficult to express (RDF)(RDFschema).

If any precision is to be available in the processing of the positional relevance, the place name must also be defined by its coordinates as a polygon. Again, it does not matter greatly which coordinate system is used as long as this definition format is declared. If it is not declared, the granularity of the place name will be doubtful.

The user profile: CC/PP and WAP Forum UAProf

CC/PP

The CC/PP profile is a collection of the capabilities and preferences associated with a user and the agents used by the user 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 (Ohto)(Reynolds).

The basic data model for CC/PP is a collection of tables. These are described as assertions in RDF (RDF)(RDFschema). In the simplest form, each table in the CC/PP is a collection of RDF statements with simple atomic properties. These tables may be constructed from default settings, persistent local changes, or temporary changes made by a user.

The profile is associated with the current network session or transaction but can be made independent of these. Each major component may have a collection of attributes or preferences. Examples of major components are the hardware platform upon which all the software is executed, the software platform upon which all the applications are hosted, and each of the applications.

Some collections of properties and property values may be common to a particular component. For example, a specific model of a smart phone may come with a specific central processing unit, screen size, and amount of memory by default. Gathering these default properties together as a distinct RDF resource makes it possible to independently retrieve and cache those properties. A collection of "default" properties is not mandatory, but it may improve network performance, especially the performance of relatively slow wireless networks.

Using the CC/PP Exchange Protocol (Ohto) and Xpath (Xpath), it becomes possible to address and retrieve sections of a profile and for a device to send updates of a profile to the profile repository (which may be the WAP gateway in the case of WAP, or a HTTP proxy) (UAProf). This means that the user can send his or her position to the origin server without sending the entire profile, something that is relevant to privacy as well as bandwidth matters. It is also possible to make the user's request anonymous, using the functions of the WAP gateway.

Since HTTP is a stateless protocol, from the point of view of any particular network transaction, the only property or capability information that is important is whatever is "current." The network transaction does not care about the differences between defaults or persistent local changes; it cares only about the capabilities and preferences that apply to the current network transaction. Because this information may originate from multiple sources and because different parts of the capability profile may be cached differently, the various components must be explicitly described in the network transaction.

WAP Forum UAProf

WAP was developed by a consortium of companies from the mobile communications industries with the primary intent of bringing information to mobile telephones. As the system has developed, it has become a general system for information transmission based on technologies developed by W3C, and its data formats are converging with those developed by W3C (WAP)(Reynolds)(Ohto).

However, the mobile environment is different from the traditional Web environment. The network is slower, and mobile devices are expected to have an ever-divergent range of input and output capabilities, network connectivity, and levels of scripting language support. Moreover, users may have content presentation preferences that also cannot be transferred to the server for consideration. As a result of this device heterogeneity and the limited ability of users to convey their content presentation preferences to the server, clients may receive content that they cannot store, that they cannot display, that violates the desires of the user, or that takes too long to convey over the network to the client device.

The UAProf specification extends WAP 1.1 to enable the end-to-end flow of UAProf, also referred to as Capability and Preference Information (CPI), among the WAP client, the intermediate network points, and the origin server. It uses the emerging standards for CC/PP (Ohto)(Reynolds). The specification defines a set of components and attributes that WAP-enabled devices may convey within the CPI. This CPI may include, but is not limited to, hardware characteristics (screen size, color capabilities, image capabilities, manufacturer, etc.), software characteristics (operating system vendor and version, support for MExE, list of audio and video encoders, etc.), application/user preferences (browser manufacturer and version, markup languages and versions supported, scripting languages supported, etc.), WAP characteristics (WML script libraries, WAP version, WML deck size, etc.), and network characteristics (device location, bearer characteristics such as latency and reliability, etc.). This specification seeks to minimize wireless bandwidth consumption by using a binary encoding for the CPI and by supporting efficient transmission and caching over WSP (Wireless Session Protocol) in a manner that allows easy interoperability with the CC/PP Exchange Protocol over HTTP.

As a request travels over the network from the client device to the origin server, each network element may add additional profile information to the transmitted CPI. These additions may provide information available solely to that particular network element. Alternatively, this information may override the capabilities exposed by the client, particularly in cases where that network element is capable of performing in-band content transformations to meet the capability requirements of the requesting client device.

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.

Ericsson UAProf Parser

In the WAP Forum UAProf group, several demonstration and proof-of-concept systems have been developed.

Ericsson has created the UAProf Parser as a component for the WAP Application Server product. The aim of the component is to provide a generic and easy-to-use module for developers. The WAP Application Server is a development and deployment platform based on open and extendable application programming interfaces (APIs) that are aimed towards telephony operators, Internet service providers (ISPs), and the development community.

The UAProf Parser is a component that closely follows the UAProf specification from the WAP Forum. The UAProf specification uses the XML application RDF (see "WAP Forum UAProf" section above). When used on origin servers, the module provides a Java-based API that leverages the information received through the profile header. The API allows programmers to create applications that are as general as possible when supporting terminals with various characteristics.

The UAProf Parser is built in two layers. There is the parser (which really is two separate parsers), and there is the middleware, which handles requests from the API and implements the API.

The parser consists of two front ends. The front ends read WBXML (the WAP Forum binary-encoded XML format) encoded or plain text and build a tree out of the information enclosed therein while resolving default values. This resolution process can include the retrieval of remotely located uniform resource locators (URLs) (e.g., the retrieval of a position using a network-computed position through a product such as the Ericsson Mobile Positioning Center), in which case the UAProf Parser also supports proxies. The parsers can call themselves; for instance, if the "binary" parser finds a default URL where information is stored as text, the binary parser calls the text parser to handle the default profile.

The middleware is the manager of all other objects; it also implements the API and realizes the API's methods. The API consists of a set of methods that use the middleware to retrieve data from the tree constructed during the parsing phase. The user of the API can thus perform "get" operations to retrieve values, or lists of values.

In addition to being a component in the WAP Application Server, the component can also be used in other scenarios, such as ordinary Web servers and other products that use the CC/PP framework. The component can be used on a WAP gateway, where it completes all resolving issues before forwarding the profile to the origin server.

For more information on the WAP Application Server or the UAProf Parser, please contact your local Ericsson representative.

Conclusion

The experimental work that we have done demonstrates that a metadescription of the information object can be matched with the user's preferences and device capabilities. This has been extended to the user's position (using future versions of properties like the TerminalLocation property described in GML and the SKiCAL format). Content can be generated or selected based on the position of the user.

We hope that this conclusion will find wide acceptance, as it enables totally new classes of services.

Acknowledgments

We thank our colleagues in Ericsson (especially the WAP group), the WAP UAProf drafting committee, the W3C CC/PP working group, and W3C staff for their support and efforts.

References

[Brown] P. J. Brown, "The electronic Post-it note: A metaphor for mobile computing applications," IEE Colloquium on Mobile Computing and Its Applications, 1995.

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

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

[GML] Ron Lake, Eric Keighan, Jayant Sharma, Barry O'Rourke, and Sandra Johnson, Geography Markup Language (GML) 1.0, OGC RFC11 13 December 1999, http://feature.opengis.org/rfc11/GMLRFCV1_0.html.

[IMT-2000] Experimental WCDMA systems description, http://www.imt-2000.com/wcdma/index.htm.

[Kassing] T. Kassing, T. Wierlemann, F. Deecke, P. Jaya Shankar, B. Kreller, N. Persson, J. Harmer, P. Salomon: Field Trials Analysed Results Issue II, http://www.sics.se/~onthemove/docs/OTM_d47.doc.

[Meggers] Jens Meggers, Anthony Sang-Bum Park, Andreas Fasbender, Birgit Kreller, and Ernö Kovacs, Mobile Multimedia for Small Handheld Devices, to be published in proceedings from the ACTS Mobile Summit 1998 (also available at http://www.sics.se/~onthemove).

[NGDF] NGDF working group, Metadata guidelines, http://www.ngdf.org.uk/Metadata/met_guid.htm.

[Ohto] Hidetaka Ohto, Johan Hjelm, CC/PP Exchange Protocol using HTTP 1.1 Extension Framework, W3C Note June 1999.

[OII] European Commission's Open Information Interchange (OII) service, http://www2.echo.lu/oii/en/gis.html.

[Pascoe] J. Pascoe, "The stick-e note architectecture: Extending the interface beyond the user," International Conference on Intelligent User Interfaces, 6-9 January 1997, Orlando, Florida, USA.

[RDF] Ora Lassila, Ralph R. Swick, Resource Description Framework (RDF) Model and Syntax Specification, W3C Recommendation 22 February 1999, http://www.w3.org/TR/REC-rdf-syntax/.

[RDFschema] 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/.

[Reynolds] Franklin Reynolds, Sandeep Singhal, Spencer Dawkins, and Johan Hjelm, Composite Capabilities/Preferences Profile, W3C Note November 1998, http://www.w3.org/TR/NOTE-CCPP-19990527.

[SKI] Svenska Kalenderinitiativet, an event enhancement for the iCAL standard, under specification, http://www.skical.org.

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

[XMLns] Tim Bray, Dave Hollander, and Andrew Layman, Namespaces in XML, W3C Recommendation 14 January 1999, http://www.w3.org/TR/REC-xml-names/.