Blessed are the Cheesemakers


Sean’s response to Ed’s mention of “I’d like some cheese.. but I’d rather not know how it’s made” got me thinking about the role of standards.

Suppose I follow Sean’s suggestions and make a batch of cheese. I can’t really call the cheese Stilton unless it’s been blessed by the Stilton Cheesemakers’ Association. Consumers discover a resource using it’s name – in this case a name under control by a standards organization that assures all cheese labeled Stilton follows a strict code and is produced in Derbyshire, Leicestershire, or Nottinghamshire.

Certainly a standards body can overreach itself. I heard somewhere that Monty Python’s Cheese Shop sketch was an allusion to unintended consequences that arose from government policies aimed to regulate retail cheese. There must be some middle ground, where a standard can instill consumer confidence without burdening retailers.

This also applies to geodata. For example, almost all appraisal districts here in Texas use GIS to store parcel data. There is likely a well defined legal definition somewhere for what constitutes a parcel. As far as I know, however, there is no standard (RDF or otherwise) describing how parcels can be published. If such standards were available, appraisal districts could publish their parcels to the GeoWeb where they could be discovered and analyzed by others. But getting consensus from a standards committee would take forever. That leaves us with companies like Google calling the shots.

I bet Google is looking to do with parcels what they’ve already done with the Google Transit feed specification. I don’t think any sort of grass roots movement could have evolved a standard for transit, much less an agency like the Federal Transit Administration.

When Ed says this:

Perhaps a new approach is needed where standards are defined at the same time as new applications and functionality developed, so that the standards process is driven by individuals and organisations implementing new functionality which is standardised once demonstrated to be both stable and useful !

What he really means is this: once it has been demonstrated that Google can monetize a feed, they will support the standard.

Let’s hope the result is better than velveeta.

7 comments so far

  1. Concerned reader on

    interesting post. But the issue here is that the Transit authorities should not expend resources to meet the criteria of a private company like Google .Google’s specs are certianly not the most robus, and at the very least every TA should make available all the information to everyone not just hand over the data to Google.

  2. Kirk Kuykendall on

    Actually, many of the TA’s have made their feeds publicly available:

    Before Google Transit, Trapeze software was the big player in this arena. This was (and still is?) expensive software. DART still provides Trapeze trip planner on their web site, even though much more usable trip planning is available on Google Transit.

    Comparing Trapeze with Google Transit is an interesting study in Web1.0 vs. Web2.0.,-96.797791&spn=0.242314,0.282115

  3. Sean Gillies on

    Kirk, I’m missing the point. Are you saying that programmers cannot self-organize to produce the standards they need? Or that the standards they produce are more likely to be corrupt?

    Stilton is awesome stuff, but I’m too sensitive to the odor of ammonia to enjoy blue cheeses. I prefer Tuscan and Basque pecorino, Cheddars, and Lincolnshire Poacher.

  4. Kirk Kuykendall on

    Hey Sean – Not corrupt, just too slow. By the time a self-organized group reaches consensus they are behind the curve (e.g. using SOAP instead of REST).

    Google has the resources to move much faster and the clout to enforce a less than elegant standard. I’d be curious what level of involvement Google plays in this group:

    It seems like with a bit more info it would be possible to provide a “run cutting” (scheduling) web service. Take a look at how much is spent on different systems within a transit authority:

    But run cutting wouldn’t fit nicely within Google’s ad based revenue model, so I doubt they’d be interested in standards addressing those needs.

    Stilton takes time. I wonder how fast Kraft can crank out Velveeta.

  5. Joe Hughes on

    Hi Kirk, since I’ve been closely involved in Google’s transit work since the beginning, I can answer some of of your questions.

    The goal of the Google Transit team has always been to get better information about transit options out there in order to make life better for both new and existing transit riders. We’re transit riders, so we’re building the system that we want to use. Some of us also come from a background of building independent transit sites, so we want our activities to help those efforts whenever possible as well.

    It’s a lot more work for an agency to go from sharing data with no one to sharing data with one consumer than it is to go from one consumer to n. Given that, we sought to make that first step as easy as possible given the limited technical resources of most transit agencies.

    We noticed that (in the US, at least), none of the XML-based formats had any significant adoption, and when we had gotten detailed information from agencies, it was in a table-style format like CSV or (shudder) MS Access. So we went with what worked, on the premise that “less elegant” data was preferable to no data at all.

    Whatever the shortcomings of GTFS as a data format, there are now at least 9 more agencies sharing detailed schedule data with the developer community than there were a year ago. You and I would like to see that number get larger, but it’s a start. (And personally, I think the number will increase faster as more developers demonstrate useful things that can be done with the information.)

    GoogleTransitDataFeed was a project started by Joachim Pfeiffer to write Java-based code for converting between GTFS and TransXChange. When some Google engineers (mainly Tom Brown and myself at first) wanted to put some Python code out there, we thought it’d be better to contribute to the existing project than to create a separate project with a confusingly similar name and goal. These days, most of the project activity goes on at:

    As for the operational information that you mentioned, so far we’ve chosen to focus the GTFS project on representing rider-facing information, to keep the community discussion focused and productive. (Not to mention that our expertise is more centered on informing everyday users than on running a transit system.)

    However, the GTFS format is not limited to things that can make Google ad revenue; it’s merely limited to things that GTFS publishers and consumers want to use it for. We’ve aimed for a “rough consensus and running code” model for further development of the spec, which means that we tend to only add an extension once it’s been tested between a feed producer and a consumer with real-world data.

    While Flixer may be a wonderful cheese, most people will never get a chance to try it. Let’s start with a straightforward Neufchatel that will feed people right away.

  6. Kirk Kuykendall on

    Hi Joe –

    Thanks for the detailed answers!

    My google paranoia has been somewhat eased.

    By the way, I happen to be currently working on a project that prioritizes new sidewalk construction for City of Austin. It rates construction priority based on a number of factors, including proximity to bus stops. However, it does not factor in benefits to pedestrians walking between stops who are transferring between buses.

    If I were to propose extending transit to utilize sidewalks (and the absence of sidewalks) for the pedestrian portion of the journey, I suppose I would need to convince Google of the value. What about others in the transit community, would I need to lobby them too?

    Google is obviously benevolent in this project, but they are getting so powerful, I can’t help but recall what they said about Mussolini – “at least he got the trains to run on time”. Is there a down side?

    Thanks, Kirk

  7. Joe Hughes on


    When you say “extending transit to utilize sidewalks”, do you mean just providing detailed walking directions as part of the transit trip? If so, I don’t think Google needs any convincing on that count. :] Incidentally, how does Austin keep track of its sidewalks?

    As for downsides–I don’t know, I’d like to think that our work is a net win for transit riders. If anything, I hope that the work that Google is doing to make transit easier to figure out won’t discourage other developers from building their own transit sites. I know from experience that many transit hackers are motivated by a lack of good options for looking up bus times and the like.

    Anyway, feel free to send me email if you want to discuss any of this stuff in more detail.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: