Scapes

Google announced a while ago that they were 'deprecating' their SOAP Search API in favour of an Ajax based search syndication strategy [as reported by Brady Forrest]. One motivation for this, it was speculated, was that the SOAP API-based syndication of search did not support their ad-based revenue model. Why? Because control of the data and how it was presented as part of the user experience was passed over to an application outside their control. With the alternative Ajax-based approach control of the user experience remains with Google, and they can place ads where they wish. Google is an advertizing engine, and its model depends on aggregating attention for its ads. Syndicating search without accompanying ads does not generate revenue. A win-lose model? It is interesting to contrast this with Amazon. Amazon is an e-commerce engine, and its model depends on aggregating attention for purchase opportunities. In the Amazon syndication model it is the data itself which is the advertizing and so it remains happy to syndicate its data. Partners find this very helpful, and it gathers potential buyers for Amazon offerings. A win-win model?

The Google announcement made me think about a distinction I have made in the past between an 'information brandscape' and an 'information landscape'. Here is how I described it in these pages a while ago:

Information landscape was a term used in various conversations some time ago to refer to the idea of a set of resources organized around user interests rather than around the characteristics of supply. For example, an information landscape might be a personalized selection of information resources delivered within a metasearch environment.
Brand is important. Providers want their value to be recognized. One approach we have seen is the incorporation of a logo in a result.
This is why after so many years of work, we still have an 'information brandscape', rather than an information landscape. Different user interfaces jostle for our attention, each with its own unused help screens and superfluous advanced features.
Perhaps this is a case where the interests of individual providers have overcome the interests of the overall user experience? This may be becoming clearer as we see the gravitational pull of Google, Yahoo, and Amazon, large consolidations of data with simple interfaces.
However, as Richard Wallis notes, libraries are now facing this issue themselves as they provide services into other environments.
Librarians have understood the value of what they do to enable the rest of humanity to identify, find, and get to the information they need, since Aristotle was a lad, and because they also kept the books they were appreciated for it. When this massive value-add for humanity is burred behind several web service calls and some non-library interface, that connection won't be so obvious. [panlibus]
It is becoming clearer that library services need to be integrated with various user environments. How much do they want to hold onto their 'brand' in how they are presented? Contributing to the 'information brandscape'? Or how much will they adapt to the 'landscape' in which they are presented? [Lorcan Dempsey's weblog: Landscape and brandscape]

So, in these terms Google does not appear to want to submerge itself in somebody else's landscape. Brady Forrest talks about the Ajax API being great for "web applications and users that want to bling their blog" but argues that it "does not provide the flexibility of the SOAP API". Bling - the Google controlled user experience embedded in another environment - is being promoted over flexibility - the ability to blend the Google search into the user experience controlled by the consuming site, the landcape provider, if you will.

And what about the library landscape and brand today? Three things occur. First, while it may be important for the library to create its own landscape, to integrate a range of services, it is becoming increasingly important for those services to be available in ways in which they can be integrated into other environments. Integration is not an end in itself. Second, this does raise interesting brand questions. The library may want to appear in the university or enterprise portal 'landscape', or in the course management system 'landscape', or in the Google Scholar landscape. Increasingly, it wants to appear in the personal landscape of the RSS aggregator, or My Yahoo!, or FaceBook, or whatever apparatus folks use to landscape (handscape?) their own digital identities and workflows. There is a small irony here in that while the library might like to submerge other providers' individual brands in the landscape it provides, it is now facing a similar issue itself. Does it want to be 'brandless' in somebody else's landscape? And of course, 'brand' here is shorthand for appreciation of value, recognition, appreciation, and what those translate into: financial and political support. Third, we have seen the stronger emergence of the 'bling' approach in recent years, with HTML fragments, widgets, portlets, and so on, emerging as preferred ways of collocating services within a user experience. In this context, there is less full integration than in the model of protocol- or API-based integration where a consuming application controls the user experience. This is probably partly because of a desire not to lose identity on the part of comsumed applications. In other words there is a variety of ways in which the library may want to syndicate services or data, and a variety of ways in which other environments might like to consume them.

Worldcat.org currently offers this 'surface' integration through its published link syntaxes, and through the embeddable search box. Later this year, it will also support some RESTful web services. This means that it will be possible to integrate Worldcat more fully into other environments, into your landscape.

Comments: 0