Robert_Charlton - 9:02 pm on Dec 17, 2012 (gmt 0)

I should have also added that all this stuff can probably already be accomplished by implementing the schema markup tags if I'm understanding this thing properly? So, why force yet another layer of work on top of us?

This isn't for people who can hand code their sites. This is for people who don't know what code is. It's sort of like microdata for dummies. That said, in some companies that have inhouse coding capabilities, bypassing the I.T. people might not be a bad thing.

Have you actually tried to find the date, time, and location for, say, a local event in a metro area on the web? The websites are an abomination.

It's probably optimistic of Google to think that people and organizations who need this are going to be aware of the tool or will provide enough information in sufficiently searchable form that the microdata will be helpful, but I've got to thank them for at least trying.

I have, in the last several months, run into events announcements where the only information displayed on the web was in a 1-megabyte graphic... or on an events calendar titled "events", which listed every event in a particular field of interest in San Francisco for the past two years, with no consistency about placename, address, or dates.

But even sites that should know better screw it up. Major league sports event sites often omit the year, and you're much more likely to get last week's info than next week's, or a string of article highlights for the season. Search [teamname tv] on some engines and you'll get listings for a TV episode from 1955.

When we see calls for microdata information, we may have good reason to assume that Google might be thinking about aggregating the data... probably for the same reason I generally go right to Place Pages (aka +) rather than to local websites, because at least I've got an expectation that I'll easily find the address, phone number, and hours of operation.