Hi all,
This is a summary of a discussion that started on the member list. The
discussion has to do with the definition of device families to support
content adaptation or other scenarios. The DDWG is chartered to produce
a note regarding this issue. The options for supporting device families
are:
---
1) have belongsTo(family(ies)) as an explicit property in the DDR and maintain the device family classifications within our ontology
- this will be unachievable as there could be a cartesian product of families based on all combinations of properties. Alternatively we mandate properties, but as Andrea says, this would be a 'best guess' and would require an operational process to introduce more.
2) have belongsTo(family(ies)) as an explicit property in the DDR and point to another classification schema as the criteria source. The suggested classification schema is OWL. (Jose) The advantages of using OWL are:
+ A higher level of abstraction and improved maintenance (I don't
imagine spreading all over the source code the condition 'XHTML-MP +
width > 128 + height > 160')
+ The portability and reuse of common device families between an
organization or a community
+ The possibility of using tools like Protege for defining device
families
+ The possibility of exploiting all the semantic web axioms
(equivalency, sameAS, etc) in defining device families.
+ A better alignment with the delivery context ontology
- This is better than (1), although Kevin worried that we then need to define a mechanism for modelling and querying this external source.
Jose: There is no need to query an external source, the DDR can store the definition of the family devices by means of OWL
3) have the logic at the consumer end (by consumer I mean whoever queries the DDR). So for example a convenience global variable in the language that is performing the query could wrap all the query criteria that make up the device family.
Pseudo-pseudocode:
$advanced-device = "supportsXHTML-MP AND hasPixelWidth > 128 AND hasPixelheight > 160)"
If DDR.query('$advanced-device')=true
# include advanced markup
Then the consumer is free to vary the criteria of their device family at will (e.g., what they define as a 'advanced' device now will surely be different in 2009, and will likely differ between consumers at the same time). I guess Andrea will explain a 'developer defined device family' approach a lot better in his document
Jose: This mechanism could not be very maintanable in languages such as Java. A change in the filtering conditions results in a recompilation of the source code. That's why Jose is proposing supporting options 2 and 3.