The Government Printing Office tells us:
The U.S. Government Printing Office (GPO) has released MetaLib <http://metalib.gpo.gov>, a federated search tool that is a service of the Catalog of U.S. Government Publications. The initial release of MetaLib contains fifty-three Federal Government databases. Over time, the collection will grow based on recommendations from the GPO MetaLib team as well as public suggestions.
“Metalib” is actually the name of a particular broadcast search product from Ex Libris, that GPO has apparently purchased.
Interesting — and in my opinion terrible — choice to actually advertise and brand the GPO offering using the name of the vendor’s product. What if you later decide to use a different product to try and provide a search accross multiple federal government databases? You’re going to have to change the URL (metalib.gpo.gov), you’re going to have to change the branding, you’re going to confuse users. Why get users thinking of your service as called the name of a particular third party vendor’s product?
At my own place of work, we ran into a little bit of this with SFX, another Ex Libris product. While we branded it with a vendor-neutral name, we still included “sfx” in several places in the link resolver URL. A link resolver URL is even worse, because it’s promulgated to dozens or hundreds of licensed database provider platforms too. It’s really hard to change. Why “hard code” the name of a particular vendor’s product in it? Bad idea. While we are still using SFX as a link resolver knowledge base, when we switched to use Umlaut as a front-end for it, we also took the opportunity to change the URL to not have “sfx” in it (it doesn’t have “umlaut” in it either, that would be a bad idea too!).
On a side topic, GPO seems to be using the stock Metalib interface, which is just awful. I think just about any Metalib service tends to be pretty bad no matter what — and this is probably true of broadcast search services in general, which I consider a neccesary evil of last resort, it’s the best we can often do, but it’s still pretty bad. But if you’re going to use Metalib, you can make the interface a lot better, and probably just about as good as you are going to get a Metalib-provided broadcast search to be, by front-ending it with Xerxes. I don’t think there’s any good reason for any Metalib customers not to be using Xerxes.
Bibliographic Wilderness 
Hi Jon,
I have to agree that it makes a lot more sense to give the service a name unrelated to the vendor providing it (it certainly helped us move from Metalib/SFX to 360 Search/360 Link) but there are a couple of caveats from my perspective in an academic institution.
a) The vendor branding is acceptable if the brand is a clear market leader and a person new to an institution would be looking for that brand name, having dealt with it at another institution. Imagine Google or Word being called something different in each institution. I think Summon could eventually fall into that category, although we’ve chosen another name for our installation.
b) The name you choose is meaningful. I despair of catalogues given cute names as a result of campus competitions to name them (guilty as charged your honour). I understand that at the time it was big thing to automate your catalogue and this was an attempt at ‘buy in’ but now you scan web sites fruitlessly for a link that says ‘library catalogue’. Students and staff move between institutions as they progress their careers and it’s a needless terminology barrier.
The sidebar to the second one is that for some services there is no generic name meaningful to a non-librarian. Your SFX example is a case in point; OpenURL Link Resolver doesn’t inspire freshmen – nor does ‘Federated Search Engine’ or ‘Discovery Layer’.
I’m guessing we’ll get to a point when the ‘Discovery Layer’ is thought of as ‘The Library’ and students will just ‘Search the Library’ unless Google offers up a tool that is preferred to any gateway we can provide (some students would say they already do). Until then the answer to ‘What’s in a name?’ is ‘Lots’.
Yes, our catalog here where I work is still called the catalog, but we seem to be about to come up with a cute name instead.
As you note, and I agree, it’s hard when we can’t come up with a common sense description of the service. How come you can search _some_ things in ‘the catalog’, but _other_ things in our federated search engine — the difference between what you can search where is really based on underlying technical and business limitations, not on anything meaningful to the user. So what _is_ “the catalog” anyway? It’s a good question, but I don’t think we can possibly come up with any name that will be any MORE clear than “the library catalog”, rather than even less. I’m not seeing the benefit to our users in coming up with a unique-to-us name for it.
Certainly the unified aggregated index discovery service like Summon is an attempt to put everything you’ve got to be searched in one place, so you really can just say ‘search the library’. It’s got it’s own strengths and weaknesses of course. (And on the ‘everything’ front, I wonder if it’s possible, or if anyone’s done it yet, to put your actual library website content in products like Summon to be searchable, or other local ‘content’ that is not the kind of published material we’re used to finding in such tools. I keep considering whether we might, when we have a chance after we’ve gotten the core stuff in there, to crawl the library website and make all the pages searchable in ‘the catalog’ too.)
My understanding is that you could get metadata for your web site pages into Summon, but I’m not sure if anyone’s doing it. I’ve also toyed with importing Libguides data. Summon also has a recommended database feature that will, for very generic queries, offer up a specialist database as well as the search results. For example a search for Nursing could bring up a link to CINAHL, as well as the ranked results of the search. Still trying to get a handle on how you configure it though.