The Semantic Web or The Generic at War with the Specific

It's easy to imagine an application that takes advantage of Linked Data by extracting just what it needs and dumping it into a local relational database. But that's clearly cheating. It's equally easy to imagine a completely generic low-level Linked Data browser, but there's something less than completely satisfying about that, too. The basic problem is that a rich user experience requires specifics, while taking full advantage of the "anyone can say anything about anything" nature of the semantic web means that applications must be able to handle almost totally generic data[1]. At least that was the theme of my presentation to the Dallas chapter of the IxDA earlier tonight...



I'm especially proud of the way I failed to force people to sit through a detailed explanation of graph structures, subject-predicate-object triples, the use of URIs as identifiers, or any of the other traditional cruft that obscures the capabilities of semantic web technology under a morass of unnecessary detail. (Imagine introducing relational databases by first forcing people to understand index paging mechanisms, or learning to cook via an explanation of organic chemistry). The audience seemed to appreciate it.

[1] I struggled with this earlier over in /2009/03/linked-data-end-user-applications.html

[2] The translation from Keynote to Powerpoint to Google docs was not without problems. And you will definitely need to click through and get a larger version to read some of the screens.

Facebook, Intrigue, Betrayal, Murder

A working understanding of authentication and authorization protocols is key to making use of modern web APIs. But protocols like the three-party delegated authc/authz[1] typical of modern web services can be difficult to follow. Role-playing protocol participants[2] is a fun way to make a very abstract process concrete, so I decided to write, produce and direct some geek theater at my recent Facebook Developer Garage Dallas presentation. When you get to the script pages, imagine Alice played by about the least feminine guy you've ever seen and you'll have the right atmosphere (you might need to click through and view the presentation full-sized to read the text on some pages)



I finished up with a quick review of some very traditional distributed programming topics. The questions "just how many test cases would you need to cover the possible states your program can be in?" and "what makes you think you can test these modules independently?" get people thinking along the right lines.

Oh. In the end Alice runs off with Bob and all of Dave's money, leaving him on the hook with the Mafia for four guns and several bribes. Such is life in the high-stakes world of distributed programming.


[1] Authc = authentication, or identifying a user, and authz = authorization, or determining what services a user is allowed to make use of once they're identified. Authentication says who you are, authorization says what you can do. In the presentation I talk specifically about delegated authc/authz, and ignore the more traditional single-process examples. People seem surprised to learn that OAuth, which is an authorization protocol, doesn't necessarily tell your application the userid of the user (although many implementations include the info along with the authorization tokens that are the primary purpose of the protocol) It doesn't help that the OAuth spec confuses the two.

[2] So, admittedly, the examples aren't usually acted out in front of an audience, but the role-playing does have a long and honored history. The script actually simplifies the real protocol considerably, but it should give the correct flavor: http://www.networkworld.com/news/2005/020705widernetaliceandbob.html