On 25/09/2012 18:16, Brenndorfer, Thomas wrote: <snip> > Currently, RDA authority records are undergoing such a change. Thousands of > records have already replaced existing AACR2 authority records, and many of > the new records have new RDA data fields that have all the hallmarks of > controlled vocabulary, with its promise of easier maintenance, flexible > display, and eventually searching and filtering. > > In a collaborative, shared environment, the opportunities exist for rapid > updating of data. > > This is happening right now. </snip>
I realize this, but it still doesn't let people know what role a specific person played in a specific resource. So, the authority record for Cory Doctorow may be updated with the 37x fields, but a search for Cory Doctorow *as an editor* would still not retrieve this record: http://www.worldcat.org/oclc/166368077 that is, until someone added the role information manually (or automatically in some kind of way) <snip> >> I have also never said that AACR2 shouldn't be changed. Of course it should. >> The problem is, there is still not >enough information to know how it should >> change. The FRBR structure seems obsolete to me, although yes, there a >few >> nice things, but modern faceted indexing has obviated any "need" to manually >> create the FRBR format >structures. > False. The core chapter on the FRBR structure, Chapter 17 in RDA, > acknowledges the opposite, that > > "Some encoding standards may not have a design that is suitable for recording > the primary relationships. In these cases, primary relationships are not > explicitly recorded though they may be inferred from other data elements in > composite descriptions." > There is a tremendous burden put on end-users in having to make inferences > about basic relationships found in cataloging data (and often added there at > great effort by catalogers, but in free-text form). Facets and other tools > using current data have not solved the problem. </snip> What I was discussing was the modern faceted *indexing* capabilities seen with Lucene-type technologies which allows for facets, and how that has obviated the need to manually create the FRBR format structures--if we are supposed to believe the stated purpose of FRBR: to let users do the FRBR user tasks, which they can now. When you state that facets and other tools have not solved the problem, that must be supported. First and foremost, it must be seen as a *real* problem among a significant percentage of the public and not only a theoretical issue. Plus, that it is a more important problem than other problems, e.g. adding new materials. Then, any solutions must also be possible in the real world of limited and diminishing resources, again, not only in a theoretical world of unlimited budgets and trained staff. Yes, if we had inherited something different, we could do other things. If I had inherited Berlusconi's wealth, I could become a great philanthropist and everybody would trip over themselves to say how wonderful of a person I am. But I won't inherit any of that. It would do no good crying over it but we all must use what we have in the best ways. Libraries have what they have. >> I still like Michael Gorman's idea of simplifying the rules to an absolute >> minimum and then allowing various >groups (maps, images, theology, law, >> Arabic and so on) to make additional rules for their own communities, >> thereby >modularizing the entire system. > There is nothing simpler or more modular than: > > * Entity -- has several attributes (which can be used for display, naming, > description, filtering, searching) > > * Entity can have relationship to other entities (which assists in exploring > similar resources-- by same author, on same subject, derived from work, part > of set, etc.) No. What I meant was to modularize the rules themselves. (By the way, this is my understanding of his idea) There would be separate bibliographic communities: law catalogers, theology catalogers, maps, images and so on. Of course, there are lots of these communities now with lots of their own guidelines. For instance, I created a manual for Slavic languages cataloging. Each community would be responsible for developing their own standards suitable to their own areas, but there would be a basic accepted standard that allows for a specific level of interoperability. I consider that *if* the rules were coded correctly (DocBook for example), stylesheets could merge them as you wished. So in theory, a cataloger who happened to be working on a video of an Arabic scholar discussing the law, the cataloger could in essence, merge everything together that would give him everything he needed in one nice place. A cataloging manual on videos of discussions of Arabic law. And it could be done on the fly. I understand how it works and can even build these tools, other I am not as good as others. As a result, I realize that what I theorized is a tremendously big *if* and the results would very possibly be completely incorrect or totally incomprehensible. Transferring the capabilities I just mentioned assumes you start from scratch and redo everything. With a single book or set of books as I postulate here, that may be achievable although much more difficult than it may sound, but doing anything similar with millions of catalog records created over the decades (or longer) designed for other purposes, is a task of radically different dimensions. -- *James Weinheimer* weinheimer.ji...@gmail.com *First Thus* http://catalogingmatters.blogspot.com/ *Cooperative Cataloging Rules* http://sites.google.com/site/opencatalogingrules/ *Cataloging Matters Podcasts* http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html
