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.
- 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
- 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 page I own
- A link to a contact on this site
<a href="http://kate.example.com/" rel="contact">Kate</a>
- A link to a contact on this site
- 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>
- 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="title">Web Developer</div>
- 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.
- RSS/Atom. You should use RSS 2.0 and/or Atom 1.0 for syndicating data such as blogs
- MS Outlook CSV export
- 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.
- 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
<link rel="alternate" type="application/rss+xml" title="RSS" href="link_to_RSS_File" />
<link rel="meta" type="application/rdf+xml" title="FOAF" href="foaf.xml" />
- You should also provide links in the visible HTML to these files.
- 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.
- 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.
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.