SocialWebTechOverview

By Harry Halpin and Renato Iannella and Christine Perey

Problem Statement

People express their personality through social norms that allow them to deviate from a single instance, depending on the social context. This human trait enables people to maintain various relationships within and across different social structures: the family, the sporting team, the business environment, etc.

In the “real world” people can usually sustain this multiplicity of personalities as they are physically constrained to a relatively small set of social structures and interaction opportunities.

In some ways, social dynamics in the Web resemble those in the physical world. Many people with cyber identities or electronic personae are associated with the same people (they “know” one another in both the physical and digital worlds).

Social structures in the digital world differ from those which dominate the physical world in a number of important ways:

• the set (number) of people with whom interactions are possible is not limited by distance or time,
• a person can block digital communications with or “manage” the type of association/relationship they wish to have with others (individuals or groups)
• the personae exhibited by one individual, unique person:
  • are not controlled by the same social norms as in the physical world,
  • can - as in the physical world - evolve (quickly or slowly) over time and
  • are less limited (perhaps even unlimited).

Social Graph Management Today

Many Web users manage different social and professional network accounts. They utilise their different accounts in different ways, depending on the digital context. For example, more friendly chat on FaceBook, more professional discussion on LinkedIn, and a bit more daring interactions on Hi5.

While it has advantages, such as those which permit people to experiment with and to benefit from new social structures in the Web world, the current architecture, in which social networks must each provide a separate system to manage the user's profiles, identities, permissions, social graph and social media is not scalable.

There are three major problems experienced by the end user:

1. Maintaining a multitude of online profiles is cumbersome and time consuming.
2. This is also an impediment for new social networks to attract new members simply because of the effort involved in creating and maintaining "yet-another-profile" and re-establishing different aspects of your profile under a new context.
3. A user cannot control how their information is viewed by others in context (contextualized by different social applications)

Participation is the life blood of social networks. If no one (or if too few people) participates, a social network or social application dies. If social applications are to thrive and provide engaging and new (most importantly valuable) services to Web users, then there must be scalable ways for people to connect with and manage their social interactions and connections.

The Vision

In this section we offer what we believe to be the vision of the Social Web.

Every user will seek to participate in the Social Web, but will also seek to have different personae for different situations/contexts. This ability - to set up and to maintain multiple profiles, depending on the context of the social application - will be the driving force that will expand participation in the Social Web including and beyond the silo applications provided by existing Social applications.

A Social Web user should be able to create and to organise one or more profiles at a virtual location and using the management interface of their choice. For example, a user might want to manage their personal information such as home address, telephone number, and best friends on one profile management system and their work-related information such as office address, office telephone number, and work colleagues on an other management system, or may even want to store their entire profile locally with a trusted third party. Today an open environment for this scenario does not exist. The current “aggregator” approach are short term solutions akin to the “screen scraping” days of the 1980s.

The new approach we propose allows the user to associate their Digital or Social Identity directly to Web 2.0 service providers. For example, your Friends Profile can be exposed to MySpace and Twitter, whereas your Work Profile to Plaxo and LinkedIn. Additionally, traditional service providers can utilise the same features, and your Health Profile can be exposed to Medicare and your Citizen Profile exposed to online Government services.

Open technical standards for interoperable distributed profiles offer the enabling technologies. They will allow more social applications to give Social Web users the necessary control of their own profiles. Standards will allow users themselves to decide on which service providers they share which profiles. It will make it easier to shift or share profiles to other applications, and it will make the application providers compete for the attention of the web users, improving value added services. Technical issues, such as profile synchronisation, can also be addressed with clearer management of profile sources. The range of technical issues for distributed profiles is immense and growing; from our work new and different architectures and representation formats providing interoperability will emerge.

Privacy is still one of the major issues with online profiles managed by existing social networks, and often the user believes that by setting a “private” user profile they will not be exposed to any threats outside of their social network. With the open and user-managed policy framework interconnected to the identity and profiles, the user will now be in direct in control of access and usage permissions to their profiles, the issue of Privacy, and also rights management, then becomes somewhat easier to understand and the implications of their decisions clearer to the users.

As custodian of their own identity and profiles, users can then decide which social applications can access which profile details via exposing one (or more) profiles to that provider. In this new architecture, exposing a profile is an explicit act, and one that the user is more aware of, and can just as easily retract as well. This, in itself, is one of the biggest challenges for the entire web community, not just social networks, and needs a new “policy-oriented web” architecture to support trusted rule-based services in the longer term.

This paper will propose definitions for the following concepts:

• What is Social identity?
• What is a Social application?
• What is the Social Web?
• What is a social profile?
• What is a distributed profile?

It seeks to provoke discussion and to offer our answers to the following questions:

• Does the user of digital networks (Social Web) have one or more identities?
• Does the user have one or many profiles?
• What are the relationships between the user, the user’s profiles and social graphs?
• What data is in a profile?
• How is information on a user distributed?

The Terminology

Social Identity and Profiles

Figure 1 below shows primarily how a single Social Web User (one identity) can have multiple profiles and, in this case, the user has three overlapping profiles. Profiles can share common properties. The Social Web User can then associate his/her profile at the profile level with particular social applications. The Profiles are exposed to and/or synchronized with different social applications. In some cases, depending on how a profile services works, the social application will update a profile property and this modified property will be reflected across all profile uses.

The properties included in a Profile will depend greatly on the needs/desires of the individual user and context of each social application. There are many clear candidates to cover personal and work information (e.g., vCard) and social graph relationships.

A Profile format or standard must be extensible to cater for all types of properties needed for that specific context or social application. However, one of the more interesting aspects of the future profile format will be the dynamic properties that capture the evolving changes of a person’s context.

One question which bears consideration is to what extent a social profile will include a user’s true name. Some applications may not wish the user to expose their true identity/real world name.

In Figure 1, one Profile is associated with the Light Blue and Red social applications, one Profile to the Grey social application, and one Profile to the Blue, Green and Orange social applications.

The deeper layer of discussion goes into the update/synchronization of the profile properties. 

Question: does the user use the profile to log into a social application, 
or is there is something else which is used to log in with something else? 
- use specific log-in credentials which would be decoupled from your profile? 

Distributed Social Profile

Properties within a profile may be distributed. This means that the relevant properties are stored with a social application service for use in the context of that application. For example, a work phone property is stored by my workplace (social app) service, but a social application (e.g., LinkedIn) may store my previous employer's information. Together, these two (distributed) properties make up my Work Profile.

A profile management service would understand the distributed properties and allow the Social Web User to edit/access the properties as if the properties were local.

Figure 2 below shows a Profile that has two sets of two properties at distributed sites, and two local properties. The Social Web User is interacting with the Profile through the Blue social application.

Social Graph

A Social Web Profile is associated with one or more Social Applications in which the user's Social Graph is formed and nurtured. The social graph, typically, is managed by the Social Application, but the two are inheritably linked. The social application is the context for how a user is connected to the profiles of others and will support the specific connection types (eg friend, colleague, family, doctor, etc) that will typically be the purpose of the social application. A core feature or service of a social application is to make, maintain, and expand these connections.

A Social Web User’s connections in a particular context should be portable. The user should be able to take them to another social application, so it is not necessary to re-establish all connections again in another (new) social application.

Connections have contextual metadata associated with them. They are dependent on the social app, portable, and become part of your profile. As social applications increase and compete for your attention, moving your profile should also support taking your connections. There maybe a lost of some context, but the core connections should travel with your profile.

Figure 3 shows an example Social Graph with a number of different Social Web Users, Profiles, and Social Applications. Specifically:

• Blue social application connects:
  • Amy - using her Profile#1 to:
    • Bob - using his Profile#2
    • Col - using his Profile#3
    • Dan - using his Profile#2
    • Bob - using his Profile#1
• Green social application connects:
  • Amy - using her Profile#1 to:
    • Fran - using her Profile#3
    • Gary - using his Profile#1
    • Ed - using his Profile#2
• Orange social application connects:
  • Bob - using his Profile#1 to:
    • Amy - using her Profile#2
    • Fran - using her Profile#1
    • Ed - using his Profile#7
• Red social application connects:
  • Ed - using his Profile#7 to:
    • Dan - using his Profile#2

Note that Amy (profile#1) in the Blue social application is connected twice to Bob via his Profile 1 and 2. This demonstrates that the same Social Web User (identity) can connect via different contexts (supported by the same social application).

The lines between profiles are either uni-directional or bi-directional to capture where the connection is mutual or one-way. Two dots means that the connection is bi-directional. One dot means the connection or association it is not reciprocal. For example, Facebook is always bi-directional but Twitter is uni-directional.

Doesn’t solve the pain point we have today. 
We have to confirm all the contacts from scratch for every social application. 
Can I somehow have an architecture where I can see how I’m connected to everyone?
A single connection tool which “sees” the context of a friend (Central management of all connections…)

A System of Frameworks

In this paper, an emphasis has been placed on the creation and management of profiles and how end user "pain points" associated with profiles might be addressed differently with a Social Web approach. To be successful, scalable and open, a Social Web architecture or framework must specify and support a range of Social Web services, including yet far more than Profile management.

We propose an open, conceptual system in which there are multiple, interoperable frameworks (see Figure 4).

In effect we depict a "meta-framework" within which there currently appears:

• Identity Framework,
• Profile Framework,
• Policy Framework,
• Content Framework, and
• Analytics Framework

There is no attempt in the current document to specify how the frameworks achieve their goals but the assumption is that industry or defacto standards will permit frameworks to "work together" seamlessly (e.g., pass data in formats which are acceptable to other contiguous frameworks) to enable the complete Social Web services platform for a wide variety of social applications. An evolving combination of interoperable frameworks will move us towards this overall objective.

Identity Framework

Identity management services are required to access and authorise social application services and enable/support the (distributed) services for other Frameworks (see below).

In the Identity Framework, the user gains access to (views) his/her distributed (or centralized)
profile properties at a global level. Through the Identity Framework the user would not only
view but also have the rights/authorization, and define the rights of social applications, 
to modify the Social Web User's profile properties. 

An identity management service provider can guarantee different levels of security and authentication to users, merchants and social application providers.

Profile Framework

The Profile Framework contains those services which the social applications would access to modify profile properties, and the distributed access to such information.

Policy Framework

The Policy Framework will capture the expression, transparency, conflict detection, and accountability services for trusted rules-based policies for permissions and obligations. Specifically, the Policy Framework would apply Privacy services to Profiles and underlying rights management services to the Content Framework that consistently manages the user generated content in online interactions (eg blogs).

Content Framework

Though not emphasized in the current document, another end user pain point is associated with the management of User Generated Content. A Social Web Framework must offer a way to avoid having identical user content stored multiple times in different community silos (social network platforms). Content should reside in one or more user-designated places and, through the Content Framework, social applications simply point to the content object. This is an extension of what is called among those in Semantic Web circles the principle of Linked Data.

The Content Framework covers all types of User Generated content: photos, videos, voice, music, messages, generically called the user's “social media objects” etc. The Content Framework describes how content (objects) are imported into the content storage systems, then individual objects stored, manipulated, shared, and how policies with respect to social applications are linked and so forth.

A set of interfaces or APIs that social applications communicate with to show/display or retrieve social content will drive this framework.

Analytics Framework

The Analytics Framework provides the driver that enables users to benefit from active social application participation by providing the dynamic understanding of the user’s behaviour and feeding this back into the user’s profile.

Other Frameworks

The proposed system is open to the introduction, in order to fill gaps or to suit new/emerging applications, new Social Web services via additional frameworks. For example, it is possible to envisage an e-Commerce Framework encompassing an assortment of billing, product tracking, fulfillment protocols which are already in use in other e-Commerce applications.

Or, the e-Commerce components may be orthogonal to the Social Web System of Frameworks but access a user's information for billing, shipment, past purchasing history, etc. through the Social Application's interface to Social Web services.

Further, the current system does not specify where or how Social Applications might access user location. Like with e-Commerce, location information may be derived from an entirely separate system of technologies, using standard interfaces which "feed" location data to the user's profile properties at user-defined intervals using a Social Web Profile Framework interface.

At present the System of Frameworks is not suggesting how or where to address two very important aspects of Social Applications: Context and Trust. We propose that context be inherent in the social application and, in essence, providing the user context is precisely a fundamental value proposition the social application offers to the user. The social application would "assemble" context in real time from Web service by combining information from the profile, policies the user has stipulated and user generated content from a third framework.

It is also recognized that trust is a complex subject, highly dependent on context and other factors. The level of trust between users will depend on their context. The level of trust necessary between a merchant and a user, for the purpose of fulfilling a transaction is totally different. To execute a transaction, for example, the merchant may require that the identity be verified via the Identity Framework or a third party Identity confirmation with a signed certificate.

Summary

A new Social Web Architecture is necessary to separate underlying services which are embodied in the Web from the social applications which leverage these services. With the Social Web in place, social application developers will be able to focus on their value proposition to users, not the management of low level services in silos. The Social Web Architecture as described in this contribution will replace the current “walled-gardens” (social network silos) and radically re-shape the next generation of social applications.

For this vision to become reality will require striking a balance between the complexity of managing multiple, distributed profiles and polices with the benefits of greater user control and social network interoperability. We hope that this contribution will push Web science researchers, technologists and developers to think of new, innovative ways to move towards an open Social Web architecture.