User profile filling

From Morfeo Wiki

Contents 1 Introduction 2 Profile classification 2.1 Content based 2.2 Semantic richness based 3 Profile population 3.1 Usable microformats 3.2 Using user activity 3.3 Using APIs to obtain data 4 Examples 4.1 Profile population examples 4.2 Profile extension example 4.3 Semantic data explotation example 5 References

Introduction

Problems about personal profiles:

The number of "social" sites which require the users to enter their personal data is increasing more and more. Besides having to reenter all their information, contacts, etc. in every new site they whish to take advantage of, which leads to what Brian Oberkirch termed "social network fatigue problem", all of these profiles need permanent maintaining. So, if a user moves to another address, changes companies, gets promoted or even wants to add an up-to-date photograph, he has to deal with the updating of lots of profiles.

In the Mobile Web scope, this maintenance becomes harder, specifically as far as reentering information is concerned, because of the dificulty of usability on mobile devices caused by a minimized screen, the lack of a complete keyboard, etc. Therefore, both reusing personal data previously stored in such well-known social sites and synchronizing all of these profiles, are some goals in the MyMobileWeb Project.

Profile classification

This section aims to explain some possible kinds of user profile classifications and the main differences between them.

Content based

Users have different types of profiles according to the nature of the website where each profile is located. Thus, the following kinds of user profiles are identified:

• Personal profile: this kind of profile include the basic data of an user. It contains data about the user name, address, telephone, e-mail, etc. These data are quite stable.
• Professional profile: this kind of profile has its information linked to the user professional life. These data are similar to a CV and they could contain both professional details like his position, his experience, his work place, his knowledges, etc. and personal data. This kind of profiles are frequently updated in order to offer an up-to-date CV.
• Leisure profile: this kind of profile shows details related to the spare time of the user. These data include issues like interests, tastes, social groups, etc. and it could contains personal data too. This is a very changing profile since the user can find new interests every day.

Semantic richness based

According to the semantic richness of the user profile definition, these could be classified in two groups:

• profile with a formal description: this profile has an strongly semantic definition that allows knowing exactly the meaning of each detail of the user profile. One of the best ways of making a formal description of a user is using either OWL, the W3C recommended language for ontologies in the Semantic Web or RDF, which is less strong but simpler than the former. FOAF, which can be defined using these languages, is one of the most widely used description method among Web users. Some expert users made their own descriptions by hand, which are more accurate and comprehensive. Others use automatic genterated FOAF profiles, without the user being aware of it. LiveJournal is one example of exporting FOAF in RDF, accessing to http://www.livejournal.com/users/username/data/foaf. Although a FOAF profile is usually given on a separated XML document, it is possible, and more comfortable sometimes, to embed the FOAF description in a HTML document through RDFa like in this example.
• profile with a light description: this type represents user information described by definitions with less semantic richness. This is the case when a social site does not export the user data in a formal format and a simple format is used for representing them. Folksonomies (like in del.icio.us), microformats such as hCard, hResume or hCalendar (like in LinkedIn, Last.fm) or similar representations (RSS, ICal, etc.), even taken out of an API (like in Facebook), are included in this group.

Profile population

MyMobileWeb user profile aims to maintain a formal description of comprehensive user data through FOAF and some extensions. Due to the usability problems of mobile devices, the platform will assist the user to fill his data with the information represented in his existing profiles. To do this, it is necessary to take into account the following issues:

• Establishing priority policies: when more than one profile is given by a user it is necessary to establish some rules about how to prioritize these profiles to extract their data.
• Establishing clash policies: as in the previous issue happens, it is necessary to establish some clash policies to decide which values must be used for a user profile property and how to obtain them.
• Establishing update policies: to ensure an always updated user profile it is necessary to establish some preferences related to the moment in wich the profile status must be checked.

Moreover, in order to fill the user profile, new individuals of the MyMobileWeb user ontology should be obtained from their equivalent data extracted from the external user information. On the one hand, if the external profile is described as an ontology, the same instance must be created automatically in the new user ontology. On the other hand, when a external light description is given, for instance, with microformats, this information can be processed through human knowledge in order to find an equivalence with the model ontology. However, having different kinds of light profiles may complicate this task because they require different data processing. Therefore, having some kind of adaptator (per type of profile) which performs a previous light description analysis in order to generate a formal description (ontology) could help. Flickr2FOAF tool is an example of this kind of light-to-formal description transformation.

In addition to the external data that have a direct correspondence to each FOAF property, there are other ones which have not got a direct equivalence. For instance, any information represented in a folksonomy or RSS and iCalendar documents. Actually, this information depicts the user actions and behaviour which can be analysed in order to find out the interests, preferences, etc. of the user. For example, a folksonomy is a usual format for representing data stored in a social bookmarking site such as del.icio.us, furl or spurl. In this kind of sites the user can save his favourites or simply interesting pages giving a tag which categorize them. This action means that the tagged topic might be relevant to the user, so it can be considered as a user interest candidate. On the other hand, an event set on a calendar by the user as well as aggregating some RSS of a topic can also express some kind of interest.

So, having described how existing profile data can be processed, it is possible to analyze which of these data are usable and what kind of FOAF information they match. Most of the light user profile descriptions available on the Web are represented through microformats. Moreover, user actions and events or interests are described by means of folksonomies or standars such as RSS or ICal. Therefore, these are the description formats to be analyze in order to take advantage of existing profile descriptions. Thus, according to the user profile ontology definition given in the D.3.2.2 document of the TACTOR project, the reusable data can be applied as follows:

Usable microformats

• hCard: hCard is one of the most used microformats among the social websites which store user profile data. Plaxo, last.fm, Flickr and LiveJournal are some examples of sites using hcard. The fields available in hCard are related to:
  • most of the basic information from the personal data group of the MyMobileWeb user profile ontology (first name, family name, given name, nickname, title and birthday).
  • user image from the group of physical features.
  • some information about the geographical data group (address, latitude and longitude).
  • rol and organization from professional data group.
  • email from digital identity group.
• hresume: this microformat is used to publish resumes and CVs and it is based on a set of fields common to numerous resumes published today on the Web. It reuses other microformats such as hCalendar, hCard and rel-tag in order to structure the information. One social site example of using hresume is LinkedIn. The fields available in hResume are related to:
  • some data from the education and knowledge group. With hResume, the courses are described as events through hCalendar in order to represent the course name, description, starting and finishing date, the organization which is giving the course, etc. so this data can match with some information of the MyMobileWeb user ontology.
  • some information from the professional data group. Different positions and projects are described as events through hCalendar too. This together with the skills, represented by the rel-tag microformat, can fill this data group of the ontology.
  • the information given in the activity and project connection group. HResume allows describing the user affiliations by means of an hCard microformat.
  • Moreover, hResume allows representing information about publications, which can be useful to enrich the user professional data.
• XFN: (XHTML Friends Network) is a simple way to represent human relationships using hyperlinks, in the same way as it is done in MyMobileWeb user ontology. It is widely extended among social websites such as LiveJournal or Last.fm and it allows representing the following relationships:
  • Friendship: which is divided into three levels: contact, acquaintance and friend.
  • Physical: met expresses whether the user has met the someone in person or not.
  • Professional: work relationships can be divided into two types: co-worker, which describes a person who shares an employer with the user, that is, a member of his office team, his division, or simply works for the same company, and colleage, which refers to a person who the user regards as a peer.
  • Geographical: there are two relationships referring to location relative to others: co-resident and neighbour, which is broader than the former.
  • Family: XFN contains three family-relationship values. They express whether someone is the user's child, parent, sibling, spouse or kin.
  • Romantic: this section has four descriptors: muse describes a person who inspires the user in some way, crush refers to a person to whom the user is attracted but who might not express the same feeling in return, date is used to refer to a person the user is dating, and sweetheart, which describes a person with whom the user is intimate.

Using user activity

User actions, events, interests, etc. can give useful information to obtain both useful data related to the user calendar or user interests.

Most of the social sites mantains a user interest list which could be useful to fill the personality and byography ontology group. User likes can be increased with the interests of the social network groups the user belongs to. Moreover, user actions may provide new interests. For instance, a tagging with some tags in a social bookmarking site such as del.icio.us means that this tagged pages are interesting for him and, consequently, these tags capture the user interest. Another example is a user Last.fm profile. This profile can have an event list with information related to each event and this information may provide new user interests.

On the other hand, the idea of mantaining the user location and calendar in the user profile ontology have been recently proposed on the UWA W3C Working Group. These data can be filled and frequently updated from an iCalendar document obtained from a user public calendar in a website such as Google Calendar or 30Boxes.

Using APIs to obtain data

Continuing on a different vein, the profile population could be done from a light profile located on a system which provides an API to access to its data. Some examples are Facebook API and Opensocial API . The former is an API built up by Facebook that allows a developer to access to a Facebook profile data. The second one, is the result of a Google proposal to create an open API that all social sites are able to implement to provide an unified access between these sites. Some partners of this initiative are noted social sites like MySpace, LinkedIn or Orkut.

Regarding to Facebook API, there is large amount of information that can be obtained with it. This information could fill the same ontology fields than hcard, hresume and XFN microformats as well as new ones and it could also increase the profile information with details such as:

• Personal data: Facebook API provides some information out of the reach of an hcard. For instance, it comprise additional data like the birth place.
• Physical features: the user sex could be filled.
• Social features: it is possible to obtain the user relationship status.
• Geographical data: this group could be extended in order to contain a history of user homeplaces.
• Education and knowledges: regarding to this group, the Facebook API could help to expand the ontology with a list of concentrations for each education item.
• Relationship: this API could extend the ontology existing relationships types, adding new ones like dating, networking, etc.
• Personality and biography: This API could help to create new elements like user religion, political ideas or favourite music, movies, books and tv.

Moreover, some useful information provided by this API is the profile update time. So, this field could help to establish the user profile update policies.

In regards to OpenSocial API, it specifies a People Data sub-API, which allows accesing to the social user profile, including personal data and friend relationships. This API specifies an unified way to access to the information but it does not limit the information delivered, allowing the developer to add new elements from any namespace to the basic ones. These basic elements are provided in ATOM format and comprise both Google Common and geoRSS elements.

Examples

This section shows some examples that are related to those issues explained in previous sections. These examples are real use cases that deal with the problems explained in the Introduction and try to solve them. In the following sections, the examples classified by their functionality are shown.

Profile population examples

This section include those websites that allow users to create their profile with the data stored in their existing profiles. Here are shown two kinds of examples: one aims to create a light profile from another light profile and the other one deal with the creation of a formal profile from a light profile.

An example about the former is Satisfaction. This website mantains an allways-updated FAQ about certain companies by allowing to the registered users to make questions to them. Each registered user has a personal profile with basic data that should be filled when they are registered. This register process can be simplified by giving the URL of the user profile located on an external website like flickr, Technorati, Upcoming or any other site which describes the user profile with an hcard.

Importing this profile not only makes easier the registration process but allows to keep it allways up-to-date by means of sinchronizing the new profile with the source profile provided during the registration. Therefore, the "social network fatigue" is reduced since only one profile must be maintained.

On the other hand, some examples about a formal profile population with another light profile data are tools like flickr2FOAF or Facebook2FOAF. These tools make a formal profile based on FOAF from a light profile with personal data.

The former uses a flickr profile semantically annotated with microformats to generate a formal profile. This tool analyzes the user profile looking for an hcard and gets its main data fields. On the other hand, the second example uses a Facebook profile as data source and obtains the user data using the REST based Facebook API which allows accessing to the social site data.

Profile extension example

This section shows an example about how to expand the user profile with inferred data from user actions. This example is Last.fm. In this site, the registered users have a basic profile with personal data that is filled by the user. This kind of profile may be considered static but there is other information in the user page that would be able to increase the user profile.

In this website, each user has a list of soundtracks that he is listening. Using this information and the song artist data, the system generates a topic list with the user interests which summarizes the kinds of music that the user likes. These new data are part of the user profile and they has been obtained from the user interaction.

Moreover, with the user profile data, last.fm is able to recommend useful issues to the user. For instance, the system may propose listening new music groups based on the kind of music that the user likes. Furthermore, when a user is looking at another user profile, the system makes a profile correlation getting the compatibility level between both users.

In short, this system takes advantages of the user profile to extend it with new information and it provides new issues to the user that could be useful for him.

Semantic data explotation example

An example about take advantage of semantic metadata annotations is the Firefox extension Operator. This tool gives the posibility of using some services related to the current avalilable website data that a user is visiting.

Operator uses microformats, RDFa, eRDF and other semantic annotations that are on a web page to provide new ways to interact with web services. It is possible combining pieces of information on Web sites with applications (or web services) in ways that are useful for the user. For instance, location information about a photograph on Flickr with Google Maps, last.fm events with Google Calendar, a LinkedIn user profile with Facebook to add a new contact and many more possibilities including user developed scripts.

References

• Tantek Çelic. Social Network Portability. Fundamentos Web 2007. 4/10/07 Gijón, España. http://tantek.com/presentations/2007/10/social-network-portability/