=Paper=
{{Paper
|id=Vol-40/paper-10
|storemode=property
|title=RDF Models for Dynamic Syndication and Wireless Applications
|pdfUrl=https://ceur-ws.org/Vol-40/shklar-semweb2001.pdf
|volume=Vol-40
}}
==RDF Models for Dynamic Syndication and Wireless Applications==
https://ceur-ws.org/Vol-40/shklar-semweb2001.pdf
RDF Models for Dynamic Syndication and Wireless
Applications
Leon Shklar
Information Architects
70 Hudson St.
Hoboken, NJ 07030, USA
shklar@cs.rutgers.edu
ABSTRACT syndication models can be naturally extended from targeting
Machine-understandable metadata is providing the foundation for different content channels to enabling the expanding variety of
next-generation frameworks that enable automated construction desktop and wireless devices.
of server-side Java applications. Such applications are composed Emerging commercial products support multiple devices by
of metadata objects implementing RDF models and Java classes building libraries of device-specific XSLT stylesheets to
that use metadata objects as processing context. Using RDF to transcode XML content. Such stylesheets may be fairly efficient
support dynamic transformation of content to different channels when compiled into Java bytecode (Sun distributes the XSLT
and devices opens up opportunities for multi-purpose content compiler). The problem is in maintaining stylesheet libraries for
services that target different audiences and a wide variety of the rapidly growing variety of new and evolving devices, let
desktop and wireless devices. Such services do not have to alone device personalization. The proposed solution is to change
depend on costly maintenance to keep up with new, evolving, the level of granularity of transformations and design them for
and personalized devices. Properly designed applications that are individual features rather than devices. Using RDF models to
built in the era of cell phones and palm devices should still work implement device and user agent profiles, it is possible to
for interactive TV and futuristic Star Trek-like personal dynamically compose transformations by adapting and combining
communicators. feature-based stylesheets, making it unnecessary to build and
maintain ever-expanding libraries of complex device-specific
Keywords components.
Metadata, RDF, Transformation, Wireless. W3C, in coordination with the Wireless Access Protocol (WAP)
Forum, is developing the Composite Capabilities/Preference
1. INTRODUCTION Profiles (CC/PP) specification as the standard for setting device
The Resource Description Framework (RDF) is a metadata and user agent preferences. The upcoming RDF-based
standard that was designed by the World Wide Web Consortium specification would allow defining a device by its features (e.g.,
(W3C) to enable Web applications that depend on machine- screen size, keyboard (if any), display characteristics, etc). Next-
understandable metadata and to support interoperability between generation servers that target multiple devices would combine
such applications. It targets a number of important areas that device and user agent profile information with connection
include dynamic syndication and personalization, mobile devices, bandwidth and use it to construct stylesheet transformations. An
resource discovery, intelligent agents, content rating, intellectual efficient server would optimize stylesheet construction by
property rights, and privacy preferences. RDF uses XML to caching components, as well as intermediate composites. For
encode and transport RDF models but may also use alternative example, caching device-specific stylesheets that are constructed
mechanisms in the future. based on individual device profiles and combining them with
Applying RDF to redesigning the syndication process makes it stylesheet components that are determined by the operating
possible to model content subscriptions. Instead of having to system, user agent software, and connection bandwidth.
receive scheduled distributions of content, subscribers can direct Currently, the main practical limitation is the lack of CC/PP
their customers to syndicators' sites, while syndicators use the support on the part of device vendors and service providers; it is
subscription models to recognize subscriptions (e.g., based on likely to be remedied in the near future. In the prototype, we
User-Agent or HTTP-Referer HTTP headers) and implement our own version of this service based on the local
dynamically tailor content to subscribers' profiles. RDF-based database of CC/PP-based device profiles. This implies that
administering the server involves maintaining device and user
Permission to make digital or hard copies of all or part of this work for profiles, which is orders of magnitude less work than
personal or classroom use is granted without fee provided that copies are maintaining device-specific XSLT transformations. Even this
not made or distributed for profit or commercial advantage and that copies overhead will not be necessary when CC/PP becomes the
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific recommendation and vendors start providing CC/PP services.
permission and/or a fee.
2. DEVICE SPECIFICATIONS
Semantic Web Workshop 2001 Hong Kong, China.
We begin by discussing sample RDF specifications for devices
Copyright by the author. and user agents. These specifications, when represented as
addressable metadata graphs, will provide processing context for
Consider the XML-encoded RDF specification describing a
rdf:resource="http://www.mozilla.org/wap/profiles/
rdf-syntax-ns#" Symbian-
xmlns:ccpp="http://www.w3.org/2000/07/04- beta
ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccpps
chema-19991014#">
about="http://www.mozilla.org/wap/profiles/Mozilla
"> Individual Here, ccpp:Defaults elements reference default
uaprof:BrowserVersion override default properties of the
Mozilla device and user agent correspondingly. The resulting profile,
when interpreted by the server-side transformation agent, would
Symbian
compiled into Java bytecode and cached on the server.
A feature-based approach to building device profiles helps to
text/plain
text/vnd.wap.wml automate targeted transformations of XML content. A new and
unknown device may be analyzed and mapped to a known device
with the closest set of features. The resulting specification gets
stored in a repository and serves as the basis for combining
transformations into a single XSLT stylesheet.
Here, the subject of the description is
http://www.mozilla.org/wap/profiles/Mozilla . The
rdf:type element identifies the subject resource, the
uaprof:BrowserName identifies the browser name as
Mozilla ,
uaprof:BrowserVersion identifies the browser version as
Symbian , and
uaprof:CcppAccept defines MIME types
supported by the browser.
Individual devices and user agents are likely to differ from
default configurations. For example, my xyz device may have an
optional screen, and I may have configured my browser to
support HTML in addition to plain text and WML. However, it is
possible to incorporate default configurations by reference. My
profile would have the following form:
3. CC/PP SERVER
Since CC/PP is defined as an RDF application, our approach is to
models as processing context for programmable plug-ins. In this
320x200 inference engine. Instead, we are taking a pragmatic approach by
supporting a Java API for pluggable Actor modules that get
invoked in the context of the nodes in the RDF graph.
The system graph is composed of three sub-graphs - the content
graph that models content and encapsulates content retrieval
functionality, the delivery graph that models end-user devices 3. Invokes the content retrieval Actor to perform the
and browsers, and the transformation graph that models feature- following steps:
based transformations (see Figures 1 and 2). The distinction 3.1 Recursively refer to other content nodes and
between the sub-graphs is semantic; structure-wise they are all invoke their associated content retrieval Actors (if
RDF graphs and are connected to the same root node. For required).
convenience, we will refer to content nodes, delivery nodes, and 3.2 Compute and apply content-specific transformations
transformation nodes depending on the context of the respective
graph. Note that the same node may belong to more than one based on device and user agent profiles.
graph (e.g., the node associated with the "screen size" feature 3.3 Apply profile-based content-independent
belongs to both the delivery graph and the transformation graph). transformations.
The idea of our system is to promote the design of content The architecture allows for multiple content retrieval and
transformations for features and not devices. Adding support for transformation actors that implement different policies for
a new device will only require creating a new feature profile and content aggregation, feature profiling, and the composition of
even this will become unnecessary in the future. The further idea stylesheet transformations. Transformation actors are responsible
is to separate out content-independent components of feature- for compiling feature profiles that they use to compose XSLT-
based transformations and to minimize the amount of design based transformations. Feature profiles are also used by content
work needed to define transformations when adding new content. retrieval actors for the purpose of selecting and composing
content-specific transformations. Content retrieval actors get
invoked recursively and may or may not apply transformations to
their content components.
3.2 Content Transformation Actors
Content transformation actors are responsible for figuring out
device and user agent features based on device identification and
user preference profiles that may include information about
custom extensions (e.g., additional memory) or preferences
regarding not making use of certain features that are available
with the device (e.g., keyboard).
In the future, with the support for the CC/PP standard, we will
expect browsers to submit either CC/PP specifications or
Figure 2. Sample Model - Transformation and Delivery references to such specifications. The specification may be
Subgraphs. further refined based on user preferences but it will be the
primary source for building device feature profiles. Our
3.1 Server Operation implementation is designed to function in the absence of CC/PP
Details of the server operation are illustrated in fig. 1. User support but benefit from such support when it becomes available.
requests are always directed at a content node. When the To this end, the server maintains a local repository of device
Controller receives the first request in a session, it performs the specifications. Device identities may be inferred by the
following steps: transformation actor based on information in the request (e.g.,
User Agent). They may also be identified by authenticating users
1. Sets references to content retrieval and transformation and retrieving device preferences from their profiles.
Actors according to the following priorities (in descending Having inferred information about the type of the device the
order): transformation actor checks for the availability of user
1.1 information in the request; preferences and creates the device feature profile based on
1.2 properties of the content node; combining this information. For example, the User Agent header
1.3 global defaults. in the request indicates the version of the browser that runs on a
Motorola cell phone of a particular model. The transformation
2. Invokes the transformation Actor to perform the following actor queries the local repository for device features and creates
steps: the initial profile. This profile may get modified based user
2.1 Establish a new session. preferences.
2.2 Traverse the delivery graph to compute device and For example, I may have upgraded memory on my Motorola cell
user agent profiles and store them in the session. phone. The transformation actor can at best infer the make and
2.3 Check for the availability of cached content- model of my device based on information in the request but it
independent transformations for computed can not learn about and take advantage of my upgraded memory.
profiles; if such transformations are not available, However, I can list my devices and their upgrades in my profile.
traverse the transformation graph, compute the The transformation actor can use this information to update the
transformations, and store them for future use. initial feature profile that gets retrieved from the local repository.
Once the transformation actor compiles the feature profile, it is conducive to applying content-specific transformations may
uses it to combine feature-based XSLT transformations (if the have dramatic affect on presentation quality.
target transformation is not already available). It passes the
feature profile to the content retrieval actor that may use it to 4. CONCLUSIONS
select and/or compose content-specific transformations. Once the The future direction of RDF, CC/PP, and related standards has
transformation actor receives partially transformed content from immediate implications on design and development of wireless
the content retrieval actor, it applies feature-based applications. This includes building separate classes responsible
transformations and returns the result. for the assembly and transformation of content, and
implementing feature-based XSLT stylesheets that may be
3.3 Content Retrieval Actors assembled into device-specific transformations. The way is open
Content retrieval actors are responsible for interpreting request for commercial wireless application development products that
context and using it to control retrieval and transformation of do not make use of proprietary formats and protocols and that
content. A content retrieval request always targets a metadata establish a clear path for supporting W3C and WAP Forum
node that provides the processing context, along with request standards.
headers and session information which includes the feature RDF is emerging as the foundation for next-generation
profile of the target device. Node metadata may reference frameworks that enable automated construction of Java
content, applications, or recursively refer to other metadata applications. Such applications are composed of networks of
nodes. It may also reference content-specific XSLT stylesheets metadata objects implementing RDF models and Java classes
that get selected based on feature profiles for target devices. that use metadata objects as processing context. Using RDF for
For example, a metadata node may reference a fragment of an wireless applications opens up opportunities for building next-
XML file, and two other metadata nodes that, in turn, are generation mobile services that don't depend on costly
associated with a database query and an LDAP query maintenance to keep up with new, evolving, and personalized
correspondingly. The content retrieval actor that gets invoked in devices. In other words, properly designed applications that are
the context of the first node retrieves the XML fragment and built in the era of cell phones and palm devices would still work
recursively invokes content retrieval actors for the referenced for future microwave ovens that connect to the Internet to
nodes. Content retrieval actors for the query nodes may select download cooking instructions.
and apply their own transformations to query results prior to
returning them to the original content retrieval actor. Having 5. REFERENCES
received all responses, the original content retrieval actor may [1] Composite Capabilities/Preference Profiles, Work in
apply different transformations depending on whether the Progress, W3C.
browser is running on a cell phone or a desktop computer.
[2] Resource Description Framework Model and Syntax
3.4 Summary Specification, W3C, 1999.
Our RDF server is designed to provide metadata context for [3] Resource Description Framework Schema
functional actors. Transformation actors are responsible for Specification 1.0, W3C, 2000.
building feature representations of end user devices and for using
the feature models to assemble content-independent XSLT [4] Didier Martin, How would you like that served?,
transformations. Content retrieval actors are responsible for xml.com, 2001.
retrieving and partially transforming content. Content design that