Re: [RDA-L] Cataloging Matters No. 16
On 9/21/12 1:13 AM, James Weinheimer wrote: This is very interesting, but how will it work in the real world? Let's assume that this has all been done with an acceptable percentage of the records: 60%? 70%? 80%? You are working as a reference librarian and a senior faculty member on the library committee of your institution comes up to you and explains that he or she is writing an article and needs a list of the movies directed by Clint Eastwood. (Yes, the faculty member would have this information in other ways, but I am positing a reference question, and variations of this kind of question come up all the time). We also assume the reference librarian fully understands the issues in the catalog and knows that it will be 20%, 30% or 40% wrong. Why on earth, when the question is a list of the movies directed by Clint Eastwood would any reference librarian point to the catalog?! The catalog is an inventory of the items owned by the library, not an encyclopedia. Any decent reference librarian knows that, and I suspect that most users, while they may not know that consciously, act as if that were the case. You go to IMDB, you go to Wikipedia, you find the official Clint Eastwood site online. This reference question has nothing to do with library ownership. Which is why the library catalog is NOT the first place that users go for information -- it's where they go to find out if the library has a particular item and if it is available. So the real scenario should be: Faculty member wants list of CE movies. Goes to IMDB/Wikipedia/web site. Finds list there. In perfect world, similar to how OpenURL works today, browser would show faculty member which items in that list are available at the library. Thus faculty member gets 1) needed information 2) link to library holdings, all in one place. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Cataloging Matters No. 16
JOnathan, as you say, the catalog can only answer the question: list of movies directed by CE OWNED BY THE LIBRARY. That wasn't the questioned posed, and I answered the question as posed. Obviously, if the user is only interested in those held by the library, the library catalog is the appropriate place. I don't know why you changed the question as a way to question my answer. I hardly believe that my answer was not credible or understandable. kc On 9/21/12 11:01 AM, Jonathan Rochkind wrote: Why on earth, when the question is a list of the movies directed by Clint Eastwood would any reference librarian point to the catalog?! There is only one answer to this: Because someone wants a list of movies directed by Clint Eastwood that are held by the library, that she can go check out and watch today. Exact same reason you'd point to the catalog to find out a list of books written by Mark Twain, isn't it? If you don't care if the library holds them or not, in 2012 there are better places to get a list of books written by Mark Twain than a library catalog, no? I don't see any difference here between list of books written by Mark Twain and list of movies directed by Clint Eastwood. Would you suggest there's no reason for the catalog to be able to answer list of books written by X either? -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Cataloging Matters No. 16
Yes, Jonathan, relator codes matter. kc On 9/21/12 11:40 AM, Jonathan Rochkind wrote: I wasn't trying to change the question, I agree that library catalog is only the place to answer the question if you are interested in library holdings. But if the library catalog can't identify which records in it represent movies directed by Clint Eastwood, then the library catalog can't answer the question of movies directed by clint eastwood owned by the library, right? Which is why relator codes matter, which is what we're discussing, I think? directed by X is not fundamentally different than written by X here, right? Perhaps it won't in the future be important for the catalog to answer the question Books written by Mark Twain either, if sufficient integration with other parts of the web is achieved -- you'd find out books written by Mark Twain in some other place, and then find out which of those are held by the library. Perhaps. But in the present, library catalogs need to answer Books written by Mark Twain (from amongst those records in the catalog), because users need to find books written by Mark Twain that are held by the library. (Or in the case of worldcat, held by 'some library', or 'a nearby library') perhaps. I don't think anyone expects the library catalog to give you a list of ALL books written by Mark Twain, whether the library holds them or not (well, some users might errantly expect this) -- nonetheless, it is important for the library catalog to give you a list of books written by Mark Twain from within the catalog. I think the same applies to movies directed by X, no? That's what I was suggesting, sorry if I didn't say it right, if we're still not communicating after my attempt at clarifying, I guess that's just how it will be! From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Karen Coyle [li...@kcoyle.net] Sent: Friday, September 21, 2012 2:04 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Cataloging Matters No. 16 JOnathan, as you say, the catalog can only answer the question: list of movies directed by CE OWNED BY THE LIBRARY. That wasn't the questioned posed, and I answered the question as posed. Obviously, if the user is only interested in those held by the library, the library catalog is the appropriate place. I don't know why you changed the question as a way to question my answer. I hardly believe that my answer was not credible or understandable. kc On 9/21/12 11:01 AM, Jonathan Rochkind wrote: Why on earth, when the question is a list of the movies directed by Clint Eastwood would any reference librarian point to the catalog?! There is only one answer to this: Because someone wants a list of movies directed by Clint Eastwood that are held by the library, that she can go check out and watch today. Exact same reason you'd point to the catalog to find out a list of books written by Mark Twain, isn't it? If you don't care if the library holds them or not, in 2012 there are better places to get a list of books written by Mark Twain than a library catalog, no? I don't see any difference here between list of books written by Mark Twain and list of movies directed by Clint Eastwood. Would you suggest there's no reason for the catalog to be able to answer list of books written by X either? -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Cataloging Matters No. 16
On Wed, Sep 19, 2012 at 7:14 PM, J. McRee Elrod m...@slc.bc.ca wrote: Karen Coyle said: No role in the 100 almost always means author. Not in our database. We have criminal defendants (our earlier client base was heavily law firms), artists (early clients included art schools), composers (we do quite a few music CDs). Some clever programming might handle composer. Right. I was thinking of texts, of course. The primary 100 role will vary by record type (MARC record type, that is). But I find it interesting that for so many of you (and I refer here to others who replied) that you are more motivated to declare change impossible than to think about ways to make possible changes. That's not only self-defeating, that is library-defeating. You seem to prefer to go down with the ship than steer toward shore. In fact, I'm pretty much done having this discussion because there is no progress to be made when talking to the profession of no, where every answer to every suggestion is no rather than Well, not quite but you could ALSO do No suggestions, no options, no dialog. It's a dead end. In contrast, there are lists where if I had made that suggestion someone would have come back with a complete list of types and possible algorithms to get the best results. Why anyone would prefer the worst results than the best is absolutely beyond me. If the futurists are correct, relocalization will be required in the life time of some of us, when we can no longer afford the cloud or long distance food transport. Fossil fuels are a finite resource, and much of what we do depends on them. Local hosting of bibliographic records may be more possible than linked data. Computer storage space is becoming less expensive. It's not about storage space, it's about being able to make changes like this efficiently. But because you (and that's a plural) are opposed to all change, that's not a concern you have. kc -- -- --- Karen Coyle / Digital Library Consultant kco...@kcoyle.net http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet mo.: 510-435-8234
Re: [RDA-L] Cataloging Matters No. 16
Kelley, thanks. My gut feeling is that music and moving picture cataloging have some very interesting use cases that could show some real benefit from roles. I admit that when I need movie information (usually for my gaps when doing the NYT crossword puzzle) I turn to ISBD, which lists the different roles separately on its pages: http://www.imdb.com/name/nm142/(Clint Eastwood, who has a great variety of roles.) Freebase does something similar but seems to have less data to work with: http://www.freebase.com/view/en/clint_eastwood#film I think this arrangement may at times be more helpful than, for example, listing the works in date order with an intermingling of roles. But, as many have said here, one size will not fit all, so it would be nice to be able to do a variety of displays around different organization schemes. kc On 9/20/12 3:07 PM, Kelley McGrath wrote: On Thu, Sep 20, 2012 at 7:55 AM, Karen Coyle kcoyle...@gmail.com wrote: But I find it interesting that for so many of you (and I refer here to others who replied) that you are more motivated to declare change impossible than to think about ways to make possible changes. ** I sometimes wonder what the silent majority on lists thinks. There are definitely people interested in trying to insert this kind of data into existing records. Many moving image (and music) catalogers are very interested in relator terms and codes because our materials include people performing many different kinds of roles and users want to know who is doing what. This doesn't mean just when they're looking at a single record. They might want a list of the movies directed by Clint Eastwood or the directors of recent French comedies or they might want to slice and dice the data some other way. I am involved in a project that is trying, among other things, to retrospectively add role information to authorized names in records for moving image materials. We have an article in the Code4Lib Journal about our preliminary test, which including figuring out which 700(s), if any, were for the director: http://journal.code4lib.org/articles/775. I also did a presentation at ALA in June about our current work to do this in a more sustainable, scalable way: http://pages.uoregon.edu/kelleym/publications/CCIRG_FRBRinMARC_DatainText.pdf or http://goo.gl/pFvFV. It's not a trivial problem and we can't get 100%, but we can do far better than 0%. My goal is to convert what we can to a machine-actionable form, identify and fix erroneously-converted info where practical, triage the rest and move forward. There is other interesting work with trying to extract more info and value from existing data. For example, there's a fascinating article about OCLC's GLIMIR project in the most recent Code4Lib Journal: http://journal.code4lib.org/articles/6812. Kelley ** Kelley McGrath Metadata Management Librarian University of Oregon Libraries 1299 University of Oregon Eugene, OR 97403 541-346-8232 kell...@uoregon.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Cataloging Matters No. 16
Two comments: 1) some of these can be added, albeit not perfectly, using automated processing. If a 245 $c says: illustrated by Joe Blow and there's an added entry for Blow, Joe, then the role can be added. No role in the 100 almost always means author. 2) one of the main arguments for cloud computing is that there is a fair amount of wasted space/time/effort in having copies of bibliographic records in the many tens of thousands of library catalogs. If we had a catalog cloud then this information would only be needed to be added once per manifestation, not once per every copy of every manifestation in every catalog. This is the direction that OCLC is going in, but it could also be done with different technology (that is, not necessarily WorldCat as we know it today). kc On Wed, Sep 19, 2012 at 12:11 PM, Jack Wu j...@franciscan.edu wrote: I don't know what others have gotten out of this long but interesting podcast. As for myself, I certainly see the logic of James' argument. Does it not follow then, RDA things like relator codes, 33x fields cannot be used to advantage until they are first retrospectively added to all legacy records that lack these, and that can be a huge problem. I'm just glad there will be a unified authority file and conversion of bib. headings is more machine actionable. Jack Jack Wu Franciscan University James Weinheimer weinheimer.ji...@gmail.com 9/17/2012 7:12 AM All, For those who are interested, I have just made a new Catalog Matters podcast. This one is number 16 about Consistency, Catalogs and the Future. -- 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 Scanned by for virus, malware and spam by SCM appliance -- -- --- Karen Coyle / Digital Library Consultant kco...@kcoyle.net http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet mo.: 510-435-8234
Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions
On 8/23/12 10:43 AM, James Weinheimer wrote: Still the basic idea still is worth a try (I think), where embedded metadata would be linked to separate metadata records in catalogs and spiders would keep the two in sync. I believe the technology is called microformats,[1] with the primary one today being schema.org. This is also the basis for the linked data that is now included in each Worldcat page. kc [1] http://en.wikipedia.org/wiki/Microformats But novel ideas are needed more than ever, I think that is becoming clear enough to all. -- *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 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Order of 040 subfields
Carolyn, Don't demean your knowledge of linked data. The message is actually quite simple, which is that there is a need similar to that of MARC records to be able to say who created the data so that you can estimate the authoritativeness of the data. Whether or not the 040 will figure in this in some Semantic Web future is still unknown. And the complexity of who created a particular bibliographic description is as complex in that future as it is in the MARC environment today. My guess is that getting a straight answer out of existing 040 fields will be difficult, at best. I, for one, am much less confident than Gordon that the 040 will prove to be the answer, since we know that many local systems ignore the field. But we'll have to wait and see. kc On 8/20/12 7:31 AM, Kadri, Carolyn J wrote: I stand corrected. Actually, I don't speak MARC21 schema for linked data and Semantic Web applications, so, I spoke out of ignorance of the full potential impact for metadata applications. I appreciate the informative link Gordon sent out. I have been trying to develop a basic understanding of what is meant by the Semantic Web, etc., and the website was useful although having read about the 040, it was unclear to me if the effect of order in the 040 is a real problem or not. So my apologies to my colleagues for speaking out without understanding the big picture. Carolyn Kadri Head Cataloger Special Collections University of Texas at Arlington Arlington, TX 76019 * -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of gor...@gordondunsire.com Sent: Monday, August 20, 2012 8:38 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Order of 040 subfields It also matters when it comes to semantic analysis of the MARC21 schema for linked data and Semantic Web applications. See the last paragraph of my blog post: http://managemetadata.com/blog/2012/06/07/by-passing-taggregations/ It matters even more when the provenance of the billions of data triples derived from existing MARC21 records is needed to distinguish them from metadata generated by end-users and machines, which will be orders of magnitude higher in number. Cheers Gordon On 20 August 2012 at 14:26 Mike Tribby mike.tri...@quality-books.com wrote: I have been following this thread about the 040. Does it really matter what order the subfields are placed in in the 040 in an online environment? It matters greatly (at least theoretically) to those who enjoy assigning blame to specific cataloging agencies for what they perceive to be bad cataloging. It's a bad tool for doing that, but righteous sentiment about avenging cataloging errors seems to overwhelm that. Mike Tribby Senior Cataloger Quality Books Inc. The Best of America's Independent Presses mailto:mike.tri...@quality-books.com -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions
John, thanks for being our ears on the ground. I think that we have to be careful about how we define use ISBD, and I had trouble posing that question originally. I think the key question is whether people use the ISBD documentation AS THEIR CATALOGING RULES, or whether they have local catalong rules that are designed to be compatible with ISBD. I don't know if you would consider AACR2 and RDA to be conformant with ISBD (I don't know any of them well enough to make that determination.) My question was intended to be the former: that people actually catalog from the ISBD rules as issued by IFLA. Then we get into Ed's question: is that all? Or do they supplement ISBD with headings for authors and subjects, etc.? And I have yet another question, which is: have they developed a data format that represents ISBD for this purpose? (If so, I'd like to see it.) It does appear that the Finnish library works very closely to ISBD and I have sent them a few extra questions (and I should apologize for taking their time in the midst of IFLA!). Thanks again, kc On 8/15/12 1:32 PM, John Hostage wrote: Ed, I'm sorry, we didn't get into that question. The group is planning an international survey to find out who uses the ISBD, so I'll suggest that they include that question in the survey. John -- John Hostage Authorities and Database Integrity Librarian Langdell Hall Harvard Law School Library Cambridge, MA 02138 host...@law.harvard.edu mailto:host...@law.harvard.edu +(1)(617) 495-3974 (voice) +(1)(617) 496-4409 (fax) http://www.law.harvard.edu/library/ *From:* Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Ed Jones [ejo...@nu.edu] *Sent:* Wednesday, August 15, 2012 15:46 *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions John If these countries use ISBD, they presumably use it in place of locally elaborated rules for bibliographic description (corresponding to AACR2 part 1). What do they do for choice and form of access points (corresponding to AACR2 part 2), where no comprehensive international standard exists? Ed Ed Jones Associate Director, Assessment and Technical Services National University Library 9393 Lightwave Avenue San Diego, California 92123-1447 +1 858 541 7920 (voice) +1 858 541 7997 (fax) http://national.academia.edu/EdJones *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *John Hostage *Sent:* Wednesday, August 15, 2012 12:30 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions I'm at the IFLA conference in Helsinki, so I put this question to the ISBD Review Group. The responses indicated that the ISBD is used as the cataloging code here in Finland. See, for example, this report on the National Metadata Repository (http://www.nationallibrary.fi/libraries/projects/metadatarepository.html) under Subprojects. In Slovenia, the ISBD will be used for cataloging once a translation of the consolidated edition has been completed. In many countries, the adoption of any cataloging rules depends on the availability of a translation into the local language. Because the ISBD covers description only, a translation is sometimes incorporated into a national code that includes headings. The group had trouble understanding how the question was meant because of these complications. Multiple translations of the preliminary consolidated edition are listed at http://www.ifla.org/publications/translations-of-isbd A couple of translations of the consolidated edition of 2011 are listed at http://www.ifla.org/en/publications/international-standard-bibliographic-description and more are in preparation. A document showing full ISBD examples using various languages of cataloging is also available on that page. Russia uses the ISBD for cataloging, but not the new area 0. Italy's new cataloging code REICAT was based on the ISBD, but does not include area 0. -- John Hostage Authorities and Database Integrity Librarian Langdell Hall Harvard Law School Library Cambridge, MA 02138 host...@law.harvard.edu mailto:host...@law.harvard.edu +(1)(617) 495-3974 (voice) +(1)(617) 496-4409 (fax) http://www.law.harvard.edu/library/ From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Karen Coyle [li...@kcoyle.net] Sent: Sunday, August 12, 2012 19:43 To: RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions Thanks, Judy. But now I have to ask an ignorant (but perhaps not stupid) question
Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions
Thanks, Judy. But now I have to ask an ignorant (but perhaps not stupid) question: are the libraries that catalog directly in ISBD? I've seen cataloging rules that incorporate ISBD concepts, but I haven't ever encountered a library where ISBD is their cataloging rules. I'm wondering what the resulting records might look like. kc On 8/12/12 2:32 PM, JSC Secretary wrote: An announcement about the 2011 JSC, ISBD, and ISSN harmonization discussions has been posted on the JSC web site with an indication that some topics will be addressed at the November 2012 JSC meeting. http://www.rda-jsc.org/2011jscisbdissnoutcomes.html Regards, Judy Kuhagen JSC Secretary -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] JSC, ISBD, and ISSN: harmonization discussions
Oops, that was are *there* libraries... On 8/12/12 4:43 PM, Karen Coyle wrote: Thanks, Judy. But now I have to ask an ignorant (but perhaps not stupid) question: are the libraries that catalog directly in ISBD? I've seen cataloging rules that incorporate ISBD concepts, but I haven't ever encountered a library where ISBD is their cataloging rules. I'm wondering what the resulting records might look like. kc On 8/12/12 2:32 PM, JSC Secretary wrote: An announcement about the 2011 JSC, ISBD, and ISSN harmonization discussions has been posted on the JSC web site with an indication that some topics will be addressed at the November 2012 JSC meeting. http://www.rda-jsc.org/2011jscisbdissnoutcomes.html Regards, Judy Kuhagen JSC Secretary -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Fw: What Goes into the 1xx Field?
) in a statement of responsibility? What about editors? RDA in 19.2.1.1 identifies editors as potential creators. How might this affect what goes into a 100 field? Mac Elrod has kindly shared his cheat sheets with us that address this issue. In them, he seems to support the concept of using the 700 and 710 fields more frequently for main entry personal and corporate names while setting the first indicator in the 245 at 0. (Please let me know if I'm misinterpreting this.) Is this what others plan to do? Cordially, Marjorie Marjorie E. Bloss, Adjunct Faculty Dominican UniversityGraduate School of Library and Information Science 7900 W. Division St. River Forest, IL 60305 USA 1-773-878-4008 1-773-519-4009 (mobile) -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Fw: What Goes into the 1xx Field?
Nope, even repeatable 1xx's have an order problem. kc On 7/31/12 9:16 AM, Marjorie Bloss wrote: Or, if order of the MARC fields is a concern, maybe another variation on the theme would be to make the 1xx fields repeatable? (And of course, expand the definition and description of those fields.) Just a thought... Marjorie Marjorie E. Bloss, Adjunct Faculty Dominican University Graduate School of Library and Information Science 7900 W. Division St. River Forest, IL 60305 USA 1-773-878-4008 1-773-519-4009 (mobile) - Original Message - *From:* Karen Coyle mailto:li...@kcoyle.net *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Sent:* Tuesday, July 31, 2012 9:45 AM *Subject:* Re: [RDA-L] Fw: What Goes into the 1xx Field? I second Marjorie's thanks to Bob for his well-thought-out comments. One possible approach to making decisions about how to encode RDA in MARC could be to look forward to the time that the data that is today in MARC will need to be transferred to an RDA-friendly format. Using this example, RDA makes mention of a first creator (as per comments here, not my own reading of RDA) -- if all creators are coded as 7xx, will that adequately retain the order? Given that some systems do not preserve the order of MARC fields, one could conclude that the 1xx fields for creators will be essential to that future transformation. I personally would like to see some mock-ups of RDA records that do not use MARC. I have in mind to do a few examples using the RDA elements, but I don't know enough to bring in the interesting cases that would illustrate the full scope of the rules. I was planning on using a few examples from the training materials, and code them (with code being used very loosely) in the three RDA scenarios. They'll probably be diagrams like those scenarios. Maybe with something like that before us, those of you who catalog could provide examples that would be better illustrations? kc On 7/30/12 7:00 PM, Marjorie Bloss wrote: My thanks for Bob's and others' thoughtful comments regarding my question about what goes into the 1xx field when using RDA. You support what I've instinctively been doing but was uncertain as to where to turn for the specific RDA instruction. This is where RDA 18.3 is particularly useful. Bob articulated my concerns about disconnects between MARC and RDA with regard to the 1xx and 240 fields so much better than I did. AACR2 and MARC grew up together so it's no big surprise that MARC is so AACR2-centric. MARBI has worked long and hard, bringing MARC in line with RDA but it's a complex process and the pieces don't always fit together cleanly. During the testing of RDA, the Dominican students participating in the test seriously considered not using the 1xx fields at all but 7xx fields instead in order to bring the test records more in line with the concepts found in RDA (that is, not designating any one person, family, or corporate body as the main entry). In the end, we didn't do this but it did tickle the backs of our minds. I suspect we are going to have to wait until there is a replacement for MARC before an authorized access point is an authorized access point is an authorized access point and we no longer identify one of them as the main entry. The tickle in the back of my mind about using only the 7xx fields for persons, family, or corporate body access points when creating RDA records is inching closer to the front of my mind, however. Thank you again. Cordially, Marjorie Marjorie E. Bloss, Adjunct Faculty Dominican University Graduate School of Library and Information Science 7900 W. Division St. River Forest, IL 60305 USA 1-773-878-4008 1-773-519-4009 (mobile) - Original Message - *From:* Robert Maxwell mailto:robert_maxw...@byu.edu *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Sent:* Monday, July 30, 2012 11:31 AM *Subject:* Re: [RDA-L] Fw: What Goes into the 1xx Field? I agree with the spirit of Marjorie's question, especially the part about keeping one foot on either side of the fence. It is true that we have had no official word on continued use of 1XX fields, by which I mean the MARC 21 Format for Bibliographic Data http://www.loc.gov/marc/bibliographic/ecbdhome.html instructions for 1XX have not been revised to take RDA into account. (There have been plenty of training materials prepared making use of 1XX.) But the MARC formats still refer to 1XX as main entry fields, which, as Marjorie points out, is not appropriate in an RDA context. Since AACR2 is still being used in bibliographic records
Re: [RDA-L] Fw: [RDA-L] Fw: What Goes into the 1xx Field?
Marjorie, Interestingly, there is an indicator available for the 100/110 but not the 700/710, so if we think we'll be using MARC for many years, an indicator might be indicated (sorry :-)). kc On 7/31/12 11:46 AM, Marjorie Bloss wrote: Hi, Karen. In response to what you wrote, might there be a way of handling order through the indicators? However, I think I'm just going to let this drop. It's a band-aid approach which ever way you look at it and I don't really feel it's worth the energy. Hopefully, LC is making good progress on a MARC replacement which will solve the problem. Hope all is well. Cordially, Marjorie Marjorie E. Bloss 2827 West Gregory Street Chicago, IL 60625 USA 1-773-878-4008 1-773-519-4009 (mobile) - Original Message - *From:* Karen Coyle mailto:li...@kcoyle.net *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Sent:* Tuesday, July 31, 2012 1:13 PM *Subject:* Re: [RDA-L] Fw: What Goes into the 1xx Field? Nope, even repeatable 1xx's have an order problem. kc On 7/31/12 9:16 AM, Marjorie Bloss wrote: Or, if order of the MARC fields is a concern, maybe another variation on the theme would be to make the 1xx fields repeatable? (And of course, expand the definition and description of those fields.) Just a thought... Marjorie Marjorie E. Bloss, Adjunct Faculty Dominican University Graduate School of Library and Information Science 7900 W. Division St. River Forest, IL 60305 USA 1-773-878-4008 1-773-519-4009 (mobile) - Original Message - *From:* Karen Coyle mailto:li...@kcoyle.net *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Sent:* Tuesday, July 31, 2012 9:45 AM *Subject:* Re: [RDA-L] Fw: What Goes into the 1xx Field? I second Marjorie's thanks to Bob for his well-thought-out comments. One possible approach to making decisions about how to encode RDA in MARC could be to look forward to the time that the data that is today in MARC will need to be transferred to an RDA-friendly format. Using this example, RDA makes mention of a first creator (as per comments here, not my own reading of RDA) -- if all creators are coded as 7xx, will that adequately retain the order? Given that some systems do not preserve the order of MARC fields, one could conclude that the 1xx fields for creators will be essential to that future transformation. I personally would like to see some mock-ups of RDA records that do not use MARC. I have in mind to do a few examples using the RDA elements, but I don't know enough to bring in the interesting cases that would illustrate the full scope of the rules. I was planning on using a few examples from the training materials, and code them (with code being used very loosely) in the three RDA scenarios. They'll probably be diagrams like those scenarios. Maybe with something like that before us, those of you who catalog could provide examples that would be better illustrations? kc On 7/30/12 7:00 PM, Marjorie Bloss wrote: My thanks for Bob's and others' thoughtful comments regarding my question about what goes into the 1xx field when using RDA. You support what I've instinctively been doing but was uncertain as to where to turn for the specific RDA instruction. This is where RDA 18.3 is particularly useful. Bob articulated my concerns about disconnects between MARC and RDA with regard to the 1xx and 240 fields so much better than I did. AACR2 and MARC grew up together so it's no big surprise that MARC is so AACR2-centric. MARBI has worked long and hard, bringing MARC in line with RDA but it's a complex process and the pieces don't always fit together cleanly. During the testing of RDA, the Dominican students participating in the test seriously considered not using the 1xx fields at all but 7xx fields instead in order to bring the test records more in line with the concepts found in RDA (that is, not designating any one person, family, or corporate body as the main entry). In the end, we didn't do this but it did tickle the backs of our minds. I suspect we are going to have to wait until there is a replacement for MARC before an authorized access point is an authorized access point is an authorized access point and we no longer identify one of them as the main entry. The tickle in the back of my mind about using only the 7xx fields for persons, family, or corporate body access points when creating RDA records is inching closer to the front of my mind, however. Thank you again. Cordially, Marjorie Marjorie E. Bloss, Adjunct Faculty Dominican University Graduate School of Library and Information Science 7900 W. Division St. River Forest, IL 60305 USA 1-773-878-4008 1-773-519-4009 (mobile) - Original Message
Re: [RDA-L] Additions to the JSC web site: July 28, 2012
On 7/28/12 5:21 AM, JSC Secretary wrote: 6JSC/ALA/11Revision of RDA 2.11.1.3 (Recording Copyright Dates) The current text reads: If the resource has multiple copyright dates that apply to various aspects (e.g., text, sound, graphics), record only the latest copyright date. This revision would create an exception for sound recordings. My question: is there any reason to limit non-sound recordings to only one copyright date? I can imagine situations where one would want to record more than one date, for example in some significant combinations of text and art, or in other multi-media works. It seems restrictive to pre-determine which copyright date(s) should be recorded, since circumstances can change. It may make sense to allow for the recording of only the latest -- something like If only one is to be recorded, record only the latest, but to allow for recording more than one. I realize this would mean that one needs to also record what aspect of the item the copyright date belongs to, but presumably if multiple aspects are significant they will have been recorded as media (text; illustrations). What I see here is a bit of an assumption about the structure of the data -- because I can imagine a structure that doesn't look like the MARC 260 field + 300 field where recording multiple copyright dates would make sense: [identifier for the Manifestation] publisher: Jones, Inc. dateOfManifestation: 2012 placeOfPublication: New York mediaType:text -- (c) 1823 mediaType:illustrations -- (c) 2011 I find it generally awkward in RDA that the Media Types and the information related to the media are not connected to each other. Actually, I'm not sure this is an aspect of RDA or if it is only an aspect of RDA in MARC, but in general I would expect a data design to associate descriptive elements with the things it describes. If RDA is format neutral, it should allow for this. kc 6JSC/ALA/12Revision of RDA 6.15.1.3 (Recording Medium of Performance) 6JSC/ALA/13Revision of RDA instructions relating to librettos and lyrics for musical works (RDA 6.2.2.10.2, 6.27.4.2, Appendix I.2.1, and Glossary) 6JSC/ALA/14Revision of RDA instructions for arrangements and adaptations of musical works (RDA 6.28.1.5.2 and 6.28.3.2.2) Regards, Judy Kuhagen JSC Secretary -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA and subject access
I think some of this discussion is based on a mis-interpretation of my question. My question had to do with the definition of RDA data elements [1] to represent the relationship between works and subjects. Chapter 5 of the FRBR document presents the relationships between FRBR entities. Many of these relationships are included in RDA, such as the work-to-work relationships Successor and Adaptation. These relationships can be found in appendices I, J, and K of RDA. The appendix where subject relationships would be defined was deferred to later. None of this says anything about what subject vocabularies one would use nor how subjects would be formulated. It will be necessary to create data elements for such relationships between subject and work, or to use ones that already exist in models like FRBR, as part of the development of a new bibliographic framework for RDA. I suspect that most people aren't terribly familiar with the relationships in the appendices because this is the aspect of RDA that could not be coded in MARC, and that has therefore been relegated to a future data format. kc [1] I'm calling data elements the elements defined originally in http://www.rda-jsc.org/docs/5rda-elementanalysisrev3.pdf and now encoded for us at http://rdvocab.org/. If you find those difficult to peruse, I did a brief set of cheat sheets for myself at http://kcoyle.net/rda/. The tables there use the term properties to mean what I have called elements and data elements in this email. Properties is the *proper* terminology for linked data. Although RDA also provides separate lists for relationships, (and I've got simple tables of these as well on that page) these are also considered properties in semantic web terminology. Sorry all of that is so confusing. On 7/28/12 8:01 AM, Paige G Andrew wrote: I think Robert's reply is right on the mark (though not MARC? lol!) and as Carolyn has stated I continue to follow subject access practices that have been a part of AACR2 cataloging for years. And will continue to do so as this is vital information for the users of cartographic information as most reference transactions in a map collection or unit that holds maps starts with Do you have a map showing ??? My understanding is that in time we will be able to /addiionally include/ subject terminology such as what Karen has shared, from the metadata standards world (which, of course, has long been able to use/borrow LCSH terms also and many folks chose to do so). Paige *From: *Carolyn J Kadri ka...@uta.edu *To: *RDA-L@LISTSERV.LAC-BAC.GC.CA *Sent: *Saturday, July 28, 2012 10:48:40 AM *Subject: *Re: [RDA-L] RDA and subject access I have been providing subject access points in my RDA MARC 21 records just as I always did with AACR2 cataloging, from LCSH. It was my understanding that subject access according to RDA is not developed as of this date for use for in RDA records. Robert seemed to be indicating that using the same subject thesauri that we always have, need to be continued until FRSAD becomes available. If my assumption is not correct, please advise. Thanks. Carolyn Kadri Head Cataloger Special Collections University of Texas At Arlington Arlington, TX 76019 817/272-7153 *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Robert Maxwell *Sent:* Friday, July 27, 2012 1:01 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] RDA and subject access Good question. I just didn’t want people to have the impression that current RDA cataloging was omitting subject access. Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] mailto:[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Karen Coyle *Sent:* Friday, July 27, 2012 11:56 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] RDA and subject access Robert, I was thinking POST-MARC. RDA is the first set of cataloging rules that have provided us with a metadata element set (http://rdvocab.info http://rdvocab.info/, based on the RDA element analysis [1]). I am presuming that the new bibliographic framework will follow at least some if not most of the elements as they are described in the RDA element analysis. Since we won't be using MARC, the question is what else is available to fill in what RDA does not describe? There are many things in MARC today that are not in AACR2, but in terms of RDA and subjects
Re: [RDA-L] RDA and subject access
Robert, I was thinking POST-MARC. RDA is the first set of cataloging rules that have provided us with a metadata element set (http://rdvocab.info, based on the RDA element analysis [1]). I am presuming that the new bibliographic framework will follow at least some if not most of the elements as they are described in the RDA element analysis. Since we won't be using MARC, the question is what else is available to fill in what RDA does not describe? There are many things in MARC today that are not in AACR2, but in terms of RDA and subjects there are actual chapters that read like: 34 Related Concepts [To be developed after the first release of RDA in 2009]. As one option, RDA could defer to FRBR for subject entities and relationships. (Relationships here being something like BookA _has subject_ TermB.) That could then replace the text in the chapters on subjects (something like: Use relationships defined for FRBR Group3 entities.). The relationship between an RDA Work and a subject needs to be defined. The actual subject entity may be the one defined in FRSAD - that's something I'm less clear on. My question, which probably can only be answered by JSC and/or the folks working on the new bibliographic framework, is what is the thinking on defining relationship elements for subjects? kc [1] http://www.rda-jsc.org/docs/6rda-element-analysis-table.pdf On 7/27/12 10:33 AM, Robert Maxwell wrote: There are plenty of elements in RDA MARC bibliographic records that are not RDA-related, just as there were plenty of elements in AACR2 MARC bibliographic records that are not AACR2-related. The fact that something is not found or provided for in RDA does not prevent us from recording it in a MARC record. Lack of development of RDA chapters related to subject does not prevent us from encoding subject strings in records following the rules of whichever thesaurus we are following. Subject access is included in RDA bibliographic records in 6XX fields just as it always has been. Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Mike McReynolds *Sent:* Friday, July 27, 2012 10:57 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] RDA and subject access This is very interesting and I hope some people who are have jumped in and begun cataloging by RDA rules can describe what they are doing with subject headings and indexing terminology. We are not creating records in RDA, but we have followed the OCLC Technical Bulletins and expanded our MARC settings to accept any records from OCLC that might be cataloged in RDA. Obviously, if they don't have subject terms, I will have some work to do. Mike McReynolds Cataloging Librarian Shook, Hardy Bacon Law Library Kansas City On 7/25/2012 10:01 AM, Karen Coyle wrote: Given that RDA currently says virtually nothing about subject access, I'm wondering how this will affect the work on the new bibliographic framework? There may exist, but I have not been able to find, any element that would link a subject heading (which presumably could come from any number of thesauri) to the bibliographic description in RDA. Have I missed this key element? And if not, how did the RDA tests overcome this? kc p.s. Note that I work from the Phase1 PDF documents, so if there have been updates in this area that I overlooked, please let me know! -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA and subject access
Thanks, Barbara. So, in the meantime, it sounds like using the FRBR subject relationships would not be out of keeping with the general intentions. I had done that before when mocking up some examples [1], and now that I'm working on some others I'll stick to that approach. kc [1] http://kcoyle.blogspot.com/2011/07/rda-in-xml-why-not-give-it-shot.html On 7/27/12 2:20 PM, Tillett, Barbara wrote: RDA 0.6.7 says: When recording relationships between a work and an entity that is the subject of that work, include as a minimum at least one subject relationship element. This follows the International Cataloguing Principles. The footnote to 0.6.7 in RDA reads: When using an access point to represent the subject entity, the access point may be formulated using either the preferred name, title, or term for the entity, or a classification number representing the entity. Formulate the access point representing the subject entity following the standards for subject access points and classification numbers used by the agency creating the data. The JSC also has agreed that the current placehholder chapters for concept, object, and event basically will say this same thing - to refer people out to current standards for subject terms and classification numbers. Further discussion papers about the possibilities of adjusting the scope of some of these entities (plus place and potentially also time) will be ongoing and involve future discussions between the JSC and the FRBR Review Group within IFLA. It is anticipated such discussions would occur in 2013 and beyond. However, in the meantime, the general instruction at 0.6.7 (noted above) should suffice. - Barbara Tillett, JSC Chair *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Robert Maxwell *Sent:* Friday, July 27, 2012 2:01 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] RDA and subject access Good question. I just didn't want people to have the impression that current RDA cataloging was omitting subject access. Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young University Provo, UT 84602 (801)422-5568 We should set an example for all the world, rather than confine ourselves to the course which has been heretofore pursued--Eliza R. Snow, 1842. *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Karen Coyle *Sent:* Friday, July 27, 2012 11:56 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] RDA and subject access Robert, I was thinking POST-MARC. RDA is the first set of cataloging rules that have provided us with a metadata element set (http://rdvocab.info, based on the RDA element analysis [1]). I am presuming that the new bibliographic framework will follow at least some if not most of the elements as they are described in the RDA element analysis. Since we won't be using MARC, the question is what else is available to fill in what RDA does not describe? There are many things in MARC today that are not in AACR2, but in terms of RDA and subjects there are actual chapters that read like: 34 Related Concepts [To be developed after the first release of RDA in 2009]. As one option, RDA could defer to FRBR for subject entities and relationships. (Relationships here being something like BookA _has subject_ TermB.) That could then replace the text in the chapters on subjects (something like: Use relationships defined for FRBR Group3 entities.). The relationship between an RDA Work and a subject needs to be defined. The actual subject entity may be the one defined in FRSAD - that's something I'm less clear on. My question, which probably can only be answered by JSC and/or the folks working on the new bibliographic framework, is what is the thinking on defining relationship elements for subjects? kc [1] http://www.rda-jsc.org/docs/6rda-element-analysis-table.pdf On 7/27/12 10:33 AM, Robert Maxwell wrote: There are plenty of elements in RDA MARC bibliographic records that are not RDA-related, just as there were plenty of elements in AACR2 MARC bibliographic records that are not AACR2-related. The fact that something is not found or provided for in RDA does not prevent us from recording it in a MARC record. Lack of development of RDA chapters related to subject does not prevent us from encoding subject strings in records following the rules of whichever thesaurus we are following. Subject access is included in RDA bibliographic records in 6XX fields just as it always has been. Robert L. Maxwell Special Collections and Ancient Languages Catalog Librarian Genre/Form Authorities Librarian 6728 Harold B. Lee Library Brigham Young
[RDA-L] RDA and subject access
Given that RDA currently says virtually nothing about subject access, I'm wondering how this will affect the work on the new bibliographic framework? There may exist, but I have not been able to find, any element that would link a subject heading (which presumably could come from any number of thesauri) to the bibliographic description in RDA. Have I missed this key element? And if not, how did the RDA tests overcome this? kc p.s. Note that I work from the Phase1 PDF documents, so if there have been updates in this area that I overlooked, please let me know! -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Modeling of entities
On 6/12/12 2:14 PM, Heidrun Wiesenmüller wrote: True. Place is not as easy as it looks, though: There is a problem connected with things like a city or a state. They can be seen either as a place (i.e. a geographic name) or as the corresponding jurisdiction (government), which really is some sort of a corporate body. We tend to mix up the aspects, but perhaps these should be modelled as two different entities altogether. Or perhaps we could use some sort of role indicator (e.g. Lima as a place or Lima as a jurisdiction)? Yes, place is complex. The geoNames ontology covers both jurisdictional places (down to 5 or 6 levels) as well as geographical/physical types from bays to river banks to lakes and on and on. [1] The AGROVOC thesaurus [2] also distinguishes, but at the moment the thesaurus search is not working so I can't provide examples. In the end, I don't think this is something we can entirely clear up. A history of Los Angeles may be partly about the jurisdiction and partly about the geographical area. I'm not sure what to do with places treated broadly in works. kc [1] http://www.geonames.org/ontology/ontology_v3.01.rdf [2] http://aims.fao.org/standards/agrovoc/functionalities/search I also wonder about person as a general concept. There is a curious mixup between real-life persons (who have a certain place of birth, are married to somebody, a.s.o.) and bibliographic entitities corresponding to these real persons (but: would exactly would the difference be?), not to mention separate bibliographic identities (e.g. one person with two bibliographic identities). I believe FRAD makes it clear somewhere that they are not talking about real persons, but about bibliographic entities - only I can't look it up right now as I haven't got my copy here (by the way: how come there is still no open access version of FRAD??). Personally, I think that ANYTHING that can be identified should be allowed to be a subject in the most general case, and that taking subject concepts from, for example, LCSH or the GND subjects, would be a more specific case. If I understand the results of the FRSAD group correctly, this is exactly what they ended up with. The group 3 entities are simply not enough to cover the infinite possibilities that a subject can take. Therefore, they had to make the model more general and introduced the thema entity, which basically can be everything. Heidrun -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Work manifested in new RDA examples
. To take just one example: According to the German cataloguing code only the first editor gets an access point, whereas it's up to three in AACR2. So, I am very favourably impressed by the richness of Anglo-American cataloguing data, and I often wish we had the same attitude towards cataloguing here. On the other hand, I am sometimes a bit dismayed when I look at the way this great data is stored, handled and processed. Compared with conventions and practices here, to me it often seems rather inefficient and not really suited to this day and age. Collocation via text strings is only one example. Another would be authority maintenance, where - if I understand correctly - our customs are quite different: We're used to automatic updating processes. Whenever a heading is changed or a variant name added, this only has to be done once, in the national authority file. It will then be automatically copied to the correspondent authority files in the regional networks, and from there, the changed data will be delivered to the local library systems, again automatically. Due to this system and the links between authority records and title records, there is no need for any locally done cleanup. And then, of course, there is the MARC format. When I teach MARC to students, who are already familiar with another input format (the PICA format used in the Southwestern German Library Network), they find it very hard to understand why suddenly they have to input ISBD punctuation and must type in a parallel title twice (in 245 $b and 246). Isn't this superfluous?, they ask. Why doesn't the machine do it for me?. Heidrun -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Bibliographic records vs. catalogue building
On 6/7/12 10:02 AM, Heidrun Wiesenmüller wrote: The country codes have been there in our authority file for two or three decades, but up to now I believe they have never been used for actual retrieval. Perhaps something similar could be done with the geographical area codes in MARC field 043? Definitely, but only if the code is entered into the records. In the studies done by Moen in 2006,[1] it is shown that the 043 occurs in about 30% of the records, but that 84% of the 650's have a geographic subdivision. Those figures can't be directly compared because there can be more than one 650 in a record. What you demonstrate here, though, is something important: coded data can be more easily utilized for this kind of functionality than textual data. But we have a chicken and egg problem: if coded data is entered only sporadically, it isn't good for retrieval, and therefore systems cannot use it; but if systems do not implement features based on coded data then one can argue that there is no use inputting the data since it isn't used. We need to break that cycle, but without giving users bad retrievals for a time before input practices change. kc [1] http://www.mcdu.unt.edu/?p=43 Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Bibliographic records vs. catalogue building
But you don't have any empirical data either, so this is just a says
who? says me! discussion. In fact, we have damned little empirical data
in our field, either for what librarians want or for what our users
want. Yet we spend hours in these discussions.
The impressive thing about the video the Jim sent around about Google
searching [1] is that Google HAS data, and they make decisions based on
that data. We're still making our decisions like we did in the sandbox
in elementary school, calling each other names and sticking our tongues
out at each other.
*sigh*
kc
[1] http://lectures.princeton.edu/2012/daniel-m-russell/
On 6/7/12 10:23 AM, Kathleen Lamantia wrote:
...EMPHATICALLY it is not the preferred format that staff want to work in. Rather
staff love the tabular format, where elements are arranged in rows and columns --
fantastic for sorting, fantastic for quickly discerning the nature of the result
set.
Whose staff? Under what conditions? In one sense,I am staff, and I most
definitively do NOT prefer tabular format. Is there empirical data to support this
contention? Studies, surveys?
Kathleen F. Lamantia, MLIS
Technical Services Librarian
Stark County District Library
715 Market Avenue North
Canton, OH 44702
330-458-2723
klaman...@starklibrary.org
Inspiring Ideas ∙ Enriching Lives ∙ Creating Community
-Original Message-
From: Brenndorfer, Thomas [mailto:tbrenndor...@library.guelph.on.ca]
Sent: Thursday, June 07, 2012 1:00 PM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibliographic records vs. catalogue building
How that data is searched is a matter of the ILS, not AACR2 or MARC.
The last point is profoundly wrong.
Traditional cataloging still assumes a structure dependent on headings to gather related
editions if you like.
The worst mistake is building all kinds of conditional or implicit rules in the
layout of fields and having that dominate the logic of what ILS systems can do.
FRBR and RDA are explicit as to what the data elements are -- ISBD is one
possible resulting display, but EMPHATICALLY it is not the preferred format
that staff want to work in. Rather staff love the tabular format, where
elements are arranged in rows and columns -- fantastic for sorting, fantastic
for quickly discerning the nature of the result set. The main problems arise
because of the gummed up displayed forced by ISBD, with sloppy punctuation
intruding, or distinctions lost because systems can't filter on both MARC
subfields and punctuation. What's has caused poor system design is the inane
bridging across different fields (1XX+24X vs 700 name-title) or working with
semantically different data elements within a field or even a single subfield!!
Thomas Brenndorfer
Guelph Public Library
From: Resource Description and Access / Resource Description and Access
[RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod [m...@slc.bc.ca]
Sent: June-07-12 11:54 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Bibliographic records vs. catalogue building
Heidrun said:
Correct me if I've misunderstood how Anglo-American catalogs work. I've
just tried it out in your own catalog: Typing in, e.g. lew tolstoi war
peace in keyword doesn't give me even one edition, let alone all of
them ...
This has nothing to do with AACR2 cataloguing, but with ILS search software,
which is why we should be developing advanced search capability, not fooling
around with catalogue rules and a replacement coding scheme.
AACR2 has us describe an edition by transcribing bibliographic data elements as
chosen by, and in the order of, the ISBD, adding to that notes, classification,
and access points. MARC has us code that information, and add fixed codes
(some redundant with present search possibilities).
How that data is searched is a matter of the ILS, not AACR2 or MARC.
With the end of the card catalogue, too many of us abandoned catalogue
construction to computer people, and limited ourselves to under utilized
bibliographic record creation
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] Bibliographic records vs. catalogue building
Laurence, Think of the message to users if they search on a value that is only present in 1/2 of the records it would be relevant for. You can decide that it's ok to give people only 50% of what they should get, but then what does that do for Thomas's insistence that the role of the library catalog is to retrieve all of the relevant items when a user does a find? BTW, in my experience it was the reference librarians who balked at adding features that would give only partial retrievals, since they were the ones that found themselves having to explain to users why they didn't get what they expected. I find that reference librarians are really missing in most of these discussions, but in my systems days they had a strong voice as the closest thing we had to representatives of the users. So I hope you don't see this as a systems idiots vs. all-knowing catalogers issue: it would have been easy to add some of these features to the system, but the decision-making body (and all sytsems should have a broadly representative decision-making body) nixed it. kc On 6/7/12 10:49 AM, Laurence S. Creider wrote: The irony here is lovely. The MARC fixed fields for country and language codes and the 043 and 041 were originally designed for automated retrieval at a time when there were if any online catalogs. In the computer environment of the 1960s and 1970s, even the 1980s, retrieval by the codes would have been much faster than any searching by text strings. Evidently, it still is. Unfortunately, most people did not bother with the 043 field, in particular, because no online system (including OCLC) made use of it. So now we are finding that we shouldn't make use of the 043 because the information is not in online bibliographic records because the online systems could not be bothered to develop a means of retrieving it? I am upset because, among other reasons, I spent a lot of time inputting 043 fields in the hope that they would be useful. The MARC format has enough limitations without folks blaming it for poor implementation by others. Besides, Heidrun's project is gravy. It does not retrieve everything that is relevant, but I have not met a system yet that does. Her work retrieves more, and that is progress. Larry -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Work manifested in new RDA examples
of the work] 377 eng[language code] 430 Komposition für den Film $v ÖB-Alternative[variant title, marked as preferred form for public libraries] 500 [Link via control number to authority record for]Adorno, Theodor W. $4 aut1 [aut1: first author] 500 [Link via control number to authority record for]Eisler, Hans $4 auta [auta: author who is not first author] 548 $c 1947 $4 datj[datj: year of publication] 670 Oxford Music Online[source] Note: Unfortunately, up to now we only have a small number of authority records for works - only for those used in subject headings and for musical works. Before the GND, we would have had two authority records for this work. The first one included the text string Adorno, Theodor W. / Composing for the films and the second one the text string Eisler, Hans / Composing for the films, and both would have been applied to literature on this work. So, this was fairly similar to the name-title string. Now, an author is rather seen as a relationship, and this is brought out by a link. How do you like the format? I think it's really well thought out. But there are also some drawbacks, as the new authority format in a way is too modern for some of the library systems in use in Germany. So in some cases, there are considerable problems in making use of the data in the way in which it was envisioned. But then this is all still very new, and I hope the systems will adapt in time. I'll write something about authority maintenance tomorrow. Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Work manifested in new RDA examples
to be a daunting task. But now I come to think about it, I wonder: Wouldn't it be possible to generate work authority records automatically? Based on work clustering, we could e.g. collect all variant titles for a work from the various manifestations. Maybe this is a direction worth looking at. I'm sure there are more methods than the three I've mentioned. And of course, linked data, could also play a part (one possibility of handling variant personal names could be a tool which makes use of VIAF in RDF, for example). Heidrun -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Work manifested in new RDA examples
this are one of the reasons for the German decision to implement RDA in scenario 2 instead of aiming at scenario 1. It is felt that FRBRization can be achieved by technical measures and be shown on a surface level (only virtually, as it were), without having to change too much in the underlying data structures itself. Having to create an authority record for _every_ work, as it would be necessary for method 1 (and perhaps also for method 2, as the work information obviously must come from somewhere), seems to be a daunting task. But now I come to think about it, I wonder: Wouldn't it be possible to generate work authority records automatically? Based on work clustering, we could e.g. collect all variant titles for a work from the various manifestations. Maybe this is a direction worth looking at. I'm sure there are more methods than the three I've mentioned. And of course, linked data, could also play a part (one possibility of handling variant personal names could be a tool which makes use of VIAF in RDF, for example). Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Work manifested in new RDA examples
On 6/6/12 10:09 AM, Brenndorfer, Thomas wrote: But that's the Select user task at play in this discussion. Users can select from amongst a result set, or they can pre-filter search results with limits, or algorithms can produce relevancy ranked results. Current catalogs have all kinds of responses. ... The latter point is important. A user may know of a work, but may not know that there was another book written about the work (a subject relationship). In order to FIND that other work, a relationship needs to be established and this needs to be part of what is presented to the user. The user may not be aware of any search criteria to use to find the other book-- part of the purpose of the catalog is to show the user the relationships between resources and allow them to explore or navigate the terrain (and EXPLORE is a FRSAD user task). So here's where we differ. *My* user isn't very knowledgeable. He doesn't really know what he is looking for, and he definitely does not have a particular work or edition in mind. He's looking for some information, or a good read, or more on a topic; a good first book on astronomy, a book for someone who loved Harry Potter. If your user comes to the library with full knowledge of the bibliographic universe, then the FRBR user tasks pertain. But if your user comes, like so many do, to discover, then the catalog isn't much help. A bibliographic listing, even if the user arrives at a relevant retrieved set, does not answer the needs I just posed. If we view the catalog as an inventory for users looking for specific works, editions or manifestations, then we can say that it fulfills that need. However, I think that need is a minority need among users -- not just library users, because we have trained them to only come to the library catalog when they are seeking something specific, but people seeking information/works/etc., most of whom do that searching on the Internet but who could possibly be served by library materials if they could discover them. If you maintain that is not the role of the library catalog, then we need to review our services, what they cost, and the benefit that all users derive. I honestly think that the bang for the buck of the library catalog would not turn out to be justifiable except in some specific research libraries. kc p.s. Explore is a FRSAD task, but RDA specifically does not enter into subject access. As Michael Gorman made clear in his AACR3? Not! essay, cataloging is a description of a physical object. I have elsewhere called for more attention to subject access, but that is not within the RDA purview. Thomas Brenndorfer Guelph Public Library From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle [li...@kcoyle.net] Sent: June-06-12 11:36 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Work manifested in new RDA examples On 6/6/12 8:16 AM, Brenndorfer, Thomas wrote: The users that benefit from seeing all the resources that embody particular works and expressions include those with roles in acquisition, preservation, and reference. The idea that it's OK to not necessarily find all the resources is an odd assertion in this discussion thread. Thomas, I think the question is whether this is the only possible retrieval result. There is a difference between someone who wants or needs ALL and someone who wants or needs A. That difference is exemplified in search engine results, which retrieve ALL but offer to the user SOME by employing ranking, with the assumption (which I think can be proven) that the user who wants ALL is in a small minority. ALL is available, but is by no means the default. One area where I think library catalogs are weak is that they seem to have only one type of response, and that response is often the one suitable for the minority of users. kc The name-title string is still the basis behind how catalogs functions. I don't think they're ideal, and whether they're adequate is often dependent on how well a system can handle them. As a case in point, the first web-based catalog I used could have hyperlinks attached to name-title headings. That's great -- except the 1XX+24X fields would not be caught in this net, even though those fields mean exactly the same thing as the 7XX name-title heading-- an identifier for a work. This was less than adequate and would mean anyone who clicked the link would get some related works but not all of them, and in fact, genearlly not the main ones that the library held because those were represented with the preferred title overlapping the 245 title proper. Thomas Brenndorfer Guelph Public Library From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller [wiesenmuel...@hdm
Re: [RDA-L] Work manifested in new RDA examples
in the manifestation, only the predominant or first-named work manifested is required as a core element. Now, if you want to work out an RDA representation for this, similar to the JSC examples, which of the three works would you have to give as work manifested? As far as I know, LC's opinion is that it would be the first of the individual works. But personally, I think this is highly debatable. But the ultimate point here is that these primary relationships were always implicit in traditional bibliographic records. The key to understanding RDA is that what was implicit is made explicit in such a way that the logic of what is happening in the resource is captured in the instructions-- but there is room for different conventions to carry that logic. One doesn't have to wait for a post-MARC environment to establish the primary relationships, but perhaps a post-MARC environment can be more efficient at processing and displaying those relationships. I agree absolutely. Still, I find the whole notion of the composite description one of the really disappointing features of RDA. In a way, RDA starts out saying: Yes! We want to have FRBR! But then, when it gets down to business, and the rules for the primary relationships are stated, RDA gets rather meek: O.k., if you want to, you just can go on doing what you've done before and mix everything together. Don't get me wrong: I do see that there is progress with RDA. And I do understand that the idea is to have a gradual introduction of FRBR, and that neither people nor systems ought to be overburdened by radical upheavals. But still it is a bit depressing. That's why I found the introduction of the data element work manifested in composite descriptions quite intriguing... Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Library Systems was: Work manifested in new RDA examples
On 6/4/12 12:43 PM, Heidrun Wiesenmüller wrote: Maybe. But think of all the money and resources which has already been gone into RDA. Makes you wonder why it shouldn't be possible to invest some of it into an open source solution which would be available to all... But then, of course, this was mere fantasizing :-( What I often wonder about is the role of RDA in relation to the management functions of library systems. Our records do multiple-duty -- they provide for user access, they demonstrate the nature of the collection, they link to holdings and accessibility. Somewhere along the way they also interact with acquisitions, processing, circulation, perhaps serials check-in, and are included in systems that facilitate inter-library loan. One hears concerns about modifying systems to handle RDA, but I haven't run into any discussions about this outside of the issue of the cataloging and user OPAC functions. Has anyone seen such a discussion anywhere? kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Work manifested in new RDA examples
Heidrun, the difference I see between the current practice is that currently we can link between bibliographic and authority *records* -- while FRBR requires us to link between *entities*. The entities in FRBR have a somewhat different break-down to our authority data (for example our authority data still pre-combines data elements like title and date or title and language, rather than creating an entity to represent the Expression). That said, I think scenario 2 is far superior to what most systems have today. Also look at the blog post[1] I did on the National Library of Spain's linked data implementation, which is based on the concept of authorities but still uses FRBR. kc [1] http://kcoyle.blogspot.com/2012/05/frbr-frad-isbd-in-ld-by-bne.html On 6/4/12 3:44 AM, Heidrun Wiesenmüller wrote: Karen, not necessarily, I believe. In German library systems, we're used to linking authority records (mostly for persons and corporate bodies) to bibliographic records, using the authority control numbers as identifiers. The systems are able to extract information stored in the authority records for retrieval. This makes it e.g. possible to use variant names in keyword searching. It would, on principle, also be possible to have an authority record for every work and link these to the bibliographic records. In this case, there wouldn't be a need to repeat work level information (stored in the authority record) in the bibliographic record. So in the bibliographic record, I would expect to have a link to the work record (corresponding to the data element work manifested), but not also a link to the authority record for the author (corresponding to the data element for creator) - this information would be stored in the authority record. Of course, this wouldn't be true FRBR, as the remainder would still be a mixture of expression and manifestation. It also wouldn't be a true scenario 1 implementation, but rather a mixture between scenario 1 and scenario 2. Using text strings instead of numbers to express relationships is, to my mind, indeed somewhat archaic. Personally, I find it hard to understand why it is still widespread in MARC systems. But we shouldn't forget that the MARC format already allows for transporting authority control numbers (in subfield $0), although nobody in the Anglo-American world seems to use this option... So maybe it wouldn't be necessary to wait for a true FRBR-modeled carrier for RDA. Linking via numbers is already possible in MARC, as is having authority records for works. So why shouldn't it be possible to upgrade the library systems accordingly, at least as a first step on the way to the perfect carrier for RDA data? By the way: It was just announced that the the implementation of RDA in the German speaking countries will conform to scenario 2. The announcement can be found here (sorry, it's in German only): http://lists.ddb.de/pipermail/rak-list/2012-June/001983.html Heidrun Am 03.06.2012 23:40, schrieb Karen Coyle: Heidrun, I've been assuming, perhaps incorrectly, that references to FRBR relationships in RDA, like work manifested, are essentially unusable until there is a FRBR-modeled carrier for the bibliographic data. I have a similar assumption about things like identifier for the expression, which really cannot exist until there is a FRBR-modeled carrier that allows -- nay, requires -- those identifiers in order to create the entities and their relationships.* It makes very little sense to me to be creating a text string for these relationships which have to be machine-actionable in order to have the scenario 1 data structures. kc *Hopefully without diverting this discussion, I think there is a difference between the system identifier for the expression *entity* and a string, like an ISBN, that might be considered to identify, or partially identify, an entity in the bibliographic description through its use in various contexts. On 6/3/12 7:51 AM, Heidrun Wiesenmüller wrote: I am mulling over the data element work manifested in the examples for RDA bibliographic records released by the JSC some time ago: http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf For instance, look at the example for Arlene Taylor's The organization of information (book 1, p. 10): There, you'll not only find the data element creator (Taylor, Arlene G., 1941-), but also the data element work manifested (Taylor, Arlene G., 1941-. Organization of information). Note the beautiful footnote: No equivalent encoding in MARC 21. In the earlier version of these examples wich accompanied the full draft of 2008, this data element wasn't there at all, and its appearance now strikes me as rather odd. Granted: Work manifested (17.8) is a core element in RDA (cf. 17.3: When recording primary relationships, include as a minimum the work manifested.). But in 17.4.2, three conventions
Re: [RDA-L] Work manifested in new RDA examples
Heidrun, I've been assuming, perhaps incorrectly, that references to FRBR relationships in RDA, like work manifested, are essentially unusable until there is a FRBR-modeled carrier for the bibliographic data. I have a similar assumption about things like identifier for the expression, which really cannot exist until there is a FRBR-modeled carrier that allows -- nay, requires -- those identifiers in order to create the entities and their relationships.* It makes very little sense to me to be creating a text string for these relationships which have to be machine-actionable in order to have the scenario 1 data structures. kc *Hopefully without diverting this discussion, I think there is a difference between the system identifier for the expression *entity* and a string, like an ISBN, that might be considered to identify, or partially identify, an entity in the bibliographic description through its use in various contexts. On 6/3/12 7:51 AM, Heidrun Wiesenmüller wrote: I am mulling over the data element work manifested in the examples for RDA bibliographic records released by the JSC some time ago: http://www.rda-jsc.org/docs/6JSC_RDA_Complete_Examples_%28Bibliographic%29_Revised_2012.pdf For instance, look at the example for Arlene Taylor's The organization of information (book 1, p. 10): There, you'll not only find the data element creator (Taylor, Arlene G., 1941-), but also the data element work manifested (Taylor, Arlene G., 1941-. Organization of information). Note the beautiful footnote: No equivalent encoding in MARC 21. In the earlier version of these examples wich accompanied the full draft of 2008, this data element wasn't there at all, and its appearance now strikes me as rather odd. Granted: Work manifested (17.8) is a core element in RDA (cf. 17.3: When recording primary relationships, include as a minimum the work manifested.). But in 17.4.2, three conventions for recording primary relationships are outlined, and I believe that only the first and the second presuppose work manifested as a single data element: For these two methods, an identifier for the work (method 1) or the authorized access point representing the work (method 2), respectively, are used. The third method, however, does not seem to require one single data element work manifested: Prepare a composite description that combines one or more elements identifying the work and/or expression with the description of the manifestation. So, in this case, the identification of the work is achieved by one or more elements which really belong on work level, although in the record they are mixed together with information on manifestation level. Typically, these will be the data elements for the first creator and for the preferred title of the work (vulgo: uniform title). I'd argue that in cases where there's no need to determine a uniform title (e.g. if there is only one manifestation of the work in question), the title of the manifestation can be used instead. The RDA example for book 1 mentioned earlier follows this third method for recording primary relationships, i.e. it is a composite description, which basically looks like the conventional MARC record. Therefore, I find it hard to understand why the information about the work manifested is given _twice_ in the same record: Once _implicitly_ according to method 3 (by giving the data elements creator and title proper as part of the composite description) and a second time _explicitly_ according to method 2 (by giving the authorized access point representing the work). Shouldn't it be either the one (in a composite description) or the other (in a different implementation scenario for RDA, something closer to scenario 1)? As it stands now, the information given seems to be redundant. Any ideas? Heidrun -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Added elements for expressions
used for conflict resolution in parentheses. Separate a word, phrase, date, or other designation used for conflict resolution from another word, phrase, date, or other designation also used for conflict resolution by a space, colon, space. If these instructions are followed, the examples should be rendered as: Wilde, Oscar, 1854-1900. Works (2000) Shakespeare, William, 1564-1616. Works (2003 : Yale University Press) John, probably these two examples need to be corrected with fast-track process. Note however, that this change from AACR2 requires many existing authority records to be changed in order to be coded as RDA. Perhaps this is something the JSC needs to have a look at. I don't think this came up on the list of changes needed to AACR2 records when recoding as RDA. I do see that there are indeed two examples illustrating the prescribed punctuation in 6.28.4.4: Beethoven, Ludwig van, 1770-1827. Ludwig van Beethovens Werke (1862) Authorized access point for the compilation: Beethoven, Ludwig van, 1770-1827. Works (1862) Beethoven, Ludwig van, 1770-1827. Ludwig van Beethovens Werke (1949) Authorized access point for the compilation: Beethoven, Ludwig van, 1770-1827. Works (1949) And also in 6.31.3.2: Catholic Church. Pope (1978-2005 : John Paul II). Vita consecrata. English (Simplified version) Catholic Church. Pope (1978-2005 : John Paul II). Vita consecrata. English (Institute on Religious Life) Authorized access point for the expression: Catholic Church. Pope (1978-2005 : John Paul II). Vita consecrata. English (2004) Catholic Church. Pope. Tutte le encicliche dei sommi pontefici (1940) Authorized access point for the expression: Catholic Church. Pope. Encyclicals. Italian (1940) Catholic Church. Pope. Tutte le encicliche dei sommi pontefici (1959) Authorized access point for the expression: Catholic Church. Pope. Encyclicals. Italian (1959) Catholic Church. Pope. Tutte le encicliche dei sommi pontefici (1964) Authorized access point for the expression: Catholic Church. Pope. Encyclicals. Italian (1964) --Adam Schiff ^^ Adam L. Schiff Principal Cataloger University of Washington Libraries Box 352900 Seattle, WA 98195-2900 (206) 543-8409 (206) 685-8782 fax asch...@u.washington.edu http://faculty.washington.edu/~aschiff ~~ On Fri, 1 Jun 2012, JOHN C ATTIG wrote: See Appendix E.1.1 Presentation of Access Points. There is a section called Uniform Titles (presumably because this is an attempt to reflect the punctuation in AACR2 Chapter 25). John Attig Authority Control Librarian Penn State University jx...@psu.edu From: Bernadette Mary O'Reillybernadette.orei...@bodleian.ox.ac.uk To: RDA-L@LISTSERV.LAC-BAC.GC.CA Sent: Friday, June 1, 2012 5:29:53 AM Subject: [RDA-L] Added elements for expressions Hallo In the near future I will need to draft some guidelines for colleagues who will be using RDA with ISBD and MARC21. Most of them are multi-skilled and do fairly small amounts of cataloguing, so the training has to be quick and simple. I will have to include guidelines for creating RDA headings in bibliographic records for entities for which there is no NACO record. (We do not create new NACO records for minor works or contributors.) I haven?t been able to find any rules about which additions to Expression records should be in parentheses and which should follow a full stop. The examples (6.27.3) show most additions, including publisher, after a full stop but some (translator, text version, choreographer) in parentheses. (I was actually quite surprised to find that a new choreography was regarded as only an Expression-level distinction.) Appendix E does not specify punctuation for Other Distinguishing Characteristics of the Expression. I have glanced through the PCC NACO training slides, but didn?t find anything about this. Please could someone tell me where I should look for a rule? Many thanks, Bernadette *** Bernadette O'Reilly Catalogue Support Librarian 01865 2-77134 Bodleian Libraries, Osney One Building Osney Mead Oxford OX2 0EW. *** -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Are RDA, MARC data, and Bibliographic concepts compatible with Relational database principles or systems? (Was: Re: [RDA-L] RDA, DBMS and RDF)
On 5/21/12 7:28 AM, Jonathan Rochkind wrote: On 5/19/2012 10:52 AM, Karen Coyle wrote: This is what worries me about FRBR and the assumptions that every bibliographic record will be made up of at least four and probably more like 6-8 table joins. If every record to be displayed requires a join of a Manifestation, an Expression, and a Work FRBR is an ontology, I don't think it makes any demands on how a system stores the data. First, FRBR in its IFLA document form is a mental model. FRBRer, as encoded in the Open Metadata Registry, is an RDF ontology that has *very* strict requirements on how the elements can be used in a linked data environment. In other applications, like XC, presumably how you instantiate FRBR in your data store, the field is wide open. But read what I said: I worry about the assumptions that are being made. There are actually folks creating systems in which each bib description has a separate record for WEMI because that's how they interpret FRBR, and the IFLA RDF definition of FRBR actually encodes the relationships between the entities that, if followed, many of us think lead down the wrong path. I have a page that captures some of the discussion on this at: http://futurelib.pbworks.com/w/page/48221836/FRBR%20Models%20Discussion Obviously, you can do what you want with FRBR inside your own system, but we're talking about massive sharing of data. It's the sharing part that matters. The danger is that the library community will form standards that are widely followed but that are not a good idea. Or that deteriorate over time, like MARC, but we're so stuck to our standards that we can't imagine changing. If you actually look at that page and read the arguments there, rather than just shoot back an email telling me that I don't know what I'm talking about, you might see why some folks are concerned. I think a good working meeting about FRBR and what it means for implementations is long overdue. We can prattle on about it, but I think it's time to get concrete. For example, I would like to see an implementation of the Murray/Tillett model, and compare that perhaps to an implementation of Rob Stiles' model (if he's still thinking that way). Jakob Voss also has some great ideas. It does make a big difference whether we are assuming RDF or some other way of expressing the bibliographic data. The Dublin Core community is starting to re-address standards for Application Profiles and will (hopefully) eventually get to the point of addressing FRBR as it has been modeled in various ways in RDF. (A list of those is on the futurelib page.) At the moment the AP discussion is taking on some easier issues. http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns and in particular http://wiki.dublincore.org/index.php/DCAM_Revision_High_Level_Example_Publication_Statement My assumption is that there will be silo'd database implementations that export some of the data as RDF. I also suspect that there will be something like WorldCat that is used for cataloging, and that the result of that will either stay in the library cloud (much like Ex Libris' Alma) or will be pulled into local databases for local uses. These are different applications, but they will need to play well together if we are to link our data to the web. I think we need to model all kinds of possibilities -- perhaps as part of the study for the new bibliographic framework. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Are RDA, MARC data, and Bibliographic concepts compatible with Relational database principles or systems?
On 5/21/12 1:30 PM, J. McRee Elrod wrote:
subarrange a set of identical primary data elements (e.g., name, $b
birth year...
That's $d birth and/or death year; 100$b is seldom used numeration.
A greater problem with MARC than variable fields and subfields, we
find, are fixed fields, particularly the the varying meanings of
positions depending on the LDR/06 code.
I suspect that this was one of the space-saving aspects of the MARC
format (and by that I mean Z39.2) that traded off record size for
processing complexity. Were we to develop a new data format today (what
an idea!) I think we wouldn't have to have this functionality where
positions change meaning based on a code located elsewhere in the
record. I also think this is a carry-over from the fact that the first
versions of MARC handled only books, then serials and other formats were
added over time. It was a solution that became more awkward as the
number of formats grew.
kc
The UTLAS solution which worked very well was to have the fixed fields
in the 1000 range, with no variation in meaning.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] Are RDA, MARC data, and Bibliographic concepts compatible with Relational database principles or systems? (Was: Re: [RDA-L] RDA, DBMS and RDF)
The theory of database design and the practice don't always coincide, especially for large datasets. When I was working on large databases in Oracle the catchword was that joins are costly and the more of them that it took to respond to your query (between search and display) the worse your response time. Today's computers are bigger and faster so the constraints are probably lessened, but I suspect some constraints still exist. This is what worries me about FRBR and the assumptions that every bibliographic record will be made up of at least four and probably more like 6-8 table joins. If every record to be displayed requires a join of a Manifestation, an Expression, and a Work (because you can't get to the Work unless you go through the Expression even if you aren't using anything in it for display), plus an author, I think we'll see some response time problems. I know that XC is using a FRBR-ish design. VTLS also has one. Can anyone comment on the relative efficiency, or how one can mitigate the design to improve response time? Also, is a triple store more efficient? kc On 5/18/12 6:28 PM, Simon Spero wrote: On Fri, May 18, 2012 at 8:03 PM, Joe M Tomich jtom...@uwm.edu mailto:jtom...@uwm.edu wrote: Simon, In your model, does the stored information for an individual author or publisher constitute a record within a table (as would likely be the case in a typical relational database), or is each author, publisher, etc. effectively its own table? Typically you would have a table for each type of entity; you wouldn't have a table for each instance (that would be a lot of tables :-) In the examples I gave I actually presented four different models, representing different ways of using a relational model. In the first model we had a table where the reference to the right entry in the names table was included as a column in the table for bibliographic records. In this case we have 2 tables In the second model, we created a separate join table, which had a reference to an entry in the bibliographic records table, and a reference to an entry in the names table (this approach can be used with fields that could have multiple values for the same record, e.g. added entries). In this case we have 3 tables. In the third model, we had a separate table for every property, each with two columns. One column identified the thing that this was a property of (for example bib record number 9); the other gave a value of that property - in a performer table this might be value of n91064231, or possibly http://lccn.loc.gov/n91064231 ). In this case we have a separate table for every property, not for every record. The subject, table name, and value correspond to the three parts of an RDF triple. In the fourth model, we store the subject, property name, and value in a single table. This corresponds to a naive implementation of a triple store. In this case we only have a single table. Does this make things clearer? Simon -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Are RDA, MARC data, and Bibliographic concepts compatible with Relational database principles or systems?
Joe, this is the thrust of my blog post, which started this thread: http://kcoyle.blogspot.com/2012/05/rda-dbms-rdf.html and I say: Where the goal in relational database design is to identify and isolate data elements that are the same, the goal in library cataloging data is exactly the opposite: headings are developed primarily to differentiate at the data creation point rather than allow combination within the database management system. The goal is to have each data point be as unique as possible and to be assigned to as few records as possible. I agree with you that this technique, which was useful in the card catalog, is less so in our online catalogs today. kc On 5/19/12 8:13 AM, Joe M Tomich wrote: Simon, Many thanks for your thorough response to my record/table question. As it happens, your response to Mac's post below addresses the concern that lead me to raise it so I will continue the discussion from there. Mac states: Some data may be unique to the manifestation represented by the record, e.g. call number (as opposed to just class number), title, statement of responsibility, collation. What is the advantage of having unique information in a table rather than in the record? Within your response (posted in full below), you state: Call numbers are a very good example of how linking between records is used in MARC today. My new question: Is linking between Records really in accordance with RDB principles? Is it not the ability to create interoperability between tens, hundreds, thousands of records simply by joining the tables in which the records are contained that constitutes a core advantage of a relational database? While you've given many scenarios in which catalog information can be put into an RDB environment, does doing so really produce the savings and efficiencies we associate with other RDBs when we compare them to the information storage and retrieval methods they replaced? This is really more of a question to the community, as I know you may have been addressing possibility, and not necessarily practicality. I guess, in a nutshell, the point I'm making is that I think we'd be better of looking at what improvements we can make to the catalog by borrowing some ideas from relational databases rather than taking the relational database model as a given and bending over backwards to shoehorn the libraries' holdings information into that environment by whatever means necessary. Joe - Original Message - From: Simon Sperosesunc...@gmail.com To: RDA-L@LISTSERV.LAC-BAC.GC.CA Sent: Friday, May 18, 2012 8:52:35 PM Subject: Re: [RDA-L] Are RDA, MARC data, and Bibliographic concepts compatible with Relational database principles or systems? On Fri, May 18, 2012 at 6:35 PM, J. McRee Elrod m...@slc.bc.ca wrote: Simon Spero said: [3] It is indeed possible to generate a full record by joining together things from different tables. Some data may be unique to the manifestation represented by the record, e.g. call number (as opposed to just class number), title, statement of responsibility, collation. What is the advantage of having unique information in a table rather than in the record? Beyond access points (aka entries) I see no advantage in using linked data. I think you may be seeing some of the possible advantages, but I don't think I'm expressing myself in the right way to let you see that you're seeing them. Call numbers are a very good example of how linking between records is used in MARC today. There's the call number that can go in field 050 of a bibliographic record, but that isn't enough to deal with multiple copies of the described manifestation. In this situation, we might want to use MARC holdings records. These records store, full location and copy specific call number information in 852 fields. In order to find out which bibliographic record contains the description for the items pointed at by a holdings record, a reference to the control number of the bibliographic record (001) is stored in a special field in the holdings record (004). Simon -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA, DBMS and RDF (fwd) (fwd)
Jonathan, there is nothing wrong with testing out ways to retrieve a record with multiple subject headings that share some keywords. It's probably the most common case we have. I don't know why you see experimentation as wrong. If the RDBMS doesn't give the desired result, then we should move on to other technologies. The question at hand is: do headings give us the desired result using the common technology of our library systems? If not, should something change about how we do headings, or do we need a different technology? The underlying question, though, is what do we want headings to accomplish in our systems? I happen to think that implementation details and cataloging practice must inform each other. kc On 5/16/12 10:17 PM, Jonathan Rochkind wrote: Certainly you can come up with an infinite number of wrong ways to do it that won't get the results you want. With any given technology. I do not understand why you are trying to come up with wrong ways to do this arbitrary goal, you seem to be working on refining your software approaches with the goal of finding something that won't work. Why would anyone want to do that? In addition to a nearly infinite number of wrong ways to accomplish this particular goal, there are also a few right ways to do it. There are several other designs using a rdbms, in addition to the one Simon prototypes, that could also give you the results I think you're describing. Results that it's not entirely clear to me any user actually wants, but if they did, we could do it. With an rdbms, with something else. The technology used for your database or text index or search engine is an implementation detail. Good metadata with the semantics needed to answer the questions you might want to put it to (without having to make the computer guess probabilistically) matters -- if it's there, systems can be created to do what you want. Sure, with a rdbms. Or with specialized inverted indexing tools. Or a combination. Or something else. The best tools will depend on exactly what you're wanting to do, as well as the scale (in various dimensions), the current availability/cost of various options, etc. These are questions for programmers and software engineers. If the right semantics are captured in the data, the tool can be built -- that is the question for metadata engineers and catalogers. (To be sure, some understanding of algorithms and other aspects of how computers work is important to be able to understand what software can get out of any given data modelled/represented in any given way). I don't understand what you're driving at, what the point of this conversation is. From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] on behalf of Karen Coyle [li...@kcoyle.net] Sent: Wednesday, May 16, 2012 8:46 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] RDA, DBMS and RDF (fwd) (fwd) Thanks Simon, It's much better to have an actual mock-up than just a description. If I understand this correctly, to do this you do three separate queries. If you had been able to use a single query (e.g. if you had an overall keyword index), with UNION ALL would you have been able to retain instances where the same keyword appears more than once in the record? In other words, I'm wondering if one entry for the weasels came from the title and one from the subject heading. If one book had two subject headings, could you get this result just from a subject heading search? (I'm thinking that using a search on different indexes that match the search key rather than a single index is an added factor.) kc On 5/16/12 4:38 PM, Simon Spero wrote: On Wed, May 16, 2012 at 5:50 AM, Karen Coyleli...@kcoyle.netmailto:li...@kcoyle.net wrote: This confirms what I was saying about retrieval. There are some on this list that claim that there ARE systems that could do what I asked (the bibliographic record will display 3 times in the list of retrievals). I can explain (with a bunch of drawings) why each record appears only once. Those who disagree with me should point to an example, and then we can analyze the functionality. But I want to see something real. You seem to be saying that you can use drawings that will show that it is not possible to have records show up more than once in a search using DBMS. Despite my name, I prefer to do coding. So, rather than draw this out, I'll ask a DBMS - in this case I'll go with PostgresSQL, a mature, open source relational database system. I'll create a simplified database table, with columns for author, title, and the primary subject heading. I'll also add an id column, so we can see which row is which. This simplification is for exposition purposes. The database is real; only the data has been made up to annoy the French. Lets look at the content. # select id,title, author,subject1 from book; id
Re: [RDA-L] RDA, DBMS and RDF
individual element so one can see all the relevants instructions as one is constructing an authorized access point. This will further solidify the idea that Authorized Access Points are creatures belonging to some catalog implementations, but may not be needed in others. I'm also beginning to believe that we may need indicators in the MARC fields for the elements that would be included in an authorized access point, so that a machine could generate them on the fly. If you have recorded, for example, multiple professions/occupations, you might want to designate which one should go into the authorized access point. Or you might record one or more professions that would never go into the access point, and you might want to tell the system that too. The same is true for many other elements (e.g. associated place) that are sometimes needed in an access point but which might be recorded even when not needed to differentiate an entity/access point from another. ** * Adam L. Schiff * * Principal Cataloger * * University of Washington Libraries * * Box 352900 * * Seattle, WA 98195-2900 * * (206) 543-8409 * * (206) 685-8782 fax * * asch...@u.washington.edu mailto:asch...@u.washington.edu * ** -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA, DBMS and RDF
On 5/16/12 10:21 AM, Brenndorfer, Thomas wrote: And it would be worthwhile knowing how these issues can be handled with the Linked Data link to the controlled vocabulary in the example authority record: Air pilots http://id.loc.gov/authorities/subjects/sh85002673 I think the answer is that we don't know yet, but that this is an issue that libraries and the semantic web community need to work on together. We may be the first community that has extensive examples in this area. Remember that the semantic web standards that exist today are kind of the ground floor standards. There is a lot of work going on to create the upper storeys. I'll check and see if this has been brought up to the W3C yet, and if not explore how to get it on their radar. kc Thomas Brenndorfer Guelph Public Library *From:*Karen Coyle [mailto:li...@kcoyle.net] *Sent:* May 16, 2012 12:06 PM *To:* Resource Description and Access / Resource Description and Access *Cc:* Brenndorfer, Thomas *Subject:* Re: [RDA-L] RDA, DBMS and RDF The question of plurals has come up in the discussions of vocabularies within JSC, since the vocabularies that are coded in the Open Metadata Registry (at http://rdvocab.info). The first thing to remember is that the words used are merely display forms; the actual data is an identifier (at least for any controlled list). In many cases you need singular in some situations and plural in others (1 map, 3 maps). The identifier for your vocabulary term in this case does not change; if you have give map the identifier http://something.org/23435; http://something.org/23435 in your vocabulary list, it is the same in both situations. How to indicate a plural v. singular isn't clear yet, but it's an obvious need that many communities will have. The thing that we have to remember is that different natural languages handle this differently, so there needs to be a solution that works for as many language groups as possible. The key thing to remember, though, is that we are talking about *display* forms, not their underlying meaning when we contemplate singular v. plural. In most cases (at least the ones I have so far run into) we wouldn't want separate lists for singular and plural, only the option to use different displays based on the context. kc On 5/16/12 7:34 AM, Brenndorfer, Thomas wrote: For reference, here is a recent authority record with 374 (occupation) using an LCSH term: LDR cz 22 n 4500 001 541951 005 20120514104731.0 008 800520n| acannaabn |a aaa 010 ‡an 79100565 035 ‡a(OCoLC)oca00332681 035 ‡a(DLC)n 79100565 035 ‡a(DLCn)703231 035 ‡a11654658 035 ‡a2898 040 ‡aDLC‡cDLC‡dDLC‡dMoSpS-AV‡dDLC 046 ‡f19020204‡g19740826 100 1 ‡aLindbergh, Charles A.‡q(Charles Augustus),‡d1902-1974 370 ‡aDetroit, Mich.‡bHawaii 374 ‡aAir pilots‡2lcsh 400 1 ‡wnna‡aLindbergh, Charles Augustus,‡d1902-1974 670 ‡aVan Every, D. Charles Lindbergh, his life, 1927. 670 ‡aThe entrepreneurs, an American adventure. Part 3, Expanding America [VR] 1991, c1986:‡bcontainer (Charles Lindbergh; flew across the Atlantic) 670 ‡aFunk and Wagnalls WWW Home page, Dec. 11, 2000:‡bEncyclopedia (Charles Augustus Lindbergh; b. Feb. 4, 1902, Detroit; d. Aug. 26, 1974, Maui, Hawaii; American aviator, engineer, and Pulitzer Prize winner for autobiography, The Spirit of St. Louis; first to make nonstop solo flight across Atlantic; baby son kidnapped and murdered, 1932) Thomas Brenndorfer Guelph Public Library *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *Sean Chen *Sent:* May 16, 2012 10:05 AM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] RDA, DBMS and RDF I agree values for field of activity and occupation elements should come from a controlled vocabulary, if anything to make the job of the person cataloging easier. I think I'd follow what Richard Moore says later on in the the thread: he emphasizes that a Linked Data approach would require this. Also I think the need to move away from the precoordinated Authorized Access Points and think about the rest of the elements that make up an authority record is really important. Or at least to think of them as separate beasts (which RDA does do, depending on your opinion). With field of activity, it seems to me to be less troublesome since a plural doesn't seem to cause too much dissonance in a heading (Economics vs. Economic; Statistics/Statistic) and in other situations LCSH has used a singular form; based on other guidance (Constitutional law vs Constitutional laws). Occupations are a bit more difficult with LCSH using plural a lot more; especially with headings in the category of classes of people which is where I think occupations would draw from. On top of that the actual term might often not line up with representation (Chemistry teacher vs. Professor of chemistry
Re: [RDA-L] RDA, DBMS and RDF (fwd) (fwd)
Thanks Simon, It's much better to have an actual mock-up than just a description. If I understand this correctly, to do this you do three separate queries. If you had been able to use a single query (e.g. if you had an overall keyword index), with UNION ALL would you have been able to retain instances where the same keyword appears more than once in the record? In other words, I'm wondering if one entry for the weasels came from the title and one from the subject heading. If one book had two subject headings, could you get this result just from a subject heading search? (I'm thinking that using a search on different indexes that match the search key rather than a single index is an added factor.) kc On 5/16/12 4:38 PM, Simon Spero wrote: On Wed, May 16, 2012 at 5:50 AM, Karen Coyle li...@kcoyle.net mailto:li...@kcoyle.net wrote: This confirms what I was saying about retrieval. There are some on this list that claim that there ARE systems that could do what I asked (the bibliographic record will display 3 times in the list of retrievals). I can explain (with a bunch of drawings) why each record appears only once. Those who disagree with me should point to an example, and then we can analyze the functionality. But I want to see something real. You seem to be saying that you can use drawings that will show that it is not possible to have records show up more than once in a search using DBMS. Despite my name, I prefer to do coding. So, rather than draw this out, I'll ask a DBMS - in this case I'll go with PostgresSQL, a mature, open source relational database system. I'll create a simplified database table, with columns for author, title, and the primary subject heading. I'll also add an id column, so we can see which row is which. This simplification is for exposition purposes. The database is real; only the data has been made up to annoy the French. Lets look at the content. *# select id,title, author,subject1 from book;* id | title| author | subject1 ++-+-- 5 | I hate rich people | Hollande, François | Politics--Gaffes and gaffers 2 | A brief history of white flags | Monkey, Cheese Eating-Surrender | France-History 4 | See France on twenty weasels a day | Weasel, Ima | France--Guidebooks 3 | We'll never surrender | Weasel, Ima | France--Fiction If we look at the data, we see four entries. Three of them have the word France in the subject field; one also has the word in the title. Although PostgresSQL has built in full text indexing, I'm not going to use it for this example; instead I'll just use standard SQL approximate matching - the LIKE operator. When we compare things using LIKE, the % character serves as a wild card. OPAC users may prefer to pronounce it '#'. For example, 'I hate rich people' LIKE '%France%' is false 'See France on twenty weasels a day' LIKE '%France%' is true Now we're going to try doing a search for 'France' anywhere in any of these fields. We'll also sort the results in alphabetical order, based on the field in which the word occurs. We'll do this by creating a query that has three parts - one for each field we'll be searching on. For each part of the query, we'll include the value of the matched field in a column in the result set that we'll call sort_key. Let's create the three parts of the query. First title: select id,title,author,subject1,title as sort_key from book where title like '%France%' Then subject: select id,title,author,subject1,subject1 as sort_key from book where subject1 like '%France%' Finally author: select id,title,author,subject1,author as sort_key from book where author like '%France%' (Notice that in one of these queries, we choose a different field to be the value of sort_key). Right now, we have three different queries- we need some way to combine them into a single set of results. Fortunately, we can do this using another standard SQL operator - UNION ALL.This command takes the results of two queries that return the same columns and turns them in to a single list of results. Using UNION ALL instead of UNION tells the database /not/ to get rid of any duplicate rows. select id,title,author,subject1,title as sort_key from book where title like '%France%' UNION ALL select id,title,author,subject1,subject1 as sort_key from book where subject1 like '%France%' UNION ALL select id,title,author,subject1,author as sort_key from book where author like '%France%' Finally, we'll sort the results using the sort_key column we created. It seems appropriate. To do this, we'll add an ORDER BY sort_key
[RDA-L] Library access without library catalogs
On 5/15/12 8:53 AM, Jonathan Rochkind wrote: I believe that inaction -- in ability to make significant changes in the way our data is currently recorded and maintained to accomodate contemporary needs -- will instead result in the end of the library cataloging/metadata tradition, and the end of library involvement in metadata control, if not the end of libraries. I find it deeply depressing. But I no longer find much hope that any other outcome is possible, and begin to think any time I spend trying to help arrive at change is just wasted time. Jonathan One other way to think about this is to not couch it in terms of library data but in terms of resource description. This then includes things like Dublin Core (originally designed for the description of internet resources), schema.org, and the whole host of academic projects like Bibserver [1], BIBO [2], SPAR [3]. You could also include LibraryThing [4], Open Library [5], GoodReads [6], and Freebase [7]. In other words, the way that people will discover library collections in the future may have nothing to do with the library catalog. So we might see those projects as being an entry into libraries (if libraries continue to exist). I've thought about (and not concluded much about) what we would need to connect library resources to the web. What data elements would be needed? In response to my recent blog post, a user Billio suggested that we really need use cases before we go further into modifying library data. I've started a use case page [8] on the futurelib wiki. I'm using the FRBR user tasks as headings, and did a couple of examples, although I'm not managing to make the FRBR user tasks work for me. I'd like to get use cases to add there, and would be happy to give folks write access to the page (I need to add you as a user). Just let me know. These use cases might include ways to connect to libraries from Web resources, and I think that our future might look more like an OpenURL server than a library catalog. (But that's a wild guess.) kc [1] http://bibserver.org/ [2] http://bibliontology.com/ [3] http://purl.org/spar/ [4] http://librarything.com [5] http://openlibrary.org/ [6] http://goodreads.org/ [7] http://freebase.com [8] http://futurelib.pbworks.com/w/page/53707101/Use%20Cases -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Library access without library catalogs
Thanks, Thomas. I took a quick look at the JSC document. (I have the FRBR book and will look through it. I didn't realize it was up on scribd.) The JSC doc has 3 use cases that I will add to my list. I suspect that every one of them can be resolved without resorting to the library catalog. For example, the one on finding other books by an author -- I can think of lots of ways to answer that question that might occur to today's users (Amazon, Wikipedia, the author's web site), and then it becomes an issue of how we can move the user from there to the library holdings. kc On 5/15/12 11:13 AM, Brenndorfer, Thomas wrote: This document on RDA core elements and FRBR user tasks covers a number of user scenarios: http://www.rda-jsc.org/docs/5chair15.pdf In addition, there are several FRBR and FRAD user task scenarios discussed from the point of view of user behavior in this chapter from the book FRBR: A Guide for the Perplexed: http://www.scribd.com/doc/29545162/FRBR-a-guide-for-the-perplexed#outer_page_133 Thomas Brenndorfer Guelph Public Library -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: May 15, 2012 1:19 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] Library access without library catalogs On 5/15/12 8:53 AM, Jonathan Rochkind wrote: I believe that inaction -- in ability to make significant changes in the way our data is currently recorded and maintained to accomodate contemporary needs -- will instead result in the end of the library cataloging/metadata tradition, and the end of library involvement in metadata control, if not the end of libraries. I find it deeply depressing. But I no longer find much hope that any other outcome is possible, and begin to think any time I spend trying to help arrive at change is just wasted time. Jonathan One other way to think about this is to not couch it in terms of library data but in terms of resource description. This then includes things like Dublin Core (originally designed for the description of internet resources), schema.org, and the whole host of academic projects like Bibserver [1], BIBO [2], SPAR [3]. You could also include LibraryThing [4], Open Library [5], GoodReads [6], and Freebase [7]. In other words, the way that people will discover library collections in the future may have nothing to do with the library catalog. So we might see those projects as being an entry into libraries (if libraries continue to exist). I've thought about (and not concluded much about) what we would need to connect library resources to the web. What data elements would be needed? In response to my recent blog post, a user Billio suggested that we really need use cases before we go further into modifying library data. I've started a use case page [8] on the futurelib wiki. I'm using the FRBR user tasks as headings, and did a couple of examples, although I'm not managing to make the FRBR user tasks work for me. I'd like to get use cases to add there, and would be happy to give folks write access to the page (I need to add you as a user). Just let me know. These use cases might include ways to connect to libraries from Web resources, and I think that our future might look more like an OpenURL server than a library catalog. (But that's a wild guess.) kc [1] http://bibserver.org/ [2] http://bibliontology.com/ [3] http://purl.org/spar/ [4] http://librarything.com [5] http://openlibrary.org/ [6] http://goodreads.org/ [7] http://freebase.com [8] http://futurelib.pbworks.com/w/page/53707101/Use%20Cases -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Library access without library catalogs
Thomas, they say YMMV but I looked at those pages and 1) don't see a problem with listing the books under the name of the author as listed on the book (if I'm look for Ernest Drake books I'm looking for Ernest Drake books, and I get books written under that name 2) I don't see where it says that Steer is an editor. The entries I see read: The Dragonology Handbook: A Practical Course in Dragons (Ologies) http://www.amazon.com/The-Dragonology-Handbook-Practical-Dragons/dp/076362814X/ref=la_B001H6ELHO_1_7?ie=UTF8qid=1337112787sr=1-7 by Dugald Steer (Apr 12, 2005) which is how title/author entries are shown in Amazon. The fake biography is a biography for the persona - the pseudonym. I find that perfectly acceptable. When I do the same search in WorldCat I retrieve some books with Dugald Steer and some by Ernest Drake, but no explanation that would lead me to believe that they occupy the same human body (nor do I especially care, since I'm looking for an author, not a human body). I do not seem to have a way to retrieve only the writer I am interested in, however. The wikipedia article is a stub, and will undoubtedly be expanded if he has fans, but it points to the publisher web site that gives additional information, including that he writes under the other name. Sorry, but I really don't think that the library data does more for me as a user than what I can get elsewhere, and in fact there are explanations (like linking the pseudonym to the book series he writes under) that I don't get from an authority record. kc On 5/15/12 12:23 PM, Brenndorfer, Thomas wrote: -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: May 15, 2012 2:57 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Library access without library catalogs Thanks, Thomas. I took a quick look at the JSC document. (I have the FRBR book and will look through it. I didn't realize it was up on scribd.) The JSC doc has 3 use cases that I will add to my list. I suspect that every one of them can be resolved without resorting to the library catalog. For example, the one on finding other books by an author -- I can think of lots of ways to answer that question that might occur to today's users (Amazon, Wikipedia, the author's web site), The user who isn't successful searching for a person's name as found on a book may have this kind of trouble: A library catalog distinguishes between Dugald Steer and his pseudonym, Ernest Drake. Amazon is not of much help, as it lists a fake biography of Ernest Drake: http://www.amazon.com/Ernest-Drake/e/B001NPIIZ0/ref=ntt_athr_dp_pel_1 with this skimpy author page for Dugald Steer http://www.amazon.com/Dugald-Steer/e/B001H6ELHO/ref=ntt_athr_dp_pel_2 and no cross reference. Amazon appears to be quite convinced that Ernest Drake is an author and Dugald Steer is an editor. Wikipedia entry for Dugald Steer doesn't mention that the name Ernest Drake can appear on his books: http://en.wikipedia.org/wiki/Dugald_Steer Only in the library catalog authority record for Dugald Steer do we find the full magnitude of what is happening: 100 1 ‡aSteer, Dugald 400 1 ‡aSteer, Dug 500 1 ‡wnnnc‡aDrake, Ernest 500 1 ‡wnnnc‡aSands, Emily 500 1 ‡wnnnc‡aEvans, Hestia 500 1 ‡wnnnc‡aLubber, William,‡d1965- 500 1 ‡aHardcastle, Henry,‡d1965- 500 1 ‡wnnnc‡aGray, Allen The FRBR/FRAD user tasks live or die based upon the available data elements. If the data is missing (whether in a library catalog or anywhere else) then the user task fails. Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 5/14/12 2:29 AM, Bernhard Eversberg wrote: It raises two questions, although you may not be in a position to answer the second: 1. Would you advocate a restructuring of RDA to the effect that it conforms with the relational model, or seamlessly lend itself to implementations under that concept? Or i.o.w., that RDA come with a relational table database design ready for implementation? (For otherwise, as practice has shown, different and incompatible designs will evolve.) No, I'm saying that JSC made a claim that RDA was developed on RDBMS principles, and that scenario 1 is a mock-up of an RDBMS model of RDA, albeit not in the level of detail that would actually be needed in a database. I would like to see that principle or goal tested, preferably using real data. Alternatively, someone could do an analysis of RDA in RDF, again using data. I am uneasy that we have come this far without such testing, and we know that putting RDA data in MARC is no test of these possibilities. It is possible to do a schematic mock-up of data without having a full record format. You can draw boxes and say: this goes here, and links to this over here... and database administrators do that all the time. Or you can put some actual data into a test database. Then you see if you can retrieve what you want to retrieve and display what you want to display. What happened with the MARC format is that when we moved it into actual databases it turned out that certain things that people expected or wanted didn't really work well. For example, many librarians expected that you could replicate a card catalog display with records displaying in order by the heading that was searched. That is really hard to do (and not possible to do efficiently) using DBMS functionality, which is based on retrieved sets not linear ordering, and especially using keyword searching. I'm asking: are there expectations for catalogs using RDA that will be problematic? As an example, I know that some people who have played around with FRBR-structured data have found that there are efficiency issues is formatting displays. I need to sit down and draw some diagrams, but I'm wondering about retrieval using the FRBR WEMI structure: How do you determine where to stop following links when you've retrieved on, say, a keyword in an expression record? Does it work for all cases? If not, how do you decide (algorithmically) which case you have? Maybe I just worry too much but my past experience is that there are often huge gotchas when you move from thinking about data to actually doing something with the data. 2. Is there credible progress by now in the efforts to create a successor to MARC? (After all, LC had made that e condition for implementation, and they did meanwhile decide for it to take place in 2013. Or are they taking the good intention for the deed?) And if yes, what kind of approach will it be? Relational tables? I have no idea. If your answer to question 1 is YES, wouldn't that amount to favoring the relational technology over others, potentially or probably more suitable ones? For there's that NoSQL movement gaining momentum right now. But even disregarding that, AACR was, I think, always taking pains to avoid getting involved with the fads and fashions of data structures, even MARC itself was never mentioned. Now, RDA test data have been published in nothing but MARC, only marginally embellished, thereby foregoing the opportunity to unfold much of its potential. Sticking as it does to a low-level scenario 3. I don't think that you can really design structureless data, that is data that is designed with no technology in mind. I think you can design data that is as flexible as possible, but I don't see how you can design data if you don't have some idea how you want to use it, and using it means that it has to be realized in some form. Even RDA, which wanted to be format neutral came up with scenario 1, which is a definite structure. FRBR is a structure, and FRBR is inherent in RDA. So complete format neutrality IMO is not possible, but oftentimes there is more than one actual implementation format that data can fit comfortably into. At this point, seeing a concrete example of any one format would be better than none, at least in terms of easing my mind. kc B.Eversberg -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA, DBMS and RDF
On 5/14/12 3:43 AM, Tillett, Barbara wrote: The authorized access point part of RDA is one of the carryovers from AACR2, which we hope eventually will become unnecessary in a Scenario 1 environment, other than as a default display form. Barbara, can you say more about this? Do you have examples? (Or could you make some up?) What type of retrieval would be made on RDA records compared to how we retrieve on records today? Has anyone mocked up data displays? (that aren't in MARC) It might be that I just haven't found the right site or documentation that answers my questions. kc There are several areas of RDA that had to be carried over from AACR2 simply because discussions with the relevant communities had not been completed (e.g., with the Music community, law, religion, etc. - and those discussions are underway). We also will be renewing conversations with the publishing community to revisit the RDA/ONIX framework. RDA will continue to evolve and improve with the help of our international collaborations. - Barbara Tillett, Chair, Joint Steering Committee for Development of RDA -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Sunday, May 13, 2012 1:49 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] RDA, DBMS and RDF All, After struggling for a long time with my frustration with the difficulties of dealing with MARC, FRBR and RDA concepts in the context of data management, I have done a blog post that explains some of my thinking on the topic: http://kcoyle.blogspot.com/2012/05/rda-dbms-rdf.html The short summary is that RDA is not really suitable for storage and use in a relational database system, and therefore is even further from being suitable for RDF. I use headings (access points in RDA, I believe) as my example, but there are numerous other aspects of RDA that belie its intention to support scenario one. I have intended to write something much more in depth on this topic but as that has been in progress now for a considerable time, I felt that a short, albeit incomplete, explanation was needed. I welcome all discussion on this topic. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
Mac, I'd love to see your file design. I did find an example of a record
that appears more than once in a single list, and I am wondering if you
had to replicate the record in the database to accomplish that, or if
you have another way to retrieve a record more than once on a single
keyword retrieval.
kc
On 5/14/12 8:53 AM, J. McRee Elrod wrote:
Karen said:
For example, many librarians expectedthat you could replicate a
card catalog display with records displayingin order by the heading
that was searched. That is really hard to do...
If I understnad what you mean, we had no difficulty doing this. One
example:
http://www.canadianelectroniclibrary.ca/cel-arc.html
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] RDA, DBMS and RDF
Mac, I did a search on the subject term France and on the 3d page of
hits (sorted by title) there were two titles that seemed to be for the
same item. Instead, they do turn out to be two records because there are
two volumes.
Here's the case that I'm trying to get to -- let's say you have a record
with 3 subject headings:
Working class -- France
Working class -- Dwellings -- France
Housing -- France
In a card catalog, these would result in 3 separate cards and therefore
should you look all through the subject card catalog you would see the
book in question 3 times.
In a keyword search limited to subject headings, most systems would
retrieve this record once and display it once. That has to do with how
the DBMS resolves from indexes to records. So even though a keyword may
appear more than once in a record, the record is only retrieved once.
In your catalog, which displays the subject headings on a line with the
author and title
1) will each of these subject headings appear in the display?
2) does that mean that the bibliographic record (represented by the
author and title) will display 3 times in the list of retrievals?
kc
On 5/14/12 3:02 PM, J. McRee Elrod wrote:
Karen,
Because ebrary (through whom CEL and some other clients distribute
MARC records) can only accommodate one 856$u per record, those clients
must have a monograph record for each volume of a multivolume set, and
each issue of a serial (e.g., yearbooks) having its own PDF URL.
I suspect that is why you saw what appeared to be the same record more
than once. When an individual volume has a distinctive title, that
title goes in 245$a, and the set or serial title in 490/8XX. But if
not, we must use 245$n, with the set or serial title in 245$a.
As I keep saying over and over and over, our problems arise from
systems limitations, not ISBD/AACR2/MARC21 limitations. The building
should have received out attention before the building blocks.
If what you saw was because of a 245 and a 246 being very similar, or
for some other reason, please cite an example and Matt can tell you
how his OPAC handles that.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Forwarded message
Date: Mon, 14 May 2012 10:26:19 -0700
From: Matt Elrodm...@elrod.ca
To: J. McRee Elrodm...@slc.bc.ca
Subject: Re: [RDA-L] RDA, DBMS and RDF
Mac,
I would need to know which title seems to appear twice in a hit list to
answer this question. Distinct records might *appear* to be duplicates
for multi-volume sets for example. Recall that SLC sometimes creates
redundant monograph records to handle sets and serials.
Matt
On 14/05/2012 9:58 AM, J. McRee Elrod wrote:
Karen asked:
Mac, I'd love to see your file design. I did find an example of a record
that appears more than once in a single list, and I am wondering if you
had to replicate the record in the database to accomplish that, or if
you have another way to retrieve a record more than once on a single
keyword retrieval.
I'm copying your question to the designermatt@elrod who should be able
to answer your question.
http://www.canadianelectroniclibrary.ca/cel-arc.html
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
Note to the majority of readers on RDA-L: you should feel no guilt in skipping the rest of this thread. It has veered off into a technical discussion that you may simply have no time (or use) for - kc On 5/14/12 12:50 PM, Simon Spero wrote: On Mon, May 14, 2012 at 10:45 AM, Karen Coyle li...@kcoyle.net mailto:li...@kcoyle.net wrote: What happened with the MARC format is that when we moved it into actual databases it turned out that certain things that people expected or wanted didn't really work well. For example, many librarians expected that you could *[a]* /replicate a card catalog display/ with *[b]* /records/ /displaying in order by the/ /heading that was searched/. That is really hard to do (*[c]* /and not possible to do efficiently/) using*[d]* /DBMS/ functionality, which is based on *[e]* /retrieved sets/ not /linear ordering/, and*[f] */especially using keyword searching/. [emphasis and labels added] BLUF: Not all DBMS are Relational; it is possible to efficiently retrieve records in order from many different types of DBMS, including Relational databases. [c] and [d] make the claim that it is impossible to retrieve records efficiently in some desired order using DBMS functionality. This is justified by [e] which claims that the source of this necessary inefficiency is that DBMS functionality is based on retrieved sets not linear ordering. No, that is not what I meant. Of course you can retrieve records in a given order, and we do all the time. It's about using the headings in the MARC records to establish that order. So here's the question I put to Mac: *** let's say you have a record with 3 subject headings: Working class -- France Working class -- Dwellings -- France Housing -- France In a card catalog, these would result in 3 separate cards and therefore should you look all through the subject card catalog you would see the book in question 3 times. In a keyword search limited to subject headings, most systems would retrieve this record once and display it once. That has to do with how the DBMS resolves from indexes to records. So even though a keyword may appear more than once in a record, the record is only retrieved once. In your catalog, which displays the subject headings on a line with the author and title 1) will each of these subject headings appear in the display? 2) does that mean that the bibliographic record (represented by the author and title) will display 3 times in the list of retrievals? *** I could add to that: if the record had four subject headings: Working class -- France Working class -- Dwellings -- France Housing -- France Housing -- Europe Then under what circumstances in your system design would the user see all four subject entries (heading plus bib data) in a single display? That's part of the question. The card catalog had a separate physical entry for each entry point or heading associated with the bibliographic description. Do we have a reasonably efficient way to imitate this behavior using keyword (or keyword in heading, or left-anchored string searching) in an online library catalog? (followed by: is there any reason to do that?) But I think another part is the difference between retrieval, in the database sense of the term (give me all of the records with the word *france* in a subject heading) vs. the kind of alphabetical linear access that the card catalog provided, which allows you to begin at: France -- United States -- Commerce and soon arrive at Frances E. Willard Union (Yakima, Wash.) I don't think you can get from one to the other in most online catalogs because the set of records that you can see is determined by the search that retrieves only those records with *france* in it. I've designed a browse in DBMSs using a left-anchored search that retrieves one heading (the first one hit) in a heading index followed by a long series of get next commands. Naturally, next has to also be next in alphabetical order, so the index you are traversing has to be in alphabetical order. I should say: alphabetical order that is retained even as records are added, modified or deleted. I think this may be more feasible in some DBMSs than others. However, what is obviously missing here is a display of the bib record that goes with the heading (all of that ISBD stuff). It's possible that DBMS's can do this fine today, but in my olden days when I suggested to the DBA that we'd need to get next, display that heading, then retrieve and display the bibliographic record that went with it, 20 times in order to create a page of display, I practically had to revive the DBA with a bucket of cold water. Mac's system also cannot take the display from France--US--etc to Frances E. Willard because the headings it has to work with have been retrieved on a keyword search, thus only headings with the term *france* in them are displayed. It also does
[RDA-L] RDA, DBMS and RDF
All, After struggling for a long time with my frustration with the difficulties of dealing with MARC, FRBR and RDA concepts in the context of data management, I have done a blog post that explains some of my thinking on the topic: http://kcoyle.blogspot.com/2012/05/rda-dbms-rdf.html The short summary is that RDA is not really suitable for storage and use in a relational database system, and therefore is even further from being suitable for RDF. I use headings (access points in RDA, I believe) as my example, but there are numerous other aspects of RDA that belie its intention to support scenario one. I have intended to write something much more in depth on this topic but as that has been in progress now for a considerable time, I felt that a short, albeit incomplete, explanation was needed. I welcome all discussion on this topic. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Table of content/carrier and GMD?
Having looked at Thomas' table and Mac's list, I am convinced that we can have a continuum from the specific content and carrier data, to extent, and to user display. I suspect that it may not be strictly algorithmically derivable (in either direction, e.g. from coded data to display, or from display term to coded data), but that the information should logically linked in our data because the whole provides a context that is important, both for the user and for the cataloger. In the MARC record today these elements are entirely separate. The down side of that separation is that the context cannot be used to help the cataloger or to validate the input. When coding extent the cataloger essentially starts from scratch to make a selection, yet that selection should correspond to the coded physical description information. (And vice-versa) In other words, when you have 336 $a still image 337 $a projected a helpful list of carrier types, extents and user displays could be generated. (Perhaps systems do this today, but I'm not holding my breath on that.) Another important aspect of the context is that it makes it possible to have choices about the user display. There are differences between the two tables (Thomas' and Mac's) in choice of GMD. This is not a bad thing. Since this is a user display, it should be possible to create displays that serve a particular user population. For sure it will be necessary to have these displays in different languages if RDA is to be used outside the English-speaking world. I can imagine the development of core and detailed lists that can be shared and modified as needed. This variation is possible precisely because the coded data exists to ensure uniformity of the information across communities. Having these data treated as separate in the rules and in our records makes it hard to see possible inconsistencies. As I think we saw with the simple chart that I developed of content and carrier, bringing related lists together helps us take them in as a whole. I highly recommend Thomas' list for this purpose. Then I recommend that we think about how we can bring these together in the data that we create. Thanks, kc On 4/16/12 7:07 AM, Brenndorfer, Thomas wrote: -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: April 16, 2012 7:43 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] Table of content/carrier and GMD? Has anyone already created a table that compares RDA content and carrier with the GMD terms? I found some partial ones in various slide shows (often based on Adam Schiff's giant PPT stack that seems to have become the definitive PPT on AACR to RDA), but not a complete one. Also, in looking for the GMD list itself, I could find nothing at LC in the MARC documentation, and wasn't sure if the AACR2 list has been extended. I've put together a table that compares the GMD value to the Content-Media-Carrier Type + select Extent terms (along with MARC fixed fields). The document gmd_to_cmc_and_extent_20120330.docx is at: http://rdaincanada.wikispaces.com/work+in+progress It's not exhaustive. There are more possible combinations, such as notated music on a projected medium like an overhead transparency. And the table doesn't deal with multiple carrier or hybrid carrier resources, for which additional fixed fields may be required. Still images and 3D objects have GMDs that map to RDA extent terms, and these are somewhat complicated. In some libraries, an AACR2 List 1 term is used instead (such as [graphic] for all still image resources). The Library of Congress Rule Interpretation for the GMD (AACR2 1.1C) is below: * Amendments 2001 to AACR2 revised rule 1.1C1. Under List 1, the general material designation (GMD) electronic resource has replaced computer file. Under List 2, the GMD electronic resource has replaced computer file and the GMD cartographic material has replaced globe and map. LC practice: Apply the following GMDs: electronic resource (applicable to materials cataloged after November 2001; computer file was used for materials cataloged 1989-November 2001) filmstrip (applicable to materials cataloged before 1992) graphic (applicable to materials cataloged according to Graphic Materials) microform motion picture (applicable to materials cataloged according to Chapter 7 of AACR2; not applicable to materials cataloged according to Archival Moving Image Materials) slide (applicable to materials cataloged before 1992) sound recording transparency (applicable to materials cataloged before 1992) videorecording (applicable to materials cataloged according to Chapter 7 of AACR2; not applicable to materials cataloged according to Archival Moving Image Materials) Do not apply the options in 6.5B1, 7.5B1, and 11.5B1 that permit specific material designations to be shortened
[RDA-L] Table of content/carrier and GMD?
Has anyone already created a table that compares RDA content and carrier with the GMD terms? I found some partial ones in various slide shows (often based on Adam Schiff's giant PPT stack that seems to have become the definitive PPT on AACR to RDA), but not a complete one. Also, in looking for the GMD list itself, I could find nothing at LC in the MARC documentation, and wasn't sure if the AACR2 list has been extended. Thanks, kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Table of content/carrier and GMD?
Thanks Thomas and Mac. The level of complexity between these different lists of terms is mind-boggling, and I need to study it all for a while. It would be great if we could have a single encoding of content and carrier that would serve all of the needs -- for everything from library planning to inventory to user services. I don't know how plausible that is, but it is always dangerous to input the same information separately in multiple data elements because you run the risk of ending up with contradictions - one element saying this is text and another saying it is a music sound recording, for example. Contradictions like that are irreconcilable during data processing because... well, there's no human brain there to figure out what you really meant. kc On 4/16/12 7:07 AM, Brenndorfer, Thomas wrote: -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: April 16, 2012 7:43 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] Table of content/carrier and GMD? Has anyone already created a table that compares RDA content and carrier with the GMD terms? I found some partial ones in various slide shows (often based on Adam Schiff's giant PPT stack that seems to have become the definitive PPT on AACR to RDA), but not a complete one. Also, in looking for the GMD list itself, I could find nothing at LC in the MARC documentation, and wasn't sure if the AACR2 list has been extended. I've put together a table that compares the GMD value to the Content-Media-Carrier Type + select Extent terms (along with MARC fixed fields). The document gmd_to_cmc_and_extent_20120330.docx is at: http://rdaincanada.wikispaces.com/work+in+progress It's not exhaustive. There are more possible combinations, such as notated music on a projected medium like an overhead transparency. And the table doesn't deal with multiple carrier or hybrid carrier resources, for which additional fixed fields may be required. Still images and 3D objects have GMDs that map to RDA extent terms, and these are somewhat complicated. In some libraries, an AACR2 List 1 term is used instead (such as [graphic] for all still image resources). The Library of Congress Rule Interpretation for the GMD (AACR2 1.1C) is below: * Amendments 2001 to AACR2 revised rule 1.1C1. Under List 1, the general material designation (GMD) electronic resource has replaced computer file. Under List 2, the GMD electronic resource has replaced computer file and the GMD cartographic material has replaced globe and map. LC practice: Apply the following GMDs: electronic resource (applicable to materials cataloged after November 2001; computer file was used for materials cataloged 1989-November 2001) filmstrip (applicable to materials cataloged before 1992) graphic (applicable to materials cataloged according to Graphic Materials) microform motion picture (applicable to materials cataloged according to Chapter 7 of AACR2; not applicable to materials cataloged according to Archival Moving Image Materials) slide (applicable to materials cataloged before 1992) sound recording transparency (applicable to materials cataloged before 1992) videorecording (applicable to materials cataloged according to Chapter 7 of AACR2; not applicable to materials cataloged according to Archival Moving Image Materials) Do not apply the options in 6.5B1, 7.5B1, and 11.5B1 that permit specific material designations to be shortened when they are repetitious of GMDs. * Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Comparison table of extent terms
On 4/12/12 4:27 AM, Brenndorfer, Thomas wrote: Unspecified used to be needed because of the structure of the fixed fields -- you had to put *something* in every position. It's no longer needed (and I am presuming that the age of fixed fields is over). If you don't give a value, then it is, by all logic, unspecified. In the RDA/ONIX Framework ( http://www.loc.gov/marc/marbi/2007/5chair10.pdf ), 'unspecified' is used when an implementation requires no value to be recorded. There needs to be a value to reflect the deliberate choice of recording no value. It says: The Framework also makes allowance for the incomplete or partial assignment of categories to individual resources. For example, an implementation of the Framework may define a data element corresponding to an attribute defined in the Framework, but may not require that a specified value for that attribute be recorded for all resources. In that case, the implementation would need to establish a convention for indicating that the value for an attribute is “unspecified”. Similarly, an implementation may need to establish a convention to indicate that applicability values have been assigned only partially or incompletely. This is an application or situation-specific decision. The terms in the lists for content and carrier are descriptive of the resource being described. Unspecified is about a cataloging choice, not the resource. It should not be in the same list as the description of the thing because it has a very different meaning. Obviously for the sharing of cataloging there will need to be information about the cataloging itself -- rules used, decisions made. This is not, however, information about the resource, and we should define those two separately. There are a few elements defined in RDA (e.g. cataloger notes) but I suspect that internal to systems and within our sharing environment we will want more detail. However, until we have a data format defined it's a bit hard to work on this aspect. kc Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Comparison table of extent terms
On 4/12/12 10:50 AM, Kevin M Randall wrote: Larry Creider wrote: While I can see how the term Pagination Subunits might be precise for those producing RDA records, I fail to see how it will do anything but produce derision on the part of our users. I think that Thomas was suggesting this term as the name of the RDA element, not as a label to be used for public display of the data. In fact, even the term should not be a language term -- it should be (and it is in http://rdvocab.info/) an identifier that represents a specific meaning. What the cataloger sees, what the user sees, how it is used by systems, are all open questions. Remember, the display terms can be assigned in multiple languages, and there is thought being given to how we can share different display choices beyond the natural languages being used (e.g. different displays for children's materials even though they may be coded identically.) It is, as Larry says below, like displaying values for MARC tags. So throughout this discussion we should assume that actual machine-readable values and display values are not the same thing. We can argue all we want about what is the best display term, but do not confuse that with how the data will be stored. That will be a unique identifier, used uniformly across applications. kc Of course, we will have lots of very unimaginative and/or lazy system developers/vendors who will do nothing more than take the name of the data element as the display label for that element. But it is pointless to try to come up with element names that are public-friendly, since they are not intended for public consumption. (It is no less reasonable to assume that an OPAC display should show the user a term such as Author or Creator instead of the phrase Main Entry-Personal Name or the tag 100. This is really the same issue.) Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Comparison table of extent terms
On 4/11/12 10:03 PM, Deborah Fritz wrote: Karen, I like your table as a way of looking at the lists, although I also take Thomas' point about logical clustering of content/carrier/extent terms. However, I noticed a few things about your table: - Content is a closed list, so for anything not covered by the terms provided, you need to add two terms (as per the instructions at 6.9.1): other unspecified Unspecified used to be needed because of the structure of the fixed fields -- you had to put *something* in every position. It's no longer needed (and I am presuming that the age of fixed fields is over). If you don't give a value, then it is, by all logic, unspecified. Other isn't a real list member -- it's a situation. And it's pretty useless as a term unless you are able to say what that other is. We need to figure out how we will update lists and how we will allow people to create custom values and custom lists. We need to know who created the term or list, and we need to figure out how to exchange them when we want to, how to make them visible to a wide sharing community. In the diagram that I did relating to the new bibliographic framework (http://kcoyle.blogspot.it/2012/03/can-libraries-change.html), the right-hand track, called Management, would be where folks try to work all of that out. Carrier is also a closed list, so for anything not covered by the terms provided, you need to add two terms (as per the instructions at 3.3.1): As long as it can be extended using other then it isn't closed, it's just more stable than the lists are considered open. other unspecified You are also missing from the Carrier list: object And you need to delete from the Carrier list, the grouping caption: Stereographic carriers Thanks. I've made changes based on various comments received, and at least in my browser the lists carrier and extent are now one-to-one. Extent, Extent of Still image, Extent of Text, Extent of Cartographic, Extent of 3D, Extent of Notated Music are all open lists, so instead of using audio disc, an agency could choose to use Audio CD or whatever term the agency prefers to use, as per 3.4.1.5 So, given that Extent uses an open list of terms, it has just occurred to me that *perhaps* 'Extent' simply is not meant to be machine-actionable, after all? If we don't make it machine-actionable then we have no way to do things like - select books for storage using size parameters - do accurate matching of data between systems - exchange information with communities that do have machine-actionable data, like publishers. In which case, we can't include pull-down lists in the input form; or if we do want pull-down lists to remind us of terms we *can* use, we just don't treat this element/sub-elements as a vocabulary. Hmm, I'll have to think about the implications of that. So, e.g., I could imagine something like this (but I could be VERY wrong with these examples!!): Content: cartographic 3D form Media needed to access content: unmediated Carrier: object Extent: 1 globe Remember that extent will need to be expressed as a *thing* (globe, volume, etc.) and a quantity. So it's more like it will be: carrier: globe quantity: 1 I think the examples are a helpful way to think about this. kc Content: cartographic image Media needed to access content: unmediated Carrier: sheet Extent: 1 map Content: cartographic image Media needed to access content: unmediated Carrier: volume Extent: 1 atlas (68 pages) Content: still image Media needed to access content: projected Carrier: slide Extent: 100 photographs Content: still image Media needed to access content: computer Carrier: computer disc Extent: 100 photographs Content: other Media needed to access content: unmediated Carrier: other Extent: 1 laptop computer And, hopefully, we will figure out some way to tell that these, described by two different people who want to use different Extent terms, are the same: Content: still image Media needed to access content: unmediated Carrier: sheet Extent: 1 picture Content: still image Media needed to access content: unmediated Carrier: sheet Extent: 1 drawing As I say, I might be quite wrong with these examples. It would be great to see some more 'official' examples of how these elements relate to each other. Deborah -- Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com Voice/Fax: (321) 676-1904 -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Wednesday, April 11, 2012 6:36 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: [RDA-L] Comparison table of extent terms I decided that it would be interesting to see all of the extent lists side-by-side: http://kcoyle.net/rda/extentAll.html -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Karen
[RDA-L] Comparison table of extent terms
I decided that it would be interesting to see all of the extent lists side-by-side: http://kcoyle.net/rda/extentAll.html -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Content and carrier
On 4/11/12 3:04 PM, Brenndorfer, Thomas wrote:
Extent of cartographic, still image, notated music, and 3D form are
content related extent elements. The 'still image' list is
content-related-- the carriers such as sheet or card should say
nothing about what content is on them (could be a poster, could be a
map, could be a folded sheet making a pamphlet).
Thanks, Thomas, for taking the time to work this through with me.
Is it the case, then that the terms in each of the specific extent lists
represent types of content? I realize that the list itself is related to
a type of content, but are the terms in the lists themselves descriptive
of content? Is map a type of content? Is postcard a type of content? etc.
And then I wonder if these content terms have a relationship to the
terms in the RDA Content list. Let's take cartographic as an example. In
the RDA content list (the one that determines the values in MARC 336),
we have:
cartographic dataset
cartographic image
cartographic moving image
cartographic tactile image
cartographic tactile three-dimensional form
cartographic three-dimensional form
Then we have the content terms from the cartographic extent list:
atlas
diagram
globe
map
model
profile
remote sensing image
section
view
I'm not sure how diagram, profile, section and view are used, so I'll
skip those, but could we say that:
- atlas is a type of cartographic image
- globe is a type of cartographic three-dimensional form
- map is a type of cartographic image
etc.?
In other words, do we have a BT/NT or General/Specific relationship
here? Or are they a bit mix 'n match? If there is a relationship then
we have the possibility of deriving some terms from others, or of
providing some validation. It might also help with display, since
display of the 336 seems not to be very user-friendly.
All-in-all, I am finding it a bit odd to have such similar information
expressed differently in different parts of the data, so I am seeking
some reconciliation (which, again, might be obvious to those who
catalog, but my need is to understand how it can be made more
machine-friendly).
kc
That these various extent types may be augmented with subunits for
the carriers (or themselves augment carriers) is part of the
problem:
1 atlas (3 volumes) 3 maps on 2 sheets
versus
1 computer disc (3 maps) 1 microfilm reel (1 atlas)
The broad Content Type categories are fine -- a map is a content
value subordinate to cartographic image. I don't like saying 1
cartographic image for 1 map.
Rather this is better:
Content Type = cartographic image Media Type = unmediated Carrier
Type = sheet ** Extent of Carrier Type = 1 [note: one can substitute
another term for carrier type - RDA 3.4.1.5 - these should also be
registered]
** Cartographic unit = maps ** Extent of cartographic units = 2
[these number will also trigger the plural form - maps]
Display following instruction in RDA 3.4.2.3:
2 maps on 1 sheet
I think it's possible to break down the Extent values into content
and carrier categories-- but there are rules for how they can be
later combined in displays. There are some dependencies affecting
what values go together and in what order. For example:
Content Type = cartographic image Carrier Type = volume Subunits of
Carrier Type = 233 pages
Cartographic unit = atlas Extent of cartographic unit = 1
Display following instruction in RDA 3.4.2.5:
1 atlas (233 pages)
Rules to follow: a content value ('atlas') augmented by subunit
values of the carrier 'volume' which generally happens when there is
only a single volume.
Thomas Brenndorfer Guelph Public Library
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] Content and carrier
and/or motion the extent may be a measure of duration (e.g., playing time). while extent of carrier is an attribute of the Manifestation entity: 4.4.10 Extent of the Carrier The extent of the carrier is a quantification of the number of physical units making up the carrier (e.g., number of sheets, discs, reels, etc.). RDA does not have extent of content, in part (I am told) because it would have separated the instructions for formulating the extent of content and carrier between chapters 7 and 3, respectively, and thus made it difficult for catalogers to create this mixed statement. Of course, one possible response might be that we shouldn't be creating a mixed statement, but two separate statements that could be displayed together as desired. These statements should probably also be linked to the content or carrier vocabulary term that is now carried in MARC 336, 337, or 338. I looked at ONIX to see how this might have been handled by another bibliographic schema, and it appears that ONIX has two different measures: extent, which is used for extent of the content, and measure, which measures the physical item. We have to clear up inconsistencies of this nature if we hope to produce a rational format or framework for bibliographic data. Dragging along practices from the past will result in poor quality data that cannot interact well with data from any other sources. * I can't find box anywhere in any list, but perhaps I am missing something. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Content and carrier
On 4/9/12 6:00 PM, Brenndorfer, Thomas wrote: Element: Extent Exceptions... SubElement: Extent of Cartographic Resource SubElement: Extent of Notated Music SubElement: Extent of Still Image SubElement: Extent of Text SubElement: Extent of Three-Dimensional Form which are otherwise not differentiated in MARC. It seems to me that they are in the 007. Only in LDR/06 (as in 'c' for notated music; 'e' for cartographic; 'k' for still image; 'r' for 3-D form; 'a' for text)). There are some specific 007 form values such as for still images and cartographic, but 007 generally focuses on Carrier Type values and not Content. The measurement of all of these content terms still needs a placeholder, and having separately encoded RDA Extent subelements for those reflecting an emphasis on measuring content along with the physicality of the resource would be a better method than undifferentiated 300$a in MARC. It seems to be a mixed bag. The 007 has these types: map electronic resource globe tactile material projected graphic microform nonprojected graphic motion picture kit notated music remote-sensing image sound recording text videorecording Of which these are in the RDA content list: notated music tactile material text two-dimensional moving image (which I take to be the same as motion picture) So it looks like RDA does try to do a better separation of content and carrier than exists in MARC, at least in the fixed field area. Also, RDA content has the various cartographic types (dataset, image, 3-dimensional, etc.) which I assume are subsumed under map in the MARC 007. An atlas can't be a carrier-- the carrier is defined in the RDA/ONIX Framework has having attributes such as binding and intermediation device. An atlas is only cartographic content, and the physical carrier could be three distinct physical volumes. Using all the elements, an atlas could be: Content Type: cartographic image Media Type: unmediated Carrier Type: volume Extent of Cartographic Resource: 1 atlas (3 volumes) But it is listed in RDA under extent of cartographic resource. So it's either content or carrier, and it isn't in the RDA content list. So it seems that you are saying that the extent of cartographic list is neither content nor carrier, but a display form that includes both? The Carrier Type is what conveys the content -- it's not the content itself. Specific content and form values like map, globe, poster, drawing, game, coin, score describe content and cannot serve as Carrier Type values. Values like pages and leaves are better described as subunits of volumes, or potentially subunits of other carriers such as microform or online resources. OK, this makes sense. But I don't understand what you are saying about RDA's use of these. Are you saying that RDA's use of terms like atlas in Extent of Cartographic unit is a good thing? And do you see it as content, carrier, or both? kc In the mix therefore are Extent of Carrier units, Extent of specific Content units, and Subunits of Carrier units. I don't think it's that difficult to separate the Carrier and Content values: Content Type: cartographic three-dimensional form Carrier Type: object Extent of Carrier: 1 Cartographic Content: globe Extent of Cartographic Content: 1 Display: 1 globe Content Type: cartographic image Carrier Type: volume Extent of Carrier Type: 1 volume Subunits of Extent of Carrier Type: 356 pages Cartographic Content: atlas Extent of Cartographic Content: 1 atlas Display: 1 atlas (356 pages) Content Type: cartographic image Carrier Type: sheet Extent of Carrier Type: 2 Cartographic Content: map Extent of Cartographic Content: 3 maps Display: 3 maps on 2 sheets One other consideration is the consistency of the Carrier Type value across all the Content Types. A volume is a volume regardless of whether it holds text, notated music, braille, pictures, or is an atlas. At a minimum RDA has anchored the variability in the Extent value to a more solid value in the Carrier Type element so that some comparison can be done across different types of resources. While I think there could be a better arrangement and more encoding granularity, especially for subunits, the Extent value is divided into different subelements for the special cases that emphasize the content aspect of the resource. Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Content and carrier
Thomas, it seems that you have introduced a new category: unit. Given that my interest is in creating an actual machine-actionable format for this data, I have to ask: would this unit be coded as content, carrier, or is it something different? kc On 4/10/12 1:26 AM, Brenndorfer, Thomas wrote: From: Resource Description and Access / Resource Description and Access [RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle [li...@kcoyle.net] Sent: April-09-12 1:48 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Content and carrier So it looks like RDA does try to do a better separation of content and carrier than exists in MARC, at least in the fixed field area. Also, RDA content has the various cartographic types (dataset, image, 3-dimensional, etc.) which I assume are subsumed under map in the MARC 007. Rather the 007 for map is subsumed under LDR/06=e for cartographic resources. The 007s for map and globe correspond to the cartographic expression units (i.e., the cartographic extent units). My understanding is that the 007 for map is applied to all cartographic resources, except globes and if the carrier type is microform. Other 007s would be added for the actual carriers' Media Type, like projected or computer or microform. The carriers are different -- volume, slide, object, computer disc -- and don't indicate anything cartographic in and of themselves. An atlas can't be a carrier-- the carrier is defined in the RDA/ONIX Framework has having attributes such as binding and intermediation device. An atlas is only cartographic content, and the physical carrier could be three distinct physical volumes. Using all the elements, an atlas could be: Content Type: cartographic image Media Type: unmediated Carrier Type: volume Extent of Cartographic Resource: 1 atlas (3 volumes) But it is listed in RDA under extent of cartographic resource. So it's either content or carrier, and it isn't in the RDA content list. So it seems that you are saying that the extent of cartographic list is neither content nor carrier, but a display form that includes both? RDA 3.4.2.1 for the application of cartographic units points to printed, manuscript, graphic or three-dimensional resource for situations in which the cartographic unit appears first, followed by, on occasion, the carrier type value, as in: 1 atlas (3 volumes) The situation is reversed for the other carrier types, in which the cartographic unit follows the carrier type value: 1 computer disc (xv pages, 150 maps) [from RDA 3.4.1.7.1] Specifically, cartographic units are used as subunits for: RDA 3.4.1.7.1 - computer discs, cartridges, etc. RDA 3.4.1.7.4 - microfiches [this is actually being corrected in the April update to RDA to reflect subunits for all types of microform] RDA 3.4.1.7.5 - online resources The Carrier Type is what conveys the content -- it's not the content itself. Specific content and form values like map, globe, poster, drawing, game, coin, score describe content and cannot serve as Carrier Type values. Values like pages and leaves are better described as subunits of volumes, or potentially subunits of other carriers such as microform or online resources. OK, this makes sense. But I don't understand what you are saying about RDA's use of these. Are you saying that RDA's use of terms like atlas in Extent of Cartographic unit is a good thing? And do you see it as content, carrier, or both? As in the above examples, it's a bit confusing when the carrier type can be both before or after the cartographic unit in the Extent element. It's easier to understand if there's a bit more granularity, with a recognition that the cartographic units are really expression terms, not manifestation terms. Carrying expression data inside of a manifestation element isn't wrong, I would say-- it's just may lead to some inefficiencies in duplicating that information for every manifestation for the same expression. Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
[RDA-L] Content and carrier
I have done a blog post on the RDA treatment of extent of content and carrier. Here is an unformated/unlinked version of the text, but I hope to receive comments at the blog because that keeps the original post and the comments together, for future reference. http://kcoyle.blogspot.it/2012/04/content-and-carrier.html ** RDA chapter three describes carriers. This is where you find all of the terms of measurement that appear in library data, things like: 12 slides 1 audiocassette 1 map box 16 × 30 × 20 cm There is a controlled vocabulary for carriers. http://metadataregistry.org/concept/list/page/1/vocabulary_id/46.html. It has 54 entries that are in 8 categories: audio carriers computer carriers microform carriers microscopic carriers projected image carriers stereographic carriers unmediated carriers video carriers Note that one of the examples above, map, is not included in the list of carriers. Nor is the most common extent used, pages.* These are described in their own lists, Extent of cartographic resource and Extent of text. Why are these separate from other carriers? The answer is: Because they are not carriers, they are types of content. The carrier of a map is either a globe or a sheet, but map is not a carrier, it is a type of Expression, as is text. It turns out that cataloging has been mixing content and carrier descriptions in the extent area for ... well, perhaps forever. 1 map on 4 sheets 1 atlas (xvii, 37 pages, 74 leaves of plates) 1 vocal score (x, 190 pages) In addition, when describing books the carrier isn't mentioned at all, just the content: xvii, 323 pages unless there is no extent to the content, at which point the book is called a volume: 1 volume (unpaged) I have no doubt that there are clear rules that cover all of this, telling catalogers how to formulate these statements. Yet I am totally perplexed about how to turn this into a coherent data format. In FRBR, there is something called extent of content as an attribute of the Expression entity: 4.3.8 Extent of the Expression The extent of an expression is a quantification of the intellectual content of the expression (e.g., number of words in a text, statements in a computer program, images in a comic strip, etc.). For works expressed as sound and/or motion the extent may be a measure of duration (e.g., playing time). while extent of carrier is an attribute of the Manifestation entity: 4.4.10 Extent of the Carrier The extent of the carrier is a quantification of the number of physical units making up the carrier (e.g., number of sheets, discs, reels, etc.). RDA does not have extent of content, in part (I am told) because it would have separated the instructions for formulating the extent of content and carrier between chapters 7 and 3, respectively, and thus made it difficult for catalogers to create this mixed statement. Of course, one possible response might be that we shouldn't be creating a mixed statement, but two separate statements that could be displayed together as desired. These statements should probably also be linked to the content or carrier vocabulary term that is now carried in MARC 336, 337, or 338. I looked at ONIX to see how this might have been handled by another bibliographic schema, and it appears that ONIX has two different measures: extent, which is used for extent of the content, and measure, which measures the physical item. We have to clear up inconsistencies of this nature if we hope to produce a rational format or framework for bibliographic data. Dragging along practices from the past will result in poor quality data that cannot interact well with data from any other sources. * I can't find box anywhere in any list, but perhaps I am missing something. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Content and carrier
in any list, but perhaps I am missing something. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Large print differentiation in RDA
On 4/3/12 3:54 AM, J. McRee Elrod wrote:
Icons based on fixed fields might be a solution, but RDA does not
address fixed field coding or icons.
Neither did AACR/2. In fact, we have an odd mix of rules for our data --
some from the cataloging rules, and others in MARC, with these latter
sometimes seeming to be almost ad hoc.
The question now is: will the new bibliographic framework address both,
and what will guide the creation of non-RDA fields? Will we use what we
have in MARC because it is there? Or will there be some re-thinking of
the data that originates in MARC?
kc
Locally substituting patron friendly terms for display has been
suggested; why not use patron friendly terms in the first place for
uniformity from catalogue to catalogue, coded in ISBD Area 0 placement
if not 245$h?
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] What FRBR is not
On 2/22/12 11:07 AM, Myers, John F. wrote: Karen Coyle wrote: FRBR claims to be based on a relational model, as in relational database. I do not think FRBR self-identifies as a relational model. It is an Entity-Relationship model. John, you are right. (Jonathan also made this point, so he is right, too.) The FRBR document speaks solely of E-R models, and also claims to be an abstract/conceptual model. Somehow that original idea seems to have gotten lost during the RDA process -- because we end up with a database model in the 3 scenarios, and #one is a self-proclaim RDBMS-style data model. There is also talk of a relational/object oriented model in some RDA documentation, which is odd because those are two quite different data models. So how do we unpack this? RDA seems to have gotten itself tied up with a record model of FRBR that may not be what we necessarily want. In addition, IFLA has created a formal, RDF-based (RDF/OWL) declaration of FRBR which defines FRBR as a data structure. It's a very strict data structure, as well. The question then becomes: is there a way to use FRBR as the conceptual basis of our data without limiting ourselves to a single implementation that insists that each entity be a separate record? (Jonathan will wonder why not, and I can only point to the discussions listed in the Futurelib wiki at: http://futurelib.pbworks.com/w/page/48221836/FRBR%20Models%20Discussion for a lengthy and rather technical discussion by some folks who want to do otherwise.) I think we are struggling with how to move from the conceptual to the functional. It would be nice to see some different options that are available. IN particular, I'd like to see what options are available for the implementation of RDA as machine-readable catalog data that uses FRBR concepts. What I *don't* want is for there to be only one model considered as RDA is studied in light of a new bibliographic framework. kc This may seem like hair-splitting but, while the E-R model also framed the underlying structure of relational databases, I do not think that the E-R model need be restricted so narrowly to the relational database as a specific offspring of the model. The E-R model relies on a set of entities, the relationships between those entities, the attributes of the entities, and the attributes of the relationships. This modeling seems readily extensible to implementations such as RDF, linked-data, and others. This is evidenced by the ability of the E-R model to be expressed through FBRB principles which themselves are manifested in a specific cataloging code, RDA, that has three conceived implementation scenarios. The linked-data sessions I have attended have spoken of Subject-Predicate-Object structures. I do not see a significant difference at the large-scale between the E-R model and linked-data's SPO model. E-R model details can be resolved into SPO structures as needed: Subject entity has relationship Predicate to Object entity; Subject entity has attribute-nature Predicate of Object specific attribute; Subject relationship has attribute-nature Predicate of Object specific attribute. Things are a little dicey and complicated because the E-R model relationships, as predicates between the E-R model entities, are themselves subject to SPO analysis with their attributes. But this does not seem beyond the extensibility of the linked-data modeling I have witnessed. The FRBR report, in the closing paragraph of Areas for Further Study, poses the possibility that the E-R analysis may be applicable to the structures used to store, display, and communicate bibliographic data. As we consider prospective new bibliographic frameworks, that would appear to be the stage at which we find ourselves (and the area of most controversy -- where FRBR is erroneously assumed to already apply directly to them). I am intrigued by the potentials for cross-fertilization between the competing models, as I see there the greatest opportunity to transcend the specific limitations of each (remembering that limitations are almost a universality of models, being simplifications). The challenge is to develop models that are sufficiently complex to ADEQUATELY describe reality while being sufficiently simple that they don't entail reproduction of reality (which obviates the utility of the model). John F. Myers, Catalog Librarian Schaffer Library, Union College 807 Union St. Schenectady NY 12308 518-388-6623 mye...@union.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] What FRBR is not
-- where FRBR is erroneously assumed to already apply directly to them). I am intrigued by the potentials for cross-fertilization between the competing models, as I see there the greatest opportunity to transcend the specific limitations of each (remembering that limitations are almost a universality of models, being simplifications). The challenge is to develop models that are sufficiently complex to ADEQUATELY describe reality while being sufficiently simple that they don't entail reproduction of reality (which obviates the utility of the model). John F. Myers, Catalog Librarian Schaffer Library, Union College 807 Union St. Schenectady NY 12308 518-388-6623 mye...@union.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] What FRBR is not
On 2/20/12 11:28 PM, Peter Schouten wrote: Avram was not a librarian and part of the success of MARC in those days seems to have been that librarians needed to make the needed information units explicit to the techies. FRBR is a model that helps us do the same for tomorrow's data model. FRBR claims to be based on a relational model, as in relational database. That is not tomorrow's data model; it is yesterday's, although it is a step toward tomorrow's model. The difficulty is that FRBR was conceived of in the early 1990's, and completed in the late 1990's. That makes it about 15 years old. Had we implemented FRBR by, say, the year 2000, we would be looking to migrate the model to linked data, which, from today's standpoint, is tomorrow's data model. kc On a side note: when people say FRBRized catalog they often mean FRBRized display. Peter -Oorspronkelijk bericht- Van: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] Namens Gene Fieg Verzonden: maandag 20 februari 2012 18:11 Aan: RDA-L@LISTSERV.LAC-BAC.GC.CA Onderwerp: Re: [RDA-L] What FRBR is not Decided to look up the history of MARC on Google and found this in Wikipedia; I was prompted to do this after reading Karen's remark that the creation of how FRBR should be organized should be left to computer scientists. MARC was created by such an expert, but I thought Avram was also a librarian. Anyway here is the link: http://en.wikipedia.org/wiki/MARC_standards On Fri, Feb 17, 2012 at 9:42 AM, Kevin M Randallk...@northwestern.edu wrote: I think the fundamental problem in some discussions on this list is that some people are still misunderstanding what FRBR actually is, and are talking about it as if it is something that in actuality it is not. FRBR is not about having the user think in terms of work, expression, manifestation, and item. FRBR is not about having the user approach the catalog with four steps of find, identify, select, and obtain in mind. FRBR is not a model for displaying bibliographic data to the user. FRBR is not about the user interface; it is about the underlying data. And I think that some of us who really do understand what FRBR is actually perpetuate that misunderstanding by using terminology such as FRBRized catalog and FRBRized display when talking about OPAC displays showing things like hierarchical diplays of related works and expressions. We need to come up with better terms (and probably better displays as well-no, not probably but certainly), because continuing this way we just reinforce the idea that FRBR is all about hierarchical displays of the WEMI entities. Because it's not. Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345 -- Gene Fieg Cataloger/Serials Librarian Claremont School of Theology gf...@cst.edu Claremont School of Theology and Claremont Lincoln University do not represent or endorse the accuracy or reliability of any of the information or content contained in this forwarded email. The forwarded email is that of the original sender and does not represent the views of Claremont School of Theology or Claremont Lincoln University. It has been forwarded as a courtesy for information only. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Revolution in our Minds: Seeing the World Anew
On 2/21/12 7:53 AM, Kevin M Randall wrote: James Weinheimer wrote: The very purpose of imagining different entities for work, expression, manifestation and item seem to me to imply that each entity displays one time. (I realize I am jumping to incredible conclusions and will probably be excoriated for it, but FRBR and its examples imply this very, very, very strongly) I don't see any place that FRBR implies this, strongly or not. FRBR is not talking about display. At all. Anywhere. The 3-level data model produced as part of RDA, however, clearly defines FRBR as a data storage model (in model #1). Data storage does not entirely dictate display, but there is an inevitable interaction between how you store your data and what functionality is readily available to you. This is in part what has happened with the difference between the card model and the database model. When library data moved into databases, with their random access retrieval, it became very difficult to replicate the linear card view which cataloging was still in a sense trying to implement. (It's hard to explain why this is, and I've got a draft around here somewhere... it takes a lot of pictures and some digging into the guts of how retrieval works in database management systems.) Data, data storage, retrieval and display all interact and affect what a system can and cannot do, and the efficiency (which is important if you don't have infinite resources) of the resulting system. Although FRBR and RDA claim to be format neutral, they have in them assumptions that affect storage, retrieval and display. Some of those assumptions are based on practices that are so ingrained in our view of the world that we have trouble letting them go. (Headings based on alphabetically ordered display are a good example.) Also, the need to be backward compatible (rather than looking for a way to bring the old data forward) has left a lot of older practices in the cataloging rules. We have to acknowledge that the data model and the rules will indeed have an affect on what we can do with the resulting data. To think otherwise is to engage in magical thinking. kc If you do see this anywhere in FRBR, then you must have an edition that I am totally unaware of. Please cite the edition, and page(s) in that edition, where you find this. Thank you. Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] What FRBR is not
On 2/21/12 11:55 AM, Jonathan Rochkind wrote: On 2/21/2012 1:38 PM, Karen Coyle wrote: FRBR claims to be based on a relational model, as in relational database. That is not tomorrow's data model; it is yesterday's, although it is a step toward tomorrow's model. The difficulty is that FRBR was conceived of in the early 1990's, and completed in the late 1990's. That makes it about 15 years old. I think it would have been just as much a mistake to tie the FRBR model to an RDF model as it would have/was to tie it to a relational database model. Whatever we come up with is going to last us more than 15 years, and things will change again. Now, I'll admit that I'm heretically still suspicious that an RDF data model will in fact be 'the future'. But even if it is, there will be another future (or simultaneous futures plural). Whatever we do will only last so long. Things don't stay the same in this fast-paced tech world. The problem is that we develop ideas and then wait so long to implement them that the technology environment has moved on before we get around to implementation. There is nothing wrong with FRBR being based on RDBMS in 1993 or so, but if you wait for 15 years, as we did, before implementing it you have to consider how much has changed technologically in those 15 years. If we do the same today with RDF -- develop a new bibliographic framework and take a decade to get it up and running -- our data will be DOA. There's nothing that we can do to guarantee that our data won't have to change in the future. However, using mainstream technologies, like Unicode rather than MARC-8, usually provide a better upgrade path because we're in the same boat as everyone else. But we have to keep up. Is linked data the only possible future? No, but I assume that the future includes data in the Web, Web-friendly identifiers, and new information views derived from mash-ups between what are now separate data stores. Today, the linked data standards are the ones that support this. Tomorrow, something new will come along but it will build on today's technology, not the technology of 10-15 years ago. kc I think there are some fundamental principles to data modelling for information processing that are independent of particular technologies. Now, maybe not completely independent, different technologies have different 'affordances', and that, along with changing technological capacities and just increased experience and practice do lead to a constant evolution of these fundamental principles, sure. But I think they're still there. I don't know if there are any good treatises on such a topic, fundamental trans-technological data modelling principles. (Anyone know?). If there are, I wonder if they are very mathematical, formal logic and such. (I strongly suspect that, mathematically, it can be proven that rdbms and linked data and set theory and object oriented models, etc., are all actually mathematically equivalent in expressiveness. Curious if anyone has actually done so. But at any rate, that's related to the existence of some basic principles independent of technology or serialization, I'd think). One of the fundamental aspects of data modelling is deciding what the 'things' are that you are modelling (ontology). And I think the FRBR WEMI ontology gets it _pretty good_ -- whether you are using a relational database or linked data or anything else we know of. The FRBR WEMI ontology does a pretty good job of specifying the 'things' in the bibliographic/documentary universe that we should model, in order to 'say' things about these things to create information systems to serve our users. I've tried to explain why before, I will surely try to do so again. (Whether the particular attributes and relationships added on to the WEMI ontology are as right, I'm less sure. Even the FRBR report is more hesitant and provisional there itself. Whether RDA's increased specificty/formalization of the FRBR model is as good, or the RDA linked data vocabulary formalization is as good, I don't know enough to say.) I seem to remember hearing that when the FRBR report was being worked on, some people (Svenonius?) wanted it to be expressed in the language of set theory instead. But my impression is that 'relational' language won out because the FRBR committee believed that was the language that computer programmers wanted it in. Ironic that that choice has led to the opposite outcome, to some in the more CS/programming/IT oriented community dismissing the FRBR model _because_ it uses relational language. Soon after the FRBR report came out, some argued that it should have used Object Oriented modelling language instead, that 'relational' was old, and 'OO' was new. Of course, now, everyone thinks OO is old news, and everyone wants 'linked data' (or in other sub-communities, 'type theory'). I tend to think they should have just gone with 'set theory' oriented language, because it is the most clear, while
Re: [RDA-L] What FRBR is not
On 2/21/12 12:46 PM, Jonathan Rochkind wrote: On 2/21/2012 3:29 PM, Karen Coyle wrote: Is linked data the only possible future? No, but I assume that the future includes data in the Web, Web-friendly identifiers, and new information views derived from mash-ups between what are now separate data stores. Agreed. If linked data means something this general, I do not doubt it is (part of) the future; it's RDF and triples that I'm not so sure about, but we'll see, neither am I sure they are not. Today, the linked data standards are the ones that support this. Tomorrow, something new will come along but it will build on today's technology, not the technology of 10-15 years ago. I contest this. You can certainly build applications and data ecologies based on data in the web, web friendly identifiers, and new information views derived from mash-ups without RDF or triples. Absolutely. I agree with this, and specifically did not tie linked data to RDF. How different they are from each other is a common topic of debate, (or religious wars), but many people are exploring linking in a sense that could be broader than the RDF technology as defined in the RDF standards. This could turn out to be like the SGML/XML evolution, where the first attempt turns out to be more strict than is really practical, and something more usable takes its place. kc People do it all the time. Yes, I understand that RDF and the triple model are meant to facilitate this, make it easier. I think they have also not quite caught on enough to demonstrate whether they will be The Answer or not. Now, what you DO need to support this kind of data environment is 'good data, well-designed'. And we're all still figuring out exactly how to describe or recognize 'good data' (although those that work with data often think they know it when they see it). But certainly part of the characteristics of 'good data, well designed', are good persistent shareable identifiers. Certainly in RDF triple-style linked data, and also just as certainly with anything else too. But to have good identifiers, one thing you need to know is WHAT you are identifying. Sometimes you can get away with taking a sort of ayn-randian approach well, it's obvious, we're identifying what's there in the world. I'd suggest that this likely to be shown as a fallacy almost always (I take a more 'constructivist' approach), but it's especially obvious with the bibliographic/documentary universe, since it is so abstract. We're _not_ just modelling physical things in the world -- when someone cites a page number in a book, they are NOT in fact citing the particular copy with a coffee cup ring on it that's sitting on their desk -- and that's the only physical thing in the world we can find, but it's not actually what they're citing. In order to establish an identifier that represents this 'thing' they are citing, we need to make a model of what the 'things' are. With linked data, with anything. And the FRBR WEMI ontology is a pretty-good, best-effort-yet, model of things in the bibliographic universe, aimed at providing the ontology (what we are identifying) to support data about these things needed to support our users in their tasks. Whether there's relational databases involved, whether there's linked data involved (and quite possibly BOTH can be involved, these are in some ways orthogonal), or even if there's (sadly, alas), MARC involved. Yes, the FRBR report uses 'relational' language, I think in an errant belief that that was what the computer people wanted. But I challenge the assertion that there is anything particularly tied to relational database technology about the WEMI ontology. Jonathan kc I think there are some fundamental principles to data modelling for information processing that are independent of particular technologies. Now, maybe not completely independent, different technologies have different 'affordances', and that, along with changing technological capacities and just increased experience and practice do lead to a constant evolution of these fundamental principles, sure. But I think they're still there. I don't know if there are any good treatises on such a topic, fundamental trans-technological data modelling principles. (Anyone know?). If there are, I wonder if they are very mathematical, formal logic and such. (I strongly suspect that, mathematically, it can be proven that rdbms and linked data and set theory and object oriented models, etc., are all actually mathematically equivalent in expressiveness. Curious if anyone has actually done so. But at any rate, that's related to the existence of some basic principles independent of technology or serialization, I'd think). One of the fundamental aspects of data modelling is deciding what the 'things' are that you are modelling (ontology). And I think the FRBR WEMI ontology gets it _pretty good_ -- whether you are using a relational database or linked data or anything else we know
Re: [RDA-L] Revolution in our Minds: Seeing the World Anew
On 2/20/12 10:20 AM, Brenndorfer, Thomas wrote: Identification of the resource is a big part of FRBR and cataloging, but it's a stretch to say that is the exclusive focus. Many additional elements support resource discovery beyond just identification. But there's a problem when the goal post is moved, and when the goal suddenly becomes knowledge seeking or answer discovery. Those are not the scope of FRBR or RDA. This is the heart of my argument: if the catalog has such a limited approach, what else should we be doing to serve users? Because that's where I want us to focus our energy. I consider knowledge seeking to be a much more common user need than trying to decide between two editions of War and Peace. Yet we seem to spend the great bulk of our energy on resource description, and not a whole lot on knowledge organization. However, as I understand it, the catalog is supposed to support both - it actually has to because we do not have another mechanism. If cataloging as we know it (RDA, FRBR) is wholly separated from subject access, how can the catalog support both? Isn't there a strong overlap between person, title, and subject access? Shouldn't they be interrelated? Have we totally abandoned the subject search? I would argue that MORE needs to be done with the identification task, not LESS. A good chunk of cataloging is really about managing identification marks found on the resources libraries carry. There is a need to match what is in the metadata with what is on the resource. And I would argue that this activity serves the needs of very very few people seeking information and resources. We can keep doing something that is arcane and has little use, or we can help people who are seeking information. Consider the idea of preferred names of persons and preferred titles of works, along with what constitutes a variant name or title. This decision as to what becomes preferred is often based upon the frequency of appearance of the form of the name on resources or in reference sources. In FRAD, the name entity has a unique place, but this is somewhat watered down in RDA, where the name entity and the person entity are combined, and attributes really belonging to the name are attributes linked to the person entity. Note that there are no preferred names in Google, or DBPedia, or even in VIAF, and users do just fine. I think that the whole preferred is a red herring -- we are no longer limited to slotting each name into one and only one place in a linear, alphabetical catalog. There are a whole lot of other folks who work with Person entities outside of libraries (from the IRS to HR departments to elementary schools), so 1) this is hardly a concern unique to libraries and 2) if we are going to share information we have to be able to play well with different forms of names. Identity \= name. Identities are important, but they go way beyond 'preferred' name forms. One of the principle benefits I see in RDA is that we no longer talk about the entity person and the authorized access point for that person as being one and the same (likewise for other entities). I, too, see this as an advantage, although I am seriously considering the idea that in the current environment we have no need for 'authorized access points' at all, at least not as they are defined in the cataloging rules. Facets make sense to me; authorized access points (as defined in library cataloging) less so, again since they are designed for linear, alphabetical access, something that is longer used -- not since database technology introduced direct search capabilities. kc The instructions for authorized access points are downplayed in RDA, whereas they are central for AACR2 catalogs because collocation by heading is the primary mechanism of creating order. Numeric identifiers and control numbers are given prominence in RDA as the tools to use, with the complicated authorized access point now being but one of many ways of identifying entities. That's a fairly massive shift in thinking right there, because it means separating out in our minds the mechanisms we use from a more basic and conceptual understanding of the entities of interest and how we can see those be arranged. I think it's a mistake to ignore just how how difficult but necessary this step is. Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] What FRBR is not
On 2/17/12 9:42 AM, Kevin M Randall wrote: I think the fundamental problem in some discussions on this list is that some people are still misunderstanding what FRBR actually is, and are talking about it as if it is something that in actuality it is not. FRBR is not about having the user think in terms of work, expression, manifestation, and item. FRBR is not about having the user approach the catalog with four steps of find, identify, select, and obtain in mind. FRBR is not a model for displaying bibliographic data to the user. FRBR is not about the user interface; it is about the underlying data. Here's what the FRBR document (2008 version) says: The intent was to produce a conceptual model that would serve as the basis for relating specific attributes and relationships (reflected in the record as discrete data elements) to the various tasks that users perform when consulting bibliographic records. The study makes no a priori assumptions about the bibliographic record itself, either in terms of content or structure. (p.3) I'm not sure what you intend, Kevin, by underlying data, but I think we can add to what FRBR is not: FRBR is not a data structure or a record structure. It is a *conceptual* model that allows us to discover relationships that might be useful related to the user tasks. The FRBR document is primarily about attributes and relationships. The attributes are not dramatically different to those in ISBD; the relationships are almost all new elements to be assigned during the cataloging process. Most people seem to assume that each FRBR entity will be a data structure. In fact, the RDA document (RDA Database Implementation Scenarios 5JSC/Editor/2/Rev) actually shows a physical model with separate records for each of the FRBR entities as a goal. That model is based on one possible understanding of the data, and may not be a viable data model in actual functioning systems. Also, it purports to be based on relational database concepts, and the technology community is in the process of moving from relational databases to linked data, which is another model altogether. If the FRBR model is conceptual then we should investigate options for structuring that conceptual model. We definitely should not assume that FRBR defines how the data should be structured in systems. My suggestion, BTW, is that LC do as it did when moving from physical cards to machine-readable data: put the task in the hands of skilled computer scientists who have the appropriate expertise. That expertise would include modeling for the Web as well as for large databases, testing for efficiency and stability, and designing for extensibility. kc And I think that some of us who really do understand what FRBR is actually perpetuate that misunderstanding by using terminology such as FRBRized catalog and FRBRized display when talking about OPAC displays showing things like hierarchical diplays of related works and expressions. We need to come up with better terms (and probably better displays as well-no, not probably but certainly), because continuing this way we just reinforce the idea that FRBR is all about hierarchical displays of the WEMI entities. Because it's not. Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/16/12 2:10 PM, Kevin M Randall wrote: James Weinheimer has continually asserted on this list and others that no user wants: I think a viable approach would be to ask if there are user information seeking activities that we think are not covered by the FRBR user tasks. Where can we slot: - I'm in Wikipedia and the article has references. Are any of these available to me from my library? - I've done research in area X but am a novice in that topic. Where should I begin? - What are the most popular books on this subject? - Can I share this item with my work group? - Have I already retrieved this item? - What documents cite this document, and which of those can I get digitally? (There are a bunch of user tasks at: http://kcoyle.net/temp/behaviors.jpg that came from a Mellon-funded study of information-related behaviors. That's the kind of analysis that I'd like to see us do in relation to library services.) I happen to think that these (and many others) are viable user questions that the library should be able to answer. These answers will have to involve the library catalog. If they aren't covered by FRBR then we need a way to expand the FRBR user tasks. The ones that are in FRBR seem to me to be limited to tasks that begin ... a user approaches the library catalog with an author, a title, or a subject. I happen to think that this is not the predominant way that people seek or encounter information today. I'd like to see a much expanded set of tasks. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
where a cataloger can ask an expert theology librarian for help on setting up a uniform title, a Slavic librarian on how to deal with a specific subject, and someone could ask you about your own specialty. There are *so many* great possibilities. I talk about some of it in my paper I gave in Oslo. I will post it this coming Monday. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/15/12 8:22 AM, James Weinheimer wrote: In my opinion, seeing the informational universe only through FRBR-colored glasses is not a road to the future, but can lead us only to extinction. We must adapt to whatever surprises and unpleasantness we find. Jim, is it all of FRBR that you see as problematic, or just WEMI? It seems to me that Groups 2 and 3 are equivalent (more or less, but mainly more) to what we have today as name and subject authority files. Do you find those unworkable? Would you feel differently about it if FRBR Group 1 was structured differently? Or is it mainly the user tasks that you find inadequate/unworkable? There is so much to FRBR that it seems best to be specific about what the perceived problems are. I, too, have doubts about some aspects of FRBR, but am wondering if it cannot be fixed through some adjustments of the model. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/15/12 9:53 AM, Jonathan Rochkind wrote:
Yep, I think this is an example of how the FRBR WEMI ontology is a
useful shared mental model _for us_ ('us' being anyone that produces
bibliographic metadata), in analyzing our own work and sharing it with
each other. Regardless of whether it matches the end users mental models
(which may likely vary and often be internally inconsistent), it is what
allows us to work together to create data that meets user needs and wants.
You refer to FRBR as a mental model. The FRs themselves often call
themselves conceptual models. I'm fine with FRBR as a mental model,
but not so much with it as a data model. I think that FR as a data model
is problematic. Anyone can use whatever mental models they like, and
there is undoubtedly more than one that works for bibliographic data.
But then what do we do with that conceptual model when we go to create
data?
Unfortunately, IFLA has decided to encode the FRs as data models in RDF.
There have been numerous discussions about FRBR as a data model for
linked data. I have gathered some of this in a wiki page:
http://futurelib.pbworks.com/w/page/48221836/FRBR%20Models%20Discussion
You will see there that there are some alternate data models based on
FRBR, or at least the beginnings of such models. I do think this all
needs more work, however, before we can actually create data that uses
the FRBR conceptual model but also plays well on the Web.
kc
Now, it may be that expression is _not_ very important to very many user
needs/wants, and that's why traditional cataloging hasn't addressed it
much. That's quite fine. Or it may be that very cost effective means can
be found of increasing the value of our data for certain 'user
questions' in the area of 'expression'. Or some combination of both.
(Some communities may care not at all about 'expression' and thus the
metadata creators beholden to those communities spend no time on it,
other communities and their beholden metadata creators may; by sharing a
common ontology we can still interoperate, using such information when
it is present).
Regardless, the FRBR WEMI ontology gives us a shared mental model for
analyzing and discussing these things, and creating data compatible with
each others' to meet generalized past, present, and future user needs.
Not all of them. It's not perfect, nothing is. But it's pretty darn
good, and that goodness is in fact to the testament of our communities
long history of analysis of the bibliographic universe to meet user needs.
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/15/12 12:32 PM, Jonathan Rochkind wrote: But I believe strongly that it's important when creating and sharing data that we know whether the data is about a particular manifestation, a particular expression, or a work as a whole. I suggest reading A Renear's article on the futurelib page where he explains the relationship between the WEMI entities (mostly in terms of the concept of inheritance, which he argues is not part of the FRBR model). In his analysis, WEM are not things but roles. In other words, there is no manifestation thing because manifestation is an abstraction, and cannot exist without a related expression (which cannot exist without a related work). So although it makes some sense to think of WEM as entities, working with them as such in an E-R model is problematic. Three of the Four FRBR Group 1 Entity Types are Roles, not Types.(PDF) http://www.ideals.illinois.edu/bitstream/handle/2142/9094/RenearFRBRasist07.pdf I believe this argues against being able to say that the data is about a particular W E or M without including the entire WEMI structure, but I admit that the consequences are not entirely clear. I also recommend the Murray/Tillett paper that came out recently in ITAL, because it takes a different view of how one interprets the four Group1 entities. They seem to be comfortable with a whole/part interpretation of Group 1. That same interpretation is not compatible with the IFLA FRBR document and diagrams. The remaining discussions on the futurelib page are generally critical of the IFLA model as a viable domain model, and some suggest yet other ways of looking at FRBR as a domain and data model. This isn't just a theoretical discussion. If we are to model our things as data, we have to know what the things are and how they interact with other data. It appears that as a data-producing community we don't have a clear picture yet. kc Jonathan -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/14/12 4:59 AM, Brenndorfer, Thomas wrote: The evidence to the contrary is that ILS vendors are looking for ways to incorporate FRBR into their catalogs. The latest I've heard is that Bibliocommons is doing that. FRBR will help leverage content from multiple libraries, and Bibliocommons is looking for ways to more efficiently incorporate user-supplied content such as reviews. I haven't seen the Bibliocommons implementation, but there are a number of databases using something FRBR-ish so it is possible to see how they look. LibraryThing has implemented WEMI, but I'm not sure that it uses the group2 and 3 entities. Open Library has W EM, as well as Group 2 Person (which they call author), and Group 3 subject, person, place and time. (Now that I think about it, I'm not sure what FRBR Event as a subject is supposed to be.) WorldCat does W EM as far as I can tell. WC Identities is the FRBR Person entity as both agent and subject of works. For comparison: http://openlibrary.org/authors/OL21594A/Jane_Austen http://www.librarything.com/author/austenjane http://orlabs.oclc.org/identities/lccn-n79-32879/ Other than WEMI, FRBR entities are the same kinds of things that you would tend to use as foci or facets, and IMO are quite useful ways to provide interesting views for the user. WEMI is different. I think that often when people talk about FRBR they mean WEMI. Where all of the other entities are whole things that one might talk about, WEMI is a whole thing broken into parts, and those parts are abstract and appear to be hard for most people to grasp. It's ludicrous to say that a review should apply to an expression from one publisher but not the same expression from another publisher. As we know, it gets complicated. What about reviews of the new translation of Proust? Two expressions, two very different reads. Unfortunately, it is often very hard to know what a review is reviewing. There is a book that I read in the original and loved, but that was panned in the translation. None of the reviewers had read the original. Turns out the translation was awful. How do you know whether to attach that review to the Work or the Expression? The reviewers thought they were reviewing the Work. Most of your arguments perpetuate the sad paradox that many kinds of libraries are being used more than ever but that there is a perception that they are less relevant. It is one or the other, and the numbers speak to the libraries' continuing relevance. People are using libraries more but library catalogs less. That's what the OCLC report showed. So they are finding out about resources using other means. The library catalog is a last step: where is it on the shelf, and is it checked out or not? The problem is that it is hard to justify the effort that goes into cataloging for that use case. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward[?]; was Is RDA the Only Way? An Alternative Option Through International Cooperation
These two articles: PISANSKI, Jan, ŽUMER, Maja. Mental models of the bibliographic universe : part 1 : mental models of descriptions. Journal of Documentation, 2010, vol. 66, no. 5, str. 643-667. [Preprint ] PISANSKI, Jan, ŽUMER, Maja. Mental models of the bibliographic universe : part 2 : comparison task and conclusions. Journal of Documentation, 2010, vol. 66, no. 5, str. 668-680. [Preprint ] which can be found at: http://www.ff.uni-lj.si/oddelki/biblio/oddelek/osebje/zumer.html are studies of library users and their perceptions of the structure of the bibliographic universe, which is then compared to FRBR. kc On 2/14/12 1:06 PM, Jerri Swinehart wrote: Cutter's objects and means served their purpose, but they should now be placed alongside the typewriter for documents, the village smithy's bellows for fixing wagons, and the metate for grinding corn. I would love it if catalogers would begin to ask what these incredibly powerful tools can do instead of forcing our antiquated methods onto them. Let's start by asking the library users who come through the front door rather than the ones who already work in the library. Library employees' opinions are important, but our library users who do not work here need to be asked what they would like. We, who work in libraries, can no longer assume we know what library users want. We need to ask, have them demonstrate, show us, etc. Thank you. Jerri Swinehart MLIS Metadata Technician Oakland University Kresge Library Technical Services Rochester, MI 48309-4484 swine...@oakland.edu -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] RDA as the collaboratively created way forward; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/13/12 1:31 PM, Kevin M Randall wrote: Karen Coyle wrote: The relationships are new and are the best thing to come out of FRBR. But I'm not sure that those relationships couldn't have been used without the rule changes of RDA. Could we have taken the elements of AACR and MARC and combined them with the entities and relationships of FRBR? Possibly. While I agree that it would have been possible, I think it would have been highly unlikely. Unlikely because it isn't logical/reasonable, or unlikely for other reasons? What I see is that we have a long history of supporting the creation of cataloging rules, and not much history of supporting technology standards. We have no JSC for the technology to support our catalogs, and we seem to either leave that to LoC or to the vendors. The bibliographic framework initiative is really the first major technology development the library community has undertaken since MARC, and again it's mainly an LoC effort even though it affects everyone. The development of RDA was, I believe, funded through the publishing partners, but I don't know any more than that about it. It would, however, be interesting to look at the difference in how the profession values these two efforts, RDA and bibframe, through funding and other kinds of support. Given that NISO is our information technology standards body, I would have expected the effort to take place there, but of course NISO doesn't have funding for this either. Yet we valued the new cataloging rules enough to fund those. Now we have them and have no technology platform that can make use of them. Again, it is this oversight that boggles my mind. kc Even if not, it's still hard to see how changes in the use of abbreviations are required to move us forward to a new model. The example of abbreviations is the most frequent thing used in arguments that RDA is change for the sake of change. The *reason behind* the change regarding abbreviations (and other changes such as media terminology) is one part of what RDA is about, and that reason would be making the metadata easier for the user to understand. Those specific changes aren't the reaons for writing a new code. Abbreviation practice is a prime example of a changes falling into the category of While we're at it ... If it were just these minor changes, they could easily be done via minor revision of AACR2. Much of RDA seems to be couched in terms of display, even though in theory RDA wasn't about that. I agree that there's a bit too much about display in the RDA instructions, but we also need to keep in mind that we need to have a code that allows us to create metadata that can live comfortably with our legacy data. Display is how users actually encounter the metadata, so I don't think it's totally outside RDA's purview. Furthermore, I would argue that some of the display-related instructions are necessary until we know how data might end up displaying in future environments. As an example, 2.3.1.7 talks about using a full stop to separate the common title from the enumeration or alphabetic designation, and a comma to separate the enumeration or alphabetic designation from the title of the part, section, or supplement. The common title, enumeration or alphabetic designation, and title of the part, section, or supplement are elements that together make up the title proper, and I would argue that at the current time we do need to have instructions like this. Some (many?) of of the display-related instructions may actually turn out to be less than say seem. That is, things such as the punctuation marks used to separate or surround elements in access points aren't really in the instructions, just in the examples (the examples would be absolutely useless in our current cataloging environment without those marks). To me it boils down to: what do we need more... new cataloging rules or a new data model? And if the answer is both then why haven't we been working on both this entire time? I think that part of the answer is that to many the development of RDA *was* the creation of a new model. Unfortunately, I don't think that turns out to be correct. Note also that cataloging rules and data model have never been one-to-one -- at least, not since the use of a machine-readable format. RDA does not address the elements of MARC, many of which do not come from the cataloging rules. I am somewhat baffled that work on the cataloging rules was able to go forward without addressing the actual creation of data. It is important to remember that RDA is the result of what was initially going to be just a revision of AACR2 to incorporate the FRBR concepts. Discussions during the review of the first draft of AACR3 in 2005 made it apparent that a much, much bigger change was needed. In looking to the future of metadata, it isn't enough for RDA to merely describe the there--it needs to provide a bridge from here to there. RDA
Re: [RDA-L] RDA as the collaboratively created way forward; was Is RDA the Only Way? An Alternative Option Through International Cooperation
On 2/13/12 11:03 AM, Kevin M Randall wrote: RDA is extremely valuable in defining the elements and relationships. While the instructions by themselves are not at all important for development of the technical side of the future bibliographic framework, the RDA element set is crucial. I agree that the RDA elements are important. I don't know, however, how different they are from ISBD and AACR. Does anyone know of a comparison that has been done? There is definitely a large amount of overlap. We have a comparison with MARC, but I believe it is out of date. The relationships are new and are the best thing to come out of FRBR. But I'm not sure that those relationships couldn't have been used without the rule changes of RDA. Could we have taken the elements of AACR and MARC and combined them with the entities and relationships of FRBR? Possibly. Even if not, it's still hard to see how changes in the use of abbreviations are required to move us forward to a new model. Much of RDA seems to be couched in terms of display, even though in theory RDA wasn't about that. To me it boils down to: what do we need more... new cataloging rules or a new data model? And if the answer is both then why haven't we been working on both this entire time? I think that part of the answer is that to many the development of RDA *was* the creation of a new model. Unfortunately, I don't think that turns out to be correct. Note also that cataloging rules and data model have never been one-to-one -- at least, not since the use of a machine-readable format. RDA does not address the elements of MARC, many of which do not come from the cataloging rules. I am somewhat baffled that work on the cataloging rules was able to go forward without addressing the actual creation of data. kc As far away as we are right now from that future, I truly believe we'd be much, much further behind if it weren't for RDA and the push that it is providing. And I do not think that development of the RDA element set would have come about apart from simultaneous development of a cataloging code designed to work closely with it. The rules and the elements informed each other during development. (Actually, make that are informing--development will always be ongoing.) Kevin M. Randall Principal Serials Cataloger Bibliographic Services Dept. Northwestern University Library 1970 Campus Drive Evanston, IL 60208-2300 email: k...@northwestern.edu phone: (847) 491-2939 fax: (847) 491-4345 -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Application profiles - was Period of activity - was Showing birth and death dates
be for a particular library or other application that wished to have its own variation. This document would include such things as specific policies and guidelines (like the Library of Congress Policy Statements (LCPSs) or other policies agreed by the community) for * data entry/input/cataloging, including agreements on conventions/agreements for * sharing data, policies, and best practices for * maintaining data, guidelines for * search and display of data, and possibly more aspects depending on the application need. It could be used by system vendors or designers for use in libraries or other cultural heritage institutions, or by publishers, or by individuals (creators of resources or users of the data), and so on. We now have agreements and guidelines for the library-specific application of AACR2 with the MARC 21 format for the Program for Cooperative Cataloging (PCC) through the combination of the LCRIs (Library of Congress Rule Interpretations), the PCC agreements, and related documents on application of the MARC 21 format by libraries. Likewise for RDA, we have the LCPSs and training documents to provide guidance to use RDA in our current systems, and the PCC is reviewing its own policies and guidelines for RDA. Most of those documents are already available or well underway for RDA as applied by PCC libraries or those who wish to follow their practices. I have heard from many sources that establishing an RDA application profile that is widely agreed to, would help us move more quickly beyond MARC and on to greater cost savings for cataloging operations. So now, I'd like to hear from system vendors/system designers: what more is needed and how can we best move the process along? Barbara Tillett, JSC Chair *From:*Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] mailto:[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] *On Behalf Of *James Weinheimer *Sent:* Monday, January 30, 2012 5:37 PM *To:* RDA-L@LISTSERV.LAC-BAC.GC.CA mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA *Subject:* Re: [RDA-L] Period of activity - was Showing birth and death dates On 30/01/2012 17:25, Tillett, Barbara wrote: snip RDA may have several application profiles.For the Library of Congress, we have provided the LCPS (Library of Congress Policy Statement) at 9.3.4.3 to say that our practice (for our application of RDA) will be to use active and century with this element.LC considers 'flourished' to be rather outdated.Would it help to add such an example with 'active' to RDA? /snip Could you please explain further what you mean by an application profile? That term means something very specific to me, although here it seems to be limited to display issues. Thank you. -- *James Weinheimer* weinheimer.ji...@gmail.com mailto:weinheimer.ji...@gmail.com *First Thus* http://catalogingmatters.blogspot.com/ *Cooperative Cataloging Rules* http://sites.google.com/site/opencatalogingrules/ -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working
Quoting Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca: What appears to be missing is the ability to add the horizontal relationships-- the Whole-Part relationships from an individual expression to an aggregate expression, or to other related expressions. The split in MARC authority and bibliographic data seems to hamper this flexibility, which means that expression modelling is limited to the attributes that exist in bibliographic records. For many application purposes, this might be sufficient, but it does mean a lot of baggage has to be carried to try to model aggregates out. This is where linked data technology is needed. With WEMI there is only one kind of link between each of the entities. Horizontally between W's, however, there are many possible relationships. You need more than link -- you need links with meaning (derived from abridged as). I don't know how VTLS has stored its relationships internally, but I do know that this kind of semantic linking is what makes the semantic web a great idea. kc Thomas Brenndorfer Guelph Public Library -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Heidrun Wiesenmüller Sent: January 16, 2012 11:41 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working .. If we discard the idea of aggregating works and aggregating expressions in the sense of the Working Group, we are back to aggregate works, and there is certainly more than one way of modeling them. Personally, I can think of four possibilities, which I've tried to visualize in yet another paper: http://www.mendeley.com/profiles/heidrun-wiesenmuller/ under Working papers, called Additional diagrams #3 or directly under: http://tinyurl.com/7wskyjp I didn't have the time to comment on them thoroughly, but I hope the main differences are clear from the diagrams. If you can think of more ways of modeling aggregates, please let me know. The next step should be to take a number of interesting cases (e.g. an augmented edition; a monographic series; two collections containing different expressions of the same works; a journal article as part of an aggregate work and as an off-print; a collection of essays as part of an aggregate, i.e. the question of recursiveness) and see what the models would look like in these cases. Then it should be possible to compare them as to their strengths and weaknesses. Hopefully, one model would stand out in the end as the one which works best. Then this could be a basis for questions of technical implementation. -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working
Quoting Heidrun Wiesenmüller wiesenmuel...@hdm-stuttgart.de: When I started this discussion, I already had a strong feeling that the theory presented in the final report was somehow weird. Looking back now, I find that I had only noticed the tip of the iceberg of the wrongness then. Now after all the points we've covered during the discussion, I really think the final report (in the main body of the text) gets it utterly wrong and is, I'm afraid, rather pointless. Here's the million euro question: is there a way that is right? And, bonus question: is that right way one we really think we can implement in systems? kc Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working
John, I'm dying to see how this displays. I assume this will be available for viewing at ALA? But of course I now have another question :-) for the list. FRBR appears to have been designed on presumed database management principles, in particular relational databases. A relational database is a closed system in the sense that it needs to be coherent within that one database, but no further. Does this same model work in the cloud -- and by cloud I don't mean in a huge system like WorldCat, which is really just one giant database, I mean integrated with the Web, the real cloudy cloud. kc Quoting John Espley espl...@vtls.com: Not sure what to say about is there a way that is right (I have my private opinion about that, which I'm sure most of you can guess what it is :-), but in regards to whether we can implement a system, VTLS has implemented a RDA/FRBR Implementation Scenario One in our Virtua ILS. Our system not only follows what is described in the FRBR Final Report (that is, separate, linked, Work to Expressions to Manifestations), but the system is also in line with the Final Report of the FRBR Working Group on Aggregates. That is, Virtua can have an aggregating Manifestation which is linked to its aggregating Expression to the Expressions aggregating Work as well as to the individual Work/Expressions contained in the Manifestation (see figure 3 in the Final Report). In other works the Manifestation can be linked to multiple Expressions/Works. John Espley VTLS Inc. On 1/15/2012 10:13 AM, Karen Coyle wrote: Quoting Heidrun Wiesenmüller wiesenmuel...@hdm-stuttgart.de: When I started this discussion, I already had a strong feeling that the theory presented in the final report was somehow weird. Looking back now, I find that I had only noticed the tip of the iceberg of the wrongness then. Now after all the points we've covered during the discussion, I really think the final report (in the main body of the text) gets it utterly wrong and is, I'm afraid, rather pointless. Here's the million euro question: is there a way that is right? And, bonus question: is that right way one we really think we can implement in systems? kc Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Heidrun Wiesenmüller wiesenmuel...@hdm-stuttgart.de: By the way, I find it rather absurd to have to speculate about the true meaning of the report in this way. It's not a theological tract from the Middle Ages, is it? If it were, we could just pretend to believe and go on about our business. that would be much easier! kc Moreover, I'm fairly sure that all the members of the Working Group are subscribed to this list and probably following this thread closely. So I really would appreciate it if someone would clarify the matter. If my interpretation is wrong after all, I'll leap for joy. One last point: There is no such thing as a FRBR police. So, of course, we can all just go on using whole/part relationships as a means of modeling aggregates, simply ignoring the model of the Working Group. I expect this is exactly what will happen if the Final Report is approved as is (which I sincerely hope it won't). Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Bernhard Eversberg e...@biblio.tu-bs.de: Furthermore, others have already passed us by, inventing devices that do the job we expect work records to do, and not in very complicated ways either: http://www.librarything.com/work/1386651 note their canonical title, original title, ... Librarything has done a great job of gathering information of interest to readers, including names of characters, etc. There is less emphasis in LT on describing manifestations than in library cataloging, and I believe this is why they have been free to emphasize works. LT isn't a strict inventory and does not need to distinguish clearly between two similar but not exactly the same manifestations. The manifestations that users add in their personal libraries are merely fodder for creating the work information. In at least some cases the manifestations chosen by LT users are not the exact ones on the user's shelf (and I know this from personal experience) because the underlying goal is to record the work, not the physical object. I would said that LT is what readers are interested in, and library cataloging is what libraries think libraries (and a very few scholars) need. Library cataloging is still primarily describing a manifestation, which this recent discussion is proof of. kc B.Eversberg -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca: If we want a collective entity related to individual entities, then we will make one. But in the process of doing so (from my memory of a database course), it's good to avoid unnecessary duplication and redundancy, as this effects the efficiency of systems built out of the data model. This is the *theory* of databases, but the practice varies. Most actual databases are designed with redundancy that is necessary for efficient retrieval and display. A theoretically efficient data model is not necessary a system that serves the needs of users. My concern about the theoretical model of FRBR is that in practice it will be horribly inefficient for user services. So far our discussions of FRBR are all about getting the data *in* but very little about using the data for retrieval and display. The users seem to be entirely missing from this discussion. If the library data cannot provide what LibraryThing does (and with reasonable response time), then I can assure you that we've missed the user view and have lost the users. Shouldn't we really be discussing what we want to provide for users? kc Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Tillett, Barbara b...@loc.gov: FRBR includes whole/part relationships for all of the Group 1 entities (see 5.3.1.1 - work level 5.3.2.1 - expression level 5.3.4.1 - manifesation level 5.3.6.1 - item level. The relationships between the group 1 entities are the *inherent relationships (i.e., is realized through/realizes or expresses, is embodied in/embodies, is exemplified by/exemplifies), not the *structural relationships like whole/part, accompanying, sequential, and not the *content relationships like equivalent, derivative, and descriptive. Yes, I think we've covered that in our discussion. There does seem to be some confusion about the nature of the structural relationships, which some folks seem to perceive as having a whole/part nature -- perhaps because of the terminology embodied. It would be good to clarify what that embodied means. The difficulty is that there appears to be a desire to create a whole/part from, say, a Manifestation to an Expression, which does not seem to be valid in the FRBR model, even though it is conceptually logical. If you want to say that Essay1 is a part of ManifestationX, and you want the whole/part aspect to be clear, that is different from a structural relationship using embodied. For this to be a manifestation-to-manifestation whole/part, then you need a manifestation for Essay1. But say there isn't a separate manifestation for Essay1, and it doesn't seem to make sense to say that Essay1 in ManifestationX is a part of ManifestationX. What one seems to want to be able to say is that the Expression of Essay1 is manifested in ManifestationX as a *part* of ManifestationX. If you can see a way out of this one, shout it out! kc - Barbara Tillett -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Friday, January 06, 2012 7:03 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates Quoting Tillett, Barbara b...@loc.gov: Quick note to mention that the manifestation to work bit can be handled with a placefolder at the expression level. Yes, but what is the relationship? to isn't a valid relationship. As I read both FRBR and RDA, the whole/part has to be between Manifestations. I don't see how you can have a whole/part from a Manifestation to an Expression. Or you can simply have Manifestation 1 is embodiment of Expression A Manifestation 1 is embodiment of Expression B Manifestation 1 is embodiment of Expression C This to me seems inferior to a whole/part relationship, but perhaps it is sufficient. The other option is to have (and this is hard to do without diagrams) w1 e1 m1 (the aggregate work) w2 e2 m2 (one of the essays) w3 e3 m3 (another essay) m1 has part m2 m1 has part m3 Again, without mocking this up it's hard to imagine what users would see. However, I think this is conceptually valid linked data. kc Of course there will always actually be an expression, but a cataloger may choose not to identify it for local reasons, and if someone needs it later, it can be added. This has been discussed by the JSC and with Gordon Dunsire when looking a the element set on the Open Metadata Registry, and we felt this was a workable approach that enables practice while allowing the structure to be complete in systems. As for the whole/part relationships and mapping to 505, that also is covered in RDA. Whether it would be displayed as a note as now with MARC or done otherwise in the future with links between the whole and parts will depend on systems. You may be interested in seeing a training tool used by The MARC of Quality folks (Deborah and Richard Fritz - they just did a demo here at LC yesterday) which beautifully demonstrates such links in a non-MARC environment - I hope they can show their views to others at ALA or soon thereafter. It would show you how all of your questions in this thread work nicely with RDA and FRBR. - Barbara Tillett (personal opinion) -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Friday, January 06, 2012 4:46 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates Quoting JOHN C ATTIG jx...@psu.edu: - Original Message - | Karen said: | RDA does not have a data element for contents; there is nothing | similar to the MARC 505. Karen is not quite correct. The contents (parts) of a resource are considered Related Works in RDA. The formatted contents note is a structured description of the related work -- a list of the titles of the parts of the resource. If you look at the MARC to RDA mapping provided in the RDA toolkit, you
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Jonathan Rochkind rochk...@jhu.edu: I think you need to just create an identifier for the manifestation or expression that doesn't yet exist (if it doesn't), and make the relationship M-M to E-E. The 'extra' M or E you created doens't need to have any other metadata recorded about it -- just it's M/E relationship, and the whole/part relationship you want to record. I need to diagram this. So now you have a WE with an empty M. Let's say W title: Some Essay author: John Smith E (expresses that W) language: English M1 (empty) -- part of -- M2 M3 title: Some Essay by John Smith (this one is stand-alone) M2 title: Essays on whatever When someone retrieves that W using the title, the system would display all of the M1-3 information. It would find no M1 title, but would display the relevant data from M2, the containing item. (Bonus question: could M3 ever be part of another M? Given that M's are publications, I would say no. An M can include E's, but not other M's, except perhaps in the case of bound with.) I don't think that M1 would ever be filled in. That manifestation of the essay is in fact non-existent as a stand-alone entity. I believe this is exactly the kind of thing that Heilbrun is attempting to structure with her models, only her models create a part at a work and expression level that are expressly parts. However, they are equivalent to the initial W and E here, their coding as parts is just more specific. But now the 'extra' M or E is identified in case someone later DOES want to assert things about it. Are there problems with this approach? Whether or not M/E 'contained in' relationships might conceivably be conceptually logical, a model is just a model, in the end. If the FRBR model says make 'contained in' relatinoships only M-M or E-E (or conceivably W-W) -- what are the actual practical or theoretical problems, if any, of just doing so, creating identifiers for intermediate M's or E's as neccesary? I think there are some benefits to this approach, in clarity and parsimony. I honestly can't think it through far enough to know if this creates problems in a large data store. We keep postulating individual records while the fact is that this will take place on a catalog-level scale. That's the part that's hard to think through. but I think you've got a testable hypothesis, Jonathan. kc Jonathan If you want to say that Essay1 is a part of ManifestationX, and you want the whole/part aspect to be clear, that is different from a structural relationship using embodied. For this to be a manifestation-to-manifestation whole/part, then you need a manifestation for Essay1. But say there isn't a separate manifestation for Essay1, and it doesn't seem to make sense to say that Essay1 in ManifestationX is a part of ManifestationX. What one seems to want to be able to say is that the Expression of Essay1 is manifested in ManifestationX as a *part* of ManifestationX. If you can see a way out of this one, shout it out! kc - Barbara Tillett -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Friday, January 06, 2012 7:03 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates Quoting Tillett, Barbara b...@loc.gov: Quick note to mention that the manifestation to work bit can be handled with a placefolder at the expression level. Yes, but what is the relationship? to isn't a valid relationship. As I read both FRBR and RDA, the whole/part has to be between Manifestations. I don't see how you can have a whole/part from a Manifestation to an Expression. Or you can simply have Manifestation 1 is embodiment of Expression A Manifestation 1 is embodiment of Expression B Manifestation 1 is embodiment of Expression C This to me seems inferior to a whole/part relationship, but perhaps it is sufficient. The other option is to have (and this is hard to do without diagrams) w1 e1 m1 (the aggregate work) w2 e2 m2 (one of the essays) w3 e3 m3 (another essay) m1 has part m2 m1 has part m3 Again, without mocking this up it's hard to imagine what users would see. However, I think this is conceptually valid linked data. kc Of course there will always actually be an expression, but a cataloger may choose not to identify it for local reasons, and if someone needs it later, it can be added. This has been discussed by the JSC and with Gordon Dunsire when looking a the element set on the Open Metadata Registry, and we felt this was a workable approach that enables practice while allowing the structure to be complete in systems. As for the whole/part relationships and mapping to 505, that also is covered in RDA. Whether it would be displayed as a note as now
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Casey A Mullin cmul...@stanford.edu: [I'm behind on this thread, which raced forth over the weekend. Still catching up...] In the mean time, I'll respond to Karen and Heidrun's comments. To be clear, I'm not suggesting certain works/expressions be flagged as primary or secondary. What I'm referring to is the idea that certain works/expressions need not even be identified in the data. According to FRBR, we may know they exist, but identifying them (whether through access points, identifiers, etc.) is of marginal utility in a case like this. kc: Right, none of what we're talking about relates to parts or secondary works that are not identified as such in the cataloging. We are concerned about what to do if you *do* wish to bring them out in the description. If someone wished to come back later and identify the introduction as a work in its own right, they could do that.As Karen pointed out, this can seem devilish, but only when trying to envision it in a MARC environment. kc: Nothing devilish at all in MARC: you add a 7xx for it. It's only devilish in a FRBR-based environment. [Hide Quoted Text] As for Karen's other question: snip Manifestation 1 is embodiment of Expression A Manifestation 1 is embodiment of Expression B Manifestation 1 is embodiment of Expression C something else occurs to me about this model: there is no place for a title proper for each of the expressions -- If A is the whole, and B and C are individual works in A, then where are the titles proper for B and C? /snip Title Proper is a Manifestation attribute. Expressions have no titles, per se. I would say that if an augmenting Work (like a preface) didn't have a title, that's all the more reason to forego identifying it. If you did, you'd need to devise one in RDA. kc: Exactly. So how to you do this? that's the question we are asking. A title proper can only be defined within a FRBR manifestation entity. In this case, what does your FRBR manifestation contain, given that the the part exists physically only within that aggregate manifestation? You would end up with two manifestation entities for the same physical manifestation: one with the title proper of the part, and one for the actual item in hand. Honestly, I'd like to see what this looks like. It's ok for it to be a bit sketchy, but use, if you can, the RDA properties (from http://rdvocab.info). That would really help! (You don't need to use the URIs -- the element names will be fine.) kc
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Casey A Mullin cmul...@stanford.edu: (I'm ignoring the aggregate w/e here, as it's not useful to identify) Actually, we might need it. m1 (novel published with preface) Title proper: Bend sinister embodies e1 (novel in English) realizes w1 Preferred title: Bend sinister embodies e2 (preface in English) realizes w2 Preferred title: [Title given or devised title] This doesn't seem devilish to me at all. Am I missing something? Casey, What will you display to the user? Assume that display has to be algorithmic (it's going to be done by dumb machines), so you have to follow rules for display (e.g. always display work title And Expression title And Manifestation title... or whatever you think your rules will be.) Create those rules, and display something like: 1. Voyna i Mir (Work title) Title of expression: War and Peace Manifestation title: War and Peace, by Tolstoy, with an essay by Jane Smith. date: 2007 includes 2. Essay by Jane Smith, Those crazy Russians. 1958. 3. (separate case but in the same database) work title: Tolstoy's War and Peace (a book about the work) creator: Professor John Expression title: Tolsoy's War and Peace Manifestation title: Tolstoy's War and Peace date: 2008 *** I think you are assuming that the display will be: Work title: Expression title: Manifestation title: So in the case of the essay in the book, its Work title would substitute for the Manifestation title. I'm not convinced that's a valid assumption, but it's worth trying out. (btw, although YOU might not create an expression title that is the same as the work title, unless we discover that that is illegal in FRBR then you cannot assume that someone has not done it.) kc Does this clarify what I'm getting at, or are we still talking past each other? ;) Casey -- Casey A. Mullin Discovery Metadata Librarian Metadata Development Unit Stanford University Libraries 650-736-0849 cmul...@stanford.edu http://www.caseymullin.com -- Those who need structured and granular data and the precise retrieval that results from it to carry out research and scholarship may constitute an elite minority rather than most of the people of the world (sadly), but that talented and intelligent minority is an important one for the cultural and technological advancement of humanity. It is even possible that if we did a better job of providing access to such data, we might enable the enlargement of that minority. -Martha Yee -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Brenndorfer, Thomas tbrenndor...@library.guelph.on.ca: The confusion seems to arise from the unique many-to-many relationship of the expression to the manifestation. As soon as the many kicks in for multiple expressions embodied in one manifestation, the notion of the structural relationship of parts unfortunately also kick in, but it shouldn't be necessary to invent some new vertical whole-part relationship when this happens, as this would convey the same information as the existing primary relationship. But the horizontal whole/part does exist. If the vertical relationships are enough to convey that, why does FRBR/RDA have the horizontal parts and what were they intended for? Maybe THAT's the source of the confusion. kc The many-to-many set also includes a many-to-one notion-- multiple phantom manifestations don't need to be created for an aggregating expression. Over time, each expression, and even the aggregating expression, could be found in other manifestations over time, fulfilling the many-to-many extent of the relationships, but the many-to-one is valid for the specific examples discussed. All of the established relationships are valid -- expression to aggregating expression, work to aggregating work, expression(s) to manifestation. There are even a range of manifestation-to-manifestation relationships as well, including whole-part (bound with is an item-to-item relationship though). Numerous existing conventions pick up on one or the other relationship, or collapse several together, and one might be able to infer all the relationships from this information. Displays are a problem, because the relationships may not be explicitly mapped behind the scenes for the most flexible display manipulation. Thomas Brenndorfer Guelph Public Library -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Casey A Mullin cmul...@stanford.edu: But regardless of whether the aggregate work and constituent work are directly related, or related by virtue of a common manifestation, W/E 2 and 3 need not be identified for the user in this example. As I stated previously, we may construe their existence, but the user need only be presented with W/E 1 and the three M's that embody it. I don't see how this could be done, algorithmically if the parts have been given a relationship of embodied in/expressed/ from the M to the W. Note that each W could be expressed and manifested in a number of different instances, so this is not a property of the work nor of the expression. Nor, in the case of a main work and a secondary work, is there any visible difference in the coding of this primary relationship. If 1, 2 and 3 are all coded identically, there is no way to know which one is the aggregate and which are the individual works. I need to back up here and say that we are talking about a linked data model, not a fixed record, so the idea of marking a W as secondary simply doesn't exist. Any such information needs to be in the relationship of the W to the M. That was the example that I gave with this: w1 e1 m1 (the aggregate work) w2 e2 m2 (one of the essays) w3 e3 m3 (another essay) m1 has part m2 m1 has part m3 I believe this is the only way to convey the information such that it can be displayed as you wish to the user. kc I hope that makes sense. Casey On 1/6/2012 1:52 PM, Karen Coyle wrote: Quoting Casey A Mullin cmul...@stanford.edu: Manifestation 1 (embodies E 1) Manifestation 2 (embodies E 1) Manifestation 3 (embodies E 1,2,3) Is embodies a part/whole relationship? Because you only have one option: Manifestation expresses Expression So this would be: Manifestation 3 (expresses E1) Manifestation 3 (expresses E2) Manifestation 3 (expresses E3) and each of those is a separate declaration of a relationship. Without a whole/part relationship in there somewhere there is nothing that says that one of them includes the others. They are all equal. The M - E relationship is not a whole/part relationship. That might be ok, but again I ask about the user view - would all three of these be displayed to the user if a search retrieved them all? And would there be anything to indicate to the user that one of them is a larger package for the other two? kc Entities we IDENTIFY (that is, fully so, beyond oblique mention in statement of responsibility or other notes): Work 1 Expression 1 Work/Expression 2-3 definitely exist, but their existence is implied, and need not be identified using RDA's methods (access points, identifiers) Manifestations 1-3 The use case would be thus: User is presented with Work/Expression 1, then the 3 Manifestations embodying it. (Presumably, W/E 1 are the primary entities of interest.) If the user wanted to probe deeper, they could learn about the existence of W/E 2 (the supplemental material) through its oblique mention in the description for M 3. As for how RDA turns this model into practice, the answer lies in Chapter 17. Whatever the nature of a resource (aggregate or not), RDA only requires at a minimum that the predominant or first-named work/expression be identified. This language ought to be clarified in light of this expanded understanding of aggregates; that is, what is predominant or first-named in an aggregate resource? For example, in a compilation, the aggregate W/E is favored in our current MARC implementation scenario (resulting in title main entry), but it needn't be. Rather, the encoding should be agnostic as to which entities are selected as the most salient for identification. It is not that FRBR is incompatible with our needs going forward, it is that MARC is inadequate to encode FRBRized data (which is probably why LC is ignoring Chapter 17 in the current implementation scenario; it just can't be applied correctly). Casey On 1/5/2012 5:36 PM, Karen Coyle wrote: Maybe what we need to do is develop some use cases and see how they would turn out. I'm less concerned about the cataloger view than the user view. You've probably run into some description of looking at FRBR from bottom-up vs. top down. Some folks consider the cataloger view to be bottom-up (from the thing in hand to the Work) while the user view is top down (from the Work to the item on the shelf). Here are three items. I don't know if they are enough to illustrate what worries me: 1. LC control no.: 47003534 LCCN permalink: http://lccn.loc.gov/47003534 Type of material: Book (Print, Microform, Electronic, etc.) Personal name: Nabokov, Vladimir Vladimirovich, 1899-1977. Main title: Bend sinister [by] Vladimir Nabokov. Published/Created: New York, H. Holt [1947] Description: 242 p. 21 cm. 2. LC control no.: 89040559
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Karen Coyle li...@kcoyle.net: Manifestation 1 is embodiment of Expression A Manifestation 1 is embodiment of Expression B Manifestation 1 is embodiment of Expression C something else occurs to me about this model: there is no place for a title proper for each of the expressions -- If A is the whole, and B and C are individual works in A, then where are the titles proper for B and C? Casey, you might be able to answer this one since this seems to be a common situation in music data. kc This to me seems inferior to a whole/part relationship, but perhaps it is sufficient. The other option is to have (and this is hard to do without diagrams) w1 e1 m1 (the aggregate work) w2 e2 m2 (one of the essays) w3 e3 m3 (another essay) m1 has part m2 m1 has part m3 Again, without mocking this up it's hard to imagine what users would see. However, I think this is conceptually valid linked data. kc Of course there will always actually be an expression, but a cataloger may choose not to identify it for local reasons, and if someone needs it later, it can be added. This has been discussed by the JSC and with Gordon Dunsire when looking a the element set on the Open Metadata Registry, and we felt this was a workable approach that enables practice while allowing the structure to be complete in systems. As for the whole/part relationships and mapping to 505, that also is covered in RDA. Whether it would be displayed as a note as now with MARC or done otherwise in the future with links between the whole and parts will depend on systems. You may be interested in seeing a training tool used by The MARC of Quality folks (Deborah and Richard Fritz - they just did a demo here at LC yesterday) which beautifully demonstrates such links in a non-MARC environment - I hope they can show their views to others at ALA or soon thereafter. It would show you how all of your questions in this thread work nicely with RDA and FRBR. - Barbara Tillett (personal opinion) -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Friday, January 06, 2012 4:46 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates Quoting JOHN C ATTIG jx...@psu.edu: - Original Message - | Karen said: | RDA does not have a data element for contents; there is nothing | similar to the MARC 505. Karen is not quite correct. The contents (parts) of a resource are considered Related Works in RDA. The formatted contents note is a structured description of the related work -- a list of the titles of the parts of the resource. If you look at the MARC to RDA mapping provided in the RDA toolkit, you will find that field 505 maps to RDA 25.1 (Related work). In the examples of structured descriptions of related works under 25.1, you will find examples of contents notes with the relationship designator Contains used as a caption. Note: I am looking at this from a data creation point of view. Data creation is not nearly as maleable as notions and ideas. My question is: can we create valid data using FRBR and the published RDA properties? RDA: http://rdvocab.info/ FRBR: http://metadataregistry.org/schema/show/id/5.html John, there is no contents note in the list of RDA elements. In that I am sure I am correct. And MARC 505 is a note. Therefore, nothing that is the same as the 505 exists in RDA *as defined*. It might seem the same conceptually, but I am struggling to find data definitions that support it. If the RDA 25.1 (and I note that in an earlier message to me you were the one who referred me to 27.1.1.3) is a work/work relationship then it cannot be used to indicate a relationship between a manifestation and a work. It isn't clear to me how a manifestation can have a related work, since manifestation in FRBR must manifest an expression, not a work. It isn't clear to me what kind of relationship a Work can have to a manifestation given the way that they are defined in FRBR. Also note that FRBRer, as defined in the metadata registry, has no related Work property. It does have a work/work whole/part relationship. The RDA definition of related Work is: A work related to the work represented by an identifier, a preferred access point , or a description (e.g., an adaptation, commentary, supplement, sequel, part of a larger work). I read this as a set of work/work relationships. There are no Manifestation to Work relationships in FRBR. There is a whole/part relationship between manifestations in FRBR 5.3.4.1. While it might make logical sense to point from a manifestation to related works the underlying structure of FRBR does not support this as far as I can tell. Therefore, if the RDA properties are associated definitionally
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Heidrun Wiesenmüller wiesenmuel...@hdm-stuttgart.de: Firstly, the system should be able to distinguish between an aggregate work and an ordinary work. The whole/part relationship (from my approach) would not be enough as ordinary works can have parts as well. So there should be some sort of flag for an aggregate work, perhaps a new attribute (aggregate / non-aggregate). This would require a new FRBR concept, I believe. The aggregate work, as it is a work, needs -among other things - a preferred title of its own (core element in RDA). This might be something like Bend sinister (With additional materials) (perhaps also: Nabokov, Vladimir, 1869-1922. Bend sinister (English. With additional materials), taking into account which expression of the novel has been used of the aggreagte work. I'll have to think on that some more). I don't think it can have the language in it, since language is an Expression-level concept. That makes this quite complex, though, because now I don't see a clear relationship between the translation and the original. In the case of augmentations, it might be useful to flag the predominant work in the aggregate work somehow (Casey A. Mullin suggested that in one of her posts in this thread). Then we'd also have the possibility to present non-predominant works at the end of such a list, or perhaps present them to the user only via a separate link (e.g. saying: There are also minor works of Ms Famous, such as: Introduction, in: Nabokov, Vladimir, 1869-1922. Bend sinister (With additional materials). Show minor works as well? Predominant and non-predominant would need to be relationships between the expression and the manifestation. It's not a characteristic of the work or the expression. Now if somebody looks for the work Bend sinister in an English version, the system would look for the English expression (in my diagram: E (W1)) and show all three manifestations linked to this. The system would also note that one of the manifestations is an aggregate one (there would not have to be an attribute aggregate on this level, I believe, as the aggregation is obvious from the fact that more than one expression is embodied). In this case, it would display further information about its environment. The display might look somewhat like this English version of: Nabokov, Vladimir, 1869-1922. Bend sinister - Published: New York : Vintage International, 1990 - Published: Alexandria, Va. : Time-Life Books, 1981, c1947. Together with: Ms Famous: Introduction. In: Nabokov, Vladimir, 1869-1922. Bend sinister (With additional materials) - Published: New York : H. Holt, [1947] Would that be an answer to your concerns or have I misunderstood the problem? I think your example works if there is a whole/part relationship between Bend sinister and the introduction, but not if the introduction is coded as embodied in the manifestation. In the latter case you have: W Nabokov.Bend sinister E Bend sinister. English M Bend sinister. NY, vintage, 1990 M Bend sinister. Alexandria, T-L. 1981 M Bend sinister. NY, Holt, 1947 W Ms Famous. Introduction E English M Bend sinister. Alexandria, T-L. 1981 Do a title search on Bend sinister and you retrieve the introduction if it has been coded in this way. Even if you can find an efficient way to de-duplicate at this point, the information does not exist to determine that the Introduction is a minor work, because every work is a work, and major and minor depend on the context. I believe that at this moment we do not have a way to make that distinction using FRBR. In the end I think I am agreeing with you that we need a whole/part relationship that connects the contents of manifestations to the manifestation. The current whole/part relationships in FRBR may not be sufficient, or it might be that we aren't clear about how they work in RDA. kc Heidrun -- - Prof. Heidrun Wiesenmüller M.A. Hochschule der Medien Fakultät Information und Kommunikation Wolframstr. 32, 70191 Stuttgart Tel. dienstl.: 0711/25706-188 Tel. Home Office: 0711/36565868 Fax. 0711/25706-300 www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting J. McRee Elrod m...@slc.bc.ca:
In MARC, adding a code for aggregate to LDR/06 should do it. Code
c, I assume, means a collection of separate items, as opposed to
bound withs. We use it for, as an example, a collection of manuscript
letters or sermons.
We have to consider that we may not be creating records in the sense
of MARC, but graphs that bring together data entities. The Work
will be used in a lot of different contexts. So there is no code that
will cover the whole graph. That information must be carried in the
relationships between things.
In this thread, the WEMI relationship has been spoken of as vertical,
and the whole part one as horizontal. It seems to me we need a third
term for the whole part relationship; the whole part relationship is
not horizontal; as Heidrun has pointed out in other posts, the part is
secondary to the whole. Translations and editions are horizontal, not
parts.
Absolutely! Thanks, Mac, for teasing this out.
kc
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
Quoting Tillett, Barbara b...@loc.gov: Quick note to mention that the manifestation to work bit can be handled with a placefolder at the expression level. Yes, of course. But I don't think that affects the issues here. As for the whole/part relationships and mapping to 505, that also is covered in RDA. Whether it would be displayed as a note as now with MARC or done otherwise in the future with links between the whole and parts will depend on systems. I don't think that's accurate. I think whether systems can display it will depend on how the bibliographic data is structured. It's data that drives systems, not the other way around. What we're trying to figure out is how to structure the data so that the user display will make sense. It appears that if the data for aggregates is not explicitly structured in some whole/part relationship it may not be possible to make that clear to users. Plus, we don't seem to be able to find a defined data structure that corresponds to the instructions in RDA. (I personally think that a contents note would be very useful for some situations, like listing the chapter headings of a book by a single author. I think this is useful information but it shouldn't have to be structured like an embedded work in order to be included.) You may be interested in seeing a training tool used by The MARC of Quality folks (Deborah and Richard Fritz - they just did a demo here at LC yesterday) which beautifully demonstrates such links in a non-MARC environment - I hope they can show their views to others at ALA or soon thereafter. It would show you how all of your questions in this thread work nicely with RDA and FRBR. Yes, I'm familiar with their product. Deborah and I talked recently about trying to create data for some aggregates, especially ones having the same work appear both in an aggregate and separately. After that, though, I think we need to find someone who can load the data into a triple store so we can run some actual linked data processes on it. For a while I've been wishing we had a test suite of RDA data in RDF. That would help us try out some of these ideas and see if the data elements as defined can support the retrieval and displays that we might want. It seems that it would really help if folks could see some results. We may be getting closer to that. kc - Barbara Tillett (personal opinion) -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Friday, January 06, 2012 4:46 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates Quoting JOHN C ATTIG jx...@psu.edu: - Original Message - | Karen said: | RDA does not have a data element for contents; there is nothing | similar to the MARC 505. Karen is not quite correct. The contents (parts) of a resource are considered Related Works in RDA. The formatted contents note is a structured description of the related work -- a list of the titles of the parts of the resource. If you look at the MARC to RDA mapping provided in the RDA toolkit, you will find that field 505 maps to RDA 25.1 (Related work). In the examples of structured descriptions of related works under 25.1, you will find examples of contents notes with the relationship designator Contains used as a caption. Note: I am looking at this from a data creation point of view. Data creation is not nearly as maleable as notions and ideas. My question is: can we create valid data using FRBR and the published RDA properties? RDA: http://rdvocab.info/ FRBR: http://metadataregistry.org/schema/show/id/5.html John, there is no contents note in the list of RDA elements. In that I am sure I am correct. And MARC 505 is a note. Therefore, nothing that is the same as the 505 exists in RDA *as defined*. It might seem the same conceptually, but I am struggling to find data definitions that support it. If the RDA 25.1 (and I note that in an earlier message to me you were the one who referred me to 27.1.1.3) is a work/work relationship then it cannot be used to indicate a relationship between a manifestation and a work. It isn't clear to me how a manifestation can have a related work, since manifestation in FRBR must manifest an expression, not a work. It isn't clear to me what kind of relationship a Work can have to a manifestation given the way that they are defined in FRBR. Also note that FRBRer, as defined in the metadata registry, has no related Work property. It does have a work/work whole/part relationship. The RDA definition of related Work is: A work related to the work represented by an identifier, a preferred access point , or a description (e.g., an adaptation, commentary, supplement, sequel, part of a larger work). I read this as a set of work
Re: [RDA-L] Some comments on the Final Report of the FRBR Working Group on Aggregates
works and aggregate works, connected in a meaningful way. Heidrun -- - Prof. Heidrun Wiesenmueller M.A. Stuttgart Media University Faculty of Information and Communication Wolframstrasse 32, 70191 Stuttgart, Germany www.hdm-stuttgart.de/bi -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
