<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Multiple Personalities on the Web: A Study of Shared Mboxes in FOAF</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>College Park College Park</string-name>
        </contrib>
      </contrib-group>
      <abstract>
        <p>The Friend-of-a-Friend Vocabulary (FOAF) is used in many online social networks to represent information about users and their friendships. Previous work has looked at how FOAF can be used to merge accounts across social networks. We often consider that merging as a bene t to the user, connecting their personal information and friend lists which would otherwise stay isolated. However, users may create multiple accounts - even on the same network - to intentionally separate their data. FOAF makes it equally easy to merge these accounts. In this paper, we are interested in the impact Semantic Web reasoning - with no additional data mining technology - can be used to resolve multiple accounts and the implications that has for privacy and safety online. We crawled FOAF pro les from all the social networking website that generate it, and looked at the pro les of individuals with multiple accounts to understand how they were using these accounts and why they were created. We present the results of this analysis and discuss the implications.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Just as social networks are one of the most popular web-based activities FOAF is
one of the most widely used ontologies on the Semantic Web. With its semantics
and the application of a Semantic Web reasoner, it is possible to merge pro les
and friendship connections within and across social networking websites. While
this capability is generally viewed as one of if not the greatest powers and bene ts
of the Semantic Web, it also has implications for privacy and security. Users may
want to create multiple pro les to keep parts of their lives separate, and this type
of reasoning would impinge on the privacy they expect. At the same time, these
multiple accounts could be used for nefarious purposes, and the reasoning and
merging may allow us to detect and prevent this bad behavior.</p>
      <p>In this paper, we ask one core question: Using Semantic Web reasoning on
existing FOAF les, what can we learn about the frequency of, reasons for, and
use of multiple pro les belonging to the same person in online social networks?
While there are mechanisms for generating FOAF when it is not available and
for merging pro les outside of Semantic Web reasoning, our work is a study of
this problem on the Semantic Web as it exists today. Thus we are interested
only in Semantic Web technologies and existing Semantic Web data. In addition
to focusing our results on a speci c problem, this restriction means that the
conclusions we draw are immediately applicable because they cover existing data
analyzed with existing techniques.
2
2.1</p>
    </sec>
    <sec id="sec-2">
      <title>Related Work</title>
      <sec id="sec-2-1">
        <title>FOAF Syntax and Semantics</title>
        <p>The FOAF vocabulary1 is used to describe people, their attributes, and the
relationships between people. FOAF is written in OWL and takes advantage of
some speci c OWL semantics. Speci cally, the vocabulary employs the Inverse
Functional Property on many of the properties connecting a person to an
account. This includes foaf:aimChatID, foaf:homepage, and, most importantly
for our purposes, foaf:mbox and mbox:sha1 sum.</p>
        <p>These latter two properties connect a person to their email address, either
using the email address directly or using the SHA1 hash of the address
respectively. Inverse Functional Properties serve as unique identi ers; in this case,
it means only one person can own a given email address. Thus, two people
with the same email address can be inferred to be the same person. All the
social networks that generate FOAF use the mbox:sha1 sum to identify users.
The value for this property is a hash of the user's email address in the form
mailto:example@example.com. Nearly all the networks provide this for every
user. A few networks do not require users to provide email addresses; if no email
is available, the property is not included in the FOAF output. Datasets are
discussed further in section 3.</p>
        <p>Because the mbox:sha1 sum is an inverse functional property, we can use it
to merge accounts. Using an OWL reasoner, all accounts that share a common
value for the mbox:sha1 sum are inferred to be the same account.
2.2</p>
      </sec>
      <sec id="sec-2-2">
        <title>FOAF in the Wild</title>
        <p>
          Previous research has looked at how FOAF is being used on the web. In 2005,
[
          <xref ref-type="bibr" rid="ref1">1</xref>
          ] collected a set of FOAF documents and analyzed the commonly used
properties and the social network structure within that set. The state of FOAF has
certainly changed over the past four years, and the original study did not look
comprehensively at the available FOAF but rather used a somewhat arbitrary
collection of FOAF documents found by Google, and those that could be reached
by crawling from this set.
        </p>
        <p>
          A later study in 2008 [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] extensively collected FOAF documents from all
the social networking website that generate it, and used that to study how
extensively Semantic Web reasoning could link accounts in di erent networks.
Those results showed that using the mbox:sha1 sum property enables accounts
to be merged connecting every pair of networks and that the percentage of nodes
that bridge networks are roughly what would be expected in a social network.
1 http://xmlns.com/foaf/spec/
        </p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Data Sources and Methodology</title>
      <sec id="sec-3-1">
        <title>Data Sources</title>
        <p>
          We are interested in nding accounts that would be merged by applying OWL
reasoning to FOAF data. Unlike previous research that studied the impact this
had on connecting social networks, we are not interested in social connections
at all. Rather, we want to know the implications that arise from identifying
multiple pro les as belonging to the same person. To do this, we used essentially
the same data as was used in [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] with slightly expended crawls. In this section,
we will explain the datasets in detail.
        </p>
        <p>
          Eleven social networking websites generate FOAF les for their users and we
used all of these networks in our research. Note that this is not just the total
number of networks we used, but all the web-based social networks with available
FOAF. LiveJournal is the largest of those, accounting for just over 75% of the
users. All of these networks were crawled in [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] and we used the same dataset.
That data was collected in 2008 and while there are certainly more accounts
on these websites now, for our purposes of understanding multiple accounts on
social networks, the dataset was completely su cient.
        </p>
        <p>For each network, we gathered as many pro les as possible. Some networks
- FilmTrust, Ecademy, and Advogato - provided a full list of all of their
members.In the rest of the networks, a full list of members was not available, and thus
we had to crawl the network. To do so, we chose several users as starting nodes
and performed a breadth rst search through the network to nd all reachable
members. For each user, we accessed the FOAF le, pulled URIs of their friends'
FOAF les, and added those URIs to our queue. Table 1 shows the number of
users in each network that we were able to use in this study.</p>
        <p>There are almost certainly smaller components of these networks that our
crawls did not reach. Also, users with no social connections would never be
discovered on a crawl. However, since we are looking for multiple pro les and
not examining social connections, missing pro les will not have a signi cant
impact on our results. Furthermore, any applications using FOAF would need
to follow the same procedures we did in this study, and thus our data set is
representative of what FOAF applications would use. In the worst case, we will
underestimate the number of pro les a person has, but our sample should provide
representative insights into the implications of merging pro les with FOAF.</p>
        <p>For every member we were able to include in the study, we accessed their
FOAF le. For the purpose of this work, we were interested only in the member's
friends and unique identi ers (given by the inverse functional properties). Thus,
to save space and increase e ciency, we implemented a task-speci c OWL
reasoner that considers only the FOAF inverse functional properties and foaf:knows
property, and ignores the rest of the data.</p>
        <p>Traditionally, a reasoner would not keep track of the sources of each axiom in
the knowledge base. Since we are speci cally interested in how data is repeated in
multiple sources, we added a provenance tracking feature to our reasoner. This
maintains a record of the document where each axiom is asserted. With this
data available, it is straightforward to identify on which and how many social
networks a member has accounts, as well as the sources for each friendship.
3.2</p>
      </sec>
      <sec id="sec-3-2">
        <title>Frequency of Multiple Accounts</title>
        <p>Once we had collected the FOAF les as described above, we implemented a
simple customized OWL reasoner that would match up pro les with the same
mbox:sha1 sum. We ran this over the data and identi ed individuals with
multiple accounts.These multiple accounts occurred both within and across networks,
though it was much more common to have multiple accounts within a network.</p>
        <p>Of all mbox:sha1 sums used on multiple accounts, 83.6% existed on only one
network. Nearly all the rest - 16.0% - were spread between two networks. Among
the mbox:sha1 sums on one network, the vast majority are on Buzznet, at 72.9%.
The now defunct GreatestJournal had 15.9%, LiveJournal has 9.3%, and the rest
of the networks have less than 1% of the users. This latter distribution is shown
in gure 3.2.</p>
        <p>There were 982,913 unique mbox:sha1 sum values among all the datasets.
Among these, 47,563 are associated with multiple accounts. The vast majority
- 77.6% (36,918) - are used on only two accounts. If we add in the 13.0% that
had three associated accounts, this comprises over 90% of the total. Only 16
mbox:sha1 sums had more than 30 associated accounts. The number of accounts
associated with each mbox:sha1 sum follows a power law distribution (see gure
2). The top ten mbox:sha1 sums with the most associated accounts had 350, 118,
108, 92, 62, 59, 56, 42, 40, and 39. Details about these are discussed in section
4.3 and 4.3.</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Experiment and Results</title>
      <sec id="sec-4-1">
        <title>Methodology</title>
        <p>In order to gain insights into why multiple accounts were associated with the
same mbox:sha1 sum, we chose several subsets of accounts to examine. First,
we selected the top ve email addresses with the greatest number of associated
accounts. Because there are so many pro les and attributes in these accounts,
we believe these users provide the clearest and most extensive picture of multiple
account holding online. Then, because smaller numbers of multiple accounts were
more common, we selected 40 mbox:sha1 sum values at random that had only
two associate accounts and another 40 mbox:sha1 sum values with 5 associated
accounts.</p>
        <p>For each of these users, we looked at the publicly accessible personal
information for each of their pro les, including name, age, gender, username, the
activity on the account (last active dates, latest blog posts, etc), the content of
their blog posts (when available), social networking connections, and other data
that was present. We then compared and analyzed this data across the accounts
held by each person to develop insights into their online personas.</p>
        <p>If two di erent users entered the same email address, we would expect to nd
very few similarities in their pro les, if any. However, if we nd ve accounts
associated with one mbox:sha1 sum and the pro les of each account have the
same age, gender, hometown, and astrological sign, it is highly unlikely that
they belong to ve random people. The shared mbox:sha1 sum implies that the
accounts belong to the same person. In our analysis of accounts, we looked for
evidence to support this inference. Only when we found few or no similarities
did we conclude that the accounts may belong to di erent people.
4.2</p>
      </sec>
      <sec id="sec-4-2">
        <title>Hypotheses</title>
        <p>
          We had several theories as to why users would have multiple accounts:
1. Users opened an account and then forgot that it existed or forgot their
password. They then opened up another account to replace it. This is
easily detectable by looking at the latest activity on the account when it was
available.
2. Users create di erent accounts to compartmentalize parts of their lives. For
example, a user may have one account for personal social networking and
entertainment use, one for business use, one for religious use, etc. The goal
in this case would be to keep these parts of the user's life separate online.
3. Users create accounts for separate topics. Unlike H2 where the accounts
are used to present di erent versions of oneself to di erent audiences, this
hypothesis addresses accounts as an organizational mechanism. For example,
a blogger may have many blogs on di erent topics and create a separate
account for each. The user presents the same persona on each blog, but
separates topics through multiple accounts.
4. Users maintain completely di erent personas in di erent accounts. For
example, a user may have a pro le of a 15-year-old boy and a 50-year-old woman.
Names, locations, interests, and other personal information may also change.
The intentions behind these multiple personas vary, but this provides one of
the more interesting reasons for creating separate accounts.
5. Sybil Attacks [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ] are attacks on systems where users create many accounts to
cause some damage. This may be in the form of creating accounts that rate
one another highly in order to arti cially increase the perceived reliability or
quality of each individual. They may also be used for voting, commenting,
or otherwise creating a larger presence and chance for being heard. Multiple
social networking accounts could be used for this purpose as well.
        </p>
        <p>We do not necessarily expect to see instances of all these theories, and we
also believe we may nd other unexpected reasons behind multiple accounts.
4.3</p>
      </sec>
      <sec id="sec-4-3">
        <title>Most Frequently Merged</title>
        <p>There are insights to be found in looking at mbox:sha1 sums associated with
many social networking accounts. Do these accounts actually belong to the same
individual? If so, this validates the assumptions behind the FOAF model that
treats an email address as a unique identi er. Understanding the purpose of
these accounts also can help us understand if FOAF reasoning presents a threat
to privacy that users are trying to maintain, or if it is a feature that can bene t
users in maintaining their identities.</p>
        <p>We considered the top ve most popular mbox:sha1 sums.
1. 350 Associated Accounts By far the most common value for the
mbox:sha1 sum was 08445a31a78661b5c746feff39a9db6e4e2cc5cf. We found
350 pro les using this address. While it is not possible to easily unhash this
address, an educated guess revealed what was happening. The sha1 hash of mailto:
(i.e. an empty email address) is 08445a31a78661b5c746feff39a9db6e4e2cc5cf.
Thus, when users left their address blank, systems generated this as the value
for their mbox:sha1 sum.
2. 118 Associated Accounts This appears to be a test account of some sort.
Ninety of the account names were consecutive integers from 2 through 90 (with
69 and 83 skipped) plus 100 and 1000. The rest of the account names were
single letters or common words. The accounts are basically empty of pro le
information. The only content to be found is collections of photographs in some
of the accounts.</p>
        <p>The social network of these users supports the hypothesis that they all
belong to one user rather than to many di erent users. Figure 4.3(a) shows the
social network for these nodes. Each red node indicates one of the 108 accounts
associated with this mbox:sha1 sum while green nodes indicate accounts with
di erent mbox:sha1 sum. The gure shows all the friendships of these nodes.
Note that the vast majority are to other nodes that share this mbox:sha1 sum.
3. 108 Associated Accounts This was a very clear case of one user creating
multiple accounts. Each pro le indicates that it belongs to a 19-year-old female living
in a speci c Detroit suburb (unnamed here to protect the user's privacy). Each
Social network of the 118 accounts
sharing one mbox:sha1 sum. Green nodes
indicate the few accounts that are in this
social network but do not share the
same email address.</p>
        <p>Social network of the 92 accounts that
share one address. Basically all are
friends with the central node that
shared the same mbox:sha1 sum.
has exactly one connection to the same person, a user called\panasonicyouth", a
buzznet sta member who is friends with over 575,000 users - the fast majority
of people on Buzznet. There is no indication as to what the purpose is for each
account - most have no content or posts.
4. 92 Associated Accounts All but three of these accounts were on the Insane
Journal blogging website, and the remaining were on Dead Journal. The account
names were related to pop music icons, contestants on American Idol, and
characters in Disney Channel television series. The pro le photos also matched that
persona (e.g. a pro le with an account name resembling Paris Hilton would also
have a picture of Paris Hilton). Forty-nine of the accounts have been shut down
by Insane Journal; attempts to access the pro les show the message \This
journal has been deleted and purged." The remaining accounts still provide plenty
of information about what is happening.</p>
        <p>Figure 4.3(b) shows the social network of these accounts, represented as
nodes. This shows all the edges for every node. Note that all the accounts are
connected, and nearly all nodes have only one connection to the node at the
center. That central person shares the same mbox:sha1 sum as the other
accounts. None of the accounts have social connections to users with a di erent
mbox:sha1 sum.</p>
        <p>An examination of the remaining accounts reveals their intent. While most
accounts have no public posts, one contains a post that explains all of the
acounts. The post states that the author is a high-school student using the
accounts to participate in celebrity fan ction sexual role playing games. The
di erent accounts represent the many di erent personas the author represents
in the games, both male and female. The games take place through private
messaging, but the accounts provide a face for the personality in the game. The
post explains the author's rules for engaging in a game with someone else and
lists characters the student likes to represent (which correspond with the type
of celebrities used in the pro le names and photos).</p>
        <p>Thus, we can conclude that these accounts also belong to the same person
who is using each as an alternative identity in role playing games.
5. 62 Associated Accounts The accounts associated with this mbox:sha1 sum do
not appear to belong to the same person. The pro le characteristics vary widely.
Pro les are well developed with photos, posts, and discussions. This level of
e ort makes it unlikely that all the accounts are the work of one individual. It is
possible that these users all entered a fake email address that we were not able
to identify; the use of fake addresses was common, as we will discuss in section
5.1.
4.4</p>
      </sec>
      <sec id="sec-4-4">
        <title>Five and Two Associated Accounts</title>
        <p>We randomly selected 40 mbox:sha1 sums that had ve associated pro les.
When one or more of the pro les were private or unavailable, we threw
out that mbox:sha1 sum and randomly selected another. These represented
mbox:sha1 sums in the top 5% with respect to the number of associated
accounts among mbox:sha1 sums with multiple accounts. We also used the same
method to select 40 mbox:sha1 sums that had two associated pro les. Over 75%
of the mbox:sha1 sums with multiple accounts had only two, so these are
representative of the most common case.</p>
        <p>In almost all cases, we found that the accounts associated with a given
mbox:sha1 sum belonged to the same person. The pro le information was largely
the same; for example, we often found the same hometown, age, astrological sign,
and gender in all the pro les. This, combined with the fact that we know they
used the same email address, is extremely strong evidence that all accounts
represented the same person. When there were discrepancies, they were often
changes in age (e.g. from under 21-years-old to 21) or hometown (e.g. from a
small suburban town in one pro le to the name of the metropolitan city in
another).</p>
        <p>Of the 80 total mbox:sha1 sums, we found only four where all the accounts
did not obviously belong to the same person - just over 1%.</p>
        <p>Interestingly, most of the accounts were essentially unused. They had some
basic pro le information, but no posts, no friends (beyond, occasionally, the
\default" friends on a given network), no photos, and no content of any other
type.When at least one account associated with a given mbox:sha1 sum has
some activity, the others could possibly be mistakes, forgotten, or used for some
purpose that cannot be observed. However, it was not infrequent that all the
accounts had no activity. In these cases, it is unclear why users would create
these accounts and not use them. They may be required to create accounts to
participate in activities on the website that are not re ected on their pro le,
however, there is no available evidence as to their true purpose.
5
5.1</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Discussion</title>
      <sec id="sec-5-1">
        <title>Reasons for Multiple Accounts</title>
        <p>Fake Email Addresses We found many fake email addresses in our data. We
identi ed these by making up obviously fake addresses, generating the SHA1
hash, and searching for that hash in the list of mbox:sha1 sums collected from
the pro les. Aside from the blank email address discussed above, table 2 shows
20 made up addresses with many associated accounts. While these are the most
popular of the fake addresses we guessed at, we found many others with only
one or two associated accounts.</p>
        <p>Di erent Personas Users often change information in their pro les to represent
variations on their personality or life situation. It was fairly common to see users
with di erent ages but otherwise identical pro le information; we found that in
29 pro les that belonged to the same person but that had di erent ages. This
was frequently a di erence between being under 21-years-old and 21 or older.
We also found variations in the pro le's sexual orientation and in relationship
status.</p>
        <p>For example, Buzznet had a high population of female users in their
midteens. It was not uncommon to see them create new pro les with new usernames
when they started dating a boy, dedicating pictures and descriptions to their
relationships, only to abandon that pro le and create a new one when the
relationship ends.</p>
        <p>Less Common Reasons
{ Sybil (pesudo)-Attacks - Some users created multiple accounts in order to
have some accounts provide positive votes to content posted on the main
account. This was only seen twice, but was a social network-based
instantiation of the Sybil attack. While there was little malicious intent, this usage is
similar to what would be done to circumvent rating systems in more critical
environments.
{ Compartmentalizing - One of our hypotheses about why users had multiple
accounts was due to compartmentalizing parts of their life, for example,
maintaining separate accounts for their personal and professional lives. We
found two mbox:sha1 sums where this was the case, but it was not a common
phenomenon.
{ Errors - When users are not permitted to change their usernames, they
register new accounts to change them. We found a few instances of users
registering multiple accounts on the same day with user names that varied
by one or two letters, correcting a typo.
{ Groups - Occasionally groups of users shared a common mbox:sha1 sum. We
particularly noticed this with music groups who may be using a common
address for the band while each member maintains a separate pro le.
5.2</p>
      </sec>
      <sec id="sec-5-2">
        <title>Privacy Implications</title>
        <p>One of our initial concerns was that people would be using multiple pro les on
a social network to keep parts of their lives separate, speci cally to keep their
personal life private from their professional life. However, this was not an issue
that we discovered. Most pro les on the same mbox:sha1 sum were very similar
and when there were variations, they were minor. The large number of empty
unused pro les also lessened the concern about privacy violations.</p>
        <p>In most cases, users were extremely open in sharing intimate details of their
lives in their pro les. There were open discussions of sexual activities, drug use,
and personal con icts. There were some variations between pro les in personal
information (e.g. the user's sexual orientation was listed as \straight" in one
pro le and \bi" in another), but it does not appear that the user was trying
to hide information by using multiple pro les; rather, these instances look more
like teenagers experimenting with their personas.</p>
        <p>Even in the few cases we found where users were keeping their professional
and private lives separate, the \professional" context was quite casual and
included personal information.</p>
        <p>This is not to say that FOAF aggregation will not raise privacy concerns. One
only need to look to the now defunct Plink as an example. The site aggregated
FOAF from many sources but was forced to shut down in October 2004 after
complaints from people who did not expect their data to be present on a site
they did not sign up for. Thus, even when users have only a single pro le, there
are privacy concerns that arise from simply taking FOAF information that is
freely available.</p>
        <p>Independent of this general concern, however, there is little evidence that the
merging of pro les will lead to information being aggregated that users intended
to keep separate.</p>
      </sec>
      <sec id="sec-5-3">
        <title>Preventing Incorrect Inferences</title>
        <p>Most of the cases where Semantic Web reasoning over the FOAF pro les seems
to merge accounts belonging to di erent people occur when users have fake
addresses. This occurs when social networking websites do not perform an email
veri cation for users to create pro les and when they allow a new user to register
with an email address that's already in the system. Both of these were the case
with Buzznet, resulting in the many duplicate accounts we found there.
6</p>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Conclusions</title>
      <p>In this paper, we looked at the implications if Semantic Web reasoning over
FOAF data to merge multiple pro les of the same user. We were particularly
interested in why users create multiple accounts, how they use them, and what
challenges or bene ts FOAF o ers in dealing with this issue. To answer this
question, we gathered FOAF data from all eleven social networking websites
that produce FOAF les for their users, and analyzed the pro les of the ve
users who had the largest number of multiple pro les as well as pro les for
40 mbox:sha1 sums with ve associated accounts and 40 mbox:sha1 sums that
represented the much more common case of having only two pro les.</p>
      <p>In all but a few cases, we found that all the accounts associated with a
given mbox:sha1 sum represented the same user. We found many examples where
people used fake email addresses, and this lead to many instances where pro les
of di erent people were linked to the same mbox:sha1 sum.</p>
      <p>Among the mbox:sha1 sums where the accounts belonged to the same
person, we made several observations. Frequently, the pro les were mostly unused;
they had only basic pro le information with no friends or posts. Users usually
maintained identical information among all of their pro les. When there were
discrepancies, they were usually in the user's age (perhaps to gain access to
age-restricted areas of the website) or hometown. The most common reason for
having multiple pro les appears to be to cultivate slightly di erent and / or
evolving personas in an online environment. Merging the available FOAF
information will lead to some inconsistent information in these cases. However, we
found no instances where the merging of data would violate privacy that users
tried to establish by separating their information into di erent accounts.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Ding</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zhou</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Finin</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Joshi</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>How the semantic web is being used: An analysis of foaf documents</article-title>
          .
          <source>In: System Sciences</source>
          ,
          <year>2005</year>
          .
          <source>HICSS'05. Proceedings of the 38th Annual Hawaii International Conference on. (</source>
          <year>2005</year>
          ) 113c{
          <fpage>113c</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Golbeck</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rothstein</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Linking social networks on the Web with FOAF: a Semantic Web case study</article-title>
          .
          <source>Proceedings of AAAI08</source>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Douceur</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>The sybil attack</article-title>
          . In:
          <string-name>
            <surname>Peer-To-Peer</surname>
            <given-names>Systems</given-names>
          </string-name>
          : First International Workshop,
          <year>Iptps 2002</year>
          , Cambridge, Ma, USA, March 7-
          <issue>8</issue>
          ,
          <year>2002</year>
          ,
          <string-name>
            <given-names>Revised</given-names>
            <surname>Papers</surname>
          </string-name>
          , Springer (
          <year>2002</year>
          )
          <fpage>251</fpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>