Discussion on Profile Structure Point7
The meaning of a value instance in a user preference profile is defined by a property definition in the Registry.
Items in the COMMON TERMS Registry are called
- Properties -- AGREED
- (Conditions -- Another class of potential registry entries -- still under discussion)
live 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?
livenon-core space can host new properties, so that others know. Approval committee will look at properties in livenon-core part, and promote it to core (optionally renaming it) where appropriate.
- Culture is a context
- very interesting - who determines my culture?