DeliveryContextOntology-Roadmap

Delivery Context Ontology Roadmap

Author: Jose M. Cantera Telefónica I+D

Items for the next Public Working Draft

• Improve the documentation
  • Move examples to an specific non-normative section at the end of the document
  • Clarify what instances are normative and what are not (if any)
  • Link the .owl and .pprj files in the document
  • Study the usage of the SpecGen tool. A preliminary result of using this tool can be found in this proof of concept
  • Make more explicit / readable the relationship between classes and properties and CC/PP 2 and UAProf 2 components and attributes
  • A better structure for the documentation, for example alphabetical order for classes / properties
  • Incorporate diagrams that clarify the relationship between classes, instances and properties
• Add more properties coming from UAProf i.e. assure that all CC/PP - UAProf 2 components and attributes are represented in the ontology
• Model the Delivery Context as having three main facets: Device (software and hardware), User and Environment
• Refactor the ontology. The current hierarchy is not readable. That implies the following tasks:
  • Create hierarchies that will be children of the DeliveryContext_Entity class:
    • DeliveryContext_HardwareEntity. It will subsume all the hardware entities
    • DeliveryContext_SoftwareEntity. It will subsume all the software entities
    • DeliveryContext_EnvironmentEntity. It will subsume all the entities that have to do with the environment (for example or location-related classes)
    • DeliveryContext_AuxiliaryEntity. It will contain auxiliary entities not directly linked to any of the above.
    • Should there also be a DeliveryContext_UserEntity? (RH)
• Add support for location-related properties and classes
• Add support for J2ME-related properties (Kevin, can you contribute to this?)
• Capture more properties about the browser and browser restrictions, including AJAX-related properties
  Should we distinguish between natural limits (e.g. available memory) and deviant limits (e.g. can't display more than 5 columns in a table)? (RH)
• Drop the AlternateNames class and model it as an annotation property (easier to maintain)
• Drop the Associated_UAProf_Entity class and model it as an annotation property pointing to UAProf spec (easier to maintain)
• Revisit the units design taking into account this feedback [1]
• Define 'Aspects' in the ontology as requested by the DDWG
• Consolidate feedback coming from OMA and W3C's DDWG and Semantic Web groups
• Take into account feedback coming from the developer community such as [2]
  Also note the the discussion thread by the DDWG on this matter. (RH)
• Add more entities /instances corresponding to units, inputyppes, character encodings, etc.

Future items

• Factor out the concept of 'Device' allowing us to represent any kind of device (including sensors, printers, GPS Receivers, keyboards, or whatever)
• Model other environmental conditions:
  • local time
  • weather conditions
  • day of week
  • nearby devices
  • nearby objects
  • detailed location (province, postal code, points of interest ...)
  • ...
• Model User
  • Preferences
  • User Contact Information and social relationships
  • Study the relationship with FOAF
• Model other device characteristics
  • Connectivity: USB, PC-MCIA, InfraRed
  • Networks: Wi-Fi, ZigBee, RFID
• Model Multimedia Capabilities
• ...