Warning:
This wiki has been archived and is now read-only.

DeliveryContextOntology-Roadmap

From UWA
Jump to: navigation, search

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
  • ...