Hi All,
One of the main concerns I have right now with librarianship in general and my area of it (cataloging) specifically is the chaotic and contradictory discussion about our future. For this list's theme, the next generation catalog, I find that we're spending time discussing software and interfaces, but not the catalog. In my view, the catalog is a service, but we have no general understanding of the service goals. I've recently tried to clarify the issue for myself [1]. In many ways, I think the NGC is doing fine; the discussion is really more about infrastructure, which is different. The data we provide, as well as how it is stored, transmitted, shared, and made available at large, are vital to the success of the service, but they are not the service. Provision of the service should be the driving force behind the adaptations of those other components. Which means we need a clearer understanding of our service. [I'm not sure how to achieve that.]
For me, discussions or assertions as to what an we should make an NGC must be bound within the service goal framework, yet most aren't. Suggestions that the NGC should be open source, modular, or evolutionary, to me confuse the software with the service. I'm not disagreeing about the software issue, just that we often conflate the two - the software and the service - and we shouldn't. (You can provide services without software.) And yet the interface is a component of the service, so the software's usability as well as its functionality is an issue that must be addressed. Additionally, though, we have to do so within the framework of what we are. For example, I work in a medium-sized academic library. We support the mission and goals of the university. Whatever we do with our catalog service has to reference that mission and those goals. What happens in public, private, or corporate settings must be contextual as well. All of which is one of the reasons I am less o!
f an adherent to the ease of use or transparency issue. I'm fine with the idea that our patrons (students and faculty) have to learn how to use tools to navigate the information universe and scholarly publishing. Why shouldn't they have to learn something in this regard? It's a messy environment [2], but at least in academe, it seems we alone are the area that apologizes for requiring learning from our patrons. Our geology profs certainly don't apologize; the require students to learn something. So I'm suggesting that our discussion should integrate with our missions and goals. First. And transparency of use, intuitiveness, etc., are characteristics to consider within that context.
Lastly, I think we should give ourselves some professional credit, or at least not bother flogging a non-existent dead horse. As a profession, we do adapt to change. If someone is resistant to my idea or suggested course of action, it doesn't mean that person is fearful of change. (It could be a lousy idea, or poorly phrased, or just one that no one else considers valuable. Resistance to change can be an issue.) On the whole, we are adaptive. We've spent about 15 years addressing electronic resources and access; this discussion list exists. You can argue we haven't adapted well, but it clouds the issue to assert that we haven't tried or that personality traits are a negative issue.
And that's about as far as I've gotten on this theme for now.
Daniel
_________________
Head of Cataloging
Central Washington University Brooks Library
400 E. University Way
Ellensburg, WA 98926-7548
dcc_at_cwu.edu
1. http://www.cwu.edu/~dcc/Cutters%20objectives%201904.pdf
2. http://www.sims.berkeley.edu/research/projects/how-much-info-2003/ [thanks to Stephen Paling]
http://hmi.ucsd.edu/pdf/HMI_2009_ConsumerReport_Dec9_2009.pdf [similar. A quote from exec summary: " In 2008, Americans consumed information for about 1.3 trillion hours, an average of almost 12 hours per day. Consumption totaled 3.6 zettabytes and 10,845 trillion words, corresponding to 100,500 words and 34 gigabytes for an average person on an average day. A zettabyte is 10 to the 21st power bytes ...]
Received on Tue Jun 29 2010 - 14:31:22 EDT