UAProf

rdf:langString UAProf

rdf:langString The UAProf (User Agent Profile) specification is concerned with capturing capability and preference information for wireless devices. This information can be used by content providers to produce content in an appropriate format for the specific device. UAProf is related to the Composite Capability/Preference Profiles Specification created by the World Wide Web Consortium. UAProf is based on RDF. UAProf files typically have the file extensions rdf or xml, and are usually served with mimetype application/xml. They are an XML-based file format. The RDF format means that the document schema is extensible. A UAProf file describes the capabilities of a mobile handset, including Vendor, Model, Screensize, Multimedia Capabilities, Character Set support, and more. Recent UAProfiles have also begun to include data conforming to MMS, PSS5 and PSS6 schemas, which includes much more detailed data about video, multimedia, streaming and MMS capabilities. A mobile handset sends a header within an http request, containing the URL to its UAProf. The http header is usually X-WAP-Profile:, but sometimes may look more like 19-Profile:, WAP-Profile: or a number of other similar headers. UAProf production for a device is voluntary: for GSM devices, the UAProf is normally produced by the vendor of the device (e.g. Nokia, Samsung, LG) whereas for CDMA / BREW devices it's more common for the UAProf to be produced by the telecommunications company. A content delivery system (such as a WAP site) can use UAProf to adapt content for display, or to decide what items to offer for download. However, drawbacks to relying solely on UAProf are (See also ): 1. * Not all devices have UAProfs (including many new Windows Mobile devices, iDen handsets, or legacy handsets) 2. * Not all advertised UAProfs are available (about 20% of links supplied by handsets are dead or unavailable, according to figures from UAProfile.com) 3. * UAProf can contain schema or data errors which can cause parsing to fail 4. * Retrieving and parsing UAProfs in real-time is slow and can add substantial overhead to any given web request: necessitating the creation of a Device Description Repository to cache the UAProfs in, and a workflow to refresh UAProfs to check for deprecation. 5. * There is no industry-wide data quality standard for the data within each field in an UAProf. 6. * The UAProf document itself does not contain the user agents of the devices it might apply to in the schema (Nokia put it in the comments). 7. * UAProf headers can often be plain wrong. (i.e. for a completely different device) UAProf device profiles are one of the sources of device capability information for WURFL, which maps the UAProfile schema to its own with many other items and boolean fields relating to device markup, multimedia capabilities and more. This XML data is keyed on the User-Agent: header in a web request. Another approach to the problem is to combine real-time derived information, component analysis, manual data and UAProfiles to deal with the actual device itself rather than the idealised representation of "offline" approaches such as UAProf or WURFL. This approach allows detection of devices modified by the user, Windows Mobile devices, Legacy devices, Spiders and Bots, and is evidenced in at least one commercially available system. The W3C MWI (Mobile Web Initiative) and the associated DDWG (Device Description Working Group), recognising the difficulty in collecting and keeping track of UAProfs and device handset information, and the practical shortcomings in the implementation of UAProf across the industry have outlined specifications for a Device Description Repository, in the expectation that an ecosystem of such Repositories will eventually eliminate the need for local device repositories in favour of a web service ecosystem.