Contrast with traditional Ajax
First, consider the classic example for XMLHttpRequest (XHR) Ajax. A web form asks for a zip code be supplied and then automagically populates the city and state fields automagically for the user. It's a decent example, having decent functionality and a certain "cool" factor for users not familiar with Ajax. It has a big problem though. Who actually has all this zip code data unless they've paid big bucks for it? Without the data, the example is useless.
But, the US Post Office has this information and is obviously the utmost authority on the matter. If they create a COWS Ajax app, a one-line script include will bring all that functionality to your site and users. It will give the benefit of accurate zip data plus an improved user experience. In return, I imagine an outfit like the USPS would simply throw in a small logo to increase branding or drive traffic to their site. It's mutally benefitial all around.
So now you see that the ideal situation is for creating apps that need to interact with all three parties (user, your site, hosting app site). It may even present a better alternative where you'd have your user connecting to the host app site (probably via an iframe).
Google Maps Possibilities
yikes! I realize the way I explain the mashups is totally wrong, but COWS Ajax can still play an important role. I'll fix this example soon!
I'm not personally a Google Maps fanatic, but there are plenty of folks out there creating amazing GMaps mashups (EXAMPLES). They'd probably have better ideas than me. The mashups I've seen use an iframe and preload all the data that's needed in one shot. Not very Ajax like, is it? Your page also has no control over what's going on inside the iframe unless you've got some proxy working under the hood. That's dandy if users go exclusively to your site, but leaves little prospect of distributing the tool for use elsewhere, severely limiting your reach.
Of course beyond rewiring the existing apps, there's plenty of potential for new apps not previously possible, especially if Google where to create some. They could create tools with direct access ot their database. So now a user clicks on a map and the coordinates can be sent back to your site and stored. Same for streets, building, landmarks, you name it. There a bunch of geniuses over that at Google, so who knows what fantastic apps they could dream up. Furthermore, there's nothing to stop you from creating your own app that sits on top of their app to create a completely new tool! It's completely feasible to insert a couple of lines to your site that then has your user interacting with your site, the host app, and Google (that the host app sits on top of). Tremendous!
Again, Flickr is an example of a site that makes beautiful apps but are confined to just their site. They also possess a tremendous resource that people want to tap into, in the form of user submitted photos. Again, I'm no Flickr expert, but I think the only tools you can run on your own website involes iframes displaying various photo montages. They could create a tool allowing you to locally tap into this resource. For example a user could now interact with these montages in some way that triggers an event back on your site. For a real-world example, suppose you were displaying a montage with photos of your various events in your life. A user clicks a photo and that could triggers your site to load a page with the details of your site. It would also present a gateway to build awareness about Flickr. It's another everyone wins situation!