Vanilla Ice was also rollin' -- in the 80's

So why schema.org? I was fortunate enough to participate in the schema.org workshop in Mountain View last month where a bunch of really smart people were talking structured data on the web. If you know anything about the history between some of the individuals attending, you’d figure we would have several opposing viewpoints and many arguments would ensue. To my surprise, this was not the case — we had a great day of very constructive talks. And with this warm and fuzzy spirit of goodwill, I figured it was time to put the rubber to the road and release a new standard for all to test.

If you’re still wondering why schema.org, please take a gander at these thoughts:

• Yep, it’s Microdata, but it’s about schema, not syntax. I’ve been doing my homework, and I believe the product reviews vocabulary created by the Google-Rich-Snippets-now-schema.org group is a solid and well thought out vocabulary. Additionally, the consensus from the workshop was the support of multiple syntaxes, so I’m not terribly worries about being lambasted for trying a new syntax .
• I still love RDFa. One of the greatest things about RDFa is it’s out of the box support for multiple types/ vocabularies, which was also a desired requirement coming out of the schema.org workshop. I was also moved by the excellent presentation by Ben Adida, where he talked RDFa and the new RDFa 1.1 Lite, which looks very, very promising. Plans are already in the works to port a segment of the reviews to RDFa 1.1 Lite, with a little help from my friends.
• Continuing to push for changes in the schema — most notably support for multiple types.
• It could be one of the first large deployments of schema.org serve as an example. Suggestions? Comments? Want to see the code change to point your parser at? Let me know, let’s create something wonderful for the web.

Finally, if you’re curious, check out this Sony TV example.

Let’s face the facts, it’s a tough job to be a retailer these days. Competition is fierce, customers are demanding, and product margins are razor thin. Just when retailers finally get that product into a customers hand and out the door, it can come marching right back into the store as a return. In fact, studies estimate there are tens of billions of dollars worth of product returned back to retailers, and very small percentage of those are actually defective. This means that brick and mortar retailers have plenty of fully functional open box products gathering dust on shelves and are missing an opportunity to get these units back into the hands of customers.

All of our local Best Buy stores are challenged with returned products. Our physical stores can be silos of beneficial product data, especially when it comes to the availability and reduced price scenarios presented by open box products. Up to this point, our open box items have not been openly displayed on the web — we tend to focus on new, unopened products, leaving an huge unmet opportunity at the store level to increase web visibility to returned products.

While this seems like a large problem to tackle, we have found a forward-thinking way to increase the visibility of open box items at our local stores using the power of open source software and open front-end semantic data standards without employing traditional marketing tactics to push individuals toward these products. Earlier this month, we began rolling out the capability for store associates to contribute to the web of data while increasing visibility to their local open box products through a simple WordPress plugin and RDFa templating mechanism. Each Best Buy store is empowered via their local store WordPress blog (background here) to enter the SKUs of the open box products they have in their inventory. The plugin fetches the relevant product data using Best Buy’s Remix API and the user is prompted to enter the open box price and a reason the product was returned. With one last click, the user saves the data and the product is published to the store site, is made available to the semantic web through front-end RDFa templates and auto-generated XML sitemaps.

There are some interesting features, techniques and potential outcomes of this work that are worth discussing:

More

There has been a flurry of chatter around the potential impact of RDFa on SEO after my brief presentation at SES Chicago 2009. In subsequent conversations with SEOs at the SES conference and folks from around the industry, I was surprised at how many people practicing SEO weren’t involving their web developers in their solutions, but rather focusing mostly on content, linking and social strategies. While these solutions are key in any SEO activities, the fact that our panel discussion and presentation was the only one involving code and coding techniques surprised me. This raises an interesting question: are many SEOs missing a core element to success, namely well structured, semantically-rich core web sites?

One can look at the current state of HTML on many web sites as an indicator of where people are focusing their efforts. The research performed to create the hProduct Microformat draft spec gives some good insight as to the condition of front-end HTML code. For years we have been building web sites mostly for visual, presentational (human-readable) purposes, and this is clear in many pages of source code analyzed for the hProduct spec. Luckily, search engines have done an incredible job of parsing out the junk and extracting the contextual and important data from billions of web pages. Machines have become vital to helping us learn, but up to this point there has been an imbalance in human-readable vs. machine-readable front-end code. Now there are emerging techniques and technologies that web developers can easily use to correct this by coding their pages to give them meaning to humans AND machines.

By combining rich front-end user and data experiences utilizing RDFa, Microformats, or the emerging Microdata spec, we build direct pathways to rich datasets, which enable machines (mostly search engines, but also next-gen parsers, browser plugins, etc.) to easily access important data and apply their algorithms, etc., to make sense of it all and index it in the ways they see fit. My personal theory is that by providing more direct access to data through front-end semantic code, machines will spend fewer CPU cycles parsing presentational code. These extra resources could then be re-allocated to better natural language processing, extending search into the “deep web”, or other efforts to make the web and it’s users smarter.

Of course this has implications to the SEO/SEM world. It forces SEO professionals to engage their web developers or become slightly more code savvy themselves. It shifts more emphasis on developing strong, data-driven semantic web sites that balance the visual needs of humans and the data needs of machines, rather than focusing on seemingly artificial techniques that increase “link juice” or utilize “secret sauce”. Using traditional SEO content strategies in combination with building strong data-rich web sites can lead to a more intelligent and useful web, which is ultimately good for businesses, users and consumers.