Archive for the ‘Federated Search’ Category

Sebastian Hammer on Federated Search

Tuesday, June 12th, 2012

Sebastian Hammer on Federated Search

From the post:

Recently our own Sebastian Hammer was interviewed by David Weinberger of the Harvard Library Innovation Lab and a member of the Dev Core for the DPLA. Sebastian explained the strengths and limitations of federated search. You can listen to the 23-minute podcast here or read the transcript attached.


Short but interesting exploration of federated search.

I first saw this at Federated Search: Federated Data Explained.

A Federated Search Approach to Facilitate Systematic Literature Review in Software Engineering

Monday, April 30th, 2012

A Federated Search Approach to Facilitate Systematic Literature Review in Software Engineering by Mohammad Ghafari ; Mortaza Saleh ; Touraj Ebrahimi.


To impact industry, researchers developing technologies in academia need to provide tangible evidence of the advantages of using them. Nowadays, Systematic Literature Review (SLR) has become a prominent methodology in evidence-based researches. Although adopting SLR in software engineering does not go far in practice, it has been resulted in valuable researches and is going to be more common. However, digital libraries and scientific databases as the best research resources do not provide enough mechanism for SLRs especially in software engineering. On the other hand, any loss of data may change the SLR results and leads to research bias. Accordingly, the search process and evidence collection in SLR is a critical point. This paper provides some tips to enhance the SLR process. The main contribution of this work is presenting a federated search tool which provides an automatic integrated search mechanism in well known Software Engineering databases. Results of case study show that this approach not only reduces required time to do SLR and facilitate its search process, but also improves its reliability and results in the increasing trend to use SLRs.

MongoDB, Python, Synonyms, ACM, IEEEXplore, ScienceDirect, do I have your attention yet?

The author’s federated search strategy will improve Systematic Literature Reviews.

What interests me is the potential for the results of those searches to improve future searches. As the experience of domain expert after domain expert is accumulated in the results of federated searches.

Important work in a rapidly developing area.

Last Call Working Draft of SPARQL 1.1 Federated Query

Thursday, November 17th, 2011

Last Call Working Draft of SPARQL 1.1 Federated Query

From the W3C:

A Last Call Working Draft of SPARQL 1.1 Federated Query, which offers data consumers an opportunity to merge data distributed across the Web from multiple SPARQL query services. Comments on this working draft are welcome before 31 December 2011.

Some “lite” holiday reading. ­čśë

Enterprise Federated Query is a hoax!

Thursday, June 30th, 2011

Enterprise Federated Query is a hoax! by Enoch Moses, January 9, 2008.

Everyone uses the federated query example as a great application in the Service Oriented Architecture (SOA) paradigm. Via SOA paradigm, the application developers can integrate their client application to numerous services and this will allow the client application users to search and browse various data sources. This sounds great in theory however an enterprise federated query application is not possible. Before we look into why an enterprise federate query application will be a reality, we need to understand what is a federated query application (fqa).

Problems listed:

  • High number or infinity number of data sources
  • Security
  • Data Source variation
  • Result set Aggregation
  • Governance

It has been a little over three (3) years since that post.

True? Still true? Ever true? True then but not now? True then but not in the near future (our next IPO)?

When Federated Search Bites (Jeff Jonas)

Monday, July 26th, 2010

When Federated Search Bites by Jeff Jonas is a bit of a rant but makes a number of telling points.

I think topic maps qualify as federated fetch to use Jonas’ terminology.

Not surprising since I think of topic maps as navigational overlays (where navigation includes subject sameness) and not as a data storage format.

But there is a lot of interest topic map software that stores data locally.

Both approaches work and have different advantages. Has anyone outlined how you would choose between those two approaches?

Federated Search Blog

Tuesday, April 13th, 2010

Topic mappers need to read the Federated Search Blog on a regular basis.

First, “federated search” is how a significant part of the web community talks about gathering up diverse information resources.

Think of it as learning to say basic phrases in a foreign language. It may not be easy but your host will be impressed that you made the effort. Same lesson here.

Second, it has a high percentage of extremely useful resources. Two examples that I found while looking at the site this morning:

Third, we need to avoid being too narrowly focused. Semantic integration needs vary from navigation of known information resources to federation of information resources to integration based on probes of document sets too large for verification (those exist, to be covered in a future post).

Topic maps have something unique to offer those efforts but only if we understand the needs of others in their own terms.