Discussion on Profile Structure Point34
What is a condition?
Request for proposals
The following use cases should be solved by any proposal:
- Pitch for UPPER-CASE TEXT
- Pitch for different characters
- Pitch for 6pm through midnight, and pitch for other times
- Pitch on speaker, and pitch on headset
- Pitch when listening to (background) music
- Any combination of these
A proposal should include:
- Encoding schemas for values references from conditions
- What component should deal with these types conditions (application, matchmaker, etc.). May be multiple components at different times and in different situations.
- Conditions should default to true
- We should offer a function (like "value" in these examples) which returns the value of a preference in the profile, the device or the context
- Some conditions may become obvious at runtime only and over the course of many sessions. That's why our structure should be flexible and extensible.
- We want to describe these situations so that the system can learn.
- Different matchmaking approaches: rule-based & statistics based.
- Rules can be present, but not in the registry.
- It is important to encode the condition-property together with the values.
- Uppercase could be either static condition or even a separate property.
- What needs to be standardized?
- Can we combine static and dynamic conditions, and decide for every piece at runtime whether it can change or not?
- Different problems:
- How to share the preference profile information
- How to find a good solution (matchmaker)?
- Is it good to embed a "programming language" into a profile? Requirements on components for parsing...
- Only parsing boolean expressions, very simple parser
- Information model vs. binding
- Format for preference server vs. format for launch handler - can be transformed and evaluated before
- Exchange dialog with architecture wg
- EBNF is used in many standards, useful to have grammar
- Can we use any other grammar that is already existing?
- Controlled vocabulary for the contextual parameters that can become part of the condition?
- Registry needs to store context properties as well
- Conditions are boolean expressions referencing contextual parameters/properties
- Preferences, properties, conditions?
The registry should also include an enumeration of constants that occur in the value spaces of context properties. However, the actual meaning of them should be defined in an ontology. But what if we have multiple ontologies?
- The registry should have a basic definition (string) of each of the constants.
- The registry should not reference any ontology (because there are multiple ontologies).
- One condition field per item in preference profile
- A preference consists of a preference property, a condition, and a value
- A condition is a boolean expression referencing one or more context properties
- A context property can include without limiting:
- sensor data from the environment
- any other preference
- A context profile is a collection of context properties and their values, used for evaluating conditions (by matchmaker or perhaps other components)
The registry is a registry of common preference properties and a separate section of common context properties. Both of them may have ontologies applied to them to make them easier to use, but will be flat in nature.
Any preference property can also serve as a context property.