Vanilla Ice was also rollin' -- in the 80's
Well folks, it’s deployment season again here at Best Buy, which means lots of changes, late night code deployments, and business project managers running around with their hair on fire. It also means it’s time to sneak some good structured data type stuff on to the site without actually having to explain in detail what’s so gosh darn important about delivering rich data in our site’s HTML output. It’s with great pleasure that I announce the official launch of schema.org reviews markup on all pages of bestbuy.com, gradually rollin’ out over the next couple of days to a browser near you.
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.
There is a good amount of chatter about the semantic web out there, but not a ton of concrete, working examples. I decided to put our Best Buy data to work and publish BBY SKUs in RDFa, using the GoodRelations e-commerce ontology. As I see it, simply publishing the RDFa is not an issue — the challenge is to apply real-world style and structure to the code to make it both machine and human readable. I’m trying to answer the question: is the RDFa model flexible enough to allow Joe Web Developer to successfully publish valid structured data while satisfying the desires of his design, business, and marketing counterparts?
I’m pleased with the first round of results, ~460K worth of “next-gen” product detail pages. Take a look at some choice example SKUs from the Best Buy product catalog:
Interested parties can get a full URL list here (txt, gz), or split up into list 1, list 2, and list 3 (txt).
Thanks to: Martin Hepp, Andreas Radinger, Alex Stolz, Yahoo! Searchmonkey, Jason Galep (design guidance), and Best Buy Remix.
Over the past couple of months I’ve been thinking a lot about semantic web — specifically how it fits in with the company’s overall future web development strategy. This has lead me to tinkering with RDFa markup, re-engineering current solutions with more forward thinking, semantic approaches. I have been a big proponent of microformats as a lightweight semantic markup tool (and I still think they have merit), but since have been intrigued and impressed with the power of RDFa. As with all new concepts, RDFa isn’t a “silver bullet” right out of the gate. Sitting down and actually coding the stuff into real-world examples has brought to light some potential issues that may be encountered by developers introducing RDFa to their pages.
Ontology Explosion?
Like RDF/XML, RDFa markup depends on identifying and utilizing specific ontologies in your HTML document. One could create a custom ontology specifically for a single use case. This could result in hundreds or even thousands of custom ontologies for the same concept or object. My fear is that that without proper oversight, the overabundance of ontologies will lead to a decrease in the effectiveness of RDFa, and clutter the semantic web with non-reusable ontologies. Since RDFa is recognized by the W3C, my hope is this group can provide some leadership and governance — possibly working to establish more officially recognized ontologies for use (and reuse!) on a wide scale.
Document Size
Maybe I’m just being old fashioned here, but are people still concerned about HTML document size and performance? I know my company is. In most of my examples, I saw an increase in the amount of HTML markup needed to fully code the page, usually between 5-20%, depending on the complexity of the solution. Efforts will need to be made by developers to streamline their code in order to avoid performance issues due to “heavy” HTML.
Object Order
For some ontologies, object order matters — that is, element y is in the domain of x, and should be nested under the parent. If your web page has a specific visual look and feel, will that match the object order needed to be valid RDFa? While flexible front-end development techniques using CSS will handle most of these instances, I foresee a certain amount of give and take between design/ information architecture staff and developers to achieve a balance of human usability while maintaining the data structure of the document.
Overall, I am convinced that RDFa is the right technology to fuel the semantic web, providing human usability and machine readability, even with the issues described above. In most scenarios, the benefits of delivering rich data directly to the front-end outweigh the effort to implement it. As adoption increases, new techniques will be invented that should alleviate most problems. After all, we developers are a smart bunch
