Hi,

My take is that the current version of the ontology does not represent an ontology of the Delivery Context, but an ontology of certain aspects of the Delivery Context. i.e. we need properties that would be in the domain of the DeliveryContext class

I think we need to discuss more on this in the UWA and in fact I think this has a lot of  to do with the modularization of the current ontology and the possibility of separation in different pieces, such as:

+ Device Ontology
+ Browser Ontology
+ Location Ontology
+ User Ontology

etc

Best Regards

Rotan Hanrahan escribió:

[Forwarded to the UWA public list in respect of the UWA’s public status.]

 

The DDWG is having some issues regarding the mapping of their vocabulary entries to entries in the UWA ontology. The DDWG API design calls for properties to belong to certain aspects. The actual aspects have not been defined yet, but these are likely to include things like “display”, “camera” and “browser” (to name just a few). A property in the DDWG viewpoint is something generic like “vendor”, which may be applied in one or more aspects. In that way one can have a vendor of the browser, separate from the vendor of the platform and so on.

 

Sample Question: To what part of the ontology should the DDWG’s property called “vendor” be mapped, when no particular aspect is being identified?

 

This question arose because at the recent DDWG weekly call we noted that the DDWG’s properties were actually at a higher level than (some of) the items in the UWA ontology. To some, on first reading, this might seem to be counter to what one would expect of a vocabulary and ontology. (That is, the vocabulary would be specific, while the ontology would be more generic.) However, the DDWG’s specificity is achieved through the introduction of aspects, which do not at this point appear to have a corresponding ontological representation.

 

To make this concrete, earlier this week I circulated a table that showed how some of the DDWG property/aspect combinations would be mapped to corresponding entries in the ontology. There was support during the DDWG call for this approach. It was proposed that I circulate the email and attachment to the UWA for consideration.

 

It is now our intention to publish a first draft of the DDWG’s vocabulary document, but the issue of cross-referencing will only be mentioned as part of editor comments in the document, and will remain so until we have come to a mutual understanding of how to proceed.

 

Note: it is expected that the DDR API will support the idea of querying on the basis of a DDWG Property alone (i.e. without mentioning an aspect) in which case it will be up to the implementation of the API to determine what aspect should be assumed, or throw an exception if no such determination can be made. We acknowledge that the presence of such potential implementation differences causes issues for interoperability, but this is inevitable and not altogether undesirable in light of commercial differentiation. However, a more deterministic behaviour is possible when aspect is included as a query parameter, and this one can expect to form the basis of interoperability requirements.

 

The DDWG would like to hear from UWA on this issue, particularly in respect of providing bindings from DD vocabulary properties to UWA properties, bindings from DD vocabulary properties+aspects to UWA properties, and possibly from DDWG vocabulary aspects to UWA properties (or other information within the ontology).

 

---Rotan (DDWG chair).

 

From: Rotan Hanrahan
Sent: 28 November 2007 14:02
To: DDWG
Subject: RE: Cross references to the Ontology

 

Attached is a start of a mapping that incorporates DD property, DD aspect and UWA property. The next step would be to see how the UWA “browserUsableDisplayPixelsX/Y” would fit in, and so on.

 

I selected the aspects off-the-cuff. They are certainly not formalised, and I’m wondering 1) should an initial set be formalised, 2) what should be in the set and 3) where do we document this set?

 

I was hoping that this approach might help shed some light on the bringing together of the FPWD of the vocabulary (or vocabularies, if that’s what we end up doing).

 

---Rotan.

 

[… remaining thread deleted …]




Untitled Page

The table below shows how DD Properties (expressed as UWA types) and their mapping to UWA entries when used in certain aspects. For example, the DD "vendor" propertye is of type xsd:string and when used in a Platform aspect it corresponds to the UWA property called deviceVersion. Whereas if "vendor" is used in the Browser aspect then it corresponds to the UWA webBrowserVendor property.

This table is incomplete, and is only here for illustration.


Visual Output Audio Output Tactile Input Visual Input Platform Browser OS Physics
UWA Type DD Property                
PixelCount pixelWidth totalDisplayPixelsX              
PixelCount pixelHeight totalDisplayPixelsY              
PhysicalLength PhysicalWidth               displayWidth
PhysicalLength physicalHeight               displayHeight
xsd:string vendor         deviceVendor  webBrowserVendor    
xsd:string model         deviceModel  webBrowserModel    
xsd:string version         deviceVersion  webBrowserVersion    
xsd:positiveInteger colorDepth displayBitsPerPixel              
xsd:string[] inputDevices     keyboardTypeName          
PageMarkupSupport markupSupport           pageMarkupSupport    
xsd:string[] stylesheetSupport           styleLanguageName/Version    
xsd:string[] imageFormatSupport           imageContentType    
xsd:string[] inputModeSupport                
xsd:boolean cookieSupport           browserSupportsCookies