Social Interaction in Databases - Community-Built Databases: Research and Development - page 177

There are several answers to these concerns. Our approach is based on distin-
guishing between public data (that in the database, curated, accessible to all users
with the right permissions) and private data (user generated, accessible only to the
user and to whoever the user wishes to share the data with). They are kept separate
to a certain degree; data in the database does not get changed, except as permitted
by the usual channels. Private data is kept apart. We have proposed a mechanism to
make private data sharable; however, note that private data, even when shared, is
still kept separate from regular data. Also, private data can be examined before
being admitted to the central repository by a curator or editor. A particular control
implemented in social sites is to allow other users to judge if contents are appropri-
ate; i.e., people can complain that other people's comments are offensive, etc., viz
the mechanisms of Wikipedia [ 10 ]. Clearly, there is additional work for the DBA to
take care of. However, our mechanism is uniform and simple (and we cannot expect
new functionality to be added with no cost).
There are, on the other hand, many benefits that a database system can derive
from allowing users to store private data. We have hinted at such benefits through-
out the paper, but here we list them to make the case that the additional overhead is
well worth the effort:
l Users may add valuable metadata to the database. If a user has questions about
how to interpret the result, the user could consult what other users have said about
the data involved. An important type of metadata is that where users comment on
the meaning and interpretation of the database schema (mostly table attributes).
This is the source of many problems in database integration [ 11 - 13 ]; hence,
saving user-generated metadata could be very useful, as such metadata is rarely
present nowadays. By mining the tags and comments deposited by users, a system
could add information to its Catalog tables, obtaining a more accurate description
of the items in the database. Such description could prove extremely useful to the
DBA: it could alert about misconceptions that users may have about the data in
the database, it could help change the way data is represented and/or captured,
etc. Thus, we believe that capturing user data is a first step toward a better
understanding not just of the users, but of the database itself.
l The system can also exploit a user's profile to its advantage. As mentioned,
many systems already keep histories in order to understand system usage, for the
purposes of tuning and optimizing system resources (although such systems
usually keep a centralized history for all users, since it is not interested, as we
are, in using such information in an individual basis). But a more fine-grained
approach can allow further tuning by taking into account which users are logged
into the system, and using only their information to set parameters dynamically.
l There is a large body of research on social networks [ 14 ] that can be applied
once the network is built, and which can lead to a better understanding of the
users of the database (for instance, centrality measures may reveal influential
users). This in turn may lead to a better understanding of how users access the
database, their expectations, and understanding of it. This may influence data-
base evolution and maintenance.