Re-imagined a bit, anyway. Why browse a vertical list of results when you can flip through them like pages in a book (or album covers in iTunes). Searchme on the iPhone and iPod touch does just that.

As you type your search term, icons representing rough categories appear, allowing you to target your search and helping people who’re searching for information about pythons the snake avoid results about the programming language. Though, in practice, the category results for “python” include “computer programming”, “web development,” but no obvious category for animals or zoological queries.

The results are displayed in a cover-flow-like interface, with each website represented by a screenshot image. The result is that you can browse through a half-dozen results much faster than you could individually load each page. Unfortunately, the search results are poor compared to Google or Yahoo (to engines I use regularly), and you’ll likely find yourself having to browse a few sites before you find your answer.

Despite these annoyances, and a few bugs, Searchme is a good reminder that new technologies offer new affordances. Cover flow offers a very simple method of exploring a dataset. I’m not convinced that web search results are well suited to it, but I can imagine a few datasets — photo archives, for example — that might be.

OpenSearch is a common way of querying a database for content and returning the results. The idea is that it brings sanity to the proliferation of search APIs, but a realistic view would have to admit that we’ve been trying to do that since before the development of z39.50 in libraries decades ago, and the hundreds of APIs that have followed have all well intentioned and purposeful.

So what makes makes OpenSearch something more than an also ran in a crowded herd? Part of it is in what it doesn’t do. “Rather than reinventing the wheel, it uses the simple and very popular syndication formats RSS and Atom, along with a document describing the search engine.”

DeWitt Clinton helped create the OpenSearch protocol while working at Amazon’s A9.com. DeWitt is currently at Google, but he’s continuing his work on OpenSearch as an open, Creative Common’s licensed specification, and I caught up with him there to talk about what it takes to develop an open format.

My first questions were about where OpenSearch came from.

DeWitt Clinton: Amazon launched a wholly owned subsidiary called A9. This was in late 2003, and revealed the first beta site in early 2004. A9’s mission was to explore search and to see where search could be done better.

One of the first things that we launched was the A9 front-end search interface, including search results from Google and handful of other partners. We integrated the different search results and displayed them to users, which was, I think, relatively novel for the time. It was a multiple column display where you could do one search query and see search results. They weren’t necessarily interleaved, but they were aggregated on screen.

We worked with Google’s search API, Answers.com’s search API, we worked with a few other search APIs and we started talking to additional partners about getting their searches into A9. There were a number of companies that had search engines, but far more often than not, they also had proprietary search APIs.

Basically, if you were a search company — if you were Answers.com or something like that — you would say, “OK, I can accept search requests and I’ll going to give you search results back, maybe I’ll use this XML format, maybe it’s going to be SOAP, maybe it’s going to be something else.”

So we worked with a couple more of these proprietary APIs and said, “You know, this is getting silly. We’re doing all this work on our end to integrate search results, maybe there is an easier way.” We looked around to see if there was a standard for search, and didn’t really surface anything specifically for web-based, web-type search. There were formats for more structured search, but web search is at best very loosely structured.

So we started to pick it apart, looking to propose a search format that our partners could use. But what would go into a search format? What are the common traits of search? What are the things that all web-search engines accept as parameters on the request and what are the type of things that they send back?

We started looking at the existing protocols — those that Yahoo!, Google, and even the smaller, more niche search engines had exposed — and asking ourselves what they were doing. We took the common elements from those formats until we found the subset that we could tell, just empirically, was going to cover at least the 80% case of what other people are already doing.

Then there was this moment when we realized we were inventing yet another proprietary format. You know, essentially a closed format. Fortunately, having done a lot of work with RSS in the past, we realized, “You know, search results are just a list. And the whole world is using RSS as a way of syndicating lists. So what if we — instead of trying to invent something completely new — what if we leveraged an existing protocol?”

RSS was already out there, already open, already extremely well-adopted, and had tons of client and server libraries available. Combining RSS-based responses, the extra search result metadata, and our new format for describing search interfaces gave us the common subset, the 80% case we needed for syndicated search. And that became OpenSearch 1.0.

There were three “lightbulb moments” in designing OpenSearch. The first was extracting the common features of web search. The second was leveraging existing formats, such as RSS. The third “lightbulb” was in asking the question: “who benefits if this is a proprietary A9/Amazon solution? Is the world a better place, is even our business better off if this is closed and proprietary?” And the answer, very clearly, was “no.” With that the decision was clear, “You know what, let’s open this protocol. Let’s use the Creative Commons as a way of opening the text of the format of the protocol.”

DeWitt Clinton, OpenSearch, interview, open formats, protocols, search, search syndication, RSS

A bibliographic instruction quiz we used to use asked students how many of Dan Brown’s books could be found in our catalog. The idea was that attentive students would dutifully search by author for “brown, dan,” get redirected to “Brown, Dan 1964-,” and find three books. Indeed, the expected answer was “three.”

As it turns out, my library has all four of Dan Brown’s published books, including the missing Digital Fortress. The problem is that three books are cataloged under the more common Brown, Dan 1964-, but Fortress was cataloged under Brown, Danielle.

The problem is that cataloging is imperfect.

Yeah, it takes some marbles to say that, but the fact is that cataloging is a human endeavor. Humans make mistakes. The challenge we face is to build systems that tolerate error, and then make it easy to fix those errors when discovered.

catalog, cataloging, error, errors, findability, keyword search, libraries, library, opac, search, searching, usability

OpenSearch is a standard way of querying a database for content and returning the results.

The official docs note simply: “Any website that has a search feature can make their results available in OpenSearch format,” then adds: “Publishing your search results in OpenSearch™ format will draw more people to your content, by exposing it to a much wider audience through aggregators such as A9.com.”

It’s a lot easier to understand OpenSearch once you’ve used it, so take a look at A9.com and do a search. A9 isn’t the only OpenSearch aggregator out there, but it’s a great example. You can query a number of OpenSearch targets by clicking the buttons to add columns (also try resizing the columns), or you can add any of the 422 public search targets listed at A9.

Now, if you’ve got the beta of IE 7, you can see how it’s extending beyond server-side aggregators and into client software. Even better, you can see how this is becoming automigical via autodiscovery.

One of the most exciting features of OpenSearch is its support for complex queries as well as simple keyword searches, and the ability to return intelligent responses to a search, such as alternate search suggestions (think spelling corrections) and facets (hey, any librarians attending this?)

Now, the question for libraries is when are we going to demand OpenSearch interfaces from our information providers? The inclusion of OpenSearch in IE7 more than gives it critical mass, but so far it seems to be just something a few progressive library-types are experimenting with. In the short term, imagine how improved our metasearch tools would be if based on fully-implemented OpenSearch feeds (with the facets and suggestions). In the long term, I can’t imagine any aspect of a library’s online services not touched by this technology.

a9, API, lib20, libraries, library, library 2.0, OpenSearch, search, search aggregator, search api

“Bagged products” is little better than “cookery.” I’m gonna bet that no customer has ever asked the sales people for “bagged products,” that nobody’s ever checked the yellow pages for “bagged products,” and without context, nobody would come close to answering a question on what the heck “bagged products” are all about.

But we do have context.

And within that context, those two words are probably meaningful enough to the potential customers driving by. “Nursery stock,” “pavers,” and “bagged products” are just a few facets of that potential customer’s search for “landscaping” or “gardening supplies.”

The challenge here isn’t to reinvent our vocabularies, but to build systems that help the user who searches for “cookbooks” find more of them without needing an MLS to know the specific terms we used to catalog them. As it turns out, that search returns facets that give the user a hint that “cookery” might also be a good search term (it’s not perfect, but I’m happy to have any examples in this subject in my academic library to point to).

Aside: can somebody explain to me why a book might be cataloged as “Cookery, Indic” rather than “Cookery — Indic”? It’s not like “United States — History — 19th Century” would ever be represented as “United States, History — 19th Century” or “United States — History, 19th Century.” Or would it?

bagged products, language, categorization, subject assignment, classification, librarianship, libraries, lcsh, usability, findability, library systems, search, facet, facets, contextualized, contextualized results

Users want a rich pool from which to search, simplicity, and satisfaction. One does not have to take a 50-minute instruction session to order from Amazon. Why should libraries continue to be so difficult for our users to master?

— from page 8 of the The University of California Libraries Bibliographic Services Task Force Final Report. I find a new gem every time I look at it.

design philosophy, future libraries, information behavior, information design, libraries, library, library 2.0, search, searching, simplicity, user centered design

I prefaced my point about how the standards we choose in libraries isolate us from the larger stream of progress driving development outside libraries with the note that I was sure to get hanged for it.

It’s true.

I commented that there were over 140,00 registered Amazon API developers and 365 public OpenSearch targets (hey look, there’s another one already), but that SRW/SRU would always play to a smaller audience. Basing arguments on the popularity of the subjects is dangerous, especially so within the library community, and touching on such inflammatory arguments during a 20 minute presentation is certain to leave people feisty.

It’s also especially dangerous to use an apparently sacred cow as the object of what I wanted to be a general example. My overall argument was (and remains) that we should look for opportunities to break down the barriers that isolate our work and find means to expand our community. Still, I believe a specific argument about SRW/SRU has merit, and I’m willing to carry the flag on this side.

So let’s start with what I believe we can agree on: SRW/SRU, OpenSearch, and Amazon Web Services all serve substantially similar interests: the ability to issue a query, get a list of results, get a detailed record for each result (not possible with OpenSearch). From here, many people seem to argue that XSLT can be used to mutate the results of one schema to the other, or directly to browser-displayable content with ease. On the face of it, this seems to solve many of the incompatibilities while preserving the unique features of each.

Sadly, those XSLT arguments ignore one problem while creating another.

XSLT (and similar techniques) can change the representation of the data in a record, but they can’t change the type or nature of the data and such techniques certainly can’t address differences in the way applications interact with the API. As an example, consider that an XSLT could likely be written to translate Flickr’s schema for a single image into something that looks like Amazon’s schema for a single title, but no XSLT can make an application that interacts with one API properly interact with the other.

The problem that XSLT solutions ignore is that if all these schemas can be translated between eachother (either cleanly or not), and if catalogers working with one metadata standard must be aware of the limitations of other standards to which their work might get XSLT’d to, then what’s the value of their differences? Why invest the duplicated time and effort in each?

The rest of this argument assumes that XSLT solves neither the needs of the programmer who must still learn to navigate different APIs nor the cataloger who must either use lowest-common-denominator cataloging standards or write metadata that can’t be cleanly translated to other schemas.

With XSLT out of the picture, it becomes clear that SRU/SRW is indeed among the wall of standards that make it impossible for us within the library to share executable code with anybody outside our community. And because of our low numbers and natural variations in chosen environments (preferred language & database among them), we often find it difficult to share executable code among others within our community.

It’s also worth considering the differences in features between SRW/SRU, OpenSearch, and Amazon Web Services: Both OpenSearch and AWS offer ways to include suggested alternate searches within the search response set (OpenSearch does this especially well). Nothing I’ve seen in SRW/SRU does this (please correct me if I’m wrong), yet considering how much interest there is in developing more human search interfaces and those that allow faceted searching, these are clearly essential components of any useful standard.

Further, AWS supports all aspects of the usage of materials, not just the search and retrieval of them. Are AWS’s shopping cart and checkout features not similar to our circ checkout procedures? Could AWS’s list management features not be used to show patrons what they have checked out now or throughout their history (if we or they wanted that), as well as allowing them to maintain the reading wishlists or personal bibliographies?

And AWS’s support for returning related and recommended items for each record, as well as comments and reviews is outside the scope of SRW/SRU, but required for many of the features we want to add to our applications.

The point here is that while there are substantial differences in the details between SRW/SRU and OpenSearch or AWS, it is not easy to conclude that SRW/SRU is substantially better for the applications we seem to most want to build.

And this is when we have to take note of the recent University of California libraries report and the quote that puts us all in our places: “for the past ten years online searching has become simpler and more effective everywhere, except in library catalogs” (and the same could be said of our online databases).

The problem isn’t that we’ve been bad coders, and we certainly haven’t intentionally built systems that were difficult to use. The problem is that our community has been isolated and unable to leverage advances made elsewhere. Again, my argument is that we need to change this, that we need to find more ways to collaborate not only with those within our community, but with those outside our community.

There’s much we might be able to offer coders outside libraries, but the arguments defending SRW/SRU seem to ignore the lessons we might learn from them.

Final example: it’s pretty obvious to all of us now that chat reference should be done using common and freely available IM tools, but that didn’t stop us from investing huge sums of money in building and buying custom, library specific chat reference tools. Where else will history show we’ve made similar mistakes?

a9, amazon api, amazon web services, argument, AWS, cage match, code4lib, code4lib 2006, future libraries, information retrieval, lib20, libraries, library, library 2.0, library standards, opensearch, search, search and retrieval, search retrieval, sru/srw, srw/sru, web services

Ryan Eby gets excited over LiveSearch. And who can blame him? I mention the preceding because it explains the following: two links leading to some good examples of livesearch in the wild.

Inquisitor is a livesearch plugin for OS X’s Safari web browser. It gives the top few hits, spelling suggestions where appropriate, and links to jump to other search engines.

Garrett Murray’s ManiacalRage is an interesting blog on its own, but he’s also doing some good AJAX on his search interfaces. Look first at the archive search. But also take some time to appreciate the new content search. Sure, you’ll have some complaints, but it’s his site and not yours and there are some ideas there that are pretty interesting and useful.

live, search, live search, livesearch, ajax, ahah, javascript, web, web applications, library, libraries

I just received this email from the A9 OpenSearch team:

We have just released OpenSearch 1.1 Draft 2. We hope to declare it the final version shortly, and it is already supported by A9.com. Uprading from a previous version should only take a few minutes…

OpenSearch 1.1 allows you to specify search results in HTML, Atom, or any other format (or multiple formats) in addition to just RSS. In addition, OpenSearch 1.1 will be supported by Internet Explorer 7, among other software, so we strongly recommend that you upgrade. Also new is the ability to specify suggested searches, such as spelling suggestions and related queries. (link and emphasis addded)

Woot! I’ll be doing something with this soon.

a9, opensearch, open search, amazon, search, libraries, library, opac, library catalog, library catalogs, a9.com, metasearch, aggregated search, search, federated search

Sometimes the answer isn’t as interesting as the question. Consider this note from Yahoo Buzz:

On Sunday, the day before the nomination became official, [searches for] Alito sprang up a sudden 320%.

Did searches for Alito spike on tips White House staffers, or were White House Staffers vetting their nominee via the search engines?

tags: buzz, google, judge alito, nomination, nominee, samuel alito, search, search engines, spike, supreme court, supreme court nominee, web search, white house, white house staffers, yahoo, yahoo search

Peter Morville, author of Ambient Findability, stirred up the web4lib email list with a message about Authority and Findability. His message is about how services like Wikipedia and Google are changing our global information architecture and the meaning of “authority.”

The reaction was quick, and largely critical, but good argument tests our thinking and weeds the gardens of our mind. Argument is good. Here’s my side.

It’s important that we understand how modern search engines work. On the web, each link is a citation, and citation analysis is an important component among the many algorithms used to rank search results. Highly ranked content appears at the top because it is frequently cited (linked). This is obvious to many, but what is harder to fathom is that we (those who publish web content, anyway), not the search engines are responsible for identifying value on the web. Each link is a value statement about the resource we link to.

Think about that in the context of this comment:

Just because a document is findable, this does not mean that its contents are *better* or more truthful than a document that is not findable.

My point is that findability is in fact a measure of value. A perhaps incomplete and indirect measure, but one that has shown a remarkable ability to deliver valuable and useful information on demand.

Unfortunately, not all content is available online, and not all online content is linkable. Sadly, many web OPAC pages are not linkable, as is true of most every A&I and full-text database (or the content is linkable but inaccessible behind an authwall).

So now this quote:

As librarians, we are supposed to be experts on helping people find and retrieve quality information.

And I have to follow this with the following question: How better to help our patrons find high quality, accurate, and authoritative information than to take advantage of the search engines that already answer hundreds of millions of questions each day?

As stewards of knowledge, we need to understand the Google Economy. We need to build applications that embrace it. We need to invest the value that librarians bring to the search for knowledge in our online services.

Feh, libraries are full of people smarter than me. Hopefully they’ll forgive me for speaking out of turn.

tags: authority, citation analysis, findability, google, google economy, libraries, library, library systems, quality data, research methods, search, search engine, search engines, web opac, wikipedia

Peter Morville’s Ambient Findability sold out at Amazon today on the first day of release. There’s a reason: it’s good.

Morville’s work is the most appropriate follow-on to the usability concepts so well promoted by Steven Krug in his Don’t Make Me Think and Jakob Nielsen in Designing Web Usability. Findability, Morville argues, is a necessary component in the success and propagation of an idea or detail or fact. Business and non-profits alike will benefit from understanding the value of findability.

I noted this gem about why non-profits need to pay attention to their search engine placement and web traffic previously, but it’s worth noting again:

At [the National Cancer Institute], the [web development] team had to look beyond the narrow goals of web site design, to see their role in advancing the broader mission of disseminating cancer information to people in need.

The National Cancer Institute, it turns out, was poorly ranked in many relevant searches. Though it may seem obvious now, it doesn’t matter how authoritative their information is, it has no value until it’s found. Nach: findability.

My copy has has notes scribbled in the margin and a bunch of dog-eared pages marking things I need to revisit. No, you can’t borrow it when I’m done with it, go get your own.

tags: ambient, ambient findability, designing web usability, don’t make me think, find, findability, finding, global marketplace, google, google economy, googling, hidden web, jakob nielsen, new books, peter morville, search, search engines, search results, seo, steve krug, steven krug, the effects of findability, the hidden web, the search, top rank, usability, web usability

I’m only just getting into Peter Morville’s Ambient Findability, but I’m eating it up. In trying to prep the reader to understand his thesis — summed up on the front cover as “what we find changes who we become” — Morville relates his difficulty in finding authoritative, non-marketing information about his daughter’s newly diagnosed peanut allergy:

I can tell you from personal experience that Google does not perform well when it comes to health. [...] Google sent me to specialized sites such as peanutallergy.com, a shallow and grossly commercial web site pushing favored brands of nut free chocolate and soynut butter. Yahoo! and MSN didn’t perform any better. I did eventually find what I needed, but only by drawing on my advanced searching skills and familiarity with authoritive sources like the National Institutes of Health and the Centers for Disease Control. If I weren’t a librarian who lives on the Web, I would have failed to find the right answers.

But don’t mistake Morville. He’s not blaming the search engines, and he’s certainly not blaming himself, for failing to find the information he needed. He’s blaming the people and organizations responsible for collecting, gathering, producing, and archiving this information.

A few pages later, he talks about some consulting he did with the National Cancer Institute. It turns out that the organization’s cancer.gov web site got top rank for a search on “cancer,” but fell off the front page when Googling specific cancers like “prostate cancer” or “mesothelioma.” Anybody who understands the Long Tail probably already suspects that searches for “cancer” are hugely outnumbered by the sum of all the searches for specific cancers, and Morville spends considerable time on that. The real question, however, is why did the cancer.gov folks miss this point? The problem is that very few people understand “findability.”

Because, like so many other design teams, they viewed their responsibility from a top-down perspective. Can users find what they need from the home page? It’s an important question, but it ignores the fact that many users don’t start from the home page. Powerful search tools, directories, blogs, social bookmarks, and syndication services are moving deep linking and content sampling from the exception to the rule.

At NCI, the team had to look beyond the narrow goals of web site design, to see their role in advancing the broader mission of disseminating cancer information to people in need.

From where I sit, in a library, that means us too. As stewards of knowledge, it is our responsibility to make sure we catalog it in ways that optimize its availability and findability on the web. That means understanding the Google Economy and taking advantage of it.

If you’ve read this far, you definitely need to go order the book.

tags: ambient findability, find, findability, google, google economy, googling, hidden web, long tail, non-commercial information, peter morville, search, search engines, search results, seo, the hidden web, top rank

Just when I was beginning to feel a little on my own with my talk about the Google Economy here, I see two related new books are coming out. The first is Peter Morville’s Ambient Findability. The second is John Battelle’s The Search.

Findability appears to ask the big question that I’ve been pushing toward. From the description at Amazon:

Are we truly at a critical point in our evolution where the quality of our digital networks will dictate how we behave as a species? Is findability indeed the primary key to a successful global marketplace in the 21st century and beyond?

Here, as always when thinking about information, think about “marketplace” in broader terms than pure commercial, pure profit. This is the Google Economy.

tags: ambient, ambient findability, digital networks, find, findability, finding, global marketplace, google, google economy, john battelle, new books, peter morville, search, the effects of findability, the search

I’m going out on a limb to say MySQL’s full-text indexing and searching features are underused. They appeared in MySQL 3.23.23 (most people are using 4.x, and 5 is in development), but it’s been news to most of the people I know.

Here’s the deal, the MATCH() function can search a full-text index for a string of text (one or more words) and return relevance-ranked results. It’s at the core of the list of related links at the bottom of every post here.

For that query, I put all the tag names into a single variable that might look like this:

$keywords = “mysql database php select full-text search full-text searching docs documentation”

Then I do a select that looks something like this:

SELECT * FROM wp_posts WHERE MATCH(post_title,post_content) AGAINST(’$keywords’);

The docs give a lot more detail, including how to do boolean searches.

tags: boolean search, boolean searches, boolean searching, database, db, docs, documentation, full text, full text index, full text search, full text searching, fulltext, fulltext search, keywords, match(), mysql, rank, relevance, relevance rank, relevance ranked, relevance ranking, search, search full text

37signals takes on Google and suggests some improvements.

tags: 37signals, consulting firm, design, google, google search, improvements, improving google, search, search improvements, usability consulting, web, web design, web search

Via Jay Bhatt at LISNews: UCLA Libraries‘ discussion of Google Scholar, Search Engines, Databases, and the Research Process.

tags: google scholar, googlescholar, libraries, library, research, research database, research databases, search, search engines, sevia, ucla libraries

Call it a law, or dictum, or just a big stick, but it goes like this:

The value and influence of an idea or piece of information is limited by the extent that the information provider has embraced the Google Economy; unavailable or unfindable information buried on the second or tenth page of search results might as well be hidden in a cave.

tags: availability, big stick, dictum, findability, google, google economy, idea, ideas, influence, search, search results, value

I’m rather passionate about the Google Economy, so it shouldn’t be too much of a surprise to learn that I just wrote about it in my first ever Wikipedia entry.

Here it is:

http://en.wikipedia.org/wiki/Google_economy

“Google Economy” identifies the concept that the value of a resource can be determined by the way that resource is linked to other resources. It is more complex than search ranking, and broader than interlinked web pages, though it draws meaning from both.

The Internet and World Wide Web have emphasized the role of the citation as a means of identifying the value of a resource. The structure of the print publishing world imposes strict limits on what information is promoted and distributed, but the web imposes much lower barriers to ‘publication,’ eliminating the old-media filters that information consumers once depended on to identify worthy information. Internet Search engines were developed to help navigate the growing number of web pages, but their results could not represent the value of individual pages until Google’s Larry Page and Sergey Brin started to apply the concept of citation analysis that was developed in the 1950s by Dr. Eugene Garfield at the University of Pennsylvania. Today, Google’s PageRank weighs heavily on citation analysis among the more than 150 criteria evaluated.

The result is that the PageRank of any single web page is highly dependent on the number of web pages that link to it (and their PageRank). The highest ranked pages appear at the top of the search results page. The financial implication for commercial web sites are obvious (and often exploited), but there are serious implications for non-commercial content as well. A person doing any research on the web will find his or her results heavily influenced by PageRank-style ranking. Accurate and correct information that is poorly linked will have lower ranking than incorrect or misleading information that is better linked. Because many of the most authoritative information sources — examples: medical journals, the Oxford English Dictionary — are subscription services, their content is not available for indexing by search engines, and by extension, to those using search engines for research.

Even among free services — many library catalogs, for instance — it can be difficult to index the information because of technical obstacles like dynamic URLs that make it difficult to deep link to content or explicit prohibitions in the robots.txt. The result is that a person searching for a book is far more likely to find the Amazon.com catalog page or blog posts discussing the book long before they will find any library offering the book for loan.
As with market economies, the Google Economy is subject to uncertainties, fluctuation, and occasional manipulation. Manipulators do so, however, at serious risk, as search engines have been known to blacklist them from results pages. Further, search engine engineers continue to refine ranking criteria to deliver quality search results. In general, however, there are three rules for full participation in the Google Economy:

• Linking must be possible
• Linking must be desirable
• Linking must be measurable

External links

• Roger Sperberg on the value of availability and permanence on the web
• David Rothman on hate sites and the Google Economy
• Casey Bisson on politics and the Google Economy, one of a number of his posts about the Google Economy
• Bernard Moonreports on the Google Economy from BlogBusinessSummit 2005
• Joe Griffin on marketing a web site in the Google Economy

tags: citation analysis, dr. eugene garfield, eugene garfield, google, google economy, information consumers, larry page, link, linking, links, media filters, print publishing, search, search engines, sergey brin, value, web pages, wikipedia, world wide web

David Weinberger at Many-to-Many pointed me to Tom Coates’ post about different schools of thought regarding tags. Coates has been thinking about tags as keywords, annotations. Thats how I’ve been using and thinking about tags too, but some people have different ideas.

…At the end of the argument I said to Joshua that it was almost like he was treating tags as folders. And he replied, exasperated, that this was exactly what they were.

Exasperation aside, Coates is pretty sure that Joshua’s view is loosing currency and the keywords view is growing.

Wienberger offers this explanation: we use tags as folders to organize things for ourselves, but we use tags as keywords as a way to contribute to the social understanding of things. That’s what Yahoo’s Social Search is trying to leverage.

Related: Google’s War On Hierarchy.

tags: annotating, annotations, culture war, david weinberger, folders, folksonomy, keywords, schools of thought, search, social search, tag, tag cloud, tagging, tags, taxonomy, tom coates, yahoo social search

Roger over at Electric Forest is making some arguments about the value of open access to information. Hopefully he’ll forgive me for my edit of his comment (though readers check the original to make sure I preserved the original meaning):

…keep the [information] under heavy protection and you will find that people ignore this sheltered content in favor of the sources that embrace the web and make everything accessible… [Open and accessible resources] will become the influential authorities, not because they are more trustworthy, or more authoritative, or better written, but because they are more accessible.

I’ve been calling this the “Google Economy,” where the value of information is directly proportional to its accessibility. This is a foreign land to libraries, where isolation and division of information is the norm (just count the number of unrelated search boxes linked on your library site), but it’s something I see a few people working to overcome. Kudos to Roger and others for a lot of great work.

Technorati Tags: accessibility, accessible resources, google, google economy, information, integration, kudos, leading the way, libraries, library, open access, search, trustworthy, wikipedia