All we have to do now is convince him to rap about RDFa!

...title everything including links and images
don't use italics, use emphasis
don't use bold, please use strong
if you use bold that's old and wrong
when you use CSS, you page will load quicker
client satisfied like they eating on a snicker
they stuck on your page like you made it with a sticker
and then they convert now that's the real kicker
make you a lil richer, your site a lil slicker
design and code right man I hope you get the picture...

Source: Design Coding

Spotter: ROFLCon Sleeper Hits Session.

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.

This could get messy as hashtags participants are already placing the "#" in front of too many words that they deem relevant. Perhaps hashtaggers should only place their metadata at the end of the twittering so as not to interfere with the human-readable part of the message.

More ideas for metadata in short messages:
- hashtags could encourage participants to use a set of common prefixes and then connect their community into the greater semweb.
- comma-delimited tags after the "#"
- generate threads of related twitterings using a "re:" and a keyword

Spotter: Everything Is Miscellaneous

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.

I cannot wave this agile software development flag with much enthusiasm. All I see in agile development is a clutter of terminology describing well-worn improvements to the waterfall approach. These would include: decreasing the amount of functionality in the end product, increasing communications among the players, and reducing drag through better tools and processes. The only thing missing from agile is an admission that it is simply a faster waterfall.

Why affix a new name to something as elementary as "faster"? Is it meant to clear out mental cruft? Is it the fact that the software development community suffers from a constant case of newism?

Whatever the reason, I think that it is "inter-perception" that is doing most of the changing in our community. During the grand ball of trend-calling and over-investing, the real pace of invention may have only advanced incrementally, perhaps only getting us half-way to the next true leap: a microprocessor, a home computer, a desktop, a web... a cloud.

The true leaps are what this game is all about. In the charged atmosphere of a perceived revolution, people take more risks, do more work, and, importantly, enthusiastically drink each other's yummy, grape-flavored drinks. How else can you get all of this cooperative and creative effort that literally builds out the stage to support a really heavy technological shift?

So while I may make fun of the the artificial colors and flavors of things like "social", "agile", "2.0", "push", they are essential to the real game at play. And tasty, too.

We think that the best way for you to manage your network is to stop thinking about all of the little pieces and to start focusing on the big picture: you and the people who matter to you. We think relationships mean more than email addresses or which service you're signed on to at the moment. So we've created an experimental demo based upon open technologies OpenID, the Microformats hCard and XFN, and FOAF that allow you to see your entire network of relationships in one place - across services, across platforms, across the entire Web.

Source: We Are Opening the Social Graph

I wired OpenID into my Memecat experiment but delayed the development of "social networking" with the hope that the next iteration of what BlogLog does would emerge. I would have done "friends" myself, but I don't have too many members. There must be a lot of sites out there in this position.

Check out the video demo.

The controller and view aspects of ruby / ROR and the wide range of modelling options available in Java are going to make a powerful combination!

Spotter (and also the one who first verbalized what many JRuby watchers were thinking): Ola Bini.

The oft-cited DBpedia.org project and Henry Story's Roller Blog Demo both make use of the D2RQ API and the server. I'd recommend that if you want to find out more, start with Henry's SPARQLing Roller document.

To quickly summarize, though: the D2R library enables Jena, Joseki, and Sesame to access MySQL data as if 't were RDF. Much as it is done in ORM, a map file is used to connect the relational schemas and the corresponding ontologies. Appropriately, the map file itself is an RDF document:

D2RQ V0.5 Specification
RDF Schema for D2RQ
N3 Example of a D2RQ Map.

Delving further, I found an offshoot with a project name that was inevitable (in retrospect) - R2D2, a PHP implementation that uses a D2RQ map to access MySQL through RAP.

Are there any posts out there describing the performance of the D2R Server?

The UI on the system is much more "application-like" - functionality that I used to navigate to are now appearing in dropdowns and many options are saved via XHR. Unfortunately there is nothing new in terms of providing more built-in metadata, but I expect this to change as RDFa and microformats evolve and proliferate.

The new widgets manager looks very interesting - I can't find docs on it yet but it looks like a better way to organize the sorts of public-facing content and functionality that usually appear in the right nav. So MT is now DRYer.

Congrats to the folks at SixApart!