Socialig/Use Case TF/Profile Scenarios

From W3C Wiki

Overview and Instructions

This wiki page is used to collect brief descriptions of scenarios in which profiles are or may be used on the social web and in social business. These scenarios will be reviewed by the Use Case Task Force to generate use cases that involve single-system and federated profiles and to determine what data elements should be captured and communicated. The resulting use cases, requirements and recommendations will eventually be published in the Social IG Use Case Report.

Please use the section below to submit a 1-2 paragraph narrative of any social scenario involving a profile, using the following format:

ASSIGNMENT: We need to reformat these scenarios into the Use Case Template. Please put your name next to the scenario on this page, that you are going to put into template form, so others know you are doing that.

Scenario Title:

Submitter: (your full name or W3C username)

Narrative:


Comparison Chart grouping uses cases into types

Thanks to Lloyd Fassett for creating this table, seeking to compare social use cases by type (Profile Exchange, Federated Activity, or Centralized Control:

Social Profile Scenarios

Portable Linked Profiles

Scenario Title: Portable Linked Profiles ( https://github.com/hackers4peace/plp-docs )

Submitter: elf Pavlik

Narrative: We developed a proof-of-concept system for decentralized directories. It prevents people from duplicating their information and entering it into data silos. It follows the same pattern as http://dir.w3.org . In our setup we provide 4 reference implementations:

  • 2 apps (frontend) PLP Editor & PLP Browser
  • 2 services (backends) PLP Provider & PLP Directory


  1. elf Pavlik wants to list himself in Open Knowledge Directory
  2. He goes to the OK Directory website and clicks 'Join Directory' button
  3. OK Directory serves PLP Editor with configured endpoints for PLP Directory and default PLP Provider
  4. If elf Pavlik already has his profile published online, he just needs to paste its link to PLP Editor. PLP Editor will fetch this profile, verify it and if it passes provide button to list it in OK Directory (instance of PLP Directory)
  5. If elf Pavlik doesn't have profile already published somewhere, he will get a form to fill up.
  6. Once eP fills up form, PLP Editor will publish it to its default PLP Provider and
    • display link to profile published at default PLP Provider as first option
    • invite eP to download generated profile (JSON-LD), upload it somewhere and provide link to it in input field
    • publish it to eP remoteStorage account
  7. Once eP makes choice of where to publish such profile, PLP Editor will submit its link to OK Directory (configured as default PLP Directory in served PLP Editor)
  8. OK Directory will fetch full profile from URL provided by PLP Editor and create listing for it

Personal Domains as a Hub

Scenario Title: Personal Domains as a Hub

Submitter: Ed Krebs

Narrative: An individual elects to use a personal publishing domain for a variety or reasons. This personal domain becomes a hub which then connects out to the variety of social sites where family, friends and others interact. From a profile perspective, the user may not have an account on the spoke service, but should be identified and identifiable based on the user's profile (or perhaps a subset of the user's profile identified as "public"). There are several sub-scenarios for the actual connected interactions:

  1. Personal Syndication

    The ability to easily syndicate your content from your site to social platforms that your friends & family use. The individual posts in their personal domain environment, and the content also shows up in the other site(s). This could be via a "share" function or on a federated "follow" (a.k.a. subscription) method.

  2. Personal Interaction

    For all the same reasons as personal publishing, it's preferable to post replies, reposts, and likes of and to others' posts, (at least first) on your own site, rather than in a social silo, a 3rd party comment silo, or even only locally on another's site.

  3. Personal aggregation of others reactions
As a result of personal syndication we put copies of our content on social silos for our friends & family to see. When those friends & family interact with those copies, by commenting, resharing, favoriting, those interactions should be aggregated back onto the original posts on our own sites so that we can better present all the discussion around our content, across wherever people are interacting with it, in one place under personal control.


In the context of Profile, these sub-scenarios have the user from a personal domain sharing and/or interacting with content on other sites. The person's profile information, or a subset thereof, would need to appear in the secondary site without having that person having an account on that site. There may need to be methods and underlying data elements that the user can choose to share or not share individual elements. The working group will need to determine if this is an embedded flag or a separate set of elements in the syntax.

  1. One scenario would be that in a social site where my family interacts, I've shared a post from my personal domain. In that social site, my identity (display name) would need to be displayed as the originator of the post. The family member replies/comments on the post. A member of that social site is a friend of that family member, and the post is therefore also visible to this secondary reader. (This is a typical visibility model, such that when this reply is visible, the original post is visible even if there isn't a direct relationship. Often this is referred to friend-of-friend visibility).
  • The friend-of-friend reader would also expect that the hover-over feature of the social platform would reveal the richer profile content. Types of information that might be served this way:
    • Display name
    • Formal (real) name
    • Profile Photo
    • Workplace/school/occupation
    • Title
    • Email
  1. Another scenario would be that the friend-of-friend clicks on the display name, expecting a profile page. Since the originator does not have a profile page, one of two scenarios might be possible:
    1. The social platform may have a feature that builds a profile page on-the-fly, using available profile information
    2. The social platform would recognize it does not have a profile page, so instead serves up a vcard with the profile information it gets from the source system. In this case the syntax or mapping can be derived from the vcard spec rfc6350. We'll need to determine what the appropriate data elements are from this, as it is likely to be a limited subset that would be federated in the profile scenarios.
  2. In a business context, these scenarios can still exist - for instance a personal domain may be leveraged through the friend-of-a-friend model in any number of business-oriented social sites, including, but not limited to, professional communities, corporate recruiting communities, etc.

Business Profile and Relationship Federation

Scenario Title: Business Profile and Relationship Federation

Submitter: Ed Krebs

Narrative: Businesses require the ability to describe entities (individuals, groups, etc) and relationships (network connections, org structures, "friends", etc) in a consistent way and exchange that data securely and reliably across organization boundaries. There are two sub-scenarios.

  1. Multiple social platforms in the company
A company has a social intranet or corporate "watercooler" social networking platform. In this platform, employees post new messages and react to others in threaded discussions, likes, and so forth. They have a profile page in this platform. The company also has a social media content server for sharing and hosting videos. They've done so because the media platform helps take care of video-specific content issue such as streaming, and also has some social features like star ratings that are not part of their social intranet platform. The user should not have to have a different profile in the second system. Similar to the "Personal Domains as a Hub" scenario, a user's profile information, or a subset, should be available to the video sharing platform for features like hover-over or v-cards. In addition, the recommendation engine in the video sharing system should be able to leverage information about the user such as interests or skills in order to recommend the most relevant content.
  1. Social and non-social platforms
A company has a social intranet or company "watercooler" platform. However, the official profile is in another corporate system that is not social (examples could include Microsoft SharePoint, an HR system or a corporate directory system). The social system should be able to leverage the corporate profile information.

(Note from Ann: I think Microsoft would dispute that SharePoint is not social. This might have been written some years ago, when SharePoint had less social features.)

Federated Collaboration Groups

Scenario Title: Federated Collaboration Groups -- Use Case

Submitter: Ed Krebs

Narrative: Collaboration across entities is commonplace. Companies may collaborate on a product with key suppliers, or may collaborate with a university team on a research project. The current state is that one of the entities sets up a community/group/environment in a way that the other team members from the other organizations join and use. Often the remote participants do not create a robust profile, and in many cases don't add any information to the default minimums that platform requires (usually a display name and email). This collaboration suffers in several ways, including foreign tool (the remote user is unfamiliar with the platform and under-sharing or oversharing due to context switching (oversharing occurs when a user is normally in an internal tool and forgets they are currently in an external collaboration network - especially if the two environments are using the same technology).

A better view would be where the working group area is defined in each corporation's internal tool as a shared workspace. Key elements of the user's profile should be accessible from any of the participants. This is another case where there may be the need for a subset of the data elements to be identifiable as sharable or not. This may be especially true if this scenario occurs within a system that the internal profile was extracted from or federated with an internal corporate directory system, such as an HR system (see Business Profile and Relationship Federation within this same wiki page).

Note from AnnB: This scenario might also be called "Data Elements Identified as Sharable or Not, Across Social Platforms"

Economic Networks

Scenario Title: Economic Networks

Submitter: Bob Haugen

Narrative: An Economic Network is composed of Economic Agents who perform Economic Events in collaboration with each other. The network and any organization within it can be formal or informal, and is usually loosely coupled. In many cases, the members of the network do not want to assume profit-making business as usual, and they may or may not want to exchange resources for money.

  • An Economic Agent can be either an individual person or an organization, or even another economic network.
  • An Economic Event is the (usually collaborative) creation, consumption, use or exchange of Economic Resources.
  • An Economic Resource can be anything of value to the agents involved in the event, tangible or intangible.
  • One agent can be a member of several networks, and may want to preserve the same identity in each network. Or not.
  • Networks may want to be internetworked, so they can exchange resources with each other.

Examples:

One open-source software project for managing economic networks: [1]. Discussion is proceeding about how to implement the economic network model from that software, which is also the ISO Economic and Accounting Ontology, in the form of Linked Open Data.

A Farmer in many Food Networks

Scenario Title: A Farmer in many Food Networks

Submitter: Bob Haugen

Narrative: Food networks are a form of economic network. Typically, they aggregate and distribute food from many farmers. Any individual farmer may belong to more than one food network. This scenario describes one of the typical problems in that arrangement.

  1. Farmer MacDonald advertises the availability of 100 cases of asparagus on his farm profile, which is subscribed to by three different food networks.
  2. Because asparagus is popular, each network orders all of them.

* Note from AnnB: Alternate names might be "How to Manage Resources Advertised on a Network?" or "Jobs Available by Location" or "Available Slots per Class"

* Note from Lloyd_Fassett: This is my favorite use case because it includes a semantic vocabulary (asparagus needs to be defined), it has an inventory, timing, relationships (customers follow the farmer). I believe they combine to create stronger network effects than other Use Cases. It's also short and simple. I like asparagus too.

* Note from elf Pavlik: we could use http://goodrelations-vocabulary.org and http://aims.fao.org/agrovoc eg. asparagus: http://aims.fao.org/aos/agrovoc/c_669 #TODO: coordinate with Socialig/Vocabulary TF

Keep Your Profile and Friends Across Networks

Scenario Title: Keep Your Profile and Friends Across Networks

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the final report of the Social Web Incubator Group, published December, 2010.

Alice has gotten bored of her social networking sites, and wants to move to the new and increasingly popular augmented social reality gaming platform Fazer. However, she does not want to re-enter her old information and find her friends again. She authenticates herself using her browser-based ID and then accesses Fazer, and selects her "personal" identity as to not let her work colleagues know about her game-playing identity. Since Fazer is a "real-world" augmented reality social game, she does not create a completely fictional profile (although she could) but instead opts to use an existing profile. In the account creation process, she is not required to complete all the profile attributes, but has them auto-completed, and she even creates a few new (custom) fields in a profile, and this new updated personal profile information is automatically synchronized between Twitbook and Fazer. She also explicitly agrees to share her geolocation with Fazer, which she has never done with Twitbook. Her various settings, such as avatars, presence, mood indicators, time-of-day and geolocation context are also automatically synchronized. Then using her set of social connections, her existing friends are automatically discovered on Fazer and she is given the option to add each of them or invite them if they are not on Fazer. A few months later she quickly gets tired of Fazer after having made some new friends in the process of playing various augmented reality games, and she decides to completely remove her profile from Fazer. However, as Fazer supports portability, Alice is able to download her own data to her profile manager at SocialAggregator and not lose touch with her friends, including downloading their numbers automatically to her mobile phone and backing her valuable data up locally.


Creation of a New Profile

Scenario Title: Creation of a New Profile

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

The goal of this use case is to set up (create for the first time) a user’s personal profile and to make it "visible" in one or more social applications or to those in the community of users. Profiles may be distributed.

Should take into account:

  • Multiple Identities
  • Using a web service should not involve password or account name creation.

Entering and Modifying Personal Information

Scenario Title: Entering and Modifying Personal Information

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

When setting up a profile (use case above), a user is not required to complete all the property fields about themselves. They may wish to create new (custom) fields in a profile. And there may be, in the future, a desire to modify the content of those fields filled in/populated in the past (favorite music, movie, relationship status, etc).

A user's multiple profiles (business profile, family profile, friends profile, etc) may be managed through a single platform or service.

Profiles are "associated" with a unique user's digital identity. Use care not to mix identity with profiles.

Choosing Avatars

Scenario Title: Choosing Avatars

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

An avatar permits the user to be more and different than they really are and to engage imagination, fantasy and the digital avatar is more efficiently transmitted (low bandwidth) over mobile networks than a full resolution photograph/image. Avatar accessorizing is a huge business in some societies/communities. As part of a set up menu, or as part of a continuing personalization feature set, the user can modify what their virtual personae looks like, how it sounds and other parameters.

Blocking Others' Ability to Engage (Privacy From Unwanted Users)

Scenario Title: Blocking Others' Ability to Engage

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

A user must be able to adjust the “visibility” others have relative to their personal/profile information and some or all social media. In some scenarios this can be called “blacklisting”. Control can be binary: permit this person to send messages/do not permit this person to send messages, permit to see my profile/do not permit to see my profile, permit this user to see my presence status/do not… Settings can be more general: hide me and all my media from anyone who is not already known to me (prevents people from identifying me on a photograph?)

Adjusting Location-Awareness Service Settings

Scenario Title: Adjusting Location-Awareness Service Settings

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

In the management interface of an account or profile for a service which supports location awareness, there must be settings for adjusting when the location is detected, by whom and the level of accuracy (granularity) of the location. Companies providing location aware services are developing agreement on how to share location between services, but there must be consistent ways for the user to control the data stream/publication of location.

Managing Presence

Scenario Title: Managing Presence

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

The user’s “state” is a description of the condition between the terminal/user device and the presence server (managed/operated by presence management provider). Possible presence states may be binary: logged in/logged off, in a call/not in a call, typing/not typing, in motion/stopped (see context services), in a dark place/well lit place…

Setting Mood Indicator

Scenario Title: Setting Mood Indicator

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

Mood is an indication of the actor’s emotional state. There is no universal set of mood definitions. The user’s mood is an important element of context. This should be adjustable and then the change in state (status) propagated so that any application that monitors a user’s mood is updated, as well as the current state appearing when those with permission request to see/view the mood indicator.

Right to be Forgotten

Scenario Title: Right to be Forgotten

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

The user must be able to choose to have their own content deleted and forgotten. Must clearly specify the data concerned can include not only Profile data but also:

  • List of friends
  • Content shared
  • Comments and ratings given
  • Payment information
  • List of purchases

Adding and Removing Links Between User’s Profile and Third Party Generated Social Media Objects

Scenario Title: Adding and Removing Links Between User’s Profile and Third Party Generated Social Media Objects

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

These (adding and removing) links are two separate actions.

Adding a link between one person’s profile and a third party’s social media need not always be based on permission or reciprocal links. In other words, a user may link to the social media object of a user who they do not know. The two actors/users are not directly associated.

There should also be the ability to put conditions around a social media object which define if the object can be associated with a third party without first obtaining permissions.

Addition from AnnB: One needs the ability for the "3rd party" to be informed of the link, both at inception and ongoing -- and be able to block it if desired. Note from AnnB: an alternate title for this scenario might be "One-way Linkage"

Adding, Removing and Sharing Groups

Scenario Title: Adding, Removing and Sharing Groups

Submitter: Larry Hawes

Narrative: *Note: this scenario was copied verbatum from the Requirements and Use Cases work area page used by the Social Web Incubator Group in the work leading to publication of its final report deliverable.

The user wishes to have an explicit association with a group which has a name, a URL and other identity elements. The required elements to identify/validate a group are not known/standardized.

A group is composed of users/actors and can have its own profile, however, it only publishes social media, does not actively establish links with other groups or individuals.

Note from AnnB: why should a group not be able to establish links with other groups or individuals?

The manager of a group will be associating people and social media to a group’s profile (page).

Profiles as portfolios

Scenario Title: Profiles as portfolios

Submitter: Amy Guy (rhiaro)

Narrative: An individual builds an identity around content they create or work they do, within a particular community, or across multiple communities.

Their profile contains embedded versions of their projects (eg. video, images, audio) and/or descriptions of their projects. Their projects may be published in silos elsewhere and federated to the profile, or published on the profile first and syndicated elsewhere. The profile may also be used to federate interactions about their work (comments, ratings, shares, remixes..) between other people, from around the web.

Eg. Musical Alice

Alice films herself covering popular songs and publishes them to her YouTube channel. She is very popular, and has lots of subscribers on YouTube. Her fans like to share her videos on Twitter as well. Alice also makes music for animations, either on commission or voluntarily, which are created and published by other people on YouTube, Newgrounds, Vimeo, or independently (maybe even offline). Alice is the lead singer of an amateur band, who release their albums for free on Bandcamp. She publishes experimental work on Soundcloud, where she receives feedback from friends and fans.

On the web, Alice's identity revolves around her music creation. To some extent, she has branded herself with a stage name and persona. She also hopes she may one day be signed to a record label. She creates a profile which allows her to aggregate her videos, other peoples' videos which feature her music, her band's published albums, and her experimental work. Her profile automatically pulls the media from the platforms where they are published, rather than having her manually adding a piece every time something new is released. She annotates some projects with more detail about what took place, or what her role was. A view of each project includes comments from the content-host site and her favourite social networks. Her fans may comment directly on the projects on her profile, and share to other services from there.

Ride Sharing Network

Scenario Title: Ride Sharing Network

Submitter: Daniel Harris

Narrative: On our roads today there are many vehicles that are not carrying the maximum possible number of people, resulting in inefficient use of resources. Drivers can advertise (by posting information) available seats in their vehicles for specific pre-planned journeys. Hopefull passengers can advertise their needs to travel between two locations on (or around) a specific date. Drivers and passengers can find each other by searching posts containing specific criteria matching their own requirements. Drivers and passengers can then contact each other to arrange the journey. Note that drivers can contact passengers to fill their vehicle and passengers can contact drivers to travel with the driver – it's not a one way connection as both parties can benefit from efficiency.

  1. Sally advertises that she is driving from London to Plymouth on Thursday.
  2. Ben advertises his need to get from London to Plymouth but is flexible on the exact day, it just needs to be before the weekend.
  3. Sally finds Ben's advert when she does a search and evaluates his profile to be acceptable (with enough friends and previous driver ratings).
  4. Sally contacts Ben and they arrange pick up location and time.

Comments

Music Business Network

Scenario Title: Music Business Network

Submitter: Daniel Harris

Narrative:


Federating Profile Information From a Community In an Enterprise Social Social Suite To a Website

Scenario Title: Adding and Removing Links Between User’s Profile and Third Party Generated Social Media Objects

Submitter: Larry Hawes

Narrative: *Note: this scenario is an actual question posed by in Jive Software's customer community.

"We've got a website with user profiles and the user base overlaps with a Jive community. We want to give users a way to jumpstart their profiles on our site by authenticating themselves as users of this Jive community and pulling over profile information from there. Our plan had been to user the REST API (basic auth) to do this. Currently, federated users of the Jive community are getting 401 (unauthorized) responses from the API. Now, I've been given to understand that this might be related to a VPN issue. That aside, I want to make sure that our plan to use the REST API makes sense, and that there's not a better way to do this (or if there's any reason we might be getting 401s unrelated to a separate VPN issue)."

A few days later, the submitter wrote: "Our client, as it turns out, is using SSO with Jive, which will require us to use the OAuth 2.0 method instead."

Retrieved from "https://www.w3.org/wiki/index.php?title=Socialig/Use_Case_TF/Profile_Scenarios&oldid=81488"