My SMX Toronto presentation on using structured markup for search engine optimization.

Includes a brief overview of semantic web principles, a comparison of the different flavors of structured markup (microformats, microdata and RDFa) and examples of rich snippets generated from structured markup.

Because of its obvious relevance to SEO, schema.org is the primary
vocabulary discussed, although the importance of GoodRelations for ecommerce sites is also acknowledged.

See the section below the embedded presentation for a brief addendum.

 
I wasn't able to squeeze these into the presentation list of relevant people to follow on Twitter, but here are some great search marketers that sometimes tweet about schema.org and related topics:

• AJ Kohn
• Doc Sheldon
• Phil Buckley
• Ani Lopez
• David Harry

And here's the main list from the presentation, reiterated here because somehow SlideShare has pointed all these links simply to twitter.com (Twitter's damnable implementation of rel="canonical" perhaps?):

• Dan Brickley
  Currently under contract from Google to oversee schema.org matters
• Martin Hepp
  The irrepressibly enthusiastic GoodRelations lead
• Jay Myers
  Web architect for Best Buy, responsible for the first major implementation of RDFa in an ecommerce enviroment
• Matthew Brown
  SEO and news optimization expert at AudienceWise, previously Director of Search Strategy at the New York Times
• Manu Sporny
  RDFa/RDF WebApps chair at W3C and one of the world's key semantic web technologists
• Gregg Kellogg
  Semantic media consultant and a part of the W3C's RDF Web Applications Working Group

Finally, in determining what sort of sites and topics might experience search visibility benefits by employing structured markup, I'd like to stress these two broad categories:

1. Any and all entities (people, places and organizations)
2. Anything relevant to the vending of goods and services, from online stores to brick-and-mortar local businesses

This SMX Toronto presentation explores how an agile approach to SEO can be used to address algorithmic and other changes made by Google on an ongoing basis.

In particular, "agile SEO" facilitates:

• The identification of opportunities that Google changes might represent.
• Responding in an effective way to big decreases or increases that come about as a result of Google algorithm changes.
• Anticipating what changes Google might make in the future.

I've used "agile" here in the everyday sense of "nimble." I know this may result in some confusion with the term "agile development," which has quite a different meaning, but it really was the right word for what I wanted to convey.

In a Wall St. Journal article published recently, Google's Amit Singhal suggested that changes were afoot at the world's dominant search engine.

While the Journal piece might overstate the magnitude of possible changes ahead (it is article author Amir Efrati who calls this "a makeover" to Google's formula, not Singhal himself) and while much of the substance of what Singhal is reported as having said is not new, there are indications that there is at least a substantial retooling of Google's search technology underway, and that the nature of these changes are related to Google's embrace of semantic web technologies.  As Efrati puts it, "the company is aiming to provide more relevant results by incorporating technology called 'semantic search,' which refers to the process of understanding the actual meaning of words."

What shape can we expect the nature of that retooling to take?  What changes might Google make to both better utilize semantic technologies and encourage their use by webmasters?  And what are the implications for search marketers and the SEO industry?

Provenance, Please!

In determining the relevance of thousands of resources, one of the most important things Google does is weeding out maliciously irrelevant resources – spam detection and filtering.  By "spam" I'm talking the whole gambit, from pages that deliberately misrepresent themselves (e.g. a page built to match the query "golf clubs" that redirects the user to an online poker site) to pages that try to exaggerate their actual relevance (e.g. an on-topic but keyword-stuffed page on golf clubs).  Google needs pick the gems out of the goo, and this procedure is still a requirement when it comes to assessing the value of structured data.

You won't find much discussion about spam in the semantic web world.  It's not that the semantic web framework does not account for the necessity to validate the veracity of documents, but that it takes a different tack.  At the top of the classic semantic web "layer cake" lays the "trust and proof" layer.  The chief mechanisms being worked on in this layer surround issues of provenance:  the origin and chronology of a document.

The W3C Provenance Working Group recently published the third working draft of its provenance data model; the introductory paragraph of this document provides an excellent overview of provenance issues:

For the purpose of this specification, provenance is defined as a record that describes the people, institutions, entities, and activities, involved in producing, influencing, or delivering a piece of data or a thing in the world. In particular, the provenance of information is crucial in deciding whether information is to be trusted, how it should be integrated with other diverse information sources, and how to give credit to its originators when reusing it. In an open and inclusive environment such as the Web, users find information that is often contradictory or questionable: provenance can help those users to make trust judgments.

(See an earlier post on "trust and proof" if you're dying to know more about approaches to this topic in the semantic web world.)

So how is this relevant to Google and its "semantic search" intentions?

As stated above, Google is very much in the trust and proof business, and if provenance proves to be a useful method to help Google determine to what extent resources can be trusted, and to verify the source of those resources, they'll add provenance mechanisms to their toolkit.

Google has previously stuck its toe in the provenance water in the form of the Google News meta tags original-source and syndication-source.  Interestingly, Google News seems to have (without fanfare) dropped support for original-source (it is detailed in the original announcement, but no long appears on the publisher metadata tags help page, having been "replaced" by the more limited standout tag).  That original-source was a bust makes sense, as it was a unilateral publisher declaration where publishers could readily unilaterally lie (and continued support for syndication-source makes sense in this context, as there's limited benefit to lying about not being the original source of a news story).

Not so with Google's big entrance into the world of provenance:  rel="author" and rel="publisher tags, combined with Google+ profile pages.

What does Google have to say about your author profile (emphasis mine)?

A rich profile is not only a great way to share information with users, but it also gives Google information we need to better identify you as the author of web content.

Your publisher profile (emphasis mine)?

Linking your Google+ page and your site like this not only helps you build relationships with friends and followers, but also gives Google information we can use to determine the relevancy of your site to a user query in Google Web Search.

The combination of a meta tag and a profile page provides Google with something that unilateral publisher meta tags cannot:  an identity verification mechanism.  Both author and publisher markup use Google+ profiles to validate the identity of a publisher, enabling them to establish provenance for resources linked to verified sources.  (In all the hoopla about Google's failure or success so far to establish Google+ as a social network, it's easy to overlook how the introduction of Google+ profile pages is an important structural improvement to previous Google profile pages.  There's now value for authors and publishers to have a correctly-linked Google+ page, even if Google+ profile owners never create or consume a Google+ post).

If Google's "semantic search" plans include facilitating the propagation of more structured data, whether by encouraging structured markup or by other mechanisms, it makes sense that they're going to continue to lean on provenance measures to help make sense of it.  Being able to determine the provenance of resources makes it easier to produce something akin to a "author graph" where queries return pages based not just on the authority of the page or site, but the authority of the author as well.

Not just what you say, but who you are, will almost certainly play an increasingly important role in the search results.

Vocabularies Big and Small

In the biggest move to date by the search engines to facilitate a more semantic web, Google, Bing and Yahoo did two things when they unveiled schema.org:  they stipulated a preferred markup specification for structured data (microdata) and provided a vocabulary to use with this markup (schema.org).

The bulk of analysis surrounding the introduction of schema.org has focused on the markup standard endorsed by Google, and in particular on the relative merits of microdata compared to microformats and RDFa.  From a practical perspective I think the schema.org vocabulary itself is of more importance to publishers, and probably to Google too.  Publishers will obviously produce more uniform – and so more readily-digestible – structured markup if they're provided with specific properties to apply to specific types of things.  And the more extensive that vocabulary, the more it allows for a greater volume and greater topical breadth of structured data.

Right now, the schema.org vocabulary is extremely useful marking up three types of data:

1. Named entities (people, places, organizations, etc.)
2. Media (information about types of web pages, images, videos, etc.)
3. Things that are bought and sold (especially on the Internet)

For this last type, schema.org is good about providing information about products and offers in the abstract, without defining domain-specific properties of the things being bought and sold.  For example, it allows publishers to say very precise things about the price of a specific television, and what consumers think of that television, but doesn't provide a mechanism to classify that television by size, display resolution, or any other property specifically relevant to televisions.

Which is at least in part to say that schema.org is not useful for marking up information specifically relevant to:

1. Any vegetable, mineral or animal that is not a named entity
2. Concepts

To a certain degree this is undoubtedly by design, and is certainly in keeping with the thrust of semantic web technologies, which is to provide machine-digestible data about real-life objects in the world (objects that can be represented by URIs, if you want to get technical about it).  Certainly the bulk of what Singhal apparently conveyed to the Journal surrounded improved recognition and inclusion of entity-based information (and, further to my previous parenthetical comment, of "identifying information about specific entities referenced" on web pages – which works hand-in-hand with linked URIs).

However, the consequences of a limited vocabulary are, well, limited information.  The best that a site about televisions that doesn't actually sell them can offer to Google now using schema.org is information about the web pages that house television information, but – again – no domain-specific information about the properties of any of those televisions.  As I've often contended, structured markup will not be truly useful to content product producers until it allows them to accurately describe a cat video.  Using schema.org the properties of the video itself may indeed by accurately described, but – aside from being able to declare the subject of the video as the entity "Mittens" – cannot provide any structured information about the adorable feline.

Among those actively building and finessing schema.org you'll find lively discussions about which new types should be added to the vocabulary, and the limits of extending the vocabulary (see the W3C vocabularies mailing list).  Semantic web types mostly caution against efforts at building all-inclusive vocabularies, and the foolhardiness of pursuing an "ontology of everything" – pointing out, sensibly, that domain-specific vocabularies should be reused by publishers, linking vocabularies when necessary.

This has a great deal of merit technologically and is sensible conceptually, but leaves the everyday webmaster (even a very technically adept webmaster) at a loss if he or she wants to express, in a structured way, some specific property of a topic not covered by schema.org.  However inelegant and monstrous it might be, building an "ontology of everything" – or at least a vastly expanded (and more readily extensible) schema.org vocabulary – might be in Google's best interest to facilitate and promote the production of structured data to improve its search capability and results.

The point is, from a taxonomic perspective, if Google hopes to exploit the benefits of classified data it will be in its best interest to support that classification by building or extending vocabularies.  They've been doing this on an ad hoc basis since the introduction of schema.org (June 2011), extending it to include sports (Aug. 2011) and then software applications (Sept. 2011).

Entities Rule!

What I've suggested above about Google extending vocabulary support to cover a broader range of non-entity types is highly speculative.  That entities will play a pivotal role in Google "semantic search" is much less so.

In an interview with Mashable, Singhal stressed – just as he subsequently did in the Journal interview – that entities will play a critical role in the road ahead for Google:

Google is "building a huge, in-house understanding of what an entity is and a repository of what entities are in the world and what should you know about those entities," said Singhal.

In 2010, Google purchased Freebase, a community-built knowledge base packed with some 12 million canonical entities. Twelve million is a good start, but Google has, according to Singhal, invested dramatically to "build a huge knowledge graph of interconnected entities and their attributes."

Apparently the work on entities has been continuing at a fevered pace.  According to the Journal:

Mr. Singhal said Google and the Metaweb team, which then numbered around 50 software engineers, have since expanded the size of the index to more than 200 million entities, partly by developing "extraction algorithms," or mathematical formulas that can organize data scattered across the Web.

Bill Slawski has argued – I think convincingly – that what some observers have classified as "brand bias" is in fact Google endeavoring to make sense of queries as they might be related to named entities, and returning information relevant to an identified brand whenever it can (Slawski recently named Google's Entity Detection patent as one of "the 10 most important SEO patents – see the end of the article on the patent for more resources about Google and entities).

Between Google's filings of entity-related patents, it's 2010 purchase of Metaweb, the introduction of shema.org (supporting the structured markup of named entities) and Singhal's own unambiguous statements, it is clear that entities will play an important role in Google's "semantic search" initiative.

Does Retooling Mean More Tools?

Whether Google continues to build out from schema.org or introduces an entirely different knowledge organization scheme, the best vocabulary in the world isn't going to help if nobody uses it.  While it's not rocket science for developers, even relatively code-savvy webmasters and SEOs (these days, often the ones actually marking up HTML with microdata) find it difficult to get microdata right.  How might Google make it easier for webmasters to use structured markup?

One of the reasons often cited for the slow adoption of semantic web technologies is a paucity of useful, relatively easy-to-use tools.  Certainly there's very little in the way of microdata authoring tools, and the most widely-used content management systems (Drupal notwithstanding) lack native microdata support.  Were Google to introduce authoring tools that made structured markup easy that would probably go a long way toward improving adoption, with the added benefit that the markup would be uniform and syntactically sound.

Are "Direct Answers" (Or Much Else Here) New?

Many commentators in the search marketing industry have remarked that a "semantic" Google might answer more user queries directly in the search results, obviating the need for searchers to visit a site for that information, and so depriving publishers of (search-derived) traffic.  The Journal recounts:

Over the next few months, Google's search engine will begin spitting out more than a list of blue Web links. It will also present more facts and direct answers to queries at the top of the search-results page.

A tweet from Craig Fifield summarizes the reaction of many search marketers:

Should Google force a user to click through to a site to consume a piece of information that it thinks it can accurately return in the search results?  As long as the source or sources of that information is cited and linked (a SERP-level provenance measure) it seems to me a user's best interests are served without requiring them to jump through that particular hoop.

While I recognize that there's lots of nuance involved in debates about information ownership and Google's use of information published by others, I think that SEOs worry far too much about "direct answers" poaching traffic to their sites.  The nature of such information is, first, limited to the sort of facts that can be encapsulated in relatively brief form (e.g. "when was William Shakespeare born") and, second, as likely or not be found on a non-commercial authority site that's going to outrank you anyway (e.g. "when was William Shakespeare born").  Sites with rich content are still likely to fare well, and do any of us bemoan the loss of content farm pages in the search results that were written specifically to answer queries like "when is Memorial Day 2012?".

In any case, as ReadWriteWeb's Jon Mitchell correctly notes, such "direct answers" are not new.  Perhaps we'll see more of these, or perhaps even the development of user interfaces that permit searches to delve deeper into the response to their question without leaving a Google page.  Were this ever to present an egregious challenge to a publisher's traffic, that publisher could always prevent Google from indexing their content – though of course, that would also prevent users from discovering that content from search, and almost certainly end up being a case of cutting off one's nose to spite one's face.

As I never tire of telling people (but as they almost certainly tire of hearing), Google has been employing semantic web technologies for a long time (this earlier post on SEO and the semantic web provides examples).  It's possible that what's on the Google horizon when it comes to "direct answers," the use of named entities and other semantic web technologies may end up be being big changes under the hood, but rather less evident in the way actual search results are displayed.

The Big Takeaways for Search Marketers

Sites with structured markup will appear in the results of more queries, rank better than non-structured web pages for those queries, and have a greater visibility both in linked and "direct answer" verticals.

Sites that can successfully identify and interlink entities in a fashion that Google can readily understand, whether by the use of structured data or otherwise, will find themselves particularly favored, both in linked search results and as sources of information extracted by Google and presented directly in responses to queries.

Up until now Google has been insistent upon the fact that structured markup does not impact the ranking of a site in its search results.  To channel my inner Jan Brady, it's all rich snippets, rich snippets, rich snippets!  But here comes a point where it becomes disingenuous to leverage structured data solely to manipulate the way in which it is represented.  More to the point as it pertains to Google's business model, there comes a point where willfully ignoring the information structured data provides results an inferior user experience.

If a site – by virtue of declaring and linking named entities, employing structured markup and providing verifiable provenance information – helps Google understand that a given resource is a relevant match for a given query, Google will inevitably favor relevant results over a fear that, in doing so, it may be exhibiting bias against more loosely structured sites.  Google will absolutely continue to try to understand sites with unstructured data, but at the end of the day the better Google understands a resource, the more use it can – and will – make of it.

When one shares a resource using the +1 button, Google attempts to extract a page title, a description of the page and a thumbnail image from that resource.  This preview is then used on the Google+ post page (and one would think that the same extraction logic is used when linking to a page directly from Google+, but I have yet to verify this with testing).

According to Google's technical documentation for the +1 button, the data is extracted from the target URL in one of four ways, listed in order of precedence.

1. Schema.org microdata
2. Open Graph protocol
3. Meta "title" and "description" tags
4. Best guess from page content

The examples given for 1 (schema.org microdata) and 3 (meta tags) – and the fact they are listed separately – imply that they are mutually exclusive.  The schema.org example (like any "official" examples I've encountered) show the description and name properties (itemprop) employed in the <body>.  This is consistent with Google's discussion of "non-visible content" on their microdata page.

In general, Google won't display content that is not visible to the user. In other words, don't show content to users in one way, and use hidden text to mark up information separately for search engines and web applications. You should mark up the text that actually appears to your users when they visit your web pages.

In their discussion of exceptions they talk chiefly of using non-visible content "to provide search engines with more detailed information, even if you don't want that information to be seen by visitors to your page" (emphasis mine).

It always struck me as problematic that, according to these examples and Google's guidelines, I seemingly shouldn't be using the <meta> description as the description itemprop for a page, despite the fact they serve the same function.  And as often as not it would be disingenuous to put a description of the page a visitor is already viewing on the page itself.  Such a description is most useful in off-site environments, such as a search result or a Google+ post snippet.

The same is conceptually true of a page's <title> tag, where one would think that the <title> tag is acceptable to use as the name itemprop for an Article or WebPage type, although unlike a <meta> description the content of a <title> tag usually appears on the page as a human-viewable heading, so at least is accessible for one to markup as a human-viewable element.

However, when I went to Google's +1 Button page that contains a snippet customization tool, it provides you with the utility to set the markup location as <head>.  When I entered the following…

… this is the code it generated for me:

<!-- Update your html tag to include the itemscope
and itemtype attributes -->
<html itemscope itemtype="http://schema.org/Article">

<!-- Add the following three tags inside head -->
<meta itemprop="name" content="Aaron's Article Title">
<meta itemprop="description" content="A riveting description
of the article.">

As one can clearly see, one can encode the description itemprop in a <meta> tag that appears in the <head>.  So why not double up on the <meta> description tag?  (By the way that's the verbatim output:  yes, it says to add three tags but gives you only two.)

<meta name="description" itemprop="description"
content="A riveting description of the article.">

For that matter, why not go the full distance and double up on the <title> tag as well?

<title itemprop="name">Aaron's Article Title</title>
<meta name="description" itemprop="description"
content="A riveting description of the article.">

I don't see anything wrong with this either from a microdata syntax perspective, or from a Google+ usage perspective.  I'd love to hear from any readers that see this as problematic.

I'm hesitant to either use superlatives or make predictions concerning search engine innovations (I'm the first to deride commentators that use the phrase "game changer" in almost any context), but the joint announcement by Google, Yahoo and Bing introducing schema.org is, in my opinion, pretty big news.  Schema.org at once provides a mechanism by which semantic web technologies can become a lot more mainstream, and at the same time offers the possibility of superior search visibility for search marketers that embrace this standardized, structured on-page markup.

Both searchers and publishers of quality content (by which, in this context, I really mean "quality data") stand to gain by the introduction of schema.org.  If schema.org is adopted widely, search engine users will potentially have much better answers to more complex queries, and publishers will have a mechanism to provide the search engines with much more detailed information then the engines are currently able (or, in some cases, willing) to digest.  This promise rests on the power of structured data.

An Extraordinarily Brief Introduction to Structured Data

Structured data is a mechanism by which relationships between things can be expressed in a machine-readable format.  "This computer mouse has the price $29.99," "the father of Jane Doe is John Doe," "a mouse is a mammal," and so on.  Structured data separates the presentation layer (what a web user sees) from the data layer (what a computer robot sees):  machines consuming structured data don't have to "guess" what a web resource is about, but are provided with very exact information that can be parsed and queried.

The bedrock of structured data is the resource definition framework (RDF), a "a standard model for data interchange on the Web" that permits data to be shared across different applications, and supports the evolution of different schemas over time.  RDFa provides a set of attributes that allow the embedding of rich metadata within web documents:  that is, the addition of machine-readable attributes to standard XHTML.  Microformats allow publishers to add specific attributes to existing HTML/XHTML for a topical realm defined by the microformat, providing machine-readable information for things such as recipes, events and products.  Microdata is a (proposed) HTML5 specification that allows for the nesting of semantic information within the code of existing web pages.  Like microformats, microdata relies on a supporting vocabulary to describe an item; unlike microformats, microdata allows for (relatively) extensible vocabularies, and presents no risk of conflicting with CSS attributes.

Schema.org is microdata.  More specifically, it is a structured data markup schema with a shared vocabulary that easily allows webmasters to embed machine-readable information in their HTML5 code.

Structured data falls under the broad topical umbrella of the semantic web, for which I've previously compiled a list of resources for the beginner.   Those interested in learning more about the semantic web as it pertains specifically to search engine optimization might want to check out a presentation I gave on the subject.

Major Implications of Schema.org

The introduction of schema.org, with its support from the major search engines, accomplishes two important things.  It normalizes the structured markup supported by the search engines, and it extends the topical domains of presently supported micoformats and structured vocabularies.

From a search engine optimization perspective, the normalization of markup vocabulary now makes it easy for webmasters and SEOs to decide upon which vocabulary to implement if they're starting from scratch.  It seems unlikely that the search engines are ever going to abandon structured data, and the flavor of the month is now unequivocally clear.  And there is greater incentive to invest the time and effort into producing structured markup, because Bing (which previously, unlike Google, had no acknowledged support for either microformats or RDFa) is on board with the initiative.

Perhaps even more importantly, the adoption of a standard vocabulary by the biggest conduits of web-based information queries – the major search engines – will almost certainly accelerate the adoption of structured data across the web.  This is analagous in some ways to the introduction of Facebook's Open Graph protocol.  While Open Graph wasn't particularly warmly received by the semantic web community, the benefits of sharing structured data with Facebook resulted in rapid and widespread adoption of Open Graph in the form of the now-ubiquitous Facebook "like" button.

One-time Yahoo product manager Tyler Bell, now with Factual, made a prescient observation at the time Open Graph was introduced:

Most importantly, OpenGraph is one component in a wider ecosystem. Its deployment benefits are apparent to the consumer and the developer: add the metatags, get the "likes," know your customers.

Such consumer causality is critical to the adoption of any semantic mark-up. We've seen it before with microformats, whose eventual popularity was driven by their ability to improve how a page is represented in search engine listings, and not by an abstract desire to structure the unstructured. Successful adoption will often entail sacrificing standardization and semantic purity for pragmatic ease-of-use; this is where the semantic web appears to have stumbled, and where linked data will most likely succeed.

Despite the relatively limited topical domains of microformats supported by Google, adoption has been widespread where there's been a demonstrable benefit for search engine visibility (notably with hRecipe).  Now that there's a standardized vocubulary respected by all the major search engines, and covering a much broader topical range than those supported by microformats.

While it's anything but an ontology of everything, schema.org does vastly extend the vocabulary available with Google-supported microformats.  RDFa, as the schema.org FAQ acknowledges, is much more extensible than either microdata or microformats, "but the substantial complexity of the language has contributed to slower adoption."  Certainly the relatively few search marketers I've known with an interest in structured data have almost all focused on microformats, and marking up pages in schema.org microdata is far easier for non-specialists than RDFa.

To the extent that marketers are willing to deploy relatively simple structured data, the schema.org types now supported potentially extends the use of structured data into much more diverse topical realms than microformats.  There was, for example, no microformat available by which one could specify the URL of a movie theatre.  And schema.org often provides a richer vocabulary than that available with microformats:  the schema.org organization type will be welcomed by anyone who has tried to markup complex information about a company using hCard.

Current Search Engine Support for Structured Data and the Road Ahead

The search engines have long been consumers of structured and semi-structured data.  In 2008 Google started to display reviews from such sites as Yelp and Citysearch directly in search results as a result of parsing review data, in what was probably the first broad-based appearance of rich snippets in the SERPs.  Since then Google, especially, has supported more and more structured data types, including various microformats, RDFa, and the product vocabulary GoodRelations.  This is in addition to other types of structured and semi-structured data submitted directly from publishers to the search engines, such as product feeds (such as feeds for Google Products), RSS and XML sitemaps.

As noted, the most obvious manifestation of the search engines' consumption of structured data has been the appearance of rich snippets in the search results:  a search engine snippet that provides more information directly in the SERPs than the traditional linked title, description and URL of a web resource.  An example is a product snippet in the Web SERPs that includes price, availability and review information.

Despite the broad range of microformats and structured vocabularies for which Google has professed support, what's most typified Google's use of structured data to date is the extremely uneven appearance of rich snippets.  Google will sometimes display a rich snippet in web results for a page and sometimes not, despite the availability of specifically Google-supported structured data for that resource.

In the example above, the URL referenced in the shopping results and the URL referenced in the web results contain identical GoodRelations markup, but only the shopping result appears as a rich snippet.  While this might be ascribed to the degree of trust Google accords to a given source, just because a rich snippet appears for one result doesn't mean it will appear for a similar result from that same domain.

In short, given the amount of structured data being offered to Google, one would expect to see a far greater number of rich snippets appearing in Google than has actually been the case.

This situation changed somewhat with Google's announced support for improved recipe rich snippets based on RDFa or hRecipe in April 2010, and the introduction of "Recipe View" in February 2011.  While Recipe View provided ways with users to refine their searches based on attributes made available with structured data, Google's consumption of structured recipe data has resulted in the generation of far more rich snippets for recipes than in any other topical realm.

Google's embrace of structured data for recipes can be seen as something of a precursor to schema.org, especially as it pertains to Google's confidence in the veracity of structured data.  I don't know how successful Recipe View itself has been, but I'm willing to bet that the creation and consumption of structured recipe data has resulted in "better" recipe search results in Google, whether that success is based on the metric of higher CTRs on top results or some of other measure of search satisfaction.

What's really interesting about recipe search results is that, unlike things like consumer products, rich snippets are being fairly consistently displayed in the SERPs.  Google seems to have a high degree of trust for recipes coded with hRecipe/RDFa, and there's reasons to think that this trust in data may extend to documents marked up with schema.org types and properties.  Schema.org microdata may offer the search engines a superior methodology for evaluating the veracity of structured data.  A comment from Alan Bleiweiss on the first Search Engine Land report about schema.org summarizes this admirably:

I can already see scenarios where the engines look at content within these and say “does this belong here, or is this a spammy use of this area of the page?” I know they already evaluate such things to a certain degree, but with the new uniform elements, breaking down pages into consistent uniform blocks will make it much easier for them to do that evaluation within an individual page, across a site, and across competitive sites.

This is, in my opinion, an extremely important point.  Providing structured data to search engines is of little use if there's a low probability that the search engines will use it.  It is likely that Google's evaluation of recipe structured data concluded that those data were trustworthy, for the simple reason that there's not a lot of incentive for publishers to go to the trouble of producing hRecipe markup unless the resource is actually a recipe.  It will be very interesting to see if Google, Yahoo and Bing express the same confidence in schema.org markup:  if more varied rich snippets start to appear quickly in the SERPs, this will be an indication that Google et al. have been able to successfully roll in trust measures with their roll-out of schema.org.

The Impact of Schema.org on Search Results and SEO

As suggested above, the likeliest impact of schema.org data on search results will be the appearance of rich snippets for a much broader range of topics.  For example, a result for a book search might include the display of the number of pages and ISBN directly in the search results.  Related to this is a possible increase in the number of custom search refinements facilitated by microdata, such as those currently offered in Recipe View.  One way or another, wide scale adoption of schema.org markup certainly opens up the potential for the search engines to be able to provide more exact answers to a broader range of very specific queries.

Because schema.org microdata allows web publishers to provide attributes for sections of a web page, this will make it easier for the search engines to extract specific information from the content of web pages with less guessing.  This is likely to result in the inclusion of more information directly in the search results, as opposed to forcing the user to visit the linked resource.  This is not, as per the Einstein query above, uncommon at present, but answers delivered directly in the SERPs could become much more prevalent with schema.org.  Certainly the existence of schema.org markup on a page will make it much, much easier for search engines to parse the information that appears on a web page.  This, of course, offers something of a challenge for web publishers that want to encourage click-throughs from the SERPs to their web page:  there's less reason for a searcher to leave Google if the information they're seeking is displayed directly in the search results.

From this perspective, it seems likely that a web page containing schema.org-compliant markup will have greater visibility in the search results than a page containing similar information, but lacking structured data.  So all things being equal, web publishers that include schema.org markup in their code should have a competitive SEO advantage over those that don't.  "All things being equal" is a pretty big caveat, and the degree to which this is an actual competitive advantage revolves around the degree of trust that the search engines put in schema.org data.  However, it seems unlikely that the search engines have collaborated on a structured data schema without a fair degree of confidence that this schema will pay off in the form of better search results for users.

A bigger conundrum faces publishers that have already been employing microformats or RDFa in their code.  While Google says "it’s OK to use the new schema.org markup or continue to use existing microformats or RDFa markup, you should avoid mixing the formats together on the same web page, as this can confuse our parsers."  This puts publishers between a rock and hard place:  it may not be advisable simply to add schema.org markup to existing code because of this confusion, but leaving things as is fails to realize the benefits of Bing's adoption of schema.org.  As one of the stated goals of schema.org is to offer a common vocabulary that the search engines agree upon, the prospects for continued non-schema.org structured data support (let alone search engine support for new microformats or structured data schemas) seems slim.

One may also expect to see an increase in the amount of semantic spam being fed to the search engines.  I explored this to some degree in a previous post on the subject of trust in the semantic web, but schema.org potentially makes it much more attractive for nefarious publishers to misrepresent their data in the interests of increased traffic from search engines.  The degree to which the search engines are able to readily evaluate the veracity of schema.org data will be a determining factor is whether it's actually worthwhile to try to spam the search engines in this manner, which in turn may have bearing on how much the search engines trust (and so draw upon) microdata attributes in general.

Initial Reactions from the Semantic Web Community

Even early on, it's clear that schema.org has evoked two very different reactions from those in the semantic web community, many of whom have been working on structured data for a long time.  On one hand, schema.org may the equivalent of a "killer app" for the semantic web that finally results in the wide scale adoption of structured data that most semantic web researchers think is long overdue.  This is best summarized by the opening paragraph of a blog post from Structured Dynamics CEO Michael K. Bergman about schema.org (the post title, Structured Web Gets Massive Boost, is a pretty good summary in itself):

In my opinion, perhaps the most important event for the structured Web since RDF was released a dozen years ago was today’s joint announcement by the search engine triumvirate of Google, Bing and Yahoo! releasing Schema.org. Schema.org is a vendor specification for nearly 300 mini-schema (or structured record definitions) that can be used to tag information in Web pages. These schema are organized into a clean little hierarchy and cover many of the leading things — from organizations to people to products and creative works — that can be written about and characterized on the Web.

On the other hand, as Bergman acknowledges in his post, those that spent years on RDF and RDFa see this as the rejection of a superior set of structured data standards in favor of an inferior schema, and bemoan how these efforts are now potentially undervalued (Jay Myers, the trail-blazing web developer that brought GoodRelations to Best Buy, tweeted that "there's just nothing quite like throwing away years of vocabulary/ontology work").

Following up on a tweet by Italian semantic web researcher Irene Celino where she said she was "astonished & disappointed" by schema.org, I asked her about the reason for these feelings, to which she was kind enough to reply:

Bear in mind this is only *my* very personal point of view, and other Semantic Web-ers could partially or totally disagree.

I was already quite disappointed by the W3C to standardize microdata instead of RDFa within HTML5, since the latter is (1) much more expressive and (2) strictly connected to the Linked Data efforts of the Semantic Web community.

The fact that Schema.org FAQ explicitly suggest to drop RDFa is even worse, especially after Yahoo and Google supported the adoption of GoodRelations for product description. Of course they are free to choose the format they like, but somehow they are saying "if you want to appear in search results follow our rules". Instead, as Web site owner I'd say "dear major search engines, do your best to keep up with what the Web is offering you to index and do not restrict the natural evolution of the Web and the _data_ Web sites offer, whatever their format".

This has so far been a common reaction from semantic web researchers, and the two viewpoints taken together are bittersweet in aggregate:  isn't it great that the search engines have made this massive stride toward embracing the semantic web, but isn't it lousy that the specific standard they've adopted is microdata.  The debate within the semantic web community will be interesting to watch as schema.org markup starts to appear.  It will be also interesting to see what this means for the future of microformats, given that there's basically no longer any reason to employ them for SEO purposes (as of time of writing, there's been no reaction yet on the microformats blog or from their Twitter account).

[Update, 6 June:  I'd be remiss not to mention here Manu Sporny's eloquent polemic The False Choice of Schema.org, which I discovered after publishing this post.]

Search engine marketers are a lot more accustomed to prescriptive directives from the search engines, so the reaction from the SEO community so far has generally been favorable.  As a long time advocate of leveraging structured data for search engine visibility, I'm personally pleased that there's now a common structured data vocabulary for SEOs to stand behind (as little as a month ago, I was asking about whether to employ hCard or RDFa for the best representation of company information in search, now a moot question).  And while, like Celino, I'm disappointed by the limitations of schema.org compared to RDFa, I certainly do anticipate an easier time of it when I try to sell the semantic web to web publishers concerned with their search engine visibility.

Should coding pages using schema.org markup now become the priority task for on-page optimization?  Perhaps not, but schema.org certainly can't long be ignored in for SEOs seeking a competitive advantage and superior search engine visibility.

NOTE: I'm seeing a lot of search traffic from Canadian HuffPo readers trying to figure out how to access the .com home page.  This link should do it!

This morning saw the release of Huffington Post Canada, the first of "the first of many planned international versions," with a UK version slotted to launch July 7th.

What should have been a triumphant launch for the web's premier news and opinion publication has instead turned into something of a gong show due to one reason:  auto geolocation.  That is, readers from a Canadian IP trying to access huffingtonpost.com are automatically redirected to huffingtonpost.ca, without any option to access the .com home page.

Oh my.  Check out this comment from HuffPo user clabberty, which summarizes a lot of the outrage that Canadian-based readers are expressing today.

Americans only want to read about America. HP thinks Canadians only want to read about Canada. How wrong they are. They don't know us at all and that is going to affect this decision badly. You can put on all the Canadian "celebrity" names as commentators but we see them everywhere so we are very familiar with their opinions. We've only got 10% of the American population here so the odds of finding someone who doesn't know David Suzuki's position would be hard to find. There's an old Canadian adage – "you can lead a beaver to water but you can't make her cut down a tree." Never underestim­ate what sort of difficult curmudgeon­s you are dealing with. We just appear to be polite because we prefer to be nice.

Just to be clear, this auto geolocation is not reciprocal.  That is, readers coming from a non-Canadian IP are still able to switch between the two versions at will.  But for Canucks, it is – at least for the time being – au revoir to the huffingtonpost.com home page.

I've been down this internationalization road many times in my marketing career, and I know that both broad alternatives – allowing full access to each site version, or forcing a version on users based on geographical location – are fraught with peril.  Allowing unimpeded access to different geographical editions makes it much more difficult for the newly-introduced version to gain traction, as technology users across realms tend to like what they know, and are reticent to go to a new site when their tried-and-true favorite is still available.  Conversely, forcing a redirect to the site you want to market to a specific geographic segment is, obviously, removing choice from the hands of readers, and is likely to illicit a backlash.  It is push marketing at it's pushiest.

So there's really no right way of going about the release of a country-specific version of a site, but there is definitely a fundamental error to be avoided if you're going to force a redirect on readers:  don't pretend it isn't happening.

Automatic Redirect?  What Automatic Redirect?

Neither Arianna Huffington's announcement on .ca nor the generic announcement on .com acknowledges the issue of auto geolocation.  Um, what, did the management of HuffPo think that readers wouldn't notice?

These posts should have, in part, been used as an opportunity to come clean about the geographically-based redirect, and to answer some fundamental questions about its functioning.  You can look through the comments on these posts to identify the top issues, but they easily could have been identified prior to publication.

• Is the forced redirect temporary or permanent?
• Are any stories duplicated across top-level domains, or is any story published only under .com or .ca (this has social implications – see below)?
• Does the forced redirect change anything concerning comments made on the site or Huffington Post social profiles?

Nope.  Instead HuffPo used the release announcements purely for marketing purposes, extolling the wonderful bounty of Canadian-facing content that they've now made available.  Or, put another way, extolling the wonderful bounty of Canadian facing-content that they've forced upon unsuspecting readers.

What was the thought process over at HuffPo on rolling out geographically-based redirect without acknowledging that they were doing so?  There's three possibilities here.

• Management thought readers wouldn't notice.  Bizarre, if true.
• Management thought readers wouldn't care.  Bizarre wishful thinking, if true.
• Management thought some readers would object to forced redirection, but came to the conclusion that the best way of handling any outcry was to ignore it.

I can only think that some variation on the third possibility is what came to pass.  And that may be why they weren't up front about the auto geolocation, as it's a pretty cynical marketing strategy.  Yes, we know that you're going to be upset that we're forcing you to the Canadian version of the site, but we know that's going to give the new HuffPo editition the best chance of gaining traction.

Big.  Fat.  Fail.

Again, I'm not passing judgment on the marketing wisdom of automated redirects based on geographical location.  While I'm generally not in favor of robbing users of their navigational choices, there are legitimate uses for auto geolocation.

Without equivocation, however, I can say that the worst thing you can do to a loyal audience is to alienate them by forcing a redirect on them without acknowledgement or explanation.  While this is generally true, it should be overwhelmingly apparent for a publication that has so painstakingly built an engaged and specifically digital audience.

Don't treat your technologically savvy readership as if they're never looked at a URL before.  That's the sort of disdain for readers one would expect to see from a print publication fumbling about online, but not from one of the premier sources of Internet-based news.

To their credit, based on the tidal wave of disquiet from Canadian readers, the Huffington Post appears to be putting a mechanism in place by which Canadian readers can access the .com home page.  But they could have saved themselves a lot of grief if they had given their readers' intelligence more credit to begin with.

UPDATE

In response to the outcry, the Arianna post has been amended with this note:

Update: A number of commenters have requested the ability to easily switch from HuffPost Canada to the U.S. version — or to toggle between the two via a link in the masthead. We hear you — and are working to quickly provide this option. In the meantime, do check out HuffPost Canada — it features all the content from our U.S. version, plus some great additional Canadian content added to the mix. And thank you for the feedback — it is greatly appreciated.

As per the screenshot at right it looks as though huffingtonpost.ca has already been changed so the US home page exists as a drop-down menu item.  I know they're looking for a way that people can switch "easily," but I'm a little perplexed by the fact that the URL that allows Canadians to access the .com home page hasn't been linked to in this post, or otherwise widely broadcast.

What does a drunken SEO bet look like?  In the case of my buddy Keith Greene and I, the wager that wafted forth from the alcoholic haze concerned who would prevail in the SERPs on Google.ca for one query:

hottest toronto band

At the time I was living in Montreal, Keith in Vancouver.  Keith (an accomplished musician) had been in bands, but at the time (when he performed at all) was playing solo.  The closest I've ever come to being in a band is in my imagination, as I possess no musical talent whatsoever.

More specifically the bet, made on May 6th 2009, was for who would achieve the highest ranking for hottest toronto band on Google.ca after twelve weeks.  The only restriction on how to achieve this winning ranking was that no money could be spent on the venture (preventing a race to register hottestttorontoband.com).

Keith and I tackled the challenge in different ways – he with links, me with content.  I loved seeing the results Keith was able get on the basis of links, and his ability to drive a site to number one without a helpful domain, and with virtually no content keyword optimization, is very impressive.  Check out his insightful, amusing and aptly-named post (on his blog, I Win At Internet – another great name):

• How to Rank for Keywords No One Else is Searching For

My strategy was to build a interlinked content network based around a band called OES (read the acronym backwards – get it?).  Led by band manager Serge Page (think of the Google founders – get it?), the whole raison d'être of OES was that its members never performed together.  So while OES is fictitious, this allowed me to create a musical group without being dishonest about its existence:  OES is not a fake band, it's a real fake band.

(Each band member name is a play on the name of a readily recognizable member of the search marketing community.  A shout-out here to the first person that can correctly match each OES band member to their SEO alter ego – use the comments or contact form.)

Today Serge Page announced his retirement from OES.  I haven't done any work on the OES sites for a long time, so I wanted to wrap things up and blog about the experience before the relevant SERPs evaporated entirely.

By the way, Keith and I ended up calling it a draw, as we kept exchanging places in the number one position.  Whether or not OES was number one or two in Google, at the time the challenged ended page one consisted of Keith's site, and nine OES URLs.  That's the power of a content network.

The Hot OES Content Network

I started out by building sites and social media profiles in support of the dreaded target keyword phrase hottest toronto band.

• OES on wordpress.com.  The anchor of the content network.  Everything you ever wanted to know about OES but were afraid to ask:  profiles of band members, press releases, photographs, interviews (Serge Page even ends up interviewing himself).
• OES on MySpace.  Every musical act needs a MySpace page, right?  Chiefly used for publishing links to blog posts, and for using the calendar to announce when and where OES wouldn't be playing.  OES had a number of (Toronto-centric) MySpace friends that evaporated with a MySpace redesign.  I never did get around to uploading an MP3 of the band not performing The Sound of Silence.
• OES on Flickr. The main repository for band logos, and pictures of OES not performing.
• OES on Twitter.  OES manager Serge Page punching out the hottest Toronto tweets.
• OES on blogspot.com.  A secondary blog linking up the to wordpress.com site, chiefly featuring pathetic posts where Serge would whine about the trials and tribulations of being the OES band manager.

I didn't do a lot of external link work (the main site only boasts a PR1).  Aside from registering the blogs with the main blog directories and aggregators, I mostly just linked one OES site to another.  Despite it's basically lackluster presence, I was surprised to see that hottestorontoband.wordpress.com had been the lifetime recipient of 681 search queries from 388 keywords (60 of them containing "hot"), with 58 searches for "hottest toronto band" leading the pack.

Hottest Toronto Web SERPs

Search Engine Results for "hottest toronto band" on Google.ca, 12 April 2011

I'm the first to admit that "hottest toronto band" is as unlikely a keyword optimization target as you can find, so its not surprising that Keith and I were able to be successful in relatively short order.  It may say something about exact match subdomains being a pretty good poor relation exact match top level domains, but it doesn't account (except by association) for the MySpace and Flickr results. (I guess it also goes to prove that raw page count is not often useful in determining keyword difficulty.  The query hottest toronto band currently returns 31,200,000 results.)

What's been more surprising is the longevity of the results.  Except for one post in June 2010, I haven't added any fresh fire to the OES inferno since August 2009 – some 20 months ago – yet four of the sites remain on page one in Google.ca.  What's disappeared more-or-less altogether has been blog or band directory sites that listed OES.

Search Engine Results for "hottest toronto band" on Bing, 12 April 2011

The stack is much the same in Google.com from an US IP as it is in Google.ca, not only for OES sites but for others.  Not so, however, for Bing.  If you query hottest toronto band on Bing from Canada with a clean browser (no cookies, no cache, no logins) it returns the stack shown on the left.  If you change your location to the US, Bing then claims you're searching from your actual locale (in my case, Vancouver), and then delivers the stack you see one the right.

Interestingly, nothing happens if you toggle "pages from Canada," so seemingly Bing is returning only "Canadian" results unless you tell it not to.  Why is the blogspot.com feed showing up high in the SERPs?  Why does Bing not consider the wordpress.com or myspace.com sites worthy of inclusion in Canadian results (they're excluded on subsequent pages too), but ranks them highly for all other locations?  The mysteries abound.

Hottest Toronto Image Results

Search Engine Results for "hottest toronto band" on Google.ca Images, 15 January 2011

This is my favorite search result of all time, and in itself made the entire exercise worthwhile (that wall is the picture of the band not performing together for the first time).  Officiandos of image search optimization may want to mull over the various factors that provided the strong image results, such as the image container and its associated meta data, and the linking to images on Flickr from external locations.

And, of course, one might point out that search engines still have to rely on textual clues in order to make sense of images.  Google may have come far in being able to recognize faces, but it still can't tell a rock band from a brick wall.

Search Engine Results for "hottest toronto band" on Google.ca Images, 12 April 2011

The result above is from January and the results have changed since then, though OES is still well-represented in Google image search, as you can see at left.  Why is that album cover from The Toronto Drug Bust considered an OES site?  That's actually on the wordpress.com main site:  it was posted there in celebration of the fact that OES had just acquired its first MySpace friend – The Toronto Drug Bust.  It looks like the band is still a going concern, so Serge has asked them to be friends again.

Google and Bing Image Search Results for "oes hottest toronto band"

Bing froze OES out of image search altogether.  One could say that this is because OES is not actually the hottest Toronto band (one would be wrong, though:), but it appears to be more the case that Bing hasn't indexed the OES multimedia universe as deeply as Google has.  This is evidenced by any number of branded queries that should bring up some OES image.  This may not be a function of image indexing, however, but of general indexing.  According to site: searches, Google has indexed 71 pages of hottesttorontoband.wordpress.com, but Bing only 2.

Hottest Toronto Stemming

Hot, hot, hot Toronto photos on Google, 13 April 2011

Single-minded optimization for the phrase "hottest toronto band" also carried up with it in the SERPs other "hottest toronto" and "hot toronto" queries.  While this may be expected, the breadth of association was somewhat surprising.  In it's heyday in the search engines, there was hardly any word for which OES had decent coverage that didn't result in a top ranking when appended to a "hottest toronto" query.  Even now, OES retains top spot for things like:

• hottest toronto guitarist
• hottest toronto band manager
• hottest toronto bass player
• hottest toronto keyboard player
• hottest toronto roadie
• hottest toronto press releases

Some of Toronto's Hottest Musicians, July 2009

The "hottest toronto" effect was even more apparent in image search.  While there may be a large number of sites out there that textually support "hottest toronto" queries, actual directed and deliberate image optimization is both rare and effective.  In general terms this might not have that much of an impact in driving traffic to a site, but certainly becomes a consideration worth keeping in mind when image verticals are brought into the mix.

Hottest Chicago Band OES Not Performing

OES sites gained some traction from both the focus on the superlative "hottest" and from it's root "hot."  For example, as a result of one wordpress.com post interlinked with photos on Flickr, OES sites gained a foothold in the "hottest chicago" family of keywords ("Randy Pirhana" and I were in Chicago on business, and – not wanting the opportunity to go waste – took a couple of photos to point out that OES was perfectly capable of not performing internationally).

Google has always done a pretty good job of stemming, and certainly seems to understand that "hot" is in some ways related to "hottest."  The wordpress.com site is still number one in Google.ca for "hot toronto band," with the MySpace site also appearing above the fold.  And in general the page one entries for all websites (not just OES sites) in Google for "hot toronto band" and "hottest toronto band" are pretty similar.  Bing, not so much.  In fact, for Canada (English) results not one URL currently appears on page one for "hot toronto band" that appears on page one for "hottest toronto band."  For US results only one site appears on page one for both terms:  hottesttorontoband.wordpress.com (being number seven for "hot toronto band).

Hot Conclusions

So what does all this prove?  Not a whole hell of  a lot, although personally I did learn a considerable amount about effective content leveraging, the relative value of external links, indexing, the relationship between head and tail terms and image optimization techniques.  And that SEO can and should be a lot of fun.  One of the constants in organic search marketing is that the SERPs are there for all to see, and as much as this can be a curse when an important site you're working on isn't appearing on page one, there's a smile or two to be had when a less important site is given its moment of glory.

The newspaper industry has long been in crisis. When I say "newspaper industry" I am making reference to the word "newspaper" as it would have been defined circa 1995, at the dawn of the modern digital communications age: a large sheaf of newsprint containing articles, photographs and advertisements, provided at a nominal cost to news consumers by way of news kiosks, newspaper boxes and direct delivery.

The basic facts of the crisis are by now so well known it hardly seems necessary to enumerate them. In the past decade print subscriptions and print readers have steadily declined. Print advertising revenue has similarly been on a downward spiral, and online advertising sources have failed to close the revenue gap. Newspaper features that once guaranteed reader loyalty and advertiser dollars have long been supplanted by online alternatives, alternatives that as often as not provide one-time news consumers with superior functionality: classified ads, horoscopes, crossword puzzles, advice columns, photo features, television listings, weather forecasts, sports statistics, color supplements, the weekend comics.

Battle of the Curves: Print and Online Readership

The repercussions of this upheaval in the news landscape are also well known. Layoffs in newsrooms around the world. Bureaus closed. Bankruptcy filings. The offices of once powerful and illustrious newspapers lay empty, yellowing copies of last editions grim reminders of a glorious past eclipsed.

Those newspapers still pumping out the daily ink struggle to find their way as print circulation continues to dwindle. The same questions are asked in business meetings around the globe. How do we find new revenue sources? Now do we stay relevant? How do we survive?

My proposal is simple. It is highly actionable. The path I suggest though, even if embraced, may be too late for many newspapers. In the long run adopting this proposal may not even ensure the survival of a given newspaper's print edition, but might at least provide a fighting chance for the organization that prints it. But I think that any newspaper that fails to pay heed to this basic advice is doomed.

Write for the web first, and print second.

By "the web" I mean, of course, digital devices. From a audience perspective this means write first for those who consume their news on their desktops, laptops, tablets and digital phones. And by all means, if it's cost effective (or if you can absorb the loss) continue to provide this same information, perhaps in a modified form, for those eager to keep the pulp and paper factories in Port Alberni and Prince George going. But those consumers of news and trees should be a secondary concern. Write for the web first, and print second: in other words, do the exact opposite of what you are probably doing now.

Of course there are many newspapers that have acknowledged the importance of their digital readership, and a few have even to some degree embraced the reality of news consumption in the twentieth century. But the most cursory survey of newspapers online reveals that the majority of newspapers that were born in the age of print, the vast majority, are creating a product for print first, and the web second.

Quiz: Spot the Newspaper Website

Articles that reference websites and do not link to them.  Boring boilerplate web design.  Lousy onsite search functionality.  Limited opportunities for user engagement, if they exist at all.  Facebook Pages and Twitter profiles consisting of nothing of but a news feed, with no signs of meaningful interaction with readers.  Useless tag clouds.  Inadequate meta data.  Registration barriers.

All signs of publications produced first and foremost for print consumers, with their digital existence an afterthought.

What would the reversal of this model entail?  Fundamentally, a conceptual shift that would see writers, editors, subscription managers, sales people and secretaries visualizing their final product as something that appears on their screen, not something that's delivered throughout the newsroom when the day's print run is finished.

For news writers, there would be no more paper.  Stories would be composed, edited and published on digital platforms.  Sure, any journalist writes articles with the aid of a keyboard and monitor, but that articles are written on a digital platform does not mean they are written for digital platforms.  Writers in a web-focused newsroom would encode both internal and external links in their articles.  They would have the ability to pull data into them from any number of sources.  They would aid in the classification and findability of their  stories by curating the tags and references produced by back-end semantic engines.  They would know the keywords used by their readers to find their stories, especially if they wrote regularly on the same topics (had "a beat").  They would at least sample the comments made by readers on their stories, and possibly even digitally interact with some of those readers.

Write for the web first, and print second.  And extend this principle by substituting other verbs for "write."

Design for the web first, and print second.  Think first of how to present stories most compellingly and usefully for digital devices, and then figure out how to make those stories work in print.  Understand that "stories" are in fact dynamic documents, and account structurally for updates, reactions and revisions that will make pieces more useful for readers.  Build sites and apps that draw on two decades of lessons learned about effective user interaction, information architecture and internet marketing.  Make your website the primary delivery mechanism for your news, rather than a container into which you try to stuff a printed product.  Hire your next art director on the basis of their experience in digital design rather their print background.

Edit for the web first, and print second.  Not enough column inches for that incredible piece on the war in Afghanistan?  Publish it in full digitally, and edit out what can't fit for the print edition.  Do away with the web notice indicating "this story originally published on page B3 on the 4th of April" with the understanding it was originally published at 6:39:12 PM on the 3rd of April where your news lives – on your website.

Selling Ads: The Globe and Mail and eHow

Sell ads for the web first, and print second. When the director of advertising boots his machine in the morning an analytics dashboard is the first thing that's launched. He knows the ballpark figures for bounce rates, pages per visit, ad impressions, click-through rates and visitor demographics off the top of his head.  He knows the print numbers too, but he cares most about what reliable Comscore or Nielsen metrics he can use to entice advertisers to the site, rather than audited circulation and subscription numbers – which makes sense, as the number of those readers pale in comparison to the number that consume the newspaper's content online.

The web first, print second.  Print readers are out there, but they're getting older, and just there's a whole generation of kids out there that have never purchased a newspaper, and aren't likely to pick up the habit.  And just as print readers are shuffling toward the grave, so are the publishers and editors in chief that been lording over their publications' decline.  Will their successors be able to embrace the the digital age, or are even they too closely bound to the print tradition?

David Bradley at the London Free Press, Circa 1960

I am not some young buck bristling with disdain for a news era I never knew (I am, to say the least, not young).  I even come from a print journalism family.  My father worked for newspapers most of his life, and was at one time a managing editor at the Toronto Star.  My uncle was a columnist for the Saskatoon Star Phoenix. My sister (Masters in Journalism, thank you very much) worked at one my father's first papers, The London Free Press (though seeing the writing on the wall, she shelved her newspaper career to become a high school teacher).  Hell, All the President's Men is one of my favorite movies!

So I have both an immense fondness and a personal appreciation for the print era.  And one of the reasons I hope newspapers understand that this era has past is so they can survive, reborn, and continue to provide the world with the best that print journalism has offered, and is still required in the digital age.  Investigative journalism.  Local news of real importance to communities.  News and analysis that holds power to account.  If they do survive, news that I'll be reading on the web first, and print second.

"Battle of the Curves" source images:  Lies, Damned Lies and Statistics and RAAK.

After three decades, Frank Rich is leaving the New York Times to take up a new position at New York Magazine.  Like many others I'll miss the thoughtfulness of his commentary, the excellence of this prose, and his creative approach to the art of op-ed writing.

I'll also miss Rich's ability to link his columns to the people, events and statistics they reference.  I'm not speaking of linking here in the broad sense of making connections between things (though this is also true of Rich's writing), but in the technical, HTML sense.  Rich links.  A lot.  In fact, the digital edition of Rich's columns for the Times probably contain, on average, more links than those of any other columnist for a major newspaper.

Some might ask whether looking at the link profile of an op-ed columnist is fair or meaningful.  After all these are opinion pieces, right?  I think columnists that link out liberally are doing their readers a service for a number of reasons:

• Opinion pieces do not exist in a vacuum.  They are almost always anchored to current events, and selectively linking to resources concerning these events enriches the reader's experience.
• Columnists often cite polls, economic indicators, and other statistics that are available online (which is probably where the columnist encountered them in the first place).  Linking to these sources allows readers to explore these them further, and to independently assess their veracity.
• Not infrequently a topic under discussion is web-based to begin with.  To talk about a website, a specific page on a website, or a freely-accessible social profile without linking to it is absurd.
• Providing contextually-relevant links acknowledges the fact that the reader is likeliest to be consuming the column digitally, where you can do useful things that you can't do in the print edition – like add contextually relevant links.  This is perhaps not so much a service to readers, as to a newspaper's shareholders (who might like to be thus assured that the publisher is not wholly hell-bent on obsolescence).

Both internal and external links can be useful to readers.  It is perfectly appropriate for a newspaper column to link to an another page on the same site where relevant related information exists that will better inform readers of the column.  But linking to other sites is vital when an exterior URL is more useful (especially in preference to linking to an internal story that, itself, cites and external source).  Rich links internally when appropriate, but his linking habits are particularly laudable in that he has no reservations pointing his readers to other sites.

One way or another, when it comes to linking, Rich blows his colleagues at the Times out of the water.

New York Times (10 Most Recent Columns)

How does this stack up with other major newspapers online?

Washington Post (10 Most Recent Columns)

Guardian (10 Most Recent Columns)

Globe and Mail (10 Most Recent Columns)

As the full table of columnists at the Times demonstrates, the nature and quality of links propagated depends in a large measure on the inclinations of individual columnists, so the averages for the Post, Guardian and Globe are going to be rough estimates, given the small number of columnists sampled.  Having said that, I'm not surprised the relatively large number of links found in Guardian columns, as the paper has been on the forefront of British digital journalism for some time.  I expected Post columnists to be a bit more parsimonious with their linking – but, then again, when Dan Froomkin was at the Post his "White House Watch" columns were at least as well-linked as Rich's columns in the Times.

And the Globe and Mail? Either Canada's largest national newspaper has some sort of policy against columnists linking, or their CMS somehow doesn't permit it (I checked a number of other columnists aside from those on the list, and was unable to find a single Globe column that linked out).  I'm inquiring, and will update the post when and if the Globe gets back to me.

Will Rich continue his rich (cough) linking tradition by liberally peppering the digital edition of his pieces at New York Magazine with useful web pointers?  There are only three authors in the magazine's digital edition listed a "columnists" so it wasn't difficult for me to survey their current linking habits.

New York Magazine (10 Most Recent Columns)

It's not looking good (the anchor text and link target discovered there were "TheAtlantic.com" and "NYTimes.com" respectively, so I suspect they made have been added by the publishing platform, rather than by the authors)!  Rich, in his final column at the Times, speaks of management's willingness there to accommodate his needs; let's hope he can convince New York Magazine to add a link to their columns here and there.

Since it was released in May 2010, many posts and articles introducing the semantic web have embedded or linked to the film Web 3.0: A Doc, by Kate Ray.  For those who are seeking a baseline understanding of web 3.0 mechanics, however, I think there are videos, presentations and web pages that do a better job of explaining the core concepts and technologies of the semantic web.  Don't get me wrong:  the Ray film is an interesting, informative and compellingly-presented video, and you should definitely check it out.  But if your initial incursions into the world of the semantic web include the questions "how does it work?" or "how do I get me some?" then there's some really excellent resources out there that will go a long way to answering those questions in short order.

Intro to the Semantic Web

Manu Sporny's 2007 video, awash in stick figures, is for my money still the best video introduction to the semantic web for the layman.  This will be six minutes and seven seconds of your life well spent.

Web 3.0: The Semantic Web

Hatem Mahmoud's presentation starts with a history of web technologies, clearly defines some key terminology relevant to Web 3.0, and then provides a excellent walk-through of different semantic web structures.  Particulary strong in describing the main microformats and showing examples of their use.

From the Semantic Web to the Web of Data: Ten Years of Linking Up

Davide Palmisano's presentation is more somewhat more technical than Mahmoud's, but this is to be expected as he delves deeper into Web 3.0 technologies.  Fantastic handling of the semantic web acroynm stew, starting with a really solid explanation of RDF, followed by a brief overview of each of the core technologies related to RDF:  RDFSchema, OWL, RDFa and SPARQL.

An Intro To The Semantic Web: Why You Need To Know About It Sooner Than Later

An excellent one-pager from Samantha Wong and Richard Howlett, including some links to other beginner resources.

Taxonomy Made Easy: An Introduction to Taxonomy for the Accidental Taxonomist

If you're interested in the formal categorization of digital information (and you should be – really!), you'll do no better than this splendid introduction by Heather Hedden.  An in-depth, but very accessible, overview of core taxonomic concepts.  Controlled vocabularies, taxonomies, thesauri, controlled vocabularies, ontologies:  they're all here.

Introduction to: Linked Data

Linked Data: An Introduction

Both great linked data introductions.  The first, from New Tech Post, is a concise overview in Q&A format, and concludes with a brief, linked glossary.  The second, by Juan Sequeda, contains a brief list of four linked data principles that is priceless – you'd also do well to check out his Introduction to: RDF.

I'll stop here:  if you're new to Web 3.0 and have gone through all the resources above, you're virtually an expert by now!  You'll find more beginner resources in my list of semantic web bookmarks (though be warned I don't keep on top of curating these as much as I should).  If you have any other resources you'd like to recommend, please do so in the comments.