Summary of joint meeting - 24 Sept 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

Received on Tuesday, 2 October 2007 02:33:27 UTC