Discussion on Profile Structure Point1
Contents
Registry structure
Status: ApprovedRegistry Entries
Note: The most recent description of the record format for registry terms can be found on the REGISTRY page.
A registry entry has the following components:
- Namespace (maybe external to the registry entry)
- Local Unique Identifier
- Note: URI = Namespace + Local Unique Identifier
- Value space
- Default value?? (Note: Point 10: In a user preference profile instance, the value of those keys that are not present, are unknown (incomplete profile).)
- Reference_if_alias (URI)
- If the registry entry is an alias, all other items (except Local Unique Identifier) are empty.
- If the registry entry is not an alias, Reference_if_alias is empty.
- isCore (Boolean)
- Note: Changing the isCore flag does not change the URI
- Status (exact value space to be clarified in issue #43)
Also, parallel to the registry entry, pointing to a specific entry:
- Localized labels for multiple languages
- Only use for display to a user, not as part of an actual preference
- Localized labels for enumerated string values
- Only use for display to a user, not as part of an actual preference
- Description, including examples (localized)
- Notes (localized)
Versioning: See 29:Property definitions can only be "versioned" by giving them a new URI (namespace or local identifier).
Discussion
This ticket deals with the structure of the Registry, not the user profiles.
- Registry of COMMON atomic terms.
- COMMON terms can be Core or Non-Core.
- COMMON terms may be associated to existing terms from other standards (cf. ontology from CERTH).
- Profile consists of COMMON, non-common and application-specific terms and conditions.
- No specific profile structure is implied (multiple representations possible when associating atomic terms with conditions).
- For the preference server, there is no constraint in what structure to use for storage. See Architecture of Preferences and Data.
- Preference server can transform the profile structure on demand, with little or no loss.
- But: Translating an arbitrary Boolean expression in JavaScript into a nested structure is not always possible. Therefore people should use registered (common) terms.
Also to consider:
- Relationship between needs and preferences
- How to go from a need to the implementation of it?
Atomic term:
- Smallest component
- Opposite of compound
- E.g. fontsize
Application-specific properties are not registered.
URI
The Identifier is unique in respect to a namespace. the combination of namespace and identifier is globally unique
NeedsAndPreferences
- Name (URI/URL?)
- Labels (in multiple languages?)
Only if item is an alias:
- Reference_if_alias (URI?)
Only if item is not an alias:
- Range / value space / value range
- Labels for enumerated string values (in multiple languages?)
- Description, including examples (in multiple languages?)
- Note: Relationships to other preferences, etc.
Note: The ontology draft also models the property isCore, to distinguish between core and non-core NeedsAndPreferences.
CommonTermsForConditions
- Common terms that can be used as part of conditions
- Aliases for condition terms
Default Values
- Default Value should probably be part of the registry.
- There might be multiple Default values per term.
- Ontologies might have conflicting default values.
- Perhaps a Default-Value-Notes column to note down what a default value could be (or if there are multiple).
- Do we even need a Default-Value? Isn't it part of the Match Maker to find a value for the current situation.
Alias
- Do we want to treat aliases with a boolean flags?
- Should we specify full sets for two alias terms and link them via a relation?