- From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Date: Thu, 20 Sep 2007 10:40:26 +0100
- To: <public-ddwg@w3.org>
[Meeting summary - 17 Sept 2007] Supports vs Claims, Booleans vs Enumerations. Today's entire teleconference was dedicated to issues 20 and 21 on the issues list. Issue 20 is about the use of simple Boolean representations, in contrast to structured representations such as sets. The usual example is the representation of support for image formats. Should one have a separate Boolean property for each format (supportsGIF, supportsJPEG, etc) or should one have a set (["GIF","JPEG",...]) that then needs to be scanned to see if your specific format is supported? Meanwhile, issue 21 deals with the meaning of these Boolean values. Does "Supports XHTML" mean that the entire XHTML specification is supported 100% by the browser? If so, then unfortunately (almost) all browsers will have a FALSE value. The alternative interpretation of the property is that this is what is *claimed* to be supported, and any deviations from the claim (where true) will have to be investigated via more refined queries to the repository. Andrea supplied some background to the WURFL experience in this area: "In WURFL we found that there were many different interpretations of tags so members tried to summarise this. XML was chosen to communicate the information because of widespread support, and we went with very simple property names, and we went with Boolean values because of ease of management." Developers demonstrated a preference to work with simple Booleans, and therefore this is an important consideration for the design of the DDR API. Rotan proposed that the same degree of simplicity could be provided via the API, while still permitting the ontology to represent unbounded properties as sets/enumerations. In effect, the API can hide the nature of the ontology for those developers who prefer to keep things simple. Similarly, in cases where the entire set of values is required, the API can provide this too. Assuming the API can provide the desired Boolean values, how should developers treat these values? In practice, if a value of TRUE indicates support for a feature, it does not necessarily mean that the support is complete (e.g. GIF but not animated GIF, XHTML tables but not nested tables). Furthermore, as Bryan noted, in cases where there are alternative supported formats, the Boolean values do not indicate which of the supported formats are preferred. This idea is already present in HTTP's "q values". It may be possible to answer a question about feature support by supplying a list ordered according to preference. As a further refinement of the idea, a Boolean value could be accompanied by metadata to indicate that more information is available. For example, support for XHTML may be indicated as TRUE, but a refined query may reveal that certain XTHML features are not (properly) supported. This was described as the "yes, but" approach. Jo pointed out that if we accept the idea of representing properties as members of enumerations, we should consider the possibility that these enumerations may be extended independently by different groups. For example, one group (the DDR Core Vocab team) may decide that "GIF" will represent support for any GIF format, whereas another group may decide that "GIF" means single-frame images while "GIFa" means multi-frame (animated) images. The conflicting semantics of "GIF" means that these cannot be resolved in the same ontology, unless something like namespacing is employed. It was generally agreed that extensibility is desirable, as is simplicity. Where individual vocabularies decide to create their own values, it should be easy to do so, subsequently easy to create mappings between values known to the vocabulary and corresponding values in the ontology, and finally this extensibility should not negatively impact other groups who employ the common ontology. The group decided that this debate was a good candidate for the agenda of the joint teleconference scheduled for next week. Attendees: Matt Womer (W3C) Martin Jones (Volantis) Andrea Trasatti (dotMobi) Jongpil Yi (Samsung) Rotan Hanrahan (MobileAware) Jose Manuel Cantera Fonseca (Telefonica) Anders Ekstrand (Drutt) Bryan Sullivan (AT&T) Rafael Casero (SATEC) Jo Rabin (dotMobi) Pontus Carlsson (Drutt) Rodrigo Garcia Acevedo (CTIC)
Received on Thursday, 20 September 2007 09:40:45 UTC