In the wild snapshot#1: Lessons from my XFN coding experiment

In an offline conversation with Chris Messina, we discussed the idea of creating blog-length interviews with various in the wild apps describing their processes and the technologies that they use with regards to data portability. The goal is to profile real use cases, solutions, and lessons learned when it comes to the current state of affairs for data portability technology. I am using the term “data portability technology” loosely here and is in no way affiliated with the ongoings of DataPortability.org.

So I am giving it a go and see what comes of it because we both think this kind of information can be useful to others looking to understand the lay of the data portability land. As such, I will title all such future posts starting with “In the wild snapshot…” as well as assign the category (WordPress terminology) of “in the wild snapshot”. If any of you are interested in doing such an interview, leave a comment on here and I will get in touch with you. Note that these posts are generally meant for web developers but everyone is welcomed to read it of course.

First up, I interviewed myself on my recent XFN coding experiment, neat how that works.

Application Overview
Given the abundance of XFN producers available, I wanted to create a XFN consuming application instead. If you need an introduction to rel-me and XFN, check out my earlier post here. The basic idea is to extract XFN information from a URL and present it in a human readable form, in my case, grouping rel-me entries into “My Online Identities” and rel-contact entries into “My contacts”, that’s it, pretty simple thing to do.

Technology
Technology considered: XFN, FOAF, Javascript, JSON, DOM, server side platform (like Ruby on Rails, etc), Google Social Graph API, Google Social Graph Test Parser, lab.backnetwork ufXtract microformats parser

Technology used: XFN, Javascript, JSON, DOM, CSS, lab.backnetwork ufXtract microformats parser

To begin with, I considered client side (Javascript, JSON, DOM, CSS) vs. server side (Ruby on Rails) platforms and went with client side technologies primarily because I had a good example client side app to start with, courtesy of Kevin Marks (OpenSocial advocate and microformats founder). You will notice the very similar layout and fonts, I like to reuse code.

The next question is selecting an appropriate XFN parser. I can either try to find some Javascript library or write my own or use a 3rd party service. To make things easier, I decided to go with a 3rd party service. I have 2 choices to pick from 3rd parties, lab.backnetwork microformats parser and Google Social Graph API. I decided to use lab.backnetwork parser primarily because it parse pages in real-time whereas Google Social Graph API only parse pages crawled by Googlebot which can result in data staleness. With lab.backnetwork parser, I used the JSON callback to process the JSON data structure passed back by the parser. Once I have the JSON data, I then sliced and diced it to dynamically generate additional HTML using Javascript, DOM, and CSS.

If you want more details on how to use Javascript to call the lab.backnetwork parser, check out this excellent post Javascript badges powered by JSONP and microformats. Extracted from the post, here’s the script tag code calling lab.backnetwork parser

var script = document.createElement('script');
script.type = "text/javascript";
Badge.obj = badge;
script.src = "http://lab.backnetwork.com/ufXtract/?url=" + escape(link.href) + "&format=xfn&output=json&callback=Badge.build";
head[0].appendChild(script);

Lessons learned
As a newcomer to XFN, this is a good way, at least for me, to learn about XFN. lab.backnetwork parser works pretty well for extracting XFN information especially since it provides real-time parsing. However, unlike Google Social Graph API, it doesn’t currently parse FOAF. FOAF is a competing standard to XFN but can be used in conjunction with XFN. Here’s a post about XFN and FOAF. From the few profile pages I have seen, it is possible for people to use both XFN and FOAF. For example, on such a profile page, XFN is used to markup the multiple rel-me identities and FOAF (in a separate file) is used to list all his friends. However in other profile pages, FOAF is skipped altogether. It doesn’t appear that there is a best practice published on how to mix and match the various technology.

Another issue I ran into is parsing and displaying human readable names for XFN URLs. As it stands, XFN allows one to define relationship between oneself and friends all centered around the URLs. However, URLs are not designed for optimal human readability, some URLs are long and unruly and others employ the use of proprietary internal naming scheme, e.g. (actual site names changed to protect the innocent),

The reason why I think it is important to couple human readable names with URLs is that a consuming app usually wants to do something meaningful with the XFN information and URLs alone does not provide complete information resulting in the end user having to do more work filling in the human readable information after the initial extraction.

In my discussion with Kevin Marks, he indicated that hCard can and should be used along with XFN to provide complete information. For example, it is possible to have the following XFN and hCard markup

<li class=”vcard”><a class=”fn url” href=”http://joeblowblog.com&#8221; rel=”met colleague friend” >Joe Blow</a></li>
<li class=”vcard”><a class=”fn url” href=”http://janedoeblog.com&#8221; rel=”met colleague friend”>Jane Doe</a></li>

I think this is a best practice that is not obvious. Developers are generally familiar with each type of microformats standard but I haven’t seen much documentation in way of how to mix and match the various standards for optimal use. Each standard tends to be describe in silo without consideration for other standards, so hopefully revelations like this can help developers better understand how to use the standards.

Even though the XFN/hCard combination is more complete than just XFN, I still see some issues with it. For example, a parser has to understand the implied relationship between the hCard information and the XFN information and returns that information as a related entity meaning that hCard provides the human readable names for the XFN URL, a relationship that is currently not part of the hCard or XFN spec, so it has to be inferred by the developer. Also, I would like this type of cross standards best practices to also extend to XFN/FOAF, etc. Note that at this time, Google Social Graph APIs do not parse hCard information so even if someone put that information on their profile page, it won’t be useful if the consuming app uses Google Social Graph API. Kevin indicates that he might rectify this in the future and extends the API to also parse hCard.

One last thought, even though I started my application using Javascript, if I want to do more useful stuff, I would switch over to server side code. In particular, if I need to store persistent user information, I need a database and that’s best facilitated by server side platform.

Feedback and suggestions are welcomed.

Update
Chris pointed me to a blog post he did on XFN, Portable contact lists and the case against XFN, it’s worth a read IMO.

About these ads

8 Responses to “In the wild snapshot#1: Lessons from my XFN coding experiment”


  1. 1 Chris Messina May 18, 2008 at 11:54 pm

    A couple thoughts.

    First, nice job writing up your approach here. I would have liked to know what your use case for this application was beyond just an “XFN consuming application”. If you had started out by trying to solve a specific problem for someone, and then used XFN to solve that problem, I think that would be infinitely more valuable — something to think about for future interviews!

    Second, there is a separation between XFN and hcard for a reason: hcard is for representing information about a person, company or place. It doesn’t bake in relationship information on purpose (FOAF’s fundamental flaw). XFN, OTOH, is only about representing the relationship between two URLs (uni-directional, unless reciprocated). It is a way for a URL owner to express her relationships to other URLs that might represent her friends on the web. While using hcard to specify a human-friendly “label” for a link is useful, it’s ostensibly out of scope for representing the relationship.

    That said, by combining hcard and XFN as two complementary building block formats, you can now consistently format your links so that they express both a relationship and indicate the name of the person that *may* be represented on the other end (note that I could easily mislabel a link to someone else’s URL, so being careful about relying on such embedded hcards is something to consider).

    Now, I might also point you to my Microformatted Blogroll Plugin for WordPress, which combines XFN and hcard:

    http://factorycity.net/projects/wp-microformatted-blogroll/

    I built this plugin to address this shortcoming in WordPress.

    I propose to you that you think about Google’s Friend Connect and Facebook’s forthcoming FB Connect APIs and think about how, on your *own* blog, you could store your relationships and yet still make use of those APIs. The point of XFN+hcard here is to move outside the Google/Facebook data silos and on to your own blog. XFN+hcard is available today — and can be used as the foundation for what these two Connect APIs will offer.

    Build me something that demonstrates how this could work and *then* I’ll be impressed! ;)

  2. 2 Bob Ngu May 19, 2008 at 7:24 am

    First off, thanks for your thoughtful response.

    Actually I have a specific use case for my application, unfortunately I am not at liberty to share the details at this time. It is more or less what I said, a XFN consuming app to extract XFN information from a URL and present it in a human readable form, in my case, grouping rel-me entries into “My Online Identities” and rel-contact entries into “My contacts”. I intend for my app to consume and make available publicly available data (at least initially), so the data is totally open in and out of my app.

    While I understand your reasoning for keeping XFN and hCard separate, I still think there is a good use for specifying how they can be used together as a best practice. It really makes little sense if I am the only use using that convention and no one else does. In particular, this makes sense for an app like mine that consumes and exports publicly available data and not be forced to use an authentication layer simply to get a name. It’s the similar to what you argued for Contact List Portability only needing rel-contact and rel-me while the rest of XFN is gravy, except that this adds a name to it. I feel that this is a useful and basic piece of information that can be used by many XFN consuming apps. I understand that one can easily mislabel a name or URL but confirming identity is a different discussion :)

    Unfortunately I don’t have a local WordPress installation, so I can’t check out your Microformatted Blogroll Plugin, it sounds interesting though. Overall, I think that DiSo is doing a lot of interesting work using data portability technology but unfortunately it is limited to WordPress plugins, so hopefully you will consider expanding beyond WordPress plugins in the future.

    While it is simple enough for me to express my identities and contacts using XFN/hCard on my blog, it is not going to replace the masses using Facebook services and hence FB profile and friends features. Not to mention that Facebook will shut me down if they discover that my app taps into their users social network data just like they disabled Scoble’s account for friends scraping and blocked access to Google Friend Connect. As we all know, making the data portable is not a technical problem, it’s more about protecting your competitive advantage. Things are somewhat different for Google since their main business isn’t predicated on hoarding users data, it is in their advantage to make data portable as long as it goes through their platform which is what Friend Connect does. In fact, at Open Social Summit last week, I and many others suggested making Friend Connect RESTful spitting out XFN/hCard/FOAF data and they readily agreed that it is a good thing to have, so we shall see.

  3. 3 Sasha Cohen May 21, 2008 at 3:56 am

    Hi there…Man i love reading your blog, interesting posts ! it was a great Tuesday . Sasha Cohen

  4. 4 Greg Clinton May 21, 2008 at 4:07 am

    Thank you for this very interesting post.

    I would be very interested in such an interview. I have recently begun building a site on Google App Engine and on Amazon ec2. I don’t want to store any user
    data (especially passwords) on my servers. Instead, I want to obtain user data using the new Open API’s, XFN etc. I’m currently using the Facebook API but I don’t want to limit myself to Facebook users.

    The site works like this: you talk one-on-one with another person. The call is recorded. If both of you agree, the call is posted.

    Calls are close up, personal, genuine, relaxed, zen. Listening to them is like standing in line at the theater and eavesdropping on the couple behind you.

    You end up with a small following, which in Internet terms might be a thousand people. The Long Tail.

    You can push your calls to your facebook feed, twitter, friendfeed, etc. Go viral!

    The idea is to lower the bar to podcasting…and to make you a small celebrity.

    The site is still pretty rough and I’m just starting to acquaint myself with OpenSocial et.al.

  5. 5 Bob Ngu May 21, 2008 at 6:26 am

    Greg, sounds great, you will be my first non-me interview :)

    To start, maybe you can write up your thoughts using the following outline (same as my post):
    Application overview
    Technology
    Technology considered
    Technology used
    Lessons learned

    If you have any suggestions or improvements on format, I would love to hear them. Send your writeup to my email – I will send you an email first. We can tweak the interview via email and / or IM.

  6. 6 Julian Bond May 23, 2008 at 6:19 am

    Chris: you wrote “Second, there is a separation between XFN and hcard for a reason: hcard is for representing information about a person, company or place. It doesn’t bake in relationship information on purpose (FOAF’s fundamental flaw).”

    Could you post some time an explanation of why you see FOAF as being fundamentally flawed? To me parts of it seem directly analageous to these microformats. foaf:Person is a structural place holder that matches hCard and frequently contains the same vcard information. foaf:knows matches the XFN relationships. While XFN rel=”me” is matched by lists of links within foaf:Person. From outside the two seem to be a pretty good match. To the point where it’s feasible to think of tools that could convert back and forth between the two approaches with very little loss of information or introduced noise. So how does that make FOAF fundamentally flawed?

    If we’re going to contrast and compare FOAF and microformats, perhaps a better basis on which to do that would be to look at the relative difficulty in creating, parsing and consuming the data in the two formats.


  1. 1 I like to FOAF you « Ungeek DaPo Trackback on May 21, 2008 at 4:08 am
  2. 2 Blank (Media) Slate » Archive » DataPortability: In-Motion Podcast - Episode 11 Trackback on June 13, 2008 at 5:53 pm

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





Follow

Get every new post delivered to your Inbox.

Join 47,655 other followers

%d bloggers like this: