I'm assuming the content remains the property of the clients and that they have gb accounts (and thus domains), and further that their distinguishing features matter. I suspect your basic point is that one doesn't necessarily need to be a bona fide aggregator to do the work of posting on behalf of the clients. This is the conclusion I am coming to at least :). But I continue to wonder if I'm missing some salient value or prerogative or advantage there might be in explicitly being a GoogleBase-blessed aggregator. Why become an aggregator?
To the point on email exchanges, my understanding of the process for becoming an aggregator requires an application by the aggregator to gb to act on behalf of the clients and that gb contacts the clients for verification. On Sep 21, 7:20 pm, Celebird <[EMAIL PROTECTED]> wrote: > for my (1) an aggregator-account isn't required -- > although i understand google technically defines > an aggregator as having a multi-client account. > > for example, if you own the rights to the data > that your clients post on your site then, you > might submit their data to google-base -- > using your single-user google-base account. > > this would be similar to how companies like ecrater work. > > in theory (b) (c) and (d) don't apply in this case -- > depending on the depth of your customer-content security, > management, and error-detection. > > this use-case doesn't require any google-base > accounts or authentication other than your own. > > my (1) might use a multi-client account but only > if you require distinct display-names and domains -- > with all the limitations of a multi-client account; > i would assume this is your (1') > > neither instance should require customer-brokered email. > > simply, you don't need users to create google-base-accounts > in any aggregation scenario; just make clear that their data > is public and accessible on google-base via your application. > > application-account-management and > google-base-account-management can be > thought about quite separately -- > even as, at some point, they need > to come together within a solution. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Base Data API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Base-data-API?hl=en -~----------~----~----~----~------~----~------~--~---
