Two caveats: First, it’s been five years since Az and I lived in Rome; two since our last visit. Second, we were mostly vegetarian back then, so our dining staples tended to be pasta, contorni, and pizza. Which is not exactly a limiting diet, in Italy.

Around Piazza Navona:

My favorite lunches in town are both near Piazza Navona: first, there’s Lo Zozzone, which makes awesome sandwiches on hot, straight-from-the-oven pizza bianca that’s sliced to order and stuffed with ingredients of your choosing. The breasola, arugula, and parmesan is particularly popular; I’d generally go the tapenade-veggie-cheese route, and sometimes order a small second of nutella-ricotta for dessert. Best to arrive both hungry and patient, the lunchtime queue can be a bit of a jostle.

Even better is Da Tonino’s, which is officially called Trattoria Antonio Bassetti. I’m not at all sure if it has a sign, yet, and while I know they upgraded the decor when I visited a few years back (interior lighting used to be a couple of raw fluorescents) it’s a humble-looking place. The food isn’t fancy by any measure — it’s the simple pastas that shine here — but the taste of it all is stupendous and superlative. The pasta melanzane (eggplant) and pasta broccoli are my two favorites; in a perfect world their pasta fagiole would be spirited away somewhere safe to serve as the specimen against which all others should aspire. Check out the carciofi and brocolli romano (perfectly saute’ed with chili flakes and olive oil) as side dishes.

As for dinner, well, it’s gotta be Baffetto’s, right up the street. Look, there’s a reason this place is in every single guidebook: Baffeto’s is very, very good and very, very Roman pizza, with a two-dimensionally-thin crust that’s crunchily croccante, baked perilously close to the fire, and topped with a type of grated fresh mozarella that I’m convinced is the key to it all. (Order the Insalata Burina as an appetizer to sample the cheese raw; I’m personally torn between that and a starter bruschetta every time I go.) Be prepared for gruff service and a wait outside, with plenty of tourists and crowd-control all’italiana. It may seem gauche, but arriving early in the evening (like, ten minutes before they open) makes for a wayyy more civil experience. Plus, you’re more likely to get a seat downstairs where you can watch the two cooks work the pizza oven, which I always like. Contingency plan: if Baffeto’s won’t work, and you can’t make it to Trastevere, run with Da Francesco, around the corner at Piazza del Fico.

There’s also Da Alfredo & Ada, which is just down the street from Baffeto’s and Da Tonino. Another sign-less joint, I’d always referred to this place as the Three Sisters, since it’s run by three older women who fuss around each other like siblings. (They’re not.) It’s a tiny restaurant with a humble menu — in fact, don’t even kid yourself about a menu at all, the schtick here is that the ladies will serve you whatever they feel like serving you. Last time we went, I watched Ada scold a group for not eating their veggie sides; she promptly pulled them off their table and gave them to ours. Behave yourself — you’ll get some cookies after dinner if you do. (Check the great post and photos at tastingmenu for a second opinion.)

Around the Pantheon:

The best coffee in Rome (IMHO) is Caffe San Eustachio. And given that the queue at the bar sometimes goes three deep, it appears others feel the same. Il Gran Caffe is the paragon of espresso shots, though I swear there’s some cheating going on — the crema on top is so wonderfully fluffy that I suspect they’re doing something when they stir in the sugar for you. (A note on that: when the barista barks “zuccherato?”, he’s asking if you want sugar, and the answer is yes.) If you don’t believe me, check the weird metal guard they’ve put in to block the view of exactly what happens under the espresso machine. I know I’m not the only one who thinks something’s going on (a teensy hint of hot cream, or bicarbonate of soda, maybe?), but whatever it is, it’s good.

Also good at San Eustachio is Il Gran Cappuccino, a hefty-in-the-hand cappuccino that’s massive by Italian standards but seems just about right by me. (For more thoughts on dainty Roman cappucini, see my old post here.)

Caffe Tazza D’Oro is nearby, too, and while the decor is sweet and the place is something of a destination, I can’t say the espresso struck me as being notably better than anywhere else (in Rome, that is).

Gelato is the other staple that’s abundant around the Pantheon. Like the Trevi fountain, I think the Pantheon looks better at night, and always worth a minor course-correction when taking an evening stroll. Ditto for a few of the cremerias in the area — there’s La Cremeria right on the piazza, and the venerable Giolitti nearby. Della Palma wins on quantity (but not quality) and is wonderful to look at; it’s an OK place if you’ve got some kids in tow.

There’s a place called Forno right on the square that does great pizza bianca, with just the right mix of oil and salt. Easy enough to make a lunch of the stuff, IMHO. There’s also a place called Aristocampo on the square that’s known for porchetta sandwiches (pork stuffed with herbs and whatnot, roasted ‘til the skin gets crispy).

Campo Dei Fiori isn’t particularly great for sit-down dining, at least, not if you’re really going to focus on the food. Come night-time, it’s mostly a party nexus for international students, busy drinking exotic Stella Artois and the like. However, there’s a joint called Filetti di Baccala just a bit off of Campo dei Fiori that epitomizes the notion of ‘core competency’. Battered and deep-fried fillets of cod are what’s on offer, here, attentively cooked in massive iron bowls of hot oil. Be sure to order a side of puntarelle if it’s in season; puntarelle is a leaf vegetable related to chicory that I’ve never seen outside of Italy. It’s served cold, curly, and with a oil/salt/vinegar/anchovy dressing that complements the fish perfectly. The little square that this restaurant sits in is quite cute; IIRC there’s a couple tables outside and a little frozen yogurt place next door.

In Trastevere:

Augusto (map) is a trattoria that’s popular with locals for both lunch and dinner, and as the lone restaurant in a tiny square, it winds up being a lovely place for people-watching. If you’ve been walking the cobblestones all morning, and just want to chill a bit with good food and a quarter liter of wine, this is as good a spot as any.

Another nice break is Valzani (map), a pasticceria that’s filled with chocolate eggs come Easter time. I previously wrote a post about this place, back when we lived around the corner. Pop inside and enjoy a meringue with whip cream.

Although I’m a Baffeto’s fan to a fault, there’s some phenomenal pizza in Trastevere. Highest on my list is Pizzeria Ai Marmi right on Viale Trastevere. Like Baffeto’s it’s Roman-style, not Neapolitan, which suits my bias fine. The wood-fired pizza is top-notch, and they do wonderful fresh suppli al telefono and zucchini flowers, which you can’t get at Baffeto’s. If you haven’t had them before, suppli are deep-fried balls of rice (cooked somewhat risotto-style) wrapped around a cheese center. They’re definitely worth a try; the ‘al telefono’ bit refers to how the melted cheese in the center is liable to pull itself into a long, thin string as you try and break off a piece, like a telephpone wire. You can also get zucchini flowers as a deep-fried cheesy appetizer, or as a pizza topping — either way, you win.

If you’re looking for more variety, try the reputable Ivo, Pizzeria San Calisto, or Dar Poeta — they’re all in Trastevere. You’re not going to go wrong with any of these.

Around the Trevi Fountain / Fontana di Trevi

Il Gelato di San Crispino is hands-down the best gelato in Rome. Absolute purists, they’re written up pretty much everywhere, and this decade-old NY Times review explains why. I’m partial to a triptych of whiskey, bourbon vanilla and licorice, though on a hot day the fruit sorbetti are near-impossible to beat. Try the pear.

Prati:

Not quite sure what would bring the average tourist to this area, but I reckon lunch outside Cacio e Pepe is reason enough. Again, what we have here is a restaurant that knows what it does best — namely, pasta with pecorino cheese (cacio) and pepper (pepe). There’s more to the menu, though I frankly never saw much reason to stray from the eponymous entree, save for the variant of cacio, pepe, and pancetta. Yum.

P.S. I’m going to add to this if other restaurants come to mind, but should you be hunting for more expat recommendations, check out the far more comprehensive Beehive’s guide, written by our friends Steve and Linda. (Say hi if you stay there!)

I think I’ll have to chalk this up as one of the weirder 48 hours in my life — this is an unapologetically business-y business trip, and as such, I haven’t seen much apart from hyper-modern office buildings and exceptionally nice restaurants.

My room, though, is directly on the Bosphorous, and this morning I ate my breakfast right on the water, watching a panoply of tankers, ferries, and yachts ply the channel. And when I got back to the hotel this evening, I had a tiny bit of time left to wander around Bebek — I’d been hoping to find a suitable gift for Emmie, but the closest thing I could spot was a onesie that read, “My other car seat is in a Porsche”.

Had to pass on that one. (If only for strictly factual reasons.)

Dinner was pleasant enough. I needed to avoid a repeat of last night, where I dined awkwardly alone in a very fancy fish restaurant, Poseidon. So tonight I wound up eating a köfte sandwich, instead, from a snack-hut-thing about a block off the main strip (and maybe 15 yards east of McDonald’s). As far as I could tell, this place had everything going for it — harsh flourescent lighting, a group of old men smoking and sipping tea, Rubbermaid furniture, and a flow of bus drivers who kept darting in and running back out clutching hot dogs.

Like I said… ‘twas pleasant enough. I even topped off the meal with a wee dram of Turkish coffee. Though I made the same mistake as I invariably do at Don and Lorna’s, namely, I got greedy and took one sip too many, and hence wound up with a mouthful of coffee grounds. Cleanses the palate, at least.

Anyhow. Home tomorrow AM, and now it’s the weekend. Whoo-hoo!

We’re back from Rome, which was as great as ever. Ditto for Emelyn, who hit the Italians with a shock-and-awe charm offensive so big it deserved State Department funding. (I’m sure Emmie would’ve toned down the maximum-wattage cuteness if she’d realized that nearly every Italian man, woman, and child seemed to think she was our darling boy. The multitudes kept stopping in their tracks to say “Ciao Bello!” to her - not quite the same as “Ciao Bella”.)

Anyhow, it was a fine time, and thanks to a few years’ worth of Starwood Points, the whole affair was a mighty luxurious free ride, to boot. We stayed on Via Veneto, in a hotel that was palatial in style and scale. Emelyn, for her part, quickly discovered she had more space to crawl around than she does at home, and promptly went nuts venturing from the bathroom to the bedroom and back again.

The clear highlight of the trip from her perspective was the hotel’s bathroom scale, which she joyously clambered on every two minutes. A bit obsessive, perhaps, but still a better fixation than her very first object of desire, namely, the cable that dangled from the plasma TV screen. She’s her dad’s daughter, for sure - Emelyn started pulling and yanking on that bit of high-priced technology about 30 seconds after we first entered the room - but Azure and I quickly jerry-rigged a Grand Barricade that kept her from the electrics.

We didn’t spend the entire time in the hotel, of course — we pushed across most of the Centro Storico in our five days there. For Azure and I, the trip was prioritized solely along culinary lines, and we hit pretty much every target on our list. I’m proud to report that Emelyn’s first pasta was from Da Tonino’s (the staff there not only recognized us, but gave me the kiss-kiss) and her first bite of pizza was equally proper, coming from Pizzeria Da Baffeto. Nuthin’ but the best for my girl.

Food and caffe aside, it was a surprisingly mellow trip. Azure and I both went to bed at 8pm or so every night, since Em’s crib blocked the door - no in and out privileges for either parent. The Easter holiday also meant that a lot of the city was closed. We spent Easter Sunday lunching and lounging in the Villa Borghese with some friends who run a hostel in Rome, and wound up splurging on room service later that night, as every restaurant outside the hotel was shut down or full up. (Pity the Starwood points didn’t cover that doozy of a bill.)

Sleeping in is never an option, anymore, but in Rome the mornings were still infinitely more civil than the workweek here. The most treasured part of my day was rolling out of bed, grabbing Emelyn, and heading down the block to a Bar for a morning cappuccino. (It was also a chance to learn just how fast Emelyn’s become — she swiped my very first cappuccino in Rome right off the bar, and sent the full cup clattering to the floor. But that also taught me how carrying a baby is like wearing a VIP pass in Italy; the staff were ludicrously gracious about the whole affair.)

What else? We squeezed in multiple visits to the saints — San Eustachio for coffee, San Crispino for gelato. Never went shopping, really, except for a brief look inside La Cicogna near the Spanish Steps, where we saw a Burberry dress for infants being hawked for a mere 275 Euro. (Not Emelyn’s size, I’m afraid.) Managed to visit Lo Zozzone for sandwiches made on top of pizza bianca right out of the oven, and ate deep-fried zucchini flowers at an Hostaria in the Jewish ghetto. Can’t complain.

That’s all I have to tell. Though I should add one note, for the record: Getting there and back was not half the fun. Emelyn had sniffles and a cough for most of the trip, and the plane ride there was hard. Going back was worse - first, poverina vomited in the taxi, then Azure and I aged a few years as we almost missed the plane. Once aboard, Emelyn pretty much screamed at any point when she wasn’t read the ‘Are You My Mother?’ book. She definitely won the Worst Baby On The Plane Award going home; not much else I can say except that she’s one for superlatives. (Plus, she’s got a very good excuse - since Rome, she seems to have picked up a secondary infection that has left her totally miserable, now.) Overall, the travelling bit was a far cry from our last trip stateside, where Emelyn behaved so very nicely that our kind neighbors on the plane actually sent Emmie a pair of booties from New Zealand a few weeks afterwards. But that’s a story unto itself…

I’ve barely recovered. Lent term began promptly on Monday morning, which means I’m now fully back in business (school), and once again filling my cranium with executive-class knowledge.

Take, for example, this gem that cropped up during an Operations Management discussion: “The Price Inelasticity of Fruitcake” — i.e., as the price of fruitcake goes up, the demand for fruitcake doesn’t really drop. Interestingly, this atypical behavior occurs because fruitcakes aren’t bought for personal consumption — rather, they’re used solely as gift-items for unfortunate relatives.

Ergo, since the only way a buyer can measure the worth of a fruitcake is by looking at the price tag, bumping up the MSRP actually manages to increase the perceived value of said fruitcake. This, in turn, boosts demand for fruitcake-gift-object, and all in such a way as to offset any drop in demand due to some consumers being priced out of the fruitcake market, etc. etc.

Anyhow. I trust all this explains why I ain’t been blogging much, lately.

On a side note, I’m desperately seeking investors for an exciting, hush-hush arbitrage-ish opportunity. I can promise fantastic returns — all that’s needed is a small sum of cash, up-front, to cover costs of some flour, sugar, and roughly three tons of candied lemon peel…

Yep, and so it goes with this oft-mothballed blog. Still the same management, alas, but other items are moving around — us, namely — as we’re translocating to England.

It’s a year move, at least, and we’re allowed just four suitcases. All are empty, at the moment, save for a single frying pan that’s nestled in one. (Experience has taught us that most furnishings can be cheaply IKEA’d across Europe; obtaining well-seasoned, hard-anodized kitchenware is another story.)

Our saucepan might be a nice addition, too, but unlikely. I’m considering wearing one, Johnny-Appleseed-style, right onto the plane. (“What ma’am? Oh, it’s my Calphalon Safety Helmet. They say Chairman Kaga wears one made of gold, you know.”) But then, what if the overhead luggage spot fills? It’s hard enough to sleep in Coach Class, as is… could be uncomfortable.

Updated, 2008: And hit the lights they did. For sentimentality’s sake, I’ve reproduced the text of the original article below. This one was fun to write:

Mighty Atom: Really Similar Syndication?

Last time around, we took a look at the increasingly popular graphic, which developers use to signpost links to RSS (Really Simple Syndication) files. Well, RSS has a new competitor now: the upstart Atom Syndication Format.

Atom files can be recognized by their own cute-as-a-button button, . And whether you click or , you still get the same raw-looking XML markup — not quite fit for human consumption. All these cute buttons have a real and practical purpose, though: Site Syndication.

Those corresponding XML files are designed for audiences using the “news aggregators” — sort of like mini Web browsers — much favored by high-volume websurfers. Using a news aggregator, you can browse through the latest updates from a customized set of your favorite websites in just a fraction of the time it takes to do the same thing using Internet Explorer. Also, because syndication files follow a standardized XML-based format, they allow other sites to integrate your latest links and headlines into their pages, automatically.

So, what’s the difference between Atom Syndication and RSS?

It’s kinda like the difference between “newfangled” Philips screwdrivers and “old-fashioned” Slotted screwdrivers. A few fire-eatin’ types may spend their days trolling the rec.arts.woodworking forums, debating the differences of torque capacity thresholds, drill bit cam-out, patent history, and manufacturing-cost issues between these incompatible rivals. But most of us are more or less resigned to keeping both types of screwdrivers in our toolkits — we’ll use whichever one is handy and fits our needs.

Similarly, Atom Syndication and RSS are both tools designed to do the same basic job: advertise and distribute website content by creating machine-readable XML newsfeeds.

Chances are, your choice of syndication format will be influenced largely by your choice of Content Management System. Google’s Blogger, for example, pushes the nascent Atom format and includes a pre-built starter template for Atom feeds and Atom feeds only. (All this, even though Atom is still a work-in-progress, only at version 0.3.) Tripod’s Blog Builder tool, on the other hand, offers an RSS 2.0 generator.

Whether you’re invested in a CMS already or you’re still shopping around, it’s a good idea to have a working understanding of both technologies. We went over all the whys and hows of RSS in “Sharing Your Site With RSS,” so in the pages that follow, we’ll be focusing on Atom, starting with why people bothered to build another site syndication format in the first place.

The best testament to the intelligent design of RSS is its popularity. According to Syndic8.com, the RSS 0.9x and 2.0 formats account for about 65 percent of the 25,000+ feeds they track. Mind you, that’s a market that RSS helped pioneer.

Plus RSS (the 0.9x and 2.0 versions evangelized by Dave Winer) has weathered competition before. The unfortunately named RSS 1.0 (a separate RDF-based format) emerged as a standard for developers seeking a more sophisticated, avowedly non-commercial alternative to the RSS variants controlled by Dave Winer’s Userland Software. It’s been a few years, however, and the market still overwhelmingly favors the Fisher Price-simple RSS of versions 0.9x and 2.x.

Meanwhile, quality newsreaders and aggregators have become increasingly adept at handling almost any “flavor” of syndication. Given that, the best way to improve the usefulness of your site is to focus on creating high-quality content, not change the feed format.

So then, why do we need Atom, again?

Dave Winer’s RSS spec is penned in a succinct, conversational style that’s both easy to read and easy to learn. Yet while brevity and informality work great when it comes to getting the masses to adopt new ideas, the spec had some notable gaps and gray areas. And late efforts to re-write or repair the RSS spec were hampered by a variety of issues, such as RSS’s emphasis on backwards compatibility and its adoption of a Creative Commons license.

Perhaps the best anecdotal example of RSS’s “under-specification” is its failure to address how a developer should deal with markup code (like HTML) when it’s mixed up with content. It’s like bubble gum ice cream #151; are you supposed to chew the gumballs while eating the ice-cream, or spit them out, one by one, into a soggy, mottled napkin? Every kid, it seems, has a slightly different take. So it goes with RSS.

Consider the title of a news story. What if certain words in it just have to be italicized, or the article is called, “An Introduction to the <blockquote> Tag”. In both these cases, you’ll need to introduce ruckus-causin’ <i> or <blockquote> tags inside the <title> element of an RSS feed. Now the RSS spec, as written, doesn’t say this is allowed. But then, it doesn’t explicitly prohibit this, either.

So what’s a well-meaning newsreader app supposed to do when it comes across this markup? If it chose to always display the HTML, brackets and all, the second example would work just fine. But then the first headline would look pretty <i>funny</i>. Vice versa, newsreaders that attempt to act on (or hide) HTML tags would make the first headline look nice, but would transform the second healdine into “An Introduction to the Tag”. Hi, tag!

Those aren’t the only issues developers have come across. How do you put relative URLs in a feed? What are proper uses of the <link> tag? Sure these are oddball cases, certainly they aren’t the biggest deals in the world, but they’re just enough of a problem to make certain programs get goofy — not the kind of foundation you want for archiving or API purposes.

Despite these small but potentially pesky foibles of RSS, nobody wants to switch technologies unless there’s an option with wild new features, or at least a couple of major bugfixes. Atom heavily favors the latter. With its lengthier and rather “lawyerly” documentation, the Atom spec nails down many of the quirks, ambiguities, and surprises that became inadvertently enshrined in the now-forever-frozen RSS. And while Atom may not be burgeoning with never-before-seen features, it does add a few goodies: new tags like <summary> and <content>, and proposed attributes like content rel=”fragment”, make it easier to programmatically distinguish excerpts from entries.

Although Atom’s technical improvements over RSS are more evolutionary than revolutionary, don’t mistake this for timidity: the Atom project harbors a fairly agressive agenda. Right now, the loosely knit group that fostered the Atom Syndication Format is simultaneously working on the “Atom API”, an additional set of programming definitions that allows software agents to communicate about basic weblogging actions such as posting, editing, requesting feeds, etc. If all goes according to the Big Plan, Atom-formatted data will be used for far more than newsfeeds. Soon, Atom-enabled programs could help you edit or archive your website without opening a browser, or allow you to painlessly switch between hosting/CMS providers like TypePad or Radio Userland.

Of course it’s hard to tell how all this syndication stuff will shake out in the long run. Right now, Atom’s inchoate “version 0.3” state isn’t perfect or free from glitches, but its momentum towards that ultimate goal has wooed early adopters. To see more technical cases of why key players such as Google and Movable Type are lining up behind Atom, check out Why We Need Echo (Atom’s former name), or these slides. As for the rest of us, let’s get building.

The Building Blocks of Atom

Atom Syndication was created to accomplish the very same task as RSS, so it’s little surprise that Atom code wound up looking like RSS. Atom is newer, and wisely builds off the design successes of its predecessor. If you know how to build a feed with RSS, it’s easy to get started with Atom.

The old “view source” technique probably remains the best pedagogical tool on the Web, so let’s get started building a minimal Atom feed by looking at one. Here’s a minimal example, lifted straight outta the 0.3 spec:

<?xml version="1.0" encoding="utf-8"?>

<feed version="0.3" xmlns="http://purl.org/atom/ns#">

  <title>dive into mark</title>

  <link rel="alternate" type="text/html" 

   href="http://diveintomark.org/"/>

  <modified>2003-12-13T18:30:02Z</modified>

  <author>

    <name>Mark Pilgrim</name>

  </author>

  <entry>

    <title>Atom 0.3 snapshot</title>

    <link rel="alternate" type="text/html" 

     href="http://diveintomark.org/2003/12/13/atom03"/>

    <id>tag:diveintomark.org,2003:3.2397</id>

    <issued>2003-12-13T08:29:29-04:00</issued>

    <modified>2003-12-13T18:30:02Z</modified>

  </entry>

</feed>

Not so scary, right? It looks a lot like HTML, but since Atom is an application of XML, it’s a tad stricter: Every Atom feed must be well-formed, so when you open a tag, remember to close and nest it properly. XML rigamarole also demands the first two lines, which define the XML version and namespace. Confused? Just cut and paste the opening two lines, — they’re the same for every Atom feed.

Now, before we jump into our tag-by-tag, play-by-play breakdown, there’s one design concept that’s worth pointing out. It’s Atom’s idea of “constructs”, which are elements that share a common structure. Don’t worry, it isn’t as fancy as it sounds. It’s just that certain groups of tags always follow the same core rules, wherever and whenever they’re used.

The Person Construct requires a nested element called <name> to be present when describing persons. (Makes sense, right?) Other “child” elements of the Person Construct, <email> and <url>, are considered optional. So whether you’re talking about the author of a feed as a whole, or the author of an individual entry, these basic rules apply: <name> is a must-have tag, <email> and <url> aren’t.

The Date Construct specifies that any time you mention a date, it has to follow a very specific format. This avoids problems like confusing MM/DD/YYYY with the Euro-style DD/MM/YYYY. The rules, in this case, are to follow the delightful, whimsical guidance of “W3C.NOTE-datetime-19980827”, and write your dates just like so: YYYY-MM-DDThh:mmTZD.

The Content Construct lays down the law on dealing with markup and other weird stuff. In short, it tells you to include only plain-text (no markup) inside Content tags, unless you explicitly define another registered media type.

The Link Construct explains how to format all those URLs and links in your feed. The big news here is the mandated inclusion of a “rel” and “type” attribute for every link. The “rel” attribute describes the type of relationship a link represents, while “type” indicates an advisory media type.

Alrighty then. Now that we all understand the Construct-ion of Atom, let’s take a closer look at the code sample above:

<title> If your feed is a duplicate of a Web page, they should both share the same <title>. Simple, that. The <title> element is a Content Construct, so it’s presumed to be plain-text by default.

<modified> A simple timestamp, indicating when your feed was last modified. it’s a Date Construct, so mind your M’s and Y’s.

<author> This refers to the entity that is responsible for the feed as a whole — be it a single person or corporation. Unsurprisingly, <author> is a “Person” construct, which is why you see the <name> tags nested in there, as child elements of <author>.

OK. The elements we’ve covered so far are roughly akin to the <head> of an HTML file. They’re the basic data that describes your feed as a whole. That information won’t change as your feed is updated. Now onto the <entry>s: the dynamic headlines, links, and content you’ll be syndicating. Every time you update your site and add new stories, new entries get added to the Atom feed.

<entry> Each entry is wrapped with an <entry> tag.

<title> When it’s inside an <entry>, the <title> is a Content Construct that conveys a title for that particular entry. One <title> mandatory for each entry.

<link> At least one <link> element is also required for each entry. A <link> can represent a “permalink” for the entry itself, or it can refer to a site that you are commenting on within the entry. To clarify what kind of relationship a given <link> implies, use the required “rel” (relationship) attribute. For each entry, you must have at least one <link> with a “rel” attribute of “alternate”, as shown here. (The link with rel=”alternate” is your permalink.)

<issued> indicates the time an entry was issued. It’s a Date Construct, of course.

<id> elements convey a permanent, globally unique identifier for the entry (akin to the “guid” in RSS 2.0). The <id> element should never change, even if the entry is edited — it’s purpose is to help newsreaders and other software understand that your entry isn’t suddenly “new” just because you’ve moved some punctuation around. A unique <id> is required for each <entry>.

Got that? Now close them tags out, and … congratulations, you’ve just built a bare-bones Atom feed! You are now ready for the final steps: validating and advertising your feed.

Feed the World

Now it’s time to validate your work against the universal Feed Validator. Of course, the Atom Syndication file you’ve created needs to be updated each and every time you add content to your site. To avoid the dull and error-prone task of updating Atom feed manually, most Web builders rely on automated tools to update their feeds. Content management systems like Blogger, MovableType, and TypePad all feature starter Atom templates and tools. And you can expect to see a slew of new freeware server-side scripts to process and create Atom feeds soon.

After uploading your Atom file to your server, you still need to inform people of its existence. When you create a new feed, running through these few steps will debut your feed in style.

1. Advertise to Web surfers! Put an button or text link on your page, linking to the feed file. Go ahead, right-click, Save as …

2. Advertise to the machines! Some newsreader / aggregator applications will identify your feed’s location if you put the following “autodiscovery” code in the <head> section of your homepage: <link rel="alternate" type="application/atom+xml" title="MySite’s Atom feed" href=”http://www.YourSiteHere.com/xml/index.atom” />

3. Get listed by the major feed directories! Syndic8.com and News Is Free are two of the biggest collections of RSS and Atom feeds. Before announcing yourself to these sites, however, run a final test against the Atom feed validator. While Web browsers will render many poorly coded Web pages, Atom (and RSS) parsers can be less forgiving, and may require a well-formed XML file.

There. That should be plenty enough to get you started. Note that this was just an introduction to Atom, which means we’ve covered only the basic required elements. For early adopters, there are plenty of additional, optional tags you can integrate into your feed to make it more robust. Good places to look for ways to bulk up your feed include AtomEnabled.org, the official Atom Syndication Format specification, Cover Pages, and the Atom Wiki. Good luck, have fun, and stay on target!

Thanks to Brent Simmons, Graham Parks, Jeff Barr, Sam Ruby, and Mark Pilgrim for pointers and clarifications when researching this article.

Elsewhere, though, there’s this: Metadata, Mark II, an overview of some nifty metadata technologies.

Update, 2008: Webmonkey shuttered its doors not too long after this article was published. I’ve pasted the original text of the article below, for sentimentality’s sake — one of the last freelance writing bits I did while living in Rome…..

Metadata, Mark II: FOAF, RDF, GeoURL, and SMBmeta

Remember META tags? Once upon a time, a finely crafted META keyword tag would get you the bourgeois treatment from search engines. You could specify exactly which search words should be associated with your site and, best of all, META tags were invisible to users, allowing webmasters a touch of the ol’ “editorial liberty.”

Yeah. That didn’t last. Almost instantly, META tags were abused and mis-used by pageview-hungry Web developers, who crammed all sorts of irrelevant and naughty keywords in their pages, trying to shunt the flow of Web traffic their way. And now today Google and other search engines essentially ignore META keyword tags.

(Of course, if you’re absolutely adamant that your page be promoted in response to specific search terms, Google, Yahoo, HotBot and the gang are happy to help, but with an improved targeted-placement technique far less attractive to spammers: It’s called Advertising, and it costs cash-money.)

End of story? That’d be sad, indeed, because META keyword tags were a rather sweet idea, at least on paper: short, sensible descriptions of your site, tailored so that machines could quickly read and index it, and subsequently help people find it.

Well, META’s not dead.

In the pages that follow, I’ll be giving you a bird’s eye view of a few independent technologies, each aspiring to get useful metadata back into the Web. Some are homegrown, some corporate, and some academic, but all of them let you enhance your site with useful information and improve the ways your site is associated with other sites. Sound interesting? Good, then here’s the game plan:

1. We’ll start with an explanation of that metadata word (so we can finally quit italicizing it).

2. Next comes a tour of the platitudes and latitudes of GeoURL, a fun, on-your-site-in-just-ten-minutes META tag that pinpoints your webpage’s real-world location with GPS-style accuracy.

3. Then we’ll check out SMBmeta, a newly launched metadata framework designed to give small businesses their fair share of the Web limelight.

4. We’ll finish up with a macro look at some of the “Semantic Web” standards favored by the W3C: Dublin Core and RDF — and we’ll show them off a bit with FOAF (Friend of a Friend), an application which leverages both those high-minded efforts.

OK then, let’s get started!

Metadata Background

A lot of smart people (like Tim Berners-Lee, who merely invented the Web) are still laboring to make the big dream behind the old “META keyword” come true. That concept is Metadata, which, strictly speaking, means “data about data”, but in our context means “stuff describing your Web page as a whole”: who wrote it, what it’s about, related concepts or categories, the date it was written or updated, the language it’s written in, who controls the copyright, physical locations it describes, if there’s a Table of Contents, etc., etc.

The point is, nobody necessarily wants to see all those details cluttering every single Web page. But if that data were invisible, machine-readable, and used to describe both the contents and context of Web pages, that would open a lot of possibilities, allowing Things of Great Niftiness to ensue. The W3C calls this ambitious idea the “Semantic Web”:

“The Semantic Web will bring structure to the meaningful content of Web pages, creating an environment where software agents roaming from page to page can readily carry out sophisticated tasks for users.” Scientific American, May 2001

So having a metadata-rich Web wouldn’t just improve our user experience as we search and surf the Web, but it would also augment the ability for “robots” or software agents to collect and process information on our behalf.

When people talk about the “Semantic” Web adding meaning to the Web, it’s not really for you and me — you and I generally understand whatever we’re reading, and know which links we need to click to get certain tasks done — it’s about adding meaning that machines can process and navigate.

Whoooo! Robots! Software Agents!

Indeed. Which brings us to this rather key caveat: In this tutorial, we’ll be looking at a mishmash of different technologies that are not yet widely adopted, and may well never be. (That includes the aforementioned Robot Agents.) As of press time, not a one of these technologies will deliver the slightest boost to your Google PageRank or your listing on HotBot. And there’s absolutely no guarantee they will in the future.

Still, ‘tis better to lead than follow, and more fun to fiddle with emergent tech than to wait for the “critical masses” to show up and master it before you, right?

Let’s start, then, with a metadata application already adopted by thousands of webloggers, because it’s fun and entertaining but keeps its feet firmly anchored in the real world: GeoURL.

With just two lines of code, GeoURL maps documents in cyberspace to real-world locations. Once you’ve added your site to GeoURL’s database, you can immediately see who else has registered Web pages in (or about) your neighborhood.

Here’s what the code looks like: The first line contains your Latitude and Longitude, and the second line contains your site’s name.

<meta name=”geo.position” content=”41.8833; 12.500” />;

<meta name=”DC.title” content=”Professor Falken’s weblog” />

(here’s a fill-in-the-blanks example:)

<meta name=”geo.position” content=”xx.xxxx; yy.yyyy” />

<meta name=”DC.title” content=”your site’s name here” />

In old hacker lingo, these coordinates are called an “ICBM Address.” (Like, Inter-Continental Ballistic Missile.) The Cold War humor might now be passé, but you may still might want to use discretion here: If you aren’t comfortable publishing your street address to the Web, you can use broader coordinates here, like those corresponding to your postal ZIP, City Hall, etc.

So, where do you get these coordinates, anyways? Your own latitude and longitude can be grabbed from a GPS device, but otherwise, free Web services make it an easy lookup. For sites in the U.S., GeoURL’s Geocoder page is the easiest method; it quickly converts street addresses into regional coordinates. (Nifty, no? A crafty search spider which sniffed out postal addresses in web pages and indexed them by location with this technique won Google’s 2002 Programming Contest.)

For those outside the U.S., handy lookup services include the Getty Thesaurus of Geographic Names, GeoNET, and MultiMap, though you’ll need to jump through a few additional hoops. Additional lookup resources are available here, along with GeoURLs own documentation.

When you’ve figured out your coordinates, edit the Latitude, Longitude, and Your-Site-Name portions of the GeoURL tags, then drop them into the of your document. You’ll now need to request for the GeoURL crawler to visit your site, and in a few minutes, you’re listed &#!51; a twinkling blue pinpoint on their global map of sites!

Now, I chose GeoURL as our first example because it’s not only fun (been poking around your neighbors’ sites already?) and a fast setup, but because it nicely exemplifies how a “controlled vocabulary” makes these locations machine-understandable and easier to search for in a database. In this case, the “controlled vocabulary” is the numerical latitude and longitude coordinates of the ICBM address.

After all, while you might advertise your store’s address like this for newspaper readers:

“we’re two doors down from Starbucks, over by the mall.””

But a machine isn’t going to understand this:

<meta name=”geo.position” content=” we’re two doors down from Starbucks, over by the mall.” />

I know what you’re thinking: Most folks don’t search for, say, local restaurants by keying in latitudes and longitudes. And that’s why controlled vocabs often include a thesaurus that maps equivalent relationships to one another — for instance, a list of City Names and GPS coordinates. Ideally, producers like you and I take care of machine-readable data, while search engines would build the thesauri.

There’s one more educational nugget in the GeoURL example: That “DC.title” name used to identify your site’s name. “DC.title” isn’t an arbitrary term, it’s a smart use of the “Dublin Core” vocabulary, which we’ll cover in detail later.

While Dublin Core simmers on the backburner, let’s take a gander at SMBmeta.

Getting Busy with SMBmeta

SMBmeta knows its clientele: (S)mall and (M)edium-sized (B)usinesses. These entrepreneurial enterprises — like florists and lumberyards, candy stores and dentists — are the powerhouse of the U.S. economy. On their own, however, these local shops can’t afford an in-house Web team, or compete with Fortune-500-style advertising budgets. For many of them, simply being found on the Web is a challenge.

SMBmeta helps them by providing a “virtual Rolodex card” of sorts — a limited set of data fields, which when used like a fill-in-the-blanks template, can describe any business. The data fields cover all the small-biz essentials: name, description, address, parking, store hours, etc. To make sure it’s all easily machine-readable (and easier to search against), SMBmeta information is stored as XML, in which the tag attributes come from a controlled vocabulary but you can freely add your own descriptive content. Check out this code sample (lifted and condensed from SMBmeta’s docs), especially the line we bolded:

<?xml version=”1.0” encoding=”UTF-8”?>
<smbmeta version=”0.9” xmlns=”http://www.smbmeta.org/namespace/v0.9”>
<business domain=”concordeggplant.com”>
<name>Concord Eggplant Restaurant</name>
<description>Innovative vegetarian food for young and old.</description>
<type naics=”722110”>Vegetarian restaurant</type>
<websiteDomain>www.concordeggplant.com</websiteDomain>
<location country=”us” postalCode=”01742”>
<address href=”http://www.concordeggplant.com/directions.html”>300 Baker Avenue</address>
<languageSpoken language=”en-us”>English</languageSpoken>
<hours day=”all” open=”1130” close=”2130” timezone=”local” />
<parking type=”on-street”>Lots of metered on-street parking</parking>
**<publicTransportation type=”train” blocksAway=”3”>Five minute walk from the commuter rail</publicTransportation>
</location>
</business>

The <publicTransportation> element showcases a nice balance between natural-language descriptions and a controlled vocabulary of tag attributes. With transportation types strictly limited to a fixed selection of bus, train, subway, trolley, cable-car, or other, and the blocksAway attribute limited to integer numbers, this data can easily be parsed, indexed, and searched against. (It’s also immune from poetic hyperbole.) The machine-friendly info is supplemented by the element’s contents, “Five minute walk from the commuter rail,” a bit of information tailored for the human reader.

Having seen some code, you might wonder what’s particularly novel, here. After all, SMBmeta’s XML structure is rudimentary, simple enough to be read (and hand-edited) by humans. The rather meager collection of tags, with names like <Location> and <LanguageSpoken> can be understood at face value. Furthermore, you don’t need to register your SMBmeta file with any Web service or registry — just upload it to your domain. For brand-new technology (SMBmeta was launched in 2003) this looks like code five years outta fashion. There’s no complicated RDF syntax, no small-biz ontology, no Dublin Core vocab — almost no fancy footwork at all.

And that’s exactly the point.

SMBmeta’s creator, Dan Bricklin, hasn’t been shy about citing the RSS (Really Simple Syndication) format as an inspiration; he’s hoping a similar grassroots, bottom-up adoption of SMBmeta will lend critical mass to the format. We Webmonkeys may be in the tutorial business, but we’ll readily admit that “View Source” can be the most edifying tutorial of all; SMBmeta knows this, too, and is engineered so that middling HTML hackers can cut, paste, and tweak our way into this technology without any tools other than a text editor and the (mercifully short) spec sheet.

But even though SMBmeta emulates Fisher-Price’s focus on user-friendly design, it’s not entirely painless to implement, and purposely so. Recalling the ignominious fate suffered by the “META keyword” tag at the hands of spammers, SMBmeta developers tossed a tiny hurdle into the setup process: the SMBmeta XML file must live at the very top (root) level of the domain, and you’re allowed just one SMBmeta file per domain. This restriction discourages spammers from flooding or shotgunning the system, since registering a multitude of domain names costs a fair chunk of change. There’s other spam-proofing features built into the foundations of SMBmeta, like pointers to third-party “affirmation” authorities, who certify that your descriptions match your website and real-world offerings, and who blacklist offending entries (and their entire domains, for that matter). If the cat-and-mouse arms race between spammers and searchers intrigues you, this essay outlines the anti-spam groundwork performed by the SMBmeta folks.

Obviously, SMBmeta is a well-thought-out format, and one that addresses a real need in the Small Biz community. It’s new, though, so it’s still too early to know if it will succeed. SMBmeta faces the same chicken-and-egg conundrum as most other metadata efforts: It’s unlikely to gain search-engine support before it’s widely adopted, but unlikely to be widely-adopted before it gains search-engine support.

But c’mon, why not take the leap and build a file for your business? (When it does take off, you’ll be leading the pack.) Instead of a tag-by-tag tutorial to get you started, we’ll point you at SMBmeta.org’s Web-based form, which will spit out skeletal SMBmeta file for you in just a few minutes. Using the spec, you can quickly add any accoutrements and double-check your work. Then, after uploading your file to your own domain, we’d suggest you register your site with Overall.com, a fledgling SMBmeta directory and search engine.

Now, on to Dublin Core, the super-flexible, way-modular, librarian-friendly metadata vocabulary that only sounds like an Irish heavy metal band.

Dublin Core Curriculum

Back in 1995, a motley crew of 100-odd software engineers, librarians, and Web architects held a workshop in Dublin, Ohio, to tackle a familiar problem: the difficulty of finding stuff on the Web. (And this was back when the web contained a cute half-a-million documents, today it’s in the billions.)

The result of the brainstorming session was a core set of 15 metadata elements, designed to describe any resource (like Web pages, images, music) available via the Web or other networks. The collection was dubbed “The Dublin Core.” These are the elements:

1. Title — A name given to the resource.

2. Creator — Who/what is primarily responsible for making the content.

3. Subject — The topic of the content.

4. Description — Gives an account of the resource’s content.

5. Publisher — entity responsible for making the resource available.

6. Date — Typically, the creation or availability date.

7. Language — The language.

8. Contributor — An entity that’s made contributions to the content.

9. Source — A reference to a resource from which the present resource is derived.

10. Format — The physical or digital manifestation of the resource.

11. Type — The nature or genre of the content.

12. Resource identifier — An unambiguous reference to the resource, like a URL, URI, or ISSN#.

13. Relation — A reference to a related resource.

14. Coverage — The extent or scope of the content (e.g., a place or time).

15. Rights management — Information on Intellectual Property Rights, Copyright, etc.

You can see bibliographic influences in this vocabulary, but it’s still simpler than the heavyweight record-keeping languages used by professional catalogers for libraries and museums. With an eye towards flexibility and ease-of-use, Dublin Core allows everything to be optional — you can use as few or as many of the elements as you wish. Additionally, the Dublin Core team avoided wasting time talking about syntax and other implementation details, at least at first. (Encoding Dublin Core information in HTML META tags is now detailed here, though this more modern working draft may now be a better guide.) In short, tags look like this:

<meta name=”dc:element” content=”Value” />

As in:

<meta name=”dc:title” content=”Webmonkey” />

<meta name=”dc:date” content=”2003-06-20” />

Fast-forward to 2003, and Dublin Core hasn’t impacted the life of the average websurfer much. Mainstream search engines don’t give much weight to DC META tags, nor did commercial sites or homepages ever really bother to include Dublin Core markup in their pages. Despite their ignorance of “resource description languages” (or, arguably, because of it) brute-force, free-text search applications like Google reign unthreatened as the kings of Web research. It’s tempting, therefore, to write off the Dublin Core effort.

Of course, it’s also tempting to write off Carrot Top as a comedian. Yet between 1-800-CALL-ATT commercials and Hollywood Squares spots, it’s evident that the foul humorist’s career doth liveth still, finding new life on radio and TV airwaves. And so it is with Dublin Core.

See, Dublin Core elements have a surprising habit of making cameo appearances in other metadata frameworks. In fact, it’s in this other context that you’re most likely to find tell-tale terms like “DC.title” and “DC.subject” today. Dublin Core elements are regularly used as building blocks within richer and more specific metadata frameworks. This way, even if a spider doesn’t understand the entirety of a metadata language, it can still recognize the lowest-common-denominator DC objects, making the Dublin Core a sort of lingua franca among different metadata languages. Big organizations (like university library systems) especially rely on Dublin Core to enable searching across heterogeneous databases.

And you? Remember that code needed to get listed in GeoURL?

<meta name=”geo.position” content=”41.8833; 12.500” />

<meta name=”DC.title” content=”Professor Falken’s weblog” />

That first line is specific to GeoURL’s crawler, but the second line is a generic expression of the Dublin Core “Title” element. By adding GeoURL code to your page, you’ve also made it possible for any Dublin-Core-savvy spider or agent to identify the title of your work. (It also makes it easier for human programmers to recognize the meaning of that metada, even if they don’t fully understand the description model being used.)

So what other sorts of metadata frameworks are there? Let’s take a look at the big one, a general-use framework intended to describe anything and everything on the Web, RDF.

Resource Description Framework RDF stands for “Resource Description Framework,” and like other metadata we’ve examined so far, it’s just another way of describing resources on the Web. RDF, however, is an official initiative of the W3C, the same folks who wrote the specifications for HTML, XML, and CSS. (Nobody breeds prize-winning acronyms like the W3C.)

Apart from its esteemed pedigree, RDF is remarkable for its large scope: It was designed to be a super-encompassing framework providing interoperability between different types of metadata. RDF can describe a single Web page, but also inter-relationships between a page and other resources on the Web. Likewise, RDF-crawling applications can do more than just parse one page’s worth of metadata — they can independently follow links to other metadata resources, placing things within a larger context. Even if an RDF agent wasn’t originally designed to handle the kind of metadata on your page, it may be able to automatically “learn” enough to process it meaningfully anyhow.

RDF has a rep for being academic and hard to understand. In truth, advanced RDF gets almost philosophically abstract, not to mention technically tricky. But the basics aren’t bad at all.

At heart, RDF is just a list of sentence-like assertions, or “Statements.” Like this here:

(This article) (is authored by) (Jason Cook)

(subject) (predicate) (object)

Happily, that’s as complicated as any single RDF statement gets. Every statement must follow that simple, three-part structure of Subject, Predicate, and Object; because of this, RDF statements are often referred to as “triples.” Witty, neh?

You’ll notice that statements always describe the relationship (the predicate) between the subject and object, like in this triplet o’ triples:

(This article) (is authored by) (Jason Cook)

(Jason Cook) (has email) (jason@jasoncook.com)

(Jason Cook) (has homepage) (www.jasoncook.com)

On a cocktail napkin, we’d graph those relationships out like so:

Well, turns out my sketch above isn’t only cute-as-a-button, but it actually represents a directed graph, a type of mathematical model that’s easily traversed by computer algorithms, and which scales well to millions of nodes. That’s good news for agents like search-and-retrieval spiders.

Apart from illustrating the flow of direction from Subject to Object, you’ll notice that every arrow in my sketch is also attatched to a URL. That’s important. In fact, it’s downright key. Because while you and I already have a shared notion of what the “Is Authored By” relationship implies, a computer doesn’t.

Having a URI associated with each arrow (each predicate) allows software agents to follow links when they need more information about the properties of a relationship. For example, you could provide guidelines saying, “watch out, neither ‘January 23rd, 1971’ nor ‘Sinatra_MyWay.MP3’ is a plausible Author”.

One common way of doing this is by putting a ‘schema’, in the form of a XML namespace document, at the URI. Obviously, a schema can’t give sci-fi-type Artificial Intelligence to any crawler that visits it, but it can list useful rules like “Authors sometimes have email addresses” to aid data-gathering.

Thankfully, you don’t have to code all this by yourself! A big benefit of using URI-based schemas is that you can piggyback off of previous work on the web, and refer to terms already defined by others. For instance, if you include concepts like ‘Author’ and ‘Title’ in your metadata, might as well link to a common schema like Dublin Core to define those terms for you.

Another benefit of tacking URIs onto every relationship expressed within an RDF file is that it eases those awkward moments when people insist on using different vocabularies to describe the same stuff.

Let’s say my metadata uses:

( ThisArticle )( isAuthoredBy )( Jason ) … while most folks prefer … ( ThisArticle )( DC:Creator )( Jason ) With RDF, I can append machine-readable instructions to the (isAuthoredBy) URI which explains, “(isAuthoredBy) is equivalent to (DC:Creator)”. Theoretically, that’s enough for a clever Dublin-Core-aware agent to translate and processs my metadata.

Before we get too abstract, let’s see some code. Here’s our sketch example, in RDF-XML syntax:

(1)   <rdf:RDF
(2)    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:dc="http://purl.org/dc/elements/1.1/"
        xmlns:foaf="http://xmlns.com/foaf/0.1/">

(3)    <rdf:Description about="http://webmonkey.com/thisarticle">
(4)        <dc:title>Metadata Redux</dc:title>
(5)        <dc:creator rdf:resource="#Jason" />
       </rdf:Description>

(6)    <foaf:Person rdf:ID="Jason">
           <foaf:name>Jason Cook</foaf:name>
           <foaf:homepage rdf:resource="http://www.jasoncook.com/"/>
       </foaf:Person>
       </rdf:RDF>

Here’s a play-by-play commentary of what’s going on in the code above:

1. Get the party started with the opening <rdf:RDF> tag.

2. Inside the opening tag, we list URIs for three schemas used in this document. The first, the RDF schema, is always required. The second is the Dublin Core vocabulary, ideal for describing publications. The third is the Friend Of A Friend vocabulary, a set of terms that describe people.

3. We start describing our resource with URI (Webmonkey/thisarticle) i.e., this article.

4. We say the resource has a title, “Metadata Redux.” Recall that big to-do about needing a URI associated with every relationship? By using the <DC.title> tag, not native to RDF, but added via the Dublin Core namespace, we’ve implicitly named the Dublin Core schema as the URI containing details of what the “DC.title” relationship means.

5. Ditto with DC:creator, though instead of giving a value, we reference a more detailed description (‘#Jason’) a few lines down.

6. Using the FOAF vocabulary, we describe the resource “Jason,” identifying it as a Person, and then give him an Email and Homepage. Again, the semantics of all these relationships are in the FOAF schema listed up top.

By the way, a nice thing about coding RDF’s relational model is that it doesn’t much matter what order stuff gets listed in — it’s the (metaphorical) bubbles, boxes, and arrows of relationships that counts.

Phew! If that seemed intimidating, know this: RDF-XML code has a reputation for looking gnarly. Some RDF proponents argue that end-users shouldn’t worry about code or syntax, because one day, RDF will be hidden into tools like Dreamweaver, Word, or MovableType. That’s a debatable defense, but we can already point you to one such no-brainer tool that paints your biographical portrait in RDF, using Friend Of A Friend vocabulary. It’s kinda fun, and you won’t need to type a line of code, promise.

Friend Of A Friend does for humans what SMBmeta does for small businesses: It provides a metadata vocabulary that’s excellent for describing a specific thing — in this case, People.

Another benefit of FOAF is that it’s an application of RDF. Leveraging RDF’s proclivity for expressing relationships, FOAF links your profile in with that of your coworkers, your friends, and other on-line communities. (And, yes, this technology can be utilized to share pictures of cats.)

Like we said earlier, you don’t need to code anything to build a basic FOAF file. A quick visit to the FOAF-A-Matic website can generate one for you, Jetsons-style. After that, just upload it to your website, optionally adding a self-discovery link in your site’s <head>. Browsers like FOAF Explorer and FOAFnaut will help you visualize and hop around the FOAF universe, and they’re handy for validating your code, too.

‘Course, the terminally-curious among you (anybody still sticking around) probably won’t be satisfied without knowing a smidgeon more about what you can do with FOAF. For starters, you can slather on as much metadata from other vocabularies as you wish.

For instance, here’s a FOAFy file which talks about somebody’s location, but in two different ways: First, it uses a property from the FOAF vocabulary called ‘based_near’, which itself uses part of a geographic vocabulary called ‘geo’. Second, it tacks on ‘NearestAirport’ data from a completely different vocabulary called ‘contact’, which in turn relies on a more-specific ‘Airport’ vocabulary. (I point to the xmlns:geo, xmlns:contact, and xmlns:airport namespaces up top, so that RDF crawlers can understand what I’m talking about when I specify lattitudinal geographic coordinates, or the three-character Airport codes.)

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:foaf="http://xmlns.com/foaf/0.1/" 
xmlns:geo="http://www.perceive.net/schemas/geo"
xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#"
xmlns:airport="http://www.daml.org/2001/10/html/airport-ont#" >

<foaf:Person>

<foaf:name>Samuel Clemens</foaf:name>
<foaf:nick>Mark Twain</foaf:nick>
<foaf:mboxsha1sum>f95df4fb8e8076173d9754954067df798ab03551</foaf:mboxsha1sum>

<foaf:basednear>
<geo:Point geo:lat="41.8833" geo:long="12.5"/> 
</foaf:basednear> 

<contact:nearestAirport>
<airport:icaoCode>LIRF</airport:icaoCode>
<airport:iataCode>FCO</airport:iataCode> 
</contact:nearestAirport> 


</foaf:Person>
</rdf:RDF>

RDF’s core extensibility adds a touch of free-market flair: As new schemas and vocabularies become popular, they can be easily added to your FOAF without breaking the file.

But really, what’s the point of all this? Is this not just the mortal sin of vanity, marked up in XML?

Tough call. At the moment, FOAF suffers the same Adoption vs. Support catch-22 that hampers most new technologies. (And most new technologies bite the dust.) Like the early hypertext Web, however, a community of individuals is convinced there’s something intrinsically nifty about this technology, and they’re determinedly tinkering away on it, releasing homespun apps like FOAFexplorer, FOAF: web view, FOAFbot, and others. Some have proposed “Web of trust,” community profiling, and anti-spam applications for FOAF, but these are, by and large, still experimental.

As is the Semantic Web itself.

We’d suggest you hedge your bets, watch this space, and in the meanwhiles, have fun building!

Originally published on Webmonkey.com, August 2003. Page updated Sept. 2008.

Our squat little pinguino still loyally conditions the air in our apartment, but in a tactful and rather non-confrontational manner (penguin-ish, to a T). It steers very well clear of the gruff, freon-oozin’ and temperature-stompin’ attitude that is the more vulgar custom of California’s air-con culture. No, Mr. Pinguino does not seem to cool the air at all, in fact, but instead hums and gurgles in a way that suggests an air conditioner is present, and therefore, ostensibly cooling things.

So, neat, it’s like a psycho-somatic or sub-conscious air conditioner. Or maybe it’s just busted.

Let me qualify that, then: I’ve had my fair share of curious coifs back home — attributable to whatever fast-and-loose franchising policy drove the relentless expansion of the so-called “Fantastic” Sams’ grooming enterprise.

This was a tad different: I was playing ‘barbershop roulette’, walking into a barbiere at random, but — keeping the metaphorical safety-switch on — I requested he simply shear my head with clippers (and at the basically-bald ‘0’ setting). Hairdo-wise, that’s a tough one to screw up.

And screw-ups there weren’t: I walked out the door with exactly the super-short buzz cut I had in mind stepping in. The experience, on the other hand, was unexpected.

Ever seen those East-German or Russian-made flashlights that don’t need batteries, but instead have a hand-crank built into the grip? They’re tiresome, but if you repeatedly squeeze one fast enough, it provides light enough to get you around in a blackout. (You’ll find them today at yuppie-friendly Restoration Hardware, of all places.)

Turns out the poor barber’s clipper set worked on the same principle, completely mechanical throughout. He had a whole set of ‘em, covered in bright chrome and really heavy-looking, each for a different hair length. Obviously, this barber was an older fellow, but his wrinkled hands got those things running speedily, so they’d whirr like a push lawnmower.

(Looking back on it, I now recall seeing men getting their hair cut with similar clippers in pokhara, nepal — but that town was used to being without electricity for days at a time.)

Well, it felt odd. And in fact somewhat unpleasant, since the clippers’ blades pulled pretty hard — more like a manually-powered depilatory device than hair-trimmers. The barber, though, was about as nice as they get, and we talked about the weather some.

In retrospect, while Max Headroom’s dystopian production design may have been a ripoff of Blade Runner (hell, what isn’t, these days?), I think it’s still safe to say the series was way ahead of its time.

Yet as for why it’s still in rotation, in a somewhat decent timelsot (11ish), on a terrestrial broadcast network some 16 years after its cancellation in the U.S., I can’t say. Though the syn on the Italian dub is remarkably well done — as always.

So why waste CPU cycles climbing the ranks of do-gooder distributed computing campaigns like Folding@Home, when instead, you could effortlessly build a swarthy Level 26 Demicanadian Fighter/Organist who casts a mean Level XI Cone of Annoyance spell?

A quincunx can also refer to a crude probability-modeling device (animated here), a simple rolling ball that falls through a field of nails — distributing nice, Gaussian mounds o’ pellets on someone’s carpet.

…all of which leads us to pachinko and pinball, both championship sports in my book. A thousand jackpots in Caesar’s Palace couldn’t out-shout the everyday drone of a pachinko parlor, and the fine folks at FIFA still haven’t put on a game more thrilling than World Cup Soccer ‘94…

Some web ruins to match the Tokyo gothic: Syd Mead in HotWired; an expedition to Kowloon Walled City, and the story behind that ‘most Mos Eisley’ of Roppongi’s clubs, the venerable GasPanic.

to know enough’s enough
is enough to know.