Canonical Node Representation

Internally, node names in the Social Graph index are canonicalized to an internal format that's much cleaner to work with. Knowing the details of the canonicalization process isn't necessary to use the Social Graph API, but it might help explain what's going on.

Background

Consider all the ways you can link to a person on the web, all with slightly different URLs:

• http://brad.social-network.example.com
• http://brad.social-network.example.com/
• http://BRAD.SOCIAL-NETWORK.EXAMPLE.COM/
• http://social-network.example.com/viewBlog?user=brad
• http://social-network.example.com/viewProfile?user=brad
• http://social-network.example.com:80/viewBlog?user=brad
• http://social-network.example.com/users/brad/data/foaf

Is your friend viewBlog?user=brad or is it viewProfile?user=brad? Are these even the same person?

Clearly, working with such raw data alone would be painful.

Back to top

Canonicalizing HTTP URLs

First, standard HTTP canonicalization is done, including lower-casing the scheme and host, removing default ports, and making sure the path is at least /.

However, just lower-casing and removing default port numbers doesn't get us all the way there. Now we're still left with:

• http://brad.social-network.example.com/
• http://social-network.example.com/viewBlog?user=brad
• http://social-network.example.com/viewProfile?user=brad
• http://social-network.example.com/users/bob/data/foaf

Are those all the same person?

Back to top

Canonicalizing known URL patterns

Fortunately, the Open Source sgnodemapper project comes to the rescue, recognizing this as a known URL structure for the hypothetical social networking site social-network.example.com, and maps all of the above to:

sgn://social-network.example.com/?ident=brad

A number of people are now contributing to sgnodemapper, and more help is always appreciated. If you see some URLs that could be canonicalized better, patches are welcome!

Back to top

Requesting sgn:// URLs in responses

If you want to see what's going on under the hood, add the sgn=1 parameter in your /lookup request, and then the internal sgn:// URLs will be returned. This may also be more convenient for your application if it's aware of sgn URLs.

Back to top