Personal Mode

 

In Personal Mode, the server functions as a repository oriented
to store user profiles. The profile of a user is a set of tuples
(feature, value). Features are entities relevant to specific
applications, while values give an estimation about a user
relevence to corresponding features. All users have values for
all application features. Features may have default values, that
are assigned to new users. Also, features can be organized in a
tree or graph based manner, for easily managing conceptual
hierarchies. This organization is encoded in the name of every
feature as a path expression, and is setup by applications.
The DB structure: up_features (uf_feature, uf_defvalue,
uf_numdefvalue) with key 'uf_feature', user_profiles (up_user,
up_feature, up_value, up_numvalue) with key 'up_user' and
'up_feature'. If a field in 'up_features' is deleted, the deletion
is cascaded to 'user_profiles', because of a referential integrity
constraint. The two fields 'uf_numdefvalue' and 'up_numvalue'
are "invisible": they are not part of the results of 'select'
queries, they contain the numeric equivalent of the string
value (in the other value fields), or NULL if the string cannot be
converted to numeric. Those duplicate fields are used mainly to
allow for two types of value comparisons: string and numeric.
Note that the primary data type for values is always string, as
it is more general, and that the numeric version always correspond
to the string version. Also note that values intented to be
numeric must use '.' for the decimal part when given as strings.
If ',' is used, the string will not be successfully converted to
numeric, and its numeric equivalent will be NULL.
Personal Mode also offers a separate 'DECAY' functionality.
In decay, the server keeps a record of every user interaction with
certain features, marking the date/time the interaction occurred.
Then, it is possible to calculate a value, that shows how much a
user is interested in a feature, and that takes into account not
only how many times the user visited the feature, but also if the
user has visited other features in the meanwhile (therefore if the
feature has been 'forgotten'). Most recently visited features
receive higher scores, therefore to forget means to loose interest.
The formula depends on a variable called here 'decay rate' between
[0,1] inclusive, that determines the rate of forgetting. If rate
is set to 0, the user does not forget (or loose interest) and the
decay mechanism is reduced to sorting features based only on how
frequently a user has visited them (not when). The application
can define a number of feature groups and a rate for each group.
Each group represents a set of features that compete for the
user's interest under the decay formula. The application must
inform the server about any user interaction with such features,
and can subsequently ask for features a user is most interested
in. In case the rate of a feature group is 0, the decay value
calculated by the server for any feature of the group for a
specified user, is simply the total number of visits the user
paid to the feature.
The DB structure: decay_groups (dg_group, dg_rate) with key
dg_group, decay_data (dd_user, dd_feature, dd_timestamp) with key
dd_user, dd_feature and dd_timestamp. If a field in 'up_features'
is deleted (or a feature name updated), the deletion (or update)
is cascaded to 'decay_data', because of a referential integrity
constraint. Note that 'decay_groups' is not connected with any
other table through referential integrity constraints, so data
from this table must be deleted explicitely when initializing the
Personal Mode database. The role of 'decay groups' is secondary
 - actually the decay can function without this table, the
application is not oblidged to declare groups for using decay,
it only needs to notify PServer about user-feature interactions.
Another function of the Personal Mode has to do with "numeric
features". For some features it is not meaningful to count
how often a user has visited them in order to determine of how
much interest they are to the user. Such features have numeric
values and meaninful operations are aggregates on those values.
For example, a user interested in laptop computers can visit
laptops of different weight. In this case, a number relevant
to the profile of the user may be the average weight of all
laptop descriptions the user has visited (or showed interest in).
A single table in the DB supports this functionality: num_data
(nd_user, nd_feature, nd_timestamp, nd_numvalue) with key
nd_user, nd_feature, nd_timestamp. The table 'num_data' is not
connected with any other table through referential integrity
constraints (not even with table 'up_features'), so data from
this table must be deleted explicitely when initializing the
Personal Mode database.