Hi, Thomas, James, and all: Thanks a billion again for the brilliant discussions that you shared to the list.
I agreed with Thomas at the highest level of abstraction it is as simple as entity, attribute, and relationship. To make it extensible, we need to add scheme to let apps and people know which vocabulary it comes from. To make it categorically friendly, we add classification scheme. To make it discover-able, we add URI, etc. As far as I am concerned, to make Geo-code, postal code, etc. linked to NARs if in USMARC Authority, we just need to add GeoName record identifier. For instance, the geographic name heading for Perth (W.A.) has LCCN permanent link http://lccn.loc.gov/n79011231, whose geographic coordinates are designated in 034 field. All we need to do is to add subfield $0 to 034 field with $2 geonames. If so, the 034 field in USMARC for authority will be like the following: ... 034 ##$d E1154960 $eE1154960 $fS0315560 $gS0315560 $0 (GeoNameId)2063523$2 geonames ... 043 ##$a u-at-we 151 ##$a Perth (W.A.) ... 670 ##$a GeoNames, algorithmically matched, 2009 $b(...) 670 ##$a GeoNameId, geo-location map identifier matched from geonames.org, 2012$b (GeoNameId:2063523) 883 0#$81\p$82\p$uhttp://www.geonames.org/2063523/perth.html $c0.80$d20120926$qGeoNames.org$0(GeoNameId)2063523 ... For more info, please check the following: http://www.geonames.org/2063523/perth.html http://www.loc.gov/marc/authority/ad034.html http://www.loc.gov/marc/authority/ad883.html OCLC WorldCat registry and its related Knowledge bases are the ideal place to register web service updates from geonames.org. I would hope that LC NARs, and others would subscribe to the OCLC web service updates, and have the option to handle the updates synchronously and asynchronously. Thanks again! On Wed, Sep 26, 2012 at 6:41 AM, James Weinheimer < weinheimer.ji...@gmail.com> wrote: > 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 > -- Amanda Xu Apprentice to Information Artistry & IT Librarian for Collection Management Still In Progress P.O. Box 650295 Fresh Meadows, NY 11365 axu...@gmail.com (personal email)
