Without much conscious thought, most of us have built identities across the web. We have filled in profiles, uploaded photos, videos, reviews and bookmarks. The Ident Engine uses semantic web API’s to bring together these web footprints.

Ident Engine site /> A List Apart – Ident Engine

The Ident Engine is part of a year long personal project into combining social graph data with other open data sources. With over 1.3 billion hCard profiles on the web and RDF growing in strength, the semantic web has reached a tipping point. I built the Ident Engine to show that constructing user experiences by blending semantic web APIs and other open data sources is not only practical, but offers exciting opportunities.

Related projects

Identify – Firefox add-on /> Identify is a Firefox add-on that combines identities across various social network/media sites. Its uses the Ident Engine library.

Social Graph Explorer /> This is the original server-side application on which the Ident Engine library is based.

Microformat API – OAuth /> This experimental demo showes how OAuth can be used to add privacy to open data sources like microformats and feeds.

Presentations

I have given a number of talks about blending social graph data and other open data sources over the last year. The slide deck from Twiist.be in Leuven (below) contains the most update version of my /> talks.

• Experiments in Data Portability 2 /> Twiist.be – Leuven, Belgium /> 15 May 2009 />
• How to connect social media with open standards /> Social Web Foocamp – Sebastopol, CA /> 18 April 2009 />
• How I built the demo’s /> Barcamp London 6 – London, UK /> 28 March 2009 />
• Microformats: A Quiet Revolution /> SXSW – Austin, TX /> 14 March 2009 />
• Experiments in Data Portability /> Skillswap – Brighton, UK – 25 November 2008

Articles

• Identify: Google People With Two Keystrokes /> Read Write Web article on the Identify Firefox addon /> by Marshall Kirkpatrick

Resources

If you are interested in this area I have listed a numberof different resources you may find useful.

• Google Social Graph API
• Social Graph Node Mapper
• YQL
• URI-Template
• WebFinger
• XRD
• Portable Contacts API
• Hybrid Protocol (OpenID + OAuth) Demo

Icons will help users quickly scan lists of social media sites. However, pulling favicons directly from sites is a lot more challenging than you may first think. Google have provided a simple API to do this.

http://www.google.com/s2/favicons?domain=flickr.com

The only draw back I have found with using Google’s favicons API is that all the icons are on white backgrounds. I have created a set of PNG favicons with transparent backgrounds for the 70 social media sites which are part of the Ident Engine download or you could try Paul Lloyd’s beautifully designed set of Social Media Icons.

When creating an “elsewhere on the web” listing try and make them as easy to read as possible. Full URLs or even domain names are hard to scan read, always try and use the site name, i.e. http://www.flickr.com/people/glennjonesnet/ is displayed just as Flickr (glennjonesnet). It is important to display the username to reassure the user that you have found the right account.

The Ident Engine will accept 4 different ways of inputting a web account address

• http://twitter.com/glennjones
• twitter.com glennjones
• twitter glennjones
• glennjones@twitter.com

There is currently a lot of discussion about finding the easiest way for a user to describe their ownership of a web account. Most systems currently provide a URL that represents an individual, but these can be long and hard to remember i.e.:

• http://twitter.com/glennjones
• http://upcoming.yahoo.com/user/62673/
• http://www.mybloglog.com/buzz/members/glennjones/hcard
• http://www.linkedin.com/in/glennjones

The OpenID community has found that asking users to type in their full URL causes some user experience issues and often creates a barrier to the user.

Any type of web identity discovery system needs two visible pieces of information to work. The DNS name of the service to query and an identifier for the user. The hidden third element is the context of the query i.e. we are searching for information about a person and not some other type of entity.

To facilitate easy parsing it is useful to have a delimiting character that divides the two pieces of information.

How you then construct the input string to identify an individual is less of a technical problem and more an issue of ease and convention. The one I personally find easiest to use is an abbreviated version of the URL: /> /> http://twitter.com/glennjones becomes twitter.com glennjones

The pattern is the web sites DNS then a space and then the user identifier i.e. username. With a closed system like Ident Engine you can go one step further and accept just the name for the website.

The other pattern gaining traction at the moment is the Webfinger email structure. This aims to make the most use of the fairly well ingrained understanding of how you construct an email address and translate that convention into creating an address for any web account:

http://twitter.com/glennjones becomes glennjones@twitter.com

This works best when there is a corresponding email account but can feel a little strange where one does not exist like the Twitter example above.

I have yet to find any publically available user research which backs up either approach.