View source for Socialig/Use Case TF/Overview

http://www.w3.org/2005/Incubator/socialweb/wiki/RequirementsAndUseCases-WorkArea

== Prior Work ==

Social XG: Requirements and Use Cases - Workarea: [http://www.w3.org/2005/Incubator/socialweb/wiki/RequirementsAndUseCases-WorkArea] Final Report: [http://www.w3.org/2005/Incubator/socialweb/wiki/FinalReport]

== Use-cases ==
Use-cases are specific user-visible tasks that individuals want to accomplish.
* '''Personal publishing''': For [https://indiewebcamp.com/why numerous reasons] it is better to publish on your own site than on social [https://indiewebcamp.com/silo silos], including user-unfriendly terms-of-service and [https://indiewebcamp.com/site-deaths long term unreliability].
* '''Personal syndication''': While it is important to own your content by publishing on your own domain, there's also a strong use-case based on the need to let friends and family know what you're up to, and they may prefer to read content in a social silo. Thus there's a need for personal syndication, the ability to easily syndicate your content from your site to social silos that your friends & family use.
* '''Personal interactions''': 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. And since you want your interactions viewed by the author of the original post, syndication of these interactions from your site to wherever the original was posted is another related use-case.
* '''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.
* '''Personal archiving''': the most important memories of our personal lives are stored in consumer networks -- as photos, text, or videos. Having a standard format for our social data, and a standard API for getting that data in and out of the service, can help put users back in some control of their personal memories and lets them save that data offline or move it to another vendor's platform or preferably to their own website.
* '''Archiving Linked Documents''': Similar to personal archiving, there is a use-case for wanting to have a backup of external documents, such as backing up all replies on various websites to a particular article (or photo, or checkin etc).
* '''Data portability across providers''': ability to easily migrate social provider (also in line with EU guidelines), including profile, groups, relationships, activities AND media history. Either online via backend API between providers and/or through export/import of a (standard) social media archive [also useful for personal backup]
* '''Enterprise social applications''': The enterprise invests considerable money and time into developing applications for their business. Developing to a standard API and data format may help their investment and let them concentrate more on their business needs rather than third-party requirements.
* '''Social applications for organizations''': similar to "Enterprise social applications" but more general, including public adminstrations, non-profit-organizations or associations etc.
* '''Friending''': As a user on a social network, I would like to add other social network users to my friends list, and vice versa, as a basis for further interaction.
* '''Business Profile and Relationship Federation''': 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 (see http://opensocial.github.io/spec/2.5.1/Social-Data.xml)
* '''Federated social groups''': In enterprise or any federated context in general, people would need to gather and create temporary or permanent communities/projects hosted on one site with members having their account residing on other sites/enterprises
* '''Activities''': Distribution, collection, aggregation and analysis of fine grained activity data for a wide variety of purposes. These may range in complexity from relatively simple "Recent Activity" lists in a UI (similar in nature to RSS/Atom use cases) to more complex activity analysis and data mining capabilities.
* '''Portable In-Context Actions''': The ability to describe and attach potential actions to a piece of content, as well as a model to allow those actions to be carried out in-context, without pulling a user away from the content. (see http://opensocial.github.io/spec/2.5.1/Core-Gadget.xml#Embedded-Experiences, http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-actions.html, http://schema.org/docs/actions.html, https://developers.google.com/gmail/actions/)
* '''In-Line Social Tagging''': Some APIs, such as the Facebook Graph API, use an in-line social tagging mechanism that allows social tags to be included directly within plain text. It would be helpful to have a common mechanism that allows for federation of such systems. For instance, Facebook uses "@[AaJfY_M0tTe_ZAM6P71Zr72msCJYG2EePwuyB]". A federated approach could be as simple as: "@[{id}]" where {id} is any IRI/URI. For instance, @[acct:joe@example.org] or @[http://example.org/~joe], etc.
* '''Browser-based followship''': simple mechanisms (e.g. via JS buttons) to easily follow ("subscribe") another user using one's own social network account by clicking on someone else's identifier
* '''Browser-based sharing''': simple mechanism to easily "share" a web page using one's own social network account on any webpage (similarly to OExchange initiative)
* '''Social activity triggering via mobile interactions (barcode, NFC)''': publish social activities on the go by scanning a barcode or tap an NFC to trigger a like/checkin/etc
* '''Social interactions in proximity''': proximity-based (p2p, group) exchange of social activities between users collocated in a public or private space each having identifier on a different domain and possibly in an infrastructure-less environment (leisure, professional or public safety scenarios)
* '''Social web of things''': social-based interactions with connected objects and the web of things (IoT) leveraging AS-actions (to generally interact with objects and possibly control them), social relationships (friends, f'ers, f'ing) as access control, etc for users to control or query objects, but also for objects to send remote notifications to users. "Social Things".
* '''Digital Object memory / Product traceability''': use of activity stream to maintain & show the history of a product or object (who did what), e.g. for asset management in the business domain and/or product traceability in consumer & business domains.
* '''Extensibility''': A new unforeseen feature has been developed and deployed on one instance or node of the social network. Users like that feature and want to see it supported by as many instances as soon as possible.
* '''Check-ins to venues''' - see: [[Socialwg/Check-In_Use_Case]]

=== Domain Specific Use-Cases ===

* Learning
* Communities - There are so many kinds of communities that it's important to draw this one out a bit:
** Public vs. Private - Every community has a membership. The membership consists of one or more people or other entities (such as sub-communities). In a Public Community, the Content, activity, and information about the community is available to non-members. In a Private Community, the Content, activity, and information about the community is available only to current members.
** Open vs. Closed - An Open Community is one which any one is free to leave/join at will. A Closed Community is one in which membership is controlled/moderated by a Community Leader or Moderator.
** Organizational - These are communities that exist relative to an Organization, such as a business or a school.
*** Intra-Organizational - These communities consist solely of members of the organization. All content, activity and information about the community is private to the organization.
*** Extra-Organizational - These communities consist solely of members outside of an organization. Content, activity and information MIGHT be available to the organization, but the Organization itself does not participate.
*** Trans-Organizational - These communities consist of members both inside and outside of the organization (and may connect Intra- and Extra-Organizational communities).
** Social/Ad-hoc - (we need a better term for this) .. these are the types of communities that emerge through traditional public social media. They include things like followers/followees, your "friends list" on facebook, people who share common interests, etc. Spontaneous or engineered communities which arise (and perhaps dissipate again) around hashtags or popular topics.

== Research Topics ==
The following are more generally worded research topics (that could inform specific additional use-cases) that are not specific to particular tasks.
* Encouraging innovation: developers of web and mobile applications create new and interesting social data all the time - new kinds of sounds, videos, and data. A standard, extensible API for distributing that data to friends, family, and colleagues over a social network lets the developer concentrate on their innovative work in the client app.
* Big Data: researchers are developing new techniques to develop insights about people based on their social network data. But comparing data extracted from different platforms is like comparing apples and oranges. Standard data formats let data scientists and academics develop and test new theories about individuals and groups.

== Application Scenarios ==
Various application scenarios common to OpenSocial environments
<gallery>
File:Embedded_Third_Party_UX.png
File:Multiple.Embedded.Third.Party.UX.png
File:Server.Provided.Data.png
File:Container.and.Components.with.Multiple.Servers.png
File:Third.Party.Application.png
File:Server.to.Server.png
</gallery>

== See Also ==
* [[socialwg]]