Discussion on Profile Structure Point1

From wiki.gpii
Jump to: navigation, search

Registry structure

Status: Approved
Error creating thumbnail: Unable to save thumbnail to destination

Registry 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:

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?

See Also

Retrieved from "http://wiki.gpii.net/index.php?title=Discussion_on_Profile_Structure_Point1&oldid=6014"