This document describes a recommended approach for modeling mailing systems capabilities and the reasons behind such an approach. It starts with a review of related work[1] followed by a discussion about how our task of modeling mailing machines is the same and different from the prior work – highlighting issues specifically related to our mail finishing devices, and an ends with a proposal for building a schema for mailing system descriptions that leverages what applies from prior art and what still needs to be addressed.

An underlying assumption behind much of the available prior work, well stated in the Delivery Context Ontology specification, is: "… a user is interacting with a particular computing platform in a given physical environment in order to achieve an interactive task." The target devices being described are mostly mobile, especially cell phones, that run one or more interactive, web-based applications. Though our current emphasis is more on describing capabilities for autonomous, electro-mechanical devices with limited user interaction, the prior art serves as a good starting place. We should use the prior art to help frame our approach, but first need to determine the core thought and learnings from the prior art to design a better frame for us to begin to learn about representing and using mailing systems capabilities.

Background on Device Independence Standards and Related Efforts

CC/PP

In the summer of 1999, the World Wide Web Consortium (W3C) chartered a working group tasked with developing an open standard for better mapping web content for web clients running in diverse devices. The effort was called Composite Capability/Preference Profiles (CC/PP). The early emphasis was to create a framework for modeling arbitrary devices, in a way that could be agnostic to the actual characteristics of the device and user interaction. The framework was intended as a base for device specific models that would provide a device-specific vocabulary. An official CC/PP Version 1.0, leveraging the Resource Description Framework, was provided in January 2004 [1].

UAProf

As the CC/PP standard was being designed, the Open Mobile Alliance [2] leveraged initial versions to create a compliant vocabulary specialized for mobile devices, creating a User Agent Profile (UAProf) specification in October, 2001 [3]. As the UAProf specification was used within the telecommunications industry, deficiencies with the underlying use of RDF were discovered. The users of UAProf were not alone in uncovering deficiencies on RDF, and so the W3C enhanced RDF with a schema and data typing. A new RDF standard, called RDF Schema was introduced by the W3C in February, 2004. A new version of the UAProf specification was released in February 2006[4], stating: "… it is imperative for UAProf to continue to adopt relevant changes being proposed by the W3C. In particular this version of UAProf adopts advances in the RDF Schema and datatyping language that enable automatic processing of UAProf's schema and increase interoperability."

WURFL

Around 2004, another effort was started for helping map web content (specifically WML) onto wireless devices. The Wireless Universal Resource File (WURFL) was created as an open source project [5]. "The WURFL is an XML configuration file which contains information about capabilities and features of many mobile devices. … The main scope of the file is to collect as much information as we can about all the existing mobile devices that access WAP pages so that developers will be able to build better applications and better services for the users." Like CC/PP, the format for entries contained in the WURFL are device agnostic. A generic "capability" element with name/value attributes is used for each capability. And, capabilities can be sorted into group elements, which provide an id attribute. The WURFL project also includes an interface for managing the repository. Support for UAProf-defined information is provided via a tool that transforms the capabilities provided by the UAProf into the WURFL XML, and including a capability element with the name="uaprof" and the value=[location of the profile] in the group "product_info" group.  Currently, there are thousands of device descriptions available in the repository.

Device Independent Interfaces

The W3C offers two interfaces that provide information carried in device capability profiles to applications. The Device Description Repository (DDR) Simple API [6], recommended in December 2008, sounds comparable to the WURFL access API. The idea is that there will be a single repository that web servers use for accessing device capability information needed for transforming web content for specific devices. This transformation works well for static capabilities. Capabilities that can be dynamically changed by device users cannot be addressed at the server. For highly dynamic capabilities, e.g., location, the W3C has a DOM-based, client-side Interface standard called Delivery Context: Client Interfaces (DCCI) [7], introduced in December 2007. Both interfaces access device capabilities documents, based on implementation, and provide the information to applications that rely on information about capabilities for tailoring the behavior of the applications.

Delivery Context Ontology

An effort for creating a new version of CC/PP that leveraged RDF Schema was also launched. The CC/PP standard, like UAProf version 2.0, needed to be updated to reflect improvements in the underlying RDF technology. It also needed to fully support the updated UAProf vocabulary. A Last Call for comments was issued for this updated version in July, 2007[8] and at this time, the standard has been put on hold. Instead, the updated version of CC/PP appears to have been superseded by the Delivery Context Ontology (DCOntology), which is currently in last call as of June 2009. The DCOntology uses the OWL extensions to RDF/Schema, enabling device information stored in repositories to be even more richly used. So, in addition to being able to merge capabilities partially described across description files for the same device – as is supported with RDF Schema, more complex data representations and inferences can be supported, through the use of the OWL extensions.  

Data Representation within the MSC

Last summer, FMT introduced the concept of mailing system capabilities to support the notion of provisioning product descriptions onto diverse mailing systems. As part of this effort, we noted many deficiencies in the CC/PP model, including many ad hoc entries that appeared in odd places, e.g. the way cameras were modeled. We also extended the representations to include mechanical aspects of devices and improved and extended the representation of software capabilities. Given the breadth of changes, time pressures, need to integrate into our current code base and tool set, and our lack of understanding why semantic web technologies were chosen over straight XML schema, we recast the model represented in the Delivery Context Ontology[2] into XML Schema.

We have now revisited the Delivery Ontology effort, looked more deeply into the semantic web technologies, and uncovered the hidden underlying assumption of large device repositories. The early view for CC/PP was that the description file would be passed along with the Web page request, thus the file would be used primarily programmatically. However, property descriptions could be distributed across the web, for example a description of the capabilities of a cell phone may reference a specific camera, and the description for that camera may be located at a remote site provided by the camera manufacturer. The file passed through the request would be a merged version of the cell phone and camera properties. RDF naturally supports merging of distributed data.

As understanding of web content transformations grew, the method of access to capabilities file evolved to a more repository-centric view. Web applications would extract "evidence" properties carried in the request header, and use the evidence to access a description document in a large repository. Deriving implicit relationships across merged information could potentially help provide more complete capability descriptions - hence (IMHO) the move to OWL.

Ultimately, the same forces are at play for mailing systems. Such systems can attach to peripherals that may be described elsewhere. In addition, mailing systems can be part of a much larger production line so inferencing across device description documents may prove useful in the future.

Proposal for Representation

Focus

This iteration of work for mailing systems capabilities is targeted at understanding what capabilities are needed to more completely represent real mail finishing systems so that a product description can be used to fully provision the system within the capabilities available on the described system.

Method and Mitigation

Extending the Delivery Context Ontology or crafting a modified clone in OWL would, conceptually, be best – except that both OWL and Delivery Context Ontology specifications are in last call. They are not yet recommended standards and so will likely change. Also, the tools available for semantic web technologies are still emerging. XML Schema tools are plentiful and much more stable. Therefore, the method used last summer will be used again, with some modifications to ensure that we provide a reasonable way to migrate data representations.

The Mailing System Capabilities schema will be directly derived from the updated Delivery Context Ontology, which has changed significantly from the earlier recast of CC/PP. Modifications in the underlying structure, should change be warranted, will be documented and provided to the Delivery Context Ontology Working Group as comments to the last call. Extensions needed for the more mechanical aspects of the mailing system will also be documented. These extensions and others for modeling characteristics of larger mail production lines will be communicated to the W3C as a potential new activity, one that investigates a Delivery Context Ontology standard for the consumption of web-based content by automated (potentially head-less) devices.

To mitigate the impact of technology choice on the applications that use device capabilities, the DDR interface will be implemented. For the time being, the DCCI interface will not be implemented. Eventually though, the DCCI interface may be useful to help shape user interfaces for specific combinations of postal products and mailing systems. One potential step towards this use is to further investigate how DCCI and standard interface technologies like XForms could potentially interplay.

Maturity

As the semantic technologies and related tools mature, we can easily move our information representation from XML to OWL using fairly straightforward transforms, as structured data can be easily represented in OWL. The use of the DDR interface will shield any such change from the developed applications, though we will need to provide (or find and leverage) an OWL-based implementation of the interface.

Bibliography

[1] CC/PP Version 1.0:  http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/.

[2] Open Mobile Alliance: http://www.openmobilealliance.org/

[3] UAProf Version1.1: http://www.openmobilealliance.org/tech/affiliates/wap/wap-248-uaprof-20011020-a.pdf

[4] UAProf Version 2.0: http://www.openmobilealliance.com/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf

[7] DCCI: http://www.w3.org/TR/DPF/