tag:blogger.com,1999:blog-3338174527262061848.post6357408835254082587..comments2023-09-29T08:51:56.163-07:00Comments on Coyle's InFormation: Titles in Retail and Publisher DataKaren Coylehttp://www.blogger.com/profile/02519757456533839003noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-3338174527262061848.post-17862937947681754702007-12-27T22:19:00.000-08:002007-12-27T22:19:00.000-08:00The library catalog interface that did a good job ...The library catalog interface that did a good job of handling series data was the card catalog. Online catalog displays have a long way to go to be able to fulfill basic the basic functions of the catalog. <BR/>That is a minor point, however. The real point is that publishers and librarians conceive of titles and authors differently. The publishers can be satisfied with "good enough" because their files are small; librarians need to get things "right" or at least accurate because their files are so large. In order to make use of the publisher data, we need to be much more generous in the use of variant titlesa and to allow for matchings on spellings and titles that are close to what is on the book. This can be done by machine processing.<BR/>What cannot be done so easily by machine processing is actually matching item and bibliographic data and doing the intellectual work to identify authors (in whatever form those names are displayed). I am excited about using the ONIX data, but "useful use" will require not only careful programming but some human intervention for some time yet.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3338174527262061848.post-55189382682974309002007-12-04T09:08:00.000-08:002007-12-04T09:08:00.000-08:00So, to continue what Steve was saying, what catalo...So, to continue what Steve was saying, what catalogers need is not to change what they do, but how they display it? Stylesheets for MARC.<BR/><BR/>The problem is that if we continue to catalog the way we do (ie, ignoring the publisher-created metadata) we're always going to miss out on the efficacy of using publisher data. Does it matter that we catalog deeply when the users don't understand what we create, or don't see it?Melissahttps://www.blogger.com/profile/02857009116761816327noreply@blogger.comtag:blogger.com,1999:blog-3338174527262061848.post-50944730254557809012007-12-01T10:42:00.000-08:002007-12-01T10:42:00.000-08:00The first reason for non-matches above is interest...The first reason for non-matches above is interesting. It is obviously valuable to capture the semantic meaning of "series title," but it would seem to imply that you are actually going to do something with that relationship. <BR/><BR/>The most obvious thing to do would be to create a link out of the series name that, when clicked on, retrieves a list of all books that are part of the series. The data in the MARC record enables this and librarians seem to implicitly understand the value of coding this kind of relationship in our cataloging standard. However, I am not sure any library catalog interface provides such a simple, efficient and elegant display and user interaction opportunity out of such data. Instead we just change the way the title displays on a web page that may ironically break the connection to how it appears on work itself.<BR/><BR/>This seems to be one of the major reasons for why library description differs so much in practice from the business world's bibliographic description. We describe things to achieve a maximum *possibility* for understanding the semantics of the thing, but we stop there and do not necessarily realize all possibilities. The business world employs a description that is semantically poorer but they get maximum return on investment out of the data elements they do have. The user experience of the business's customer is far richer even though the bibliographic description offered to the library patron is far deeper.<BR/><BR/>The situation seems to be summed up by the distinction between "getting it right" (libraries) and "doing it well" (businesses). I think some of the other data you describe here also supports this subtle difference.Anonymousnoreply@blogger.com