Most of us, at some point, have used multiple search engines to solve a given problem. For example, in sourcing a consumer product, we might explore half a dozen eCommerce websites to find a good deal. Or in choosing a family holiday, we might visit a set of travel sites with common search criteria. In each case, our task is relatively straightforward: we simply take our keyword terms and copy them, along with any other context, into the respective search boxes.

But for knowledge workers, whose task is use search tools in a manner that is comprehensive, accurate and repeatable, it is a different story. In this instance, their queries can be complex and structured, and their search strategies often draw on platform-specific syntax and operators. For example, a recruiter who wants to find online social profiles matching a specific brief may specify that certain terms must appear in the URL. Likewise, a healthcare information professional might search for documents by specifying that certain terms must be found in the title or abstract. In each case, they can employ platform-specific operators (such as Google’s inurl operator or PubMed’s field tags) to articulate these requirements.

But what happens if that same individual wants to search more than one source - can their strategy be re-applied to a different search engine or database? For example, can a recruiter’s Google strategy be re-applied to Bing? Can a healthcare information professional’s PubMed strategy be re-applied to Embase? In most cases, the answer is no: those elements of the query that are platform-specific must be manually ‘translated’ for each database.

For a relatively simple query, this may not be a major undertaking, especially if those operators form a relatively small proportion of the overall query string. Even so, the user still has to recognise which elements are platform-specific, understand what the equivalent is in the other database, then manually edit their query. All of this is tedious, error-prone, and inefficient.

So we’re pleased this week to announce support for cross-platform integration, which allows a given search strategy to be applied to more than one database. For example, a Google search string may be applied to Bing, and vice versa. I should say initial support as we recognise that providing accurate and reliable translation of search strategies is a significant undertaking, often requiring skilled human judgment. In that context, what we have implemented so far is perhaps just a tiny step in that direction. But the point is that what it represents is something far greater: the prospect of a universal language for search, in which information needs can be articulated in a generic manner, with the task of mapping to the semantics of an underlying database being delegated to platform-specific adapters. Such a development could have profound implications for the way in which search skills are taught, learnt and applied.

Let’s look at a simple example. Here is a sample Boolean query which a recruiter might use to source data migration project managers based in Dublin:

(cv OR "cirriculum vitae" OR resume OR "résumé") (filetype:doc OR filetype:pdf OR filetype:txt) (inurl:profile OR inurl:cv OR inurl:resume OR initile:profile OR intitle:cv OR initile:resume) ("project manager" OR "it project manager" OR "program* manager" OR "data migration manager" OR "data migration project manager") (leinster OR munster OR ulster OR connaught OR dublin) -template -sample -example -tutorial -builder -"writing tips" -apply -advert -consultancy

And this is how this query appears when opened in 2Dsearch:

Evidently (and as we discussed in our last post), the transformation to a visual representation makes the query semantics much more transparent and amenable to editing and optimisation. And sure enough, if you look at the search results tab, we do indeed see several pages of plausible candidate social profiles. But the point is that although you may not have realized, this query uses operators that are specific to Google. This constraint becomes apparent when you switch the search target from Google to Bing:

We see that we are now finding just 3 results, and what’s more, they do not appear to be particularly relevant. So what has gone wrong? Well, there is a clue in the icon on the Messages tab. Let’s take a look underneath to see what it tells us:

Now it starts to make sense. Not only is the app telling us that the inurl operator is Google-specific, but it has also detected that the author of this search string may have inadvertently introduced an additional typo ‘initile’. Armed with this insight, we can now go back to our query and fix these errors:

The messages have now disappeared, and we have twice as many results as before (of which a number appear to be plausible candidates). We could of course continue to optimise our search strategy at this point, but let’s instead take a moment to reflect on the implications of the above.

In this example, we fixed the errors by manually replacing the Google-specific inurl operator with the Bing equivalent ‘instreamset:url’. But crucially, you could imagine a future where this fix may be suggested to us by the system, and the user may choose to apply this change automatically. Of course, any software developers reading this may conclude that such an idea is quite commonplace among software development tools, and they would indeed be correct. But for search databases, this concept is quite unprecedented. Moreover, this idea, when combined with the prospect of a universal language for search, offers profound and intriguing possibilities for the future of advanced search interfaces and for the manner in which complex information needs are articulated.

We’ll be revisiting this theme in future posts when we start to explore further integration options, focusing on professions where the the task of translating strategies between databases is particularly complex (such as healthcare information). For now, take a look at 2Dsearch, try a few searches for yourself, and let us know what you think.

Towards a universal language for search