Week 8 Readings

I am commenting on:

Definition and Origins of OAI-PMH (Chapter 1).
Federated Searching: Put It in Its Place by Todd Miller
The Truth About Federated Searching by Paula J. Hane

The OAI-PMH gives me mixed feelings. While I think it is ground-breaking that the OAI is working toward providing metadata for many different d-libs through one search, I am not convinced that it works very well. Based on the information given in this chapter, on how the two different aspects of the OAI-PMH, moving metadata appears to be very easy. The OAI service providers take the metadata from the OAI data providers and interpret which data is wanted and which needs to be delivered to the end-user. (I know that in digital library speak the end-user isn't called the end-user, but I'm still used to library speak!)
This method of transporting data that is described in chapter 1 seems complicated. One-stop shopping? That only works at Walmart. (For now.)
While the majority of this chapter delves into the history of OAI-PMH, there is still some discussion about the differences between OAI-PMH and plain open access or Dublin Core. OAI-PMH is not a protocol for searching. It is harvested searching, which means that the metadata is local and can be controlled from directly within the OAI.
Overall OAI-PMH provides a starting point for this type of federated searching, but I do not believe that it plays out the way it is presented.

Todd Miller immediately begins his article by stating that federated searching should start with the library catalog. I agree. Except that federated searching does not seem to yield the results that a regular catalog search is able to yield. When you search a catalog you are searching for very specific content in a specific manner. Oftentimes this is not possible with federated searching. The searches are much broader and less defined.
By going above and beyond the catalog and reaching into databases and other internet sources with one federated search, the user is not really aware of where they are searching. Because this is the case, they really have no idea how to make their search yield the results they need.
While it is obvious that libraries need to update their catalogs and the way to search them to provide more access, federated searching is not the way to do it, unless the goal is to confuse the end-user even more.

When I first started to read The Truth About Federated Searching I was not hopeful. I have a lot of experience with Webfeat and my experience is this: if the librarians are not able to perform an accurate Webfeat search, then how do we expect the user to be able to? We shouldn't expect Webfeat to change libraries! I agree with a lot of the points that Ms. Hane makes about the realities of federated searching.
Under point 1: even if federated searching could search every database, that doesn't mean it has the tools t search each database to its greatest potential, therefore it isn't a very good search.

Under point 2: Agreed. De-duping doesn't work. At all. And not only is it impossible to de-dup, but federated searching also is not able to tell the distinction between the significance of words being searched.

Under point 3: Refer to my point in point 2.

Under point 5: Federated searching cannot make a regular database search better. In fact, it seems to make it worse. Because the nuances of searching that particular database are not inherent in a federated search engine.

Overall I think federated searching is.... well, it needs some work.

Muddiest Points for week 7:

Does the test cover all materials in the readings (including the optional readings) as well as in the slides?

Will we all be able to fit our proposals into the time after the test?