Michael Fagan has spotted that Google Base (which we have written extensively about) is now accessable by the GData API.

We'll have a longer post about this soon. Quick notes:

• this means Google Base is now readable in a structured fashion -- this is good, very good
• missed by most coverage so far, but almost as important: AuthSub let's third party applications access Google Base on your behalf. BlogMatrix will be all over this!

This idea is somewhat different than the previous couple of ones we've been posting and more related to the plumbing that the db model.

We've produced a tool, based on structured blogging concepts, that can easily populate XML-driven databases such as Google Base. As mentioned in the first post of this series, you can go see this for yourself.

So what's the problem? This: how do we get it into Google Base?

Currently, Google Base has an "upload" model, where one logs in and uses browser upload to put the file into Google Base. This is great if you're some guy sitting at a computer, but no so great if you're a third-party service provider that the "some guy" has to give his Google password to!

I have two suggestions, both not-difficult to implement:

1. When specifying the upload file in Google Base, let the user be able to say that a different Google account can upload into this file. For example, allow BlogMatrix to do it.
2. Google's good at crawling the net. Instead of specifying a file, let the user specify a URI where Google can go get the data. When the data's ready, the user (or a tool on their behalf) can ping Google that something's changed.

It's bad that GData and Google Base don't have a lot of overlap. Here's a few ideas:

• GData's data model should explicitlity accept GBase attributes
• Google Base should adopt GData's RESTful Atom API

I'm sure there's a lot more that could be done, though I doubt many of GData's "kinds" would nicely fit intp Google Base's data model.

If you're researching Google's various APIs, you're bound to come across something called the "Google Data API" aka GData. It describes itself as:

The Google data APIs ("GData" for short) provide a simple standard protocol for reading and writing data on the web. GData combines common XML-based syndication formats (Atom and RSS) with a feed-publishing system based on the Atom publishing protocol, plus some extensions for handling queries.

It's a lot more than a protocol though. It also defines a data model ("kinds") for populating commonly used elements. Here's some of the types:

• gd:comments
• gd:contactSection
• gd:email
• gd:entryLink
• gd:feedLink
• gd:geoPt
• gd:im
• gd:originalEvent
• gd:phoneNumber
• gd:postalAddress
• gd:rating
• gd:recurrence
• gd:recurrenceException
• gd:reminder
• gd:when
• gd:where
• gd:who

These elements have deep structure, attributes and other such things. What does it have to do with the Google Base model? Easy to answer: nothing. This is very very unfortunate and it probably a good sign as any that Google's becoming a pretty big company, like IBM or Microsoft.

What use does Google have for GData? It's main purpose at this time is to allow outside to tools to populate Google Calendar. We can only hope this will somehow be merged or made consistent with the Google Base model and API.