Discussion on Profile Structure Point7

From wiki.gpii
Jump to: navigation, search

The meaning of a value instance in a user preference profile is defined by a property definition in the Registry.

Status: Approved approved


Candidates

Items in the COMMON TERMS Registry are called

  1. Properties -- AGREED
  2. (Conditions -- Another class of potential registry entries -- still under discussion)


Discussion

Items arelive non-core until they are examined and an editorial group declares them CORE. Since anyone can put something in (and it might be a duplicate or not well named or thought out) we have  live non-core  to all anyone to enter and CORE to recognize things that are more permanent. All  live non-core  can become CORE - and should when they are proven or vetted.

  • Unregistered properties can be used by any vendor (e.g. application-specific settings and data blocks)
  • The API must pass both registered and unregistered properties. One API or multiple APIs?
  • We need to be sure how the records are exchanged to maximise their interoperability
  • Core properties start with a defined domain name, e.g. http://reg.gpii.net/ns/...
  • We also allow (but don't encourage) the storing of application-specific settings as block. E.g. all TextHelp settings in a bundle
    • Are there juristic and privacy implications if we don't know - and can't control - what is stored on our servers?
  • I think we should borrow from practice where we have some properties and people can make more and then they use a set that they choose, or perhaps one that is recommended. The sets are known by DCMI as 'Application Profiles' - sorry it's not a good nam but I think we could find a name. The development of 'sets' of properties often happens because of local implementations, or groups agreeing they will use a certain set, etc.
  • We need to get the big vendors on it. This is a way to achieve this. But what if the vendor doesn’t want to tell what their application can tweak (in terms of adaptation parameters)?
    • In these cases the vendor can use the single name-value pair data block to store their preferences (or any portion they want to keep secret). Even here though we recommend that they store all that they can using the common preferences and use the data block only for those that there is a special reason to.
  • What if a new technology comes along?  live non-core  space can host new properties, so that others know. Approval committee will look at properties in  live non-core  part, and promote it to core (optionally renaming it) where appropriate.
  • Culture is a context
    • very interesting - who determines my culture?

See Also