Re: [RDA-L] Protesting RDA
Brenndorfer, Thomas wrote: snip Throughout the RDA text, the first choice listed for identifying entities or showing relationships is to use an identifier (such as a URI). This is followed by an authorized access point, and then in some areas, by textual descriptions. The reason for this is RDA's objective in supporting three scenarios: catalog card production, MARC catalogs that rely on linked headings, and object-oriented databases (http://www.rda-jsc.org/docs/5editor2.pdf). What is clear though is that access points are a permanent feature of the cataloging landscape-- they will always exist and are part of all three scenarios. The main difference is that relating entities in the future won't be dependent on the form of access points, which is a good idea considering how often they can change. For example, headings change with the addition of death dates, or when authors request that elements be removed (as I discovered recently for an author whose name was attached to many series headings and subject headings). In addition, the arrangement of RDA into elements that support attributes and relationships for entities is the basis of interest in the Linked Data community. There is a W3C Incubator Group discussing such issues now, and RDA is the game in town in support of these efforts (http://www.w3.org/2005/Incubator/lld/). In addition to promoting the use of identifiers for specific entities, all RDA elements (and a lot of controlled vocabulary) have registered URIs (http://metadataregistry.org/schema/list.html). 100 $q or Fuller Form of Name is a registered element http://RDVocab.info/ElementsGr2/fullerFormOfNamePerson /snip Thanks for pointing this out, but it still doesn't address the point I was trying to make: we should not pretend to ourselves that changing Elvis Presley's or Richard Wagner's authorized form, [or] in other words, changing one *textual string* into any other *textual string*, is any kind of a change at all. This is the sort of change that allows others to make fun of us and that gives cataloging and catalogers a bad name can anyone maintain with a straight face that the form Presley, Elvis (Elvis Aron), 1935-1977 instead of Presley, Elvis, 1935-1977 will make any kind of substantial and meaningful difference for our patrons If the purpose of RDA is to utilize URIs (which at the current rate may happen by the year 2050 if we are lucky), what is the purpose of going through the *huge task* of changing one textual string to another textual string? This makes absolutely no difference to our users (unless somebody out there can point to some fairly convincing research), while making an incredible amount of completely useless work for catalogers, when we could be doing work that is more productive. This is an example of what I have been mentioning of changes for theoretical purposes instead of practical purposes. Libraries and catalogs are facing some of the most serious challenges they have faced in a long, long time, and none of these challenges have anything to do with the *text of a heading* or in problems of *cataloging rules*. In other regards, such as how people are able to find those headings; what happens after they do find a heading, and so on, innovating in these areas would be the types of changes that could matter to our users, but yet we concentrate on the forms themselves. Even if we were to change the forms, we should aim in the directions that our users would like. I think we have some excellent evidence for their preferences in the disambiguation pages of Wikipedia--built by the users themselves, e.g. http://en.wikipedia.org/wiki/David_Johnson or http://en.wikipedia.org/wiki/IBM_%28disambiguation%29 or http://en.wikipedia.org/wiki/War_%28disambiguation%29, where the distinguishing factor isn't so reliant on dates, but on descriptive terms, e.g. for war: ... Write after read, a data hazard WAR (Sun file format) (Web application ARchive), a file format used to package Java applications KDE WAR (file format) (Web ARchive), a file format for storing a web page early versions of Decwar, a pioneering multi-user computer game ... I also prefer these types of forms, but they are not the directions RDA is leading us. I think it's time (and has been for quite awhile) for libraries and the catalogs to make some kind of big splash; to do something that will make people (i.e. our users) sit up and take notice. We have to do something that will make a difference to them. Many other organizations out there are focusing on making these big splashes right now, as we discuss. RDA has a few distant, theoretical, vague goals that are disputed in themselves, but we still should not delude ourselves that any of the changes they posit will make any difference to our users. If, by some miracle, URIs were actually implemented in our records within a mere 10 years or so (which would be the equivalent of light speed), I am
Re: [RDA-L] Form of names in RDA
Jim Weinheimer said on Autocat:
Throughout the RDA text, the first choice listed for identifying
entities or showing relationships is to use an identifier (such as a
URI).
This makes no difference whatsoever to the *form* of the entry. In
the late 1980s many Canadian libraries used UTLAS, which had an ASN
(authority sequence number) in access points, and the text of the
access point in authority records. It mattered not a whet where the
text resided, it was still text. All the objections Deborah raises to
RDA formulatons would still apply.
Subtitute URL for RSN and you have the same situation. In a future of
linked data (as in Canada in the 1980s) there will be libraries which
can not afford the biliographic utility with linked data, nor a local
ILS which will support such linked data. For such libraries, the
access point text will have to reside in the access point of the
individual record.
I'm told the complexity of this linked data structure was a factor
which led OCLC not to purchase UTLAS, when it ceased due to the small
customer base Canada afforded.
While with linked data, a change in text in the one location pointed
to by RSN or URL changes the text in the display of all records linked
to that authority record, not nearly all records in all catalogues
were/will be so linked. Not observing superimpostion, and not
continuing present forms of names as established, will produce chaos
in a time of declining budgets.
This is apart from the difficulty created by not being able to use
distinctive terms of address, which Deborah points out. Both principle
and its present application are flawed.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Web catalog
Quoting Weinheimer Jim j.weinhei...@aur.edu: Additionally, we look at the author page for Peter Temple and see the arrangement: http://www.austlit.edu.au/run?ex=ShowAgentagentId=Aja where we see the totality of his works. Again, the cataloger should try to imagine the underlying information and structure to create such a page. Actually, I don't think that the cataloger has to think about the resulting page, especially because the resulting page could differ greatly using the same catalog data. That's the big change that I see: that the catalog record is no longer the display form of the data, but is the underlying data that could result in any number of different displays. I think the cataloger needs to understand what data is needed/desired to describe and identify the thing being cataloged. I don't think this is terribly different from your intended meaning, Jim, but I did want to remove the page structure from the discussion. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Web catalog
I've been uploading some test records and it got me thinking about catalog displays. ILS OPACs usually displays catalog data in at least 2 different ways: in a results list (either one field in a browse list, or often a few chosen bits in a brief display), and in a record display, which may be broken into tabs with bibliographic information in one place and item information elsewhere. Institutions can choose to display all fields, suppress some, or change the order of display from tag number order to something else. That above the fold screen real estate is precious; what's most important to put up top? Should a long, scroll through page be replaced with mouse-over or other expansions? Should we sort the most important fields to the top, and let users scroll down for more? Cases that got me thinking - if the 245 title proper field with a parallel title in different languages doesn't begin with the title in our users' most likely preferred language (say, English), will users not click on the hit list item because they don't recognize it's what they searched for? If that turns out to be what happens, what can the cataloger do about this? With MARC and current system, not much! With the end of the rule of 3, bibliographic records could get longer - many more name entries - and this may push some OPAC displays out of shape. Do we leave out the access points because they don't fit the little box allocated for them? What do we need to enable us to give the users more findability and information, without giving them too much on one screen? If we could add an attribute that would allow us to specify which title is preferred when only one displays, that could be utilized to select one of the alternate titles to display in hit lists, but still retain the title proper for the full bibliographic display. If we could rank names, subjects, etc. by importance, knowing that our most important display is set up to show the top 5 and let the user expand to see the rest, would that be useful? But then I'm thinking further, that the right way to go about it is to abstract these kind of choices to a separate file. To do that, though, we would need a way to reference every field; guess that means identifiers for each instance of a tag or element, doesn't it? Laura Laura Akerman Technology and Metadata Librarian Room 128, Robert W. Woodruff Library Emory University, Atlanta, Ga. 30322 (404) 727-6888 lib...@emory.edu -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Karen Coyle Sent: Sunday, December 05, 2010 5:55 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Web catalog Quoting Weinheimer Jim j.weinhei...@aur.edu: Additionally, we look at the author page for Peter Temple and see the arrangement: http://www.austlit.edu.au/run?ex=ShowAgentagentId=Aja where we see the totality of his works. Again, the cataloger should try to imagine the underlying information and structure to create such a page. Actually, I don't think that the cataloger has to think about the resulting page, especially because the resulting page could differ greatly using the same catalog data. That's the big change that I see: that the catalog record is no longer the display form of the data, but is the underlying data that could result in any number of different displays. I think the cataloger needs to understand what data is needed/desired to describe and identify the thing being cataloged. I don't think this is terribly different from your intended meaning, Jim, but I did want to remove the page structure from the discussion. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet This e-mail message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message (including any attachments) is strictly prohibited. If you have received this message in error, please contact the sender by reply e-mail message and destroy all copies of the original message (including attachments).
Re: [RDA-L] Protesting RDA, utilize URIs in RDA
Am 05.12.2010 14:47, Jim Weinheimer wrote: If the purpose of RDA is to utilize URIs (which at the current rate may happen by the year 2050 if we are lucky), what is the purpose of going through the *huge task* of changing one textual string to another textual string? URIs, just like textual strings, are subject to change although not meant to be. Bare IdNumbers are a little better (and much shorter). In most cases, URIs are all alike, and the only difference is an IdNumber contained in them. So, why the trouble to store the entire URI with every record affected, when the number is all that is actually needed, and a changed URI most often differs not in the number but in some other part. For example: We might have 650 $u http://id.loc.gov/authorities/sh85090739 for the subject heading Neo-Kantianism. Now let's assume the Library of Congress is taken over by a Federal Information Company, and they then decide there needs to be a new URL structure to reflect progress, and make it http://uri.fedinc.info/subj/85090739 Then what? Change all the zillions of URIs we have accumulated. Is that a big improvement? Better: 650 $w lcsh:85090739 and then let presentation software (or web service routines) recognize the type of number and turn this into the valid URI of the month. One little change instead of zillions. Far-fetched? Well, our national library was renamed some time ago, and consequentially, all their URLs had to be changed, so as to be based on d-nb.de instead of ddb.de. Other urgent reasons, like political correctness, or technical issues (new protocol instead of http:) can surface any day. I mean, we've known it long enough: URLs are not forever, URIs neither, let's not put money on them. Of course, nothing's forever. By 2050, one will have found reasons why the LCSH numbers are terribly dysfunctional and all of them need to be changed ... to the verbal string - which is, after all, human-readable. And hasn't WikiPedia done that from the beginning? B.Eversberg
