Not to detract from Karen's statement, but "etc." and "other" do mean something -- that the category encompasses things besides those explicitly identified that, while of a similar nature, are too obscure or insufficiently fleshed out to warrant the intellectual effort to label, identify, or categorize further.
The challenge is that, while humans can live with this degree of ambiguity and inexactness, machines and machine processing can't. Every exception of this type would require programming a "bail out" mechanism for the software to identify it, and a "bail out" action for the software to treat it. I strongly suspect that the coding occurrences for handling such exceptions would grow geometrically or exponentially with the number of exceptions to be addressed. And as Karen identifies, the value of these "etc." and "other" labels would be nil in the information sense -- one would know that they are exceptions or special cases, but have no further information as to the nature of the exception/special case or how it relates to other exceptions/special cases. (And I readily admit this is going to be one of the hardest things for me in adapting to the programmatic vision of machine handling of our data, because my life and thought processes are full of these little "other" categories.) John F. Myers, Catalog Librarian Schaffer Library, Union College 807 Union St. Schenectady NY 12308 518-388-6623 [email protected] -----Original Message----- Karen Coyle wrote: "etc." needs to go away with its partner "other" (heavily used in MARC vocabularies, not in RDA). Neither of these imparts any information nor does it provide a way to expand a list as needed.
