Post details: Summary of Joint Call (DDWG+UWA) - 24 September 2007

Tuesday, October 2nd 2007

Permalink 02:40:08, Categories: Meeting Summaries

Summary of Joint Call (DDWG+UWA) - 24 September 2007

[DDWG and UWAWG Joint Meeting Summary – 24 September 2007] The DDWG and UWAWG held a one hour joint call to discuss matters of mutual concern. In particular, issues relating to the UWA ontology and its relationship to the planned DDR Core Vocabulary were discussed. What follows is representative of that discussion. The DDWG plans not only to create a vocabulary of device properties, whose semantics will be captured in the UWA ontology, but also to create an API with which the value of such properties can be obtained. Developers are generally expected to require simple data types and uncomplicated methods. When retrieving information from the repository, simple Boolean results will suffice. Questions like “Does the current device support GIF images?” will be asked. It is possible that such questions may be followed by more in-depth questions, such as “Does the device’s support for GIF include Animated GIF?” [Note: for much of the discussion, the participants used "supported image formats" as a key example, while acknowledging that the issues go much further than images.] It may seem from the point of view of the API that these properties are all Boolean in nature, that the data to answer such questions is stored as Booleans and that the ontology represents concepts such as “support for an image format” as Booleans. However, this is not the case. From the point of view of the ontology, support for one or more image formats is best represented as an enumeration, whose permitted members may extend as new image formats (or sub-formats or classifications) are identified. With this approach, the ontology does not need to be rewritten to accommodate new image formats. New image formats may occur because a vocabulary may be revised to encompass more than its predecessor. New image formats can also occur as a result of advances in image technology, which prompts the revision of the vocabulary. The way in which the vocabulary and the ontology represent properties (such as supported image formats) does not determine how the corresponding data is stored in a repository. Only the mapping between the concepts represented in the ontology and the values represented in the vocabulary are important. It was agreed that this mapping should form part of the vocabulary definition. There may also be metadata associated with vocabulary items. Once again using supported image formats as an example, a device may support several image formats but in certain contexts it is preferable to use one format over another. Such preferences may be represented in many ways. The example of HTTP “q values” was mentioned. An ordered list is another possibility. If this metadata is represented in the ontology in a particular manner, it is possible that the API will represent the same information in a different manner. It is a role of the vocabulary definition to ensure that there is a mapping between the two. This assumes, of course, that the API designers choose to expose such metadata via the API. While it is possible, and likely, that DDR API will have a simplified view of the data described in the UWA ontology, there is no requirement that the DDR API can also provide a view that is directly mapped to the ontology. For example, if the API may represent “support for feature X” as a Boolean method while the ontology uses enumerations for the same data, then it is not necessary that the API also provide the means to access this data as an enumeration. Nevertheless, there are use cases where accessing the data in the manner represented by the ontology is preferable. The DDR API is intended to support the adaptation of Web content, but this may happen at run time and/or at design time. Boolean methods are likely to be preferable for run time use, but there are design time questions that will require enumerations. For example: “What image formats are supported by this (category of) device?” It will up to the DDWG to determine how complete such methods will be in the core API. It is unlikely that the DDWG will attempt to create an API of extreme complexity and sophistication with respect to accessing ontologies. Other groups and existing technologies are better placed to provide these solutions. Assuming enumerations of values will be found in the ontology, the source of the permitted members of such enumerations must be determined. Using the familiar image formats example, it was pointed out that the DDWG may decide that “GIF” is a sufficient value to represent support for all variants of the GIF format. However, another group that is also contributing to the UWA ontology may, for its own reasons, decide that it needs “GIF” and “GIFa” to distinguish the static and animated variants. This would introduce a conflict in the semantics of “GIF”, and the ontology cannot permit such conflicts. The participants discussed ways to resolve this. The most obvious solution is that the ontology does not capture specific values, and instead relies on these being defined externally. It is only necessary that the ontology know the “type” associated with these values, and that an implementation can uniquely and unambiguously reference these typed values. URIs were designed for such a purpose. Thus the ontology could represent supported image formats for a device as an enumeration of URIs where each URI identifies a typed value. The issue of the definition of “GIF” is therefore resolved, because the two groups would use different URIs for “GIF”. The DDWG could define a namespace for the properties in the core vocabulary, and apply this namespace to “GIF” to distinguish it from a similarly named “GIF” belonging to a different vocabulary in a different namespace. While this sounds like a reasonable resolution to the problem, the participants were cautioned not to devise a solution that that could lead to the creation of many namespaces. Sticking to one is preferred, such as a common namespace for MIME types. The DDWG expects that the vocabulary will reference the ontology for the semantics of the data held in the repository. However, it is expected that both the vocabulary and the ontology will evolve over time. Different versions of each will be released as new requirements are addressed. This leads to an issue of versioning. There was a short discussion on the manner in which a particular version of the vocabulary would reference a particular version of the ontology, but it was inconclusive. To make the work more concrete, the participants were asked to consider some examples of how the DDR API would deal with the Boolean method of determining support for a feature. It is assumed that a Delivery Context Key has already been obtained as a result of device recognition. Here are the three method formats that were suggested to answer the query: “Does the current device support GIF?” supportsGIF(thisDC) supports(thisDC, “cv:claimsGIFSupport”) supports(thisDC, “cv:claimsImageFormatSupport”, “cvif:GIF”) The three proposals were discussed briefly. The first was considered to be inflexible, because new image formats would require new method names to be created, and therefore a new API to be drafted. The second is more extensible, but the third is even more extensible. In order to learn in a practical way if the third format is appropriate for the DDR API, the DDWG members present resolved to incorporate this into the next published draft of the API. Feedback will help refine this approach and make progress. The hour allocated to the meeting rapidly expired and the participants closed the meeting at this point. The next opportunity for a joint meeting will be in November. Attendees: Andrea, Bryan, Jo, Jose, Kevin, Martin, Matt, Mike, Rhys, Rotan, Steph, Rafa, Dave
Rotan Hanrahan


No Pingbacks for this post yet...