Johan Hjelm
Ericsson Research/W3C
W3C MIT LCS
545 Technology Sq
Cambridge, MA 02139 USA
+1 617-253-9630
hjelm@w3.org
Mikael Nilsson
Ericsson Infotech
Lagergrens Gata 2
SE-651 15 Karlstad Sweden
+46-54-29 41 22
mikael.nilsson@ein.ericsson.se
In this paper, we describe a general metadata-based system for context-based information exchange and adaption, building on a standardized mechanism for preferences and capabilities representation, using the W3C Resource Description Format (RDF). We describe how this can be applied to match the users position at the time of the request to the area for which the content author has declared the document to be of interest, and present a rationale for why RDF is an optimal format for this.
The mechanism described is general. If profile information for services, documents, and clients are described in a common format, they can easily be matched with each other. Using a constraint-based mechanism, it becomes possible to create a union of the descriptions which represent an optimal match.
We also arrive at a series of recommendations for future standardizations work.
Personalization, context negotiation, metadata, RDF, device characteristics, WAP, WWW, position dependency
In a mobile system, new information services will become possible [IMT-2000]. One of the more salient features of mobility is that the users position can change between requests for information. Different information sets can be generated for different positions, which is a part of the personalization of the information set for the user [Meggers][Kassing].
To allow for handling this, we have defined a mechanism which 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].
RDF was orginally intended as a metadata description language. The original uses envisioned were encapsulating 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. However, this is not always applicable 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.
While content adaption 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), the adaption of content to other parameters has so far been investigated mostly in isolated systems, which do not attempt to aggregate content from different sites. Positioning has been the starting point for several trials with contextaware mobile devices. Several methods exist for sensing the users location, such as GPS, network-based positioning, active badges, and others. If, however, a topcial 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", as Pascoe points out).
This also means that the 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.
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. It is commonly encoded in XML, which makes it possible to manage it using the emerging XML software infrastructure. The hope is that the use of a common technology to encode metadata describing both content and a users preferences will encourage the adoption of the technology and simplify the use of metadata in the Web. Powerful tools for dealing with XML and RDF, some of which are already under development, will be available.
Any RDF graph consists of nodes, arcs and leafs. Nodes are resources, arcs are properties and leafs are property values. An RDF graph based on the previous example that includes "Default" properties for each major component is relatively straightforward.
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 CCTV cameras, this would be undesirable for privacy reasons). These methods include:
GPS, user input, and beacons all deliver the position directly into the terminal. Network-based positioning delivers the position information to a proxy, from where it can be retrieved to the terminal. If the position is handled as the TerminalLocation attribute of the CC/PP profile, then this can either be derived from the device and transmitted as a CC/PP Exchange override [WAP][Reynolds][Ohto]; 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.
4.1 Position-relevance in metadata
Position relevance is expected to be one of the primary drivers for context dependent information, as witnessed by the experimental systems described in this paper. 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. How it relates to the position is irrelevant to the current discussion, but the relevance may occur in a variety of ways: Describing the physical object at the position, describing an event occurring at the position, etc.
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, and forwards them to the user. The real problem is to determine the information objects that are relevant to the user in the position.
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 IETF is intended to address this issue [SKI].
Information is location relevant if it can provide the user or an agent acting on his behalf with information that can affect the situation of the user. How the relevance occurs is not relevant to the current discussion (the granularity may depend on how hungry we are when we want to find a lunch restaurant - the closer, the better - but that is immaterial to the current discussion). The user perceives physical objects as having different degrees of relevance depending on the current context and the distance of the object from the user.
Relevance may also depend on the role of the user. For instance, at lunchtime, we may be interested in finding the restaurant that is within the nearest few blocks to our work, but when being tourists in a foreign city, we may be interested in the location of all the museums in the city. This can also be time-dependent (we are more interested in which museums exist in the morning, when planning our day; and interest in lunch increases around noon) and dependent of the mode of locomotion (when travelling by car we will not have the same ability to stop suddenly as a user on foot, nor will we be able to use restaurants without parking space) but that is a discussion that will not be addressed in this paper.
The problem of providing the information that is relevant in the user context can not 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.
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 meta-index which could be used in the same manner as robots today to retrieve information that is relevant to the current context of the user. 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.
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" having at least six possible interpretations (polygons), for example (Stockholm, the capital of Sweden as the commune of Stockholm; as the "greater Stockholm area"; as the current city of Stockholm; and 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 meta-information is presented as RDF, this is less of a problem, since the namespace 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.
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 (some research applications were discussed previously).
The triggering can be more related to the users needs if it is dependent on several contextual elements. An example could be information presented to a tourist that can depend 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 winter, and for beaches if the weather is nice and in summer).
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 minimizing the cognitive load of the user.
4.2 The SKi Format for event presentation
An example of the representation of event information is the SKiCal format, developed by Svenska Kalenderinitiativet [SKI]. Work is underway to express this in 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 what you need to describe a meeting. Besides VEVENT, there are a number of other events in the iCalendar format, such as VTODO, VALARM, etc. 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. such information as the location of an alternate text representation for a property value, the language of a text property value, the data type of the property value and other attributes. The general rule for encoding multi-valued 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).
Besides the fields (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 it 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.
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, a to-do, a journal entry, time zone information, or free/busy time 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:
<rdf:RDF>
<xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ski="http://skical.org/metadata/skical#"
xmlns:ical="ftp://ftp.ietf.org/rfc/rfc-2445.txt">
<rdf:Description about="http://www.sydneyopera.co.au/concert.html">
<ski:x-ski-placename>Sydney Opera House</ski:x-ski-placename>
<ical:geo>37.386013;-122.082932</ical:geo>
<ski:x-ski-performer>
<rdf:Bag ID=”Performer">
<rdf:li Victor Borge/>
<rdf:li James Galway/>
</rdf:Bag>
</ski:x-ski-performer>
<ski:x-ski-openingtimes>
<rdf:Bag ID=“Openingtimes”>
<rdf:li vcal:open>18:00</rdf:li>
<rdf:li vcal:close>21:00</rdf:li>
</rdf:Bag>
</ski:x-ski-openingtimes>
</rdf:Description>
</rdf:RDF>
5. The CC/PP profile
In the W3C, we are working on a framework for the description of the users device capabilities and his preferences for their use, the Composite Capability/Preference Profile (CC/PP) framework. The CC/PP profile a collection of the capabilities and preferences associated with 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 [Reynolds][Ohto].
The basic data model for a CC/PP is a collection of tables. These are described as assertions in RDF, the W3C Resource Description Format [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 executing, 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 CPU, 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.
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 a CC/PP is the current network session.
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 only cares 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 differentially cached, the various components must be explicitly described in the network transaction.
The CC/PP specification does not mandate a particular set of components or attributes, choosing instead to defer that definition to other standards bodies. The CC/PP Exchange Protocol over HTTP [Ohto] enables CC/PP profiles to be transported over the HTTP 1.1 protocol with the HTTP Extension Framework. This protocol enables effective profile caching at Web servers and proxies.
5.1 WAP Forum UAPROF
The Wireless Application Protocol system was developed by a consortium of companies from the mobile communications industries with the primary intent of bringing information to mobile telephones. Its development was based on the CC/PP format from the 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 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 User Agent Profile (UAProf) specification extends WAP 1.1 to enable the end-to-end flow of a User Agent Profile (UAProf), also referred to as Capability and Preference Information (CPI), between the WAP client, the intermediate network points, and the origin server. It uses the emerging standards for Composite Capability/Preference Profile (CC/PP) [Reynolds][Ohto].
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 optionally 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 for 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.
The matching algorithms for the system have not been standardized within the scope of the CC/PP WG, 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 matchings dependent on wether it is represented in geographical coordinates or in country-specific map networks like Rikets Nät (the Swedish national geographic grid).
Given an RDF representation of the document profile data, this 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 roundtrip traffic; the CC/PP profile can be cached in the server and re-used 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 [Reynolds][Ohto][RDF].
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, since the two will have the same datatype.
6.1 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 extensible API's that are aimed towards telephony operators, ISP's, and the development community.
The UAProf-Parser is a component that closely follows the User-Agent Profile (UAProf) specification from the WAP Forum. The UAProf specification uses the XML application RDF (see section "WAP Forum UAPROF"). 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 application that are as general as possible, when it comes to supporting terminals with various characteristics.
The UAProf-Parser is built in two layers. The parser (which really is two separate parsers), 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 builds a tree out of the information enclosed therein while resolving default values. The resolving can include the retrieval of remotely located URL's (e.g the retrieval of a position using a network-computed position through a product such as the Ericsson Mobile Positioning Center, MPC), in which case the UAProf-Parser also supports proxies. The parsers can call themselves, if for instance, 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 its methods. The API consists of a set of methods which uses 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.
The experimental work that we have done demonstrate the concept: A meta-description of the information object can be matched with the users preferences and device capabilities. This has been extended to the users position (using the TerminalLocation property and the SKiCAL format). Content can be generated or selected based on the position of the user.
Our hope is that this will find wide acceptance, as it enables totally new classes of services.
In our view, RDF is eminently suitable for position-relevant metadata. No new or separate applications are needed for the transmission of the position information or the comparison with the metadata instance, and the transport mechanisms which the W3C has defined on top of the HTTP transport protocol can be used.
We therefore recommend that:
A standardized vocabulary for the representation of position relevant information and position formats in metadata be arrived at in the different standards organizations involved (e.g. the SKICAL group, the WAP Forum Telematics Group).
A standardized vocabulary for the representation of position relevant information and position formats in device profiles be arrived at in the different standards organizations involved (e.g. the W3C CC/PP working group, the WAP Forum UAPROF group).
A standardized format, or set of formats, for position relevance be arrived at in the different standard organizations involved.
The privacy aspects of position information be especially carefully regarded (e.g. in the scope of the W3C CC/PP Working Group).
We thank our colleagues in Ericsson (especially the WAP group, but none named and none forgotten), the WAP UAPROF drafting committee, W3C CC/PP working group, and W3C staff for their support and efforts.
[Abowd] Gregory D. Abowd, Christopher G. Atkeson, Jason Hong, Sue Long, Rob Kooper and Mike Pinkerton: Cyberguide: A Mobile ContextAware Tour Guide. Baltzer Journals September 23[SKI]96, and http://www.cc.gatech.edu/fce/
[Brown] Brown 1995: P. J. Brown, "The electronic post-it note: a metaphor for mobile computing applications", IEE Colloquium on Mobile Computing and its Applications[SKI]95.
[DC] The Dublin Core Metadata Element Set home page is at http://purl.org/metadata/dublin_core/
[Friday] Adrian Friday : Infrastructure Support for Adaptive Mobile Applications, Ph.D. Thesis, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., September 1996, ftp://ftp.comp.lancs.ac.uk/pub/mpg/MPG-96-40.ps.gz
[Broadbent] Jonathan Broadbent, Patrizia Marti: Location aware mobile interactive guides: usability issues. Paper at ICHIM '97, Paris, September 1997. Also available from http://www.ing.unisi.it/lab_tel/hips/hips_pub.htm
[MCFE] The MCFE project web pages are at http://www.cs.ukc.ac.uk/research/infosys/mobicomp/
[IMT-2000] Experimental WCDMA systems description, at http://www.imt-2000.com/wcdma/index.htm
[Pascoe] Pascoe, J. "The stick-e note architectecture: extending the interface beyond the user", International Conference on Intelligent User Interfaces, January 6-9 1997, Orlando, Florida, USA.
[Meggers] Jens Meggers, Anthony Sang-Bum Park, Andreas Fasbender, Birgit Kreller, Ernö Kovacs: Mobile Multimedia for Small Handheld Devices, to be published in proceedings from the ACTS Mobile Summit 1998. Also accessible from the project web server at http://www.sics.se/~onthemove.
[WAP] Specifications for Wireless Application Protocol (WAP) version 1.1, http://www.wapforum.org
[Dey] A Context-based Infrastructure for Smart Environments. Anind K. Dey, Daniel Salber and Gregory D. Abowd. To appear in the Proceedings of the 1st International Workshop on Managing Interactions in Smart Environments (MANSE '99), Dublin, Ireland, December 13-14 1999.
[Dey2] Towards a Better Understanding of Context and Context-Awareness. Anind K. Dey and Gregory D. Abowd. GVU Technical Report GIT-GVU-99-22. Submitted to the 1st International Symposium on Handheld and Ubiquitous Computing (HUC '99), June 1999.
[Schilit] Context-Aware Computing Applications. Bill N. Schilit, Norman I. Adams, and Roy Want. In Proceedings of the Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, December 1994. IEEE Computer Society. <URL: ftp://ftp.parc.xerox.com/pub/schilit/wmc-94-schilit.ps>
[Kassing] Report AC034 / Burda / WP3 / DS / I / 047 / b1 , 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>
[Reynolds] Composite Capabilities/Preferences Profile, Franklin Reynolds, Sandeep Singhal, Spencer Dawkins, Johan Hjelm. W3C Note November 1998. http://www.w3.org/TR/NOTE-CCPP-19990527
[Ohto] CC/PP Exchange Protocol using HTTP 1.1 Extension Framework. Hidetaka Ohto, Johan Hjelm. W3C Note June 1999. http://www.w3.org/TR/NOTE-CCPPexchange
[RDF] Resource Description Framework (RDF) Model and Syntax Specification. Ora Lassila, Ralph Swick, W3C Recommendation February 22, 1999. http://www.w3.org/TR/REC-rdf-syntax/
[RDFschema] Resource Description Framework (RDF) Schema Specification, Dan Brickley, R.V. Guha, March 3, 1999. http://www.w3.org/TR/PR-rdf-schema/
[SKI] Svenska Kalenderinitiativet, an event enhancement for the iCAL standard, under specification. <http://www.skical.org>