In traditional group information repositories, files are usually organized in user created folder hierarchies . Files are found by traversing these hierarchies or by conducting a search. Files within folders are displayed in sortable lists of different layouts of thumbnail icons. In contrast, files in a social file sharing system do not exist within depths of folder hierarchies, but are organized through other, non-hierarchical metadata such as tags, collections, ownership, and records of sharing activities. This eliminates the need to create complex and often idiosyncratic folder structures.Group information repositories provide limited means of annotating a file. The file system automatically provides certain metadata such as creation and modification date, the file type and thumbnail icon. Other attributes such as keywords and comments may be stored in the file system, but they are application-dependent and do not appear reliably for all file types. Consequently, opportunities for discovering relevant files are limited, and users have to rely on memory to recall the purpose of their folders, or create workarounds like storing “readme” files in each folder . Some group information repositories allow users to make copies of files . This causes files to become out of sync, increases clutter and creates confusion . However, in the absence of a copying approach, users of folder-based file-sharing services are reluctant to modify the attributes or content of files that “belong” to other users .Figure 1 highlights these differences between the hierarchical nature of traditional group repositories and the flat nature of social file sharing systems. Social file sharing systems make the metadata associated with a file easily accessible and provide multiple opportunities for file access through different design features. The metadata can be used to pivot browse to related content. Figure 1 (b) shows how more opportunities for discovering files are provided through a social file sharing system. Attributes of a file such as the owner, access control setting, and whom it was shared with and downloaded by, can lead to multiple design features that make finding the file and related files easier. For example, a person may view all the files owned by a particular user, a collection of files created by a user, all the files associated with a tag, or a list-ordered view of public files that were downloaded the most. Additionally, file interaction information can be published in a recent events stream that supports pivot browsing for easy access.
One of my colleagues emailed me about the benefits of infering connections that the paper hightlights. I agree, Connection Inference and utilization of inferred connections will become key in the social apps. Most apps these days can properly make use of the articulated connections (i.e. contacts in your contacts list), but that doesn't help much in the way of Expertise Discovery or discovering new experts in an organization. Connection Inference may help in that area. However, Connection Inference will have to be much more intelligent than what is described in this paper to be actually useful. Inferring a connection merely because person xyz touched my content is not enough. A few micro-blogging apps will automatically recommend that you follow someone just because they commented/re-shared/liked your micro-blog posting. Just because a person "liked" my post isn't grounds enough for a connection inference. There should be more intelligence to this process.