These subtle changes should put me in much better form for the upcoming YAPC 2010!

The Internet-connected population watches roughly a trillion hours of TV a year. That's about five times the size of the annual U.S. consumption. One per cent of that is 10,000 Wikipedia projects per year worth of participation.

I think that's going to be a big deal. Don't you?

Source: Gin, Television, and Social Surplus

While this hopeful logic echoes the "1% of a billion people" fallacy, the immense amount of work directed at projects such as wikipedia attests to huge reserves of untapped intellectual energy.

We're going to need it.

I feel as if a line has been crossed and I am not even religious. Isn't it sheer gumption to name process monitoring software after Him? Whatever the answer is, I look forward to giving it a trial run.

The documentation is hilarious and is sure to bring this project a lot of attention.

Need to watch a script that doesn't have built in daemonization? No problem! God will daemonize and keep track of your process for you.

Source: god.rubyforge.org

Spotter: Simon Willison.

Although this video may have been made in jest, Jerry Yang could learn a lot from this Israeli entrepreneur. It all boils down to maximizing value. Yahoo has failed to communicate that Microsoft's bid is too low, and this makes them look (and feel) weaker.

So do the cuddly emails to employees.

When Steve Ballmer gets into the ring, it is time to fight - especially if you're going to be working for him in a few months.

Here is an example of how to assert two different meanings for a tag:

<moat:Tag rdf:about="http://tags.moat-project.org/tag/paris">
<moat:name><![CDATA[paris]]></moat:name>
  <moat:hasMeaning>
    <moat:Meaning>
      <moat:meaningURI rdf:resource="http://sws.geonames.org/2988507/"/>
      <foaf:maker rdf:resource="http://example.org/user/foaf/1"/>
    </moat:Meaning>
  </moat:has_meaning>
  <moat:hasMeaning>
    <moat:Meaning>
      <moat:meaningURI rdf:resource="http://sws.geonames.org/4402452/"/>
      <foaf:maker rdf:resource="http://example.org/user/bob/foaf"/>
      <foaf:maker rdf:resource="http://somwhere.net/myblog/foaf.rdf#me"/>
    </moat:Meaning>
  </moat:has_meaning>
</moat:Tag>

Source: MOAT ontology

I have always believed that site operators and end-users should interact with the semantic web in a seamless, familiar manner. What MOAT must be answered with is UI that encourages meaningful tagging. In its current state, though, tagging appears to have hit an innovation plateau because it is difficult for users to add more than shallow, impressionistic meaning to a subject. There is enough in tagging to generate interesting visualizations such as tag clouds and (of course) to improve the findability of site resources. But there needs to be a way to add one more dimension to the subject-tag relationship.

Two recent experiments that I have developed in meaningful tagging are to be found in the Memecat and Listgasm projects.

In order to add the third "predicate" dimension to the tagging of a subject, I provide cues as to what the tagging context is when a user enters tags. To allow for creativity, we chose to allow the users to freely enter whatever tag they wished, but still provide "object" suggestions. On the storage side, each user assertion is stored as a triple: the item, the predicate, and the tag entered by a user.

When entering a tag to "keep" a list item in Listgasm, the user is presented with a dropdown of suggested tags. The same approach is used to "lose" a list item, which represents a different predicate for the same subject. In Memecat, a video meme is similarly tagged for pattern, culture, and what it contains. A major benefit to the tagging and storage approach used in these projects is to allow a user to not only tag different aspects of an item, but to also enter more than one tag in doing so.

What I haven't yet done is connect the data that we've collected in these projects to the semantic web. MOAT could be the best way to quickly do this.

Ning obviously will start to parse incoming gadgets for malicious code as will every social software service using OpenSocial.

Unfortunately, the gadgets XML format does not use namespaces identified by URIs, much less a widely recognized way to refer to the document author and other essential metadata. As a gadget is essentially a working html document, it should follow all of the conventions of one. These oversights essentially leave OpenSocial gadgets "disconnected" from the emerging data web, increasing the difficulty of forming of a reliable and open web of trust around them.

In spite of all the positive feelings I have about the intentions of OpenSocial, I think that I'll take aim at its shortcomings as well.

My goal is to start building a way to be able to embed an app into some of these early-adopter communities. Looking over the Javascript API's Developer's Guide it appears as if I am required to use the Google Gadget API to be able to embed.

I hope that this is not the only way to do it, because the gadgets are not very pretty. This gadgets XML format that is about to be very, very widely used to embed web apps is seriously begging for an organized standardization effort. It looks like something that I half-put together in 1999. For starters, no XSD or XML namespaces are to be found. The xml description and the examples listed throughout the gadgets documentation do not even encourage developers to indicate what sort of XML a passerby is looking at, much less what version of the gadget format it represents. Should a developer (much less an automated process) come across a gadget in the wild, he would have work a while to figure out what the document is and what its elements are used for.

I can momentarily find it in my heart to sympathize with a developer who would choose to skip the XSD creation for something used in a very isolated capacity. But it is absolutely a requirement for a format that is going to be used... just about everywhere! The lack of clarity in the gadget XML format is not worth the bits conserved or the apparent simplicity for less-experienced developers.

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
 <ModulePrefs title="List Friends Example">
   <Require feature="opensocial-0.5"/>
 </ModulePrefs>
 <Content type="html">

 <![CDATA[

 <script type="text/javascript">

 /*Request for friend information when the page loads.*/

  function getData() {

    document.getElementById('message').innerHTML = 'Requesting friends...';

    var req = opensocial.newDataRequest();

    req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');

    req.add(req.newFetchPeopleRequest ('VIEWER_FRIENDS'), 'viewerFriends');

    req.send(onLoadFriends);

  };

 /* Parses the response and generates html to list the friends */

  function onLoadFriends(dataResponse) {

    var viewer = dataResponse.get('viewer').getData();

    var html = 'Friends of ' + viewer.getDisplayName(); 

    html += ':<br><ul>';

    var viewerFriends = dataResponse.get('viewerFriends').getData();

    viewerFriends.each(function(person) {

      html += '<li>' + person.getDisplayName() + '</li>';

    });

    html += '</ul>';

    document.getElementById('message').innerHTML = html;

  };

  _IG_RegisterOnloadHandler(getData);

  </script>

  <div id="message"> </div>

  ]]>

  </Content>

</Module>

Source: OpenSocial: List Friends Example

The ModulePrefs, aside from preferences and "Require" dependencies, is used to store metadata for a gadget, including title, author, author_email, and so on (see the XML below). This is beyond silly and gives OpenSocial implementers many reasons to say: we can do better.

One big picture question that is begging to be asked is whether it is realistic or not to expect MySpace, SixApart, and the dozens of other competing communities to fully implement all of the functionality that appears in this API? This is quite a lot of cooperation to expect from everyone involved and I suspect that the various gadget container implementations will begin to remind us of the brower wars of the late 1990s.

Except that this time there isn't an objective party like the W3C in the center of the field. Not yet, anyhow.

Back to creating my OpenSocial UI, the simplest way to display something using one of these gadgets is to supply a url which the javacript of the container app will use to load the external content. This is how the DogstarRadio embed works:

<?xml version="1.0" encoding="UTF-8" ?> 
<Module>
  <ModulePrefs 
    title="Now Playing on SIRIUS"
    height="60"
    width="250"
    description="Displays what is currently playing on Sirius Satellite Radio using data from DogstarRadio.com"
    author="DogstarRadio.com"
    author_email="schedule@dogstarradio.com"
    title_url="http://www.DogstarRadio.com"
    screenshot="http://www.DogstarRadio.com/images/now_playing_gadget_screenshot.png"
    thumbnail="http://www.DogstarRadio.com/images/now_playing_gadget_thumbnail.png"
    >
    <Require feature="opensocial-0.5"/>
  </ModulePrefs>
  <Content type="url" href="http://www.dogstarradio.com/sirius_display.php?size=gadget">
  </Content>
</Module>

Source: Ning's OpenSocial Gadgets Directory

Appropriately, there is a size=iphone for this URL. Seeing this, I wonder what the HTTP_USER_AGENT for the XHR client would look like to my embeddable app. I suppose that I could just create a separate controller for all embeddable functionality and then send an initial call to my hosted app containing metadata about the OpenSocial container and embedding member.

To accomplish this I can use the Remote Content APIs, a means to supply the embedding app and its OpenSocial hooks with data returned from the external app. This is one of the most interesting parts of the system. Of course it might also be the most dangerous.

While these methods will encourage more javascript code and UI to be placed into the horrid Module XML, I expect them to be a boon to developers stumped by browser cross-domain security restictions.