Re: [ACAT] Is MARC a dead end?

Posting to Autocat

On 05/07/2011 11:07 AM, Hal Cain wrote:

<snip>
On Fri, 6 May 2011 23:06:44 -0400, Jjagenbroad@AOL.COM wrote:

Do we need new filing rules? Maybe if they help catalog users find what they want among Washington,George, W. DC, W. Penn. W. (State), W. Court House, Ohio, G.W. Carver, W. Roebling, etc. Maybe not if they don’t.”

We’ve survived without them, but a routine that read subfield values in 6XX subdivisions, and gave us at least the option of a display organized to group each type of subdivision together, would be worth having.
</snip>

I think we need to change our focus on these sorts of matters: for example, in other posts was suggested that we could change our thinking from “Latin abbreviations” to “text that has been input consistently for a long time”, or to separate the MARC format coding from the ISO2709 format. In  this case, instead of “filing rules” we need to think in terms of “sorting”.

When was the last time you really browsed through an alphabetical arrangement in a computerized database–other than in a library catalog? Even the disambiguation page of Wikipedia is not in any (apparent) alphabetical order, e.g. http://en.wikipedia.org/wiki/John_Johnson.

Filing rules were always too complicated for patrons anyway, and they needed help (and rarely asked) whenever anything got just a little complicated. A lot of the reason was that there was only one way to arrange the cards. With computers, there is the power to allow multiple arrangements however, and I believe we should use these powers far more than we do now. For example, I like Hal’s suggestion to work with subdivisions of 6xx; perhaps they would be good candidates for tag clouds. I don’t know if anyone has done anything with those or not.

But in any case, I think cataloging needs a completely fresh perspective, as I touched on in my latest podcast on standards, where I suggested that our rules focus on minimums and not so much on the  attempt to create a single type of product. That attempt was never all that efficient to begin with, and I think cannot be continued in our current environment.

-391

Share