For Developers - The DataPortability Project

This page holds ideas for people who maintain or build websites on things they can do now to support Data Portability.

The ideas in here are not hard and fast rules but rather suggestions for Best Practice.

OpenID

Add support for OpenID2.0 as a consuming site for both login and registration.

Employ a library that supports Attribute Exchange 1.0 for sign-ups to pre-populate the account sign-up form (name, email etc.).

If you're thinking of being an OpenID provider think very carefully about whether that's a good idea and you want the responsibility of long term support.

Use the link between OpenID URLs and Members to do searches based on OpenID as an identifier

seeAlso:

Plaxo's guide to implementing OpenID

XFN

Add XFN to all relevant links that appear on user profile pages and lists of contacts pages.

- A link to a page I own
  <a href="http://blog.example.com/" rel="me">My Weblog</a>

- A link to a contact on this site
  <a href="http://kate.example.com/" rel="contact">Kate</a>

MicroID

To enable users to claim ownership over their hosted content, add MicroID to user profile pages in the <head> section and in the visible HTML for all other user content (comments, hCard etc.).
<meta name="microid" content="mailto+http:sha1:ca94387152e8ea62fee73c45c4bae79e54543485"/>
<span class="comment microid-mailto+http:sha1:ca94387152e8ea62fee73c45c4bae79e54543485">Comment.</span>

hCard

Add hCard contact details to user profile pages, and add a MicroID to it as well.
<div class="vcard microid-mailto+http:sha1:ca94387152e8ea62fee73c45c4bae79e54543485">
<a class="url fn" href="http://example.com/" >Jon</a>
<div class="tel">+1-303-308-3282</div>
<div class="title">Web Developer</div>
</div>

FOAF

Create a FOAF file for each user that includes a section about that owner, with all their data. Include all public data as well as the mbox_sha1sumbut don't include an email address unless it's shown publicly. Include a list of "friends" consisting of just a unique ID (mbox_sha1sum, OpenID) and a link to their FOAF file. Allow members to store a link to any external FOAF file(s) and include links to this in their data.

To allow for discovery add a <link> tag to the FOAF file.
<link rel="meta" type="application/rdf+xml" title="FOAF" href="foaf.rdf" />

Consider notifying Pingthesemanticweb.comwhen a member's FOAF is updated.

FOAF is RDF and is typically transmitted as RDF/XML (a syntax of RDF). As such there are as many ways of defining the layout of the file as there are people hand coding it. There is a style of FOAF that has become common on the web.
One file per member. that file should consist of 3 sections:-

A Section defining the document
A main defining the member with all their data. Include all the data you can that also appears on public HMTL pages. Don't include email address unless it's shown publicly, but do include the mbox_sha1sum so it can be related to data from other sources.
A list of contacts using the foaf:knows property. Each should consist of at least a unique ID (mbox_sha1sum, OpenID) and a seeAlso link to their FOAF file. It can contain some human terms such as name. It is not necessary to include all their data as that can be found by following the seeAlso link.

As an alternative to publishing the same information twice, consider using GRDDL. This allows you to setup a description of the data on your site and point to a transformer to turn it into RDF/XML.

If you need assistance with putting together FOAF data out, please ask in #swig or #foaf on irc.freenode.net.

Machine Readable Export

Support as many flavors of export data as possible, such as RSS, ATOM, JSON, APML etc. Typical formats

RSS/Atom. You should use RSS 2.0 and/or Atom 1.0 for syndicating data such as blogs
FOAF
MS Outlook CSV export
APML

APIs

Build APIs to allow your website's data to be read and updated from other services.

Use REST (GET, PUT, POST, DELETE) where possible.

Understand and copy well known APIs from elsewhere, such as Flickr, Amazon, Twitter and standards for APIs such as Atom-Pub for Blog publishing.

Auto-discovery

Many of the formats mentioned have an associated convention for auto-discovery where a link is placed in the HEAD section of a web page. eg

You should also provide links in the visible HTML to these files.

API Authentication

Use OAuth authentication to allow users to give a service access to their data without exposing their credentials (ID and Password).

Implement oAuth where you need to use the services on another system. Try to avoid asking the user to give you their ID and Password on that other system.

Privacy

Our notions of privacy must adapt. That starts by developing the language to discuss privacy in a way tha's obvious and salient. Simply demanding the protection of one's privacy is now a hollow and unrealistic demand. Our systems should protect our privacy by allowing us to fine-tune the trust we put in our friends.

The basic rule to follow is that if the data is available as public HTML web pages, then it is safe to put it into corresponding formatted files. Be careful with the possibility of private data leaking out into the public world.

Identifier Search

There are a number of types of attribute that the Web Ontology Language calls an Inverse Functional Property. This means that while a person or thing may have many of these, one of these values is generally only owned by one thing. So for instance a person may have many email addresses, but an email address is usually (but not necessarily) owned by one person. These are important to DataPortability because they are often used as unique identifiers for people.

In your site, you should add indexes to your member database to be able to find people based on one or more of these identifiers. The most important are:-

Email Address. You probably already have this. There are free and commercial libraries to get social network data from web email services as a list of your friend's email addresses, although you should avoid their use - see password anti-pattern.
mbox_sha1sum. mbox_sha1sum is a way of hiding email addresses while still providing a unique identifier. It's the result of the hash sha1('mailto:address@domain')
OpenID URL. If you support OpenID as a consuming site, then you will be already storing a lookup between OpenID URLs and Members.

There are other properties such as Instant Message address and Blog URL that are likely to be Inverse Functional but you're less likely to receive them or need to lookup members against them.

OpenID

XFN

MicroID

hCard

FOAF

Machine Readable Export

APIs

Auto-discovery

API Authentication

Privacy

Identifier Search

Problem Overview

Problem Specifics

Actions you can take

Community Evangelism

Open Initiatives

Implement DataPortability

Business Justification Guides

Design/Decision Guides

Reference Implementations

Case Studies

List of places you can promote your outcomes/register your compatibility

Host a DataPortability talk

Sample Slides

People to invite in your area (nominate yourself!)

Find out more

Action Pack Curator contact details