- The main purpose of this document is to elicit open discussion towards common understanding of the Social Web Architecture. It offers terminology and possible solutions for one or more identity, profile and social graph management challenges through a Social Web architecture/system of frameworks.
- Version 2.0
- 1 Problem Statement
- 2 The Vision
- 3 The Terminology
- 4 Social Web User and Profiles
- 5 Distributed Social Profile
- 6 Social Graph
- 7 A System of Frameworks
- 8 Summary
- 9 Acknowledgements
People express different aspects or facets of themselves through social norms that allow them to deviate from a single instance, depending on the social context, thus giving themselves multiple profiles. This human trait enables people to maintain various relationships within and across different social contexts: the family, the sporting team, the business environment, etc.
In the “real world” people can usually sustain this multiplicity of profiles as they are physically constrained to a relatively small set of social contexts and interaction opportunities.
In some ways, social dynamics on 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 in scope (perhaps even unlimited).
Social Graph Management Today
Many Web users have many accounts on social and professional network services. They utilize 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 different social contexts 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:
- Maintaining a multitude of online profiles for different contexts is cumbersome and time consuming.
- 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.
- A user cannot control how their information is viewed by others in different contexts 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.
Users participating in the Social Web will have 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 organize one or more different 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 widely adopted and open standards to do this do not exist. The current “aggregator” approach are short term solutions akin to the “screen scraping” days of the 1980s and unlikely to scale to the necessary size.
The new approach we propose allows the user to associate a specific Social Profile 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 utilize the same features, and your Health Profile can be exposed to health care providers and your Citizen Profile exposed to online Government services. New players, large or small, can also interface to these Profile services and offer seamless access to a User's personal data. This approach opens up the market for targeted user profile management services by a wide range of stakeholders.
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 (eg leaking of personal data) outside of their social network. Concepts such as "friends of friends" can open and expose personal data to wider audience than the user may have expected. With a common user-managed policy framework used across all Social Applications, the user will now be in direct control of access and usage permissions to their different profiles. Having a common framework makes it easier for the user to understand the implications of their privacy and access control decisions.
As custodian of their own 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 Web User?
- 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?
Social Web User and Profiles
Figure 1 below shows how a single Web User (one person) can have multiple profiles and, in this case, the user has three overlapping profiles. Profiles can share common attributes. The 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 instances.
The attributes 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 attributes needed for that specific context or social application. However, one of the more interesting aspects of the future profile format will be the dynamic attributes 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 real name. Some applications (and users) may not wish the user to expose their true identity( ie real world legal 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 attributes.
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
Attributes within a profile may be distributed. This means that the relevant attributes are stored with a social application service for use in the context of that application. For example, a work phone attribute 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) attributes make up my Work Profile.
A profile management service would understand the distributed attributes and allow the Social Web User to edit/access the attributes as if the attributes were local.
Figure 2 below shows a Profile that has two sets of two attributes at distributed sites, and two local attributes. The Social Web User is interacting with the Profile through the Blue social application.
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, cousin, 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. Of course, this depends on the context of the Social Application as to the level of interoperability of the connections.
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 3A 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
- Amy - using her Profile#1 to:
- 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
- Amy - using her Profile#1 to:
- 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
- Bob - using his Profile#1 to:
- Red social application connects:
- Ed - using his Profile#7 to:
- Dan - using his Profile#2
- Ed - using his Profile#7 to:
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 Web User 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 connections are 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…)
Figure 3B shows an example of Social Groups. In this example, Amy has designated a number of her connections into two Social Groups. These named sets then enable Amy to refer to the collection of connections in a single instance. For example, allow my book reviews to be read by my Book Club members only.
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). Each framework consists of a set of standards, industry best practice guidelines, and reference implementations.
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 management services are required to access and authorise social application services and enable/support the (distributed) services for other Frameworks (see below).
There are arguments for and against combining Identity and Profile Frameworks. At this stage, we have them separate.
It is currently unclear where or how, but log-in credentials for different social applications may be connected to the identity framework.
In the Identity Framework, the user gains access to (views) his/her distributed (or centralized) profile attributes 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 attributes.
An identity management service provider can guarantee different levels of security and authentication to users, merchants and social application providers.
The Profile Framework contains those services which the social applications would access to modify profile attributes, and the distributed access to such information.
Open technical standards for interoperable distributed profiles enable this use case. They will allow more social applications to give Social Web users the necessary control of their own profiles. Adoption of standards would 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.
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).
Policy Expression will focus on representing the interactions and dependencies between the critical policy languages for collaboration and sharing, such as Privacy and Rights management. A policy language is a mechanism to declare a set of rules or statements that capture and express the requirements of individuals and organisations from a corporate, legal, best practices, and/or social perspective. Currently, existing individual policy languages are missing an overall framework and architecture allowing the combination of different policy languages to interoperate and provide an accountable, enforceable, flexible and trusted experience for the web community.
The end goal is to develop a framework in which policy languages can coexist and share semantics and to support a wide range of policy functions. This poses fundamental challenges with each language having its own specific goals and context, but having a common impact on the Social Web. In particular, how they are harmonised to support open Policy Transparency of distributed policy information, conformance, and behaviour.
Policy Accountability is another major challenge to detect policy breaches so that some modicum of accountability can be instilled in the social web. This is a departure from the current approach of attempting to provide policy enforcement. Most attempts to provide enforcement on the web (for example, traditional digital rights management for multimedia content) have ended in failure, and are not well accepted by the web community. The accountability mechanism may support recording policy breaches that the user is aware of and the consequences of their actions.
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.
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.
The Analytics Framework complements the Profile Framework by automatically creating and updating a user's interest/experience/opinion viewpoints relevant to specific profile. This will enable the formation of communities-of-interest as the Profiles of individuals reach a threshold of similarity. At the same time, the Privacy aspects of a person's profile will dictate when and if such connections are made (string link to the Policy Framework).
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 attributes 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, and the Web User may require some level of disclosure to determine the merchant quality.
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.
The authors would like to thank members of the W3C Social Web Incubator Group for general comments and suggestions. Also thanks to Anita Dohler, Kaliya Hamlin, Henry Story for specific suggestions.