From Social Web XG Wiki
Social Web User and Profiles
Figure 1 below shows how a single 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 platforms. In some cases, the social platform 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 and desires of the user and context of each social application. Any possible profile standard must be extensible to cater for all types of attributes needed for specific contexts and attendant social applications. This includes dynamic attributes that capture the evolving changes of a person’s context, such as geolocation attributes.
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.
@@Henry Story: This graphic should be redone. It does not make clear where the profiles are stored: namely on the Social CMS. The central view is an aggregated view that the user may have on his desktop for example. Here is an image that is somewhat easier to understand. Profiles are portrayed as pages. Containers are boxes - they could be annotated with the icons for the different types of social network platforms. Links are just relationships from one profile on one Social CMS to another CMS. @@
Tagging is a powerful and massively deployed means to categorise content on the Web, as used for pictures (Flickr), videos (YouTube), blog posts, etc. it raises various issues in terms of interoperability.
Thus, various tagging ontologies have been developed in the past years and we describe some of them in this section. Among others, Newman's Tag Ontology and [TagOnt http://tagont.googlecode.com/files/tagont.owl] - as well as work defined as part of the TagCommons project - define models to represent the tripartite model of tagging, i.e. the relationship between a User, a Resource and a Tag. The Tag Ontology is also based on SKOS (Simple Knowledge Organizations System) - so that tags can be hierarchically organised (e.g. 'Web" > "Social Web") - and it uses DublinCore to represent the time of the tagging action. Motivated by a need of more interoperability between tag-based applications, SCOT - Semantic Cloud Of Tags - extends the previous model by focusing on the representation of tagclouds and their portability across applications. It introduces different classes and properties to model, among others, the coocurrence of tags within a particular service, a feature also provided by the model defined in the TAGora schema. Other models can also be used to represent tags and tagging relationships, yet without considering the tripartite model of tagging actions. The NEPOMUK project provides for example a a nao:Tag class in the NAO vocabulary. The Bookmark mode proposed by Annotea back in 2001 can also be used links a resource to a set of annotating terms, and to organise them using a bookmark:subTopicOf property, similarly to the skos:broader one in SKOS. The RSS 1.0 Taxonomy module can also be used for such purposes, and provides a property to link topics to any RSS item. Finally, the rel:tag microformat is used to link an item to its tag(s). While not being directly available as RDF, GRDDL can be used to transform any XHTML page using it to RDF data, for instance using one of the aforementioned model.
In order to address other interoperability issues of tagging, namely their ambiguity ('apple') and heterogeneity ('socialweb', 'social_web', 'socweb'), MOAT (Meaning Of A Tag) and CommonTag focus on modelling the Meaning of tags as an additional element in a tagging action, and consider the use of resources from the Linking Open Data project to represent that meaning. Thus, tagged content is not only linked to simple keywords, but to identifiers of structured and meaningful resources, from where additional information can be discovererd. As an example, from content tagged with http://dbpedia.org/resource/Apple_Inc. (instead of "apple"), one can identify that the content is about computer-related projects, but not about fruits, while such identification is complex in case of keyword-based tagging. In addition, one could know that a content tagged with http://dbpedia.org/resource/iPhone is related to the previous one, since the resources used to tag it share relationships in DBpedia. Thus, tagged content then becomes more interoperable and discoverable, and these models provide a way to bridge the gap between genuine Web 2.0 tagging and Linked Data.
Finally, to address the lack of predicate in tagging, as raised in the Semantic Web FAQ, NiceTag explicitly adds a relation between what is tagged and the label of the tag. This relation may remain generic if there is no available mechanism to specify it, but any existing RDF predicate may be reused, making the model open and compatible with other vocabularies. In NiceTag, three elements are connected every time an act of tagging is performed (understood as a speech act): a resource or the state of a resource, a relation and a sign (the label of the tag), all inside a named graph that receives its own URI. By doing so, it becomes easier to add context to each act of tagging (where it was performed, who did it, its license, etc.). One major feature of semantic tagging thus conceived is to improve traceability, add context and let one query tags at their various levels: individual tags or tags in various folksonomies. An important question regarding tagging is "what exactly is being tagged?". Instead of a document, the answer, according to the AWWSW task force must be "a resource" or its expression. Most of the problems that were raised in the wake of the Identity Crisis affect tagging and must be solved the same way. To do so, NiceTag reuses the IRW ontology and, overall, should not so much be considered as an ontology than as a set of design patterns, or a ready-to-use RDF layer for tagging. Consequently, it's not necessary to chose the primitives it defines, others can be imported from previous models. It is an important feature with respect to the goal of standardization as it doesn't impose one ontology of tagging over the others.
Single Distributed Social Graph
Attributes within a profile, including information about social connections, may be distributed. This means that the relevant attributes and social connections could be stored with a social application for use in the context of that application. For example, a work phone attribute is stored by my current employer's social platform, but another social platform (e.g., LinkedIn) may store my previous employer's information. Together, these two (distributed) attributes can be considered a distributed single "work" profile whose information I may want to combine in context of a social application (such as a job-hunting social application).
A profile management service would keep track of the distributed attributes and multiple profiles and allow the user to edit the attributes across multiple platforms. Figure 2 below shows a profile that has two sets of two attributes at distributed sites each with two local attributes. The user is interacting with the profile through the "blue" social platform.
@@Henry Story: The above does not show how the profile is distributed or how it can be merged. The picture below uses the widely known database symbol, a cyclinder - Oracle's campus near Redwood city is composed of 5 cylindrical buildings! - to show the information contained in the database. The two small graphs show the information fetched form social networks - it would of course be better if in a previous diagram those social networks were in fact shown to be isomorphic to this. The large graph shows the merged information. @@
Multiple Distributed Social Graphs
A profile is associated with one or more social platforms in which the user's social graph is formed and nurtured. The social platform is the context for how a user is connected to the profiles of others and will support the specific connection types (e.g. friend, colleague, likes, etc) that will typically serve the purpose of some social application. A core feature or service of a social application is to make, maintain, and expand these connections.
A user’s connections in a particular context should be portable. The user should be able to take them to another social platform, 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 platform as to the level of interoperability of the connections. Connections could have contextual metadata associated with them to be used by social applications. As social applications and platforms increase and compete for your attention, moving your profile should also support tracking your connections throughout multiple context, even if certain application-specific context is lost.
Figure 3A shows an example of multiple distributed social graphs with a number of different users, profiles, and social platforms. For example:
- The blue social platform connects Amy (Profile#1) to Bob (Profile#2), Col (Profile#3), Dan (Profile#2), Bob (Profile#1).
- The green social platform connects Amy (Profile#1) to Fran (Profile#3), Gary (Profile#1), Ed (Profile#2).
- The orange platform connects Bob (Profile#1) to Amy (Profile#2), Fran (Profile#1), Ed (Profile#7).
- The red social platform connects Ed (Profile#7) to Dan (Profile#2).
Note that Amy (Profile 1) in the "blue" social platform is connected twice to Bob via his Profile 1 and 2. This demonstrates that the same user can connect via different contexts (supported by the same social platform).
@@Henry Story: Again this graph is very confusing. To put typed symbols on the links between profiles has to be wrong. This suggest that the linking between social networks has to go through a specific owned pipe. The connections between services are on the open internet and are not owned. @@
The lines between profiles are either uni-directional (such as Twitter) or bi-directional (such as Facebook) to capture where the connection is or one-way (following) or mutual (friendship). Two dots means that the connection is bi-directional. One dot means the connection or association it is not reciprocal.
Figure 3B shows an example of explicit groups. In this example, Amy has designated a number of her connections into two groups. These named groups 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".