Google Groups Home
Help | Sign in
Recent pages and files
Use Cases    

DataPortability Technical Blueprint

Note: This page is curated by the Technical Action Group and the Evangelism Action Group

This page defines Use Cases that relate to Dataportability. They may be expanded out into more detail elsewhere. They are intended as starting points for the development of best practices, standards and specifications.

Profile

  • Auto-Filling a Profile when signing up to a new site
  • Pre-populating a job application form or otherwise sharing profile information with a career site or prospective employer.
  • Automatically building a "YASN-Roll" A list with links to my profile pages on all the different systems I've joined
  • Maintaining several persona or profiles that can be used and chosen from when signing up to a new site.
  • Assigning permissions to profile fields (at least what is public or whether it can be exported and to whom). 

Social Graph

  • Export and aggregate your contacts from a Social Network site into your contact management application
  • Find your contacts on a new Social Network
  • Building a searchable aggregation of all the social graphs. A white pages for people.
  • Building a searchable aggregation of your social graph from all the sites where you have a contact list
  • Answering the question "Who says they know this person"
  • When joining a new site, having the site say "You seem to know these people, do you want to connect with them here?"
  • When you make a new contact on one site, having the same relationship automatically created on all other sites where you are both members 
  • Being able to assign certain permissions to contacts (can see my cell number, email address etc. regarding content the same) 
  • Being able to group/tag your contacts to more easily assign permissions to them (e.g. family, business partners, friends).
  • When changing the relationship between you and a contact on one site, propagating that relationship to all the other sites where it exists.

Content

  • Migrate an existing Blog from one CMS to another
  • Aggregate your, and your friend's,  "Status" (eg Twitter) from all the "Status" systems you belong to.
  • Post a Status update from a single application to all the Status like systems you belong to.
  • Moving to a new Photo sharing site and taking all your photos with you. Or wishlist, list of RSS feeds, list of books read, etc.
  • Aggregating presence information. I'm online. I'm at this location. I'm doing this with these people. In a couple of hours I'm moving there to meet them.

Function

  • Encouraging Social Networks to link to best of breed websites instead of duplicating (badly) their functionality

Other 


Version: 
Latest 3 messages about this page (27 total) - view full discussion
Feb 11 2008 by Christian Scholz (mrtopf.de)
Hi!

I added some points regarding permissions and grouping as I had in my
original use cases.

The question is maybe also how to write use cases down. In my initial
version I tried to use at least a bit to follow Mr. Cockburn
guidelines in writing goal-based use cases with roles etc. defined.
Feb 8 2008 by Christian Scholz (mrtopf.de)
Hi!


I would second that it should be separated. That way we can later more
easily decide which use cases to implement first and
link to them on a separate page. It's also easier then to annotate the
use cases with technical ideas.

Regarding the notion of the central server we also had some discussion
Feb 6 2008 by Julian Bond
J. Trent Adams <jtrentadams@gmail.com> Wed, 6 Feb 2008 11:04:12
Go for it. One thought though, the big long list of pages on the main
page is going to become unmanageable. Perhaps we need to break out
groups of them into the associated Action group pages.
24 more messages »
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2008 Google