Re: [RDA-L] Bibframe
-Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg Sent: Tuesday, May 28, 2013 11:38 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Bibframe 28.05.2013 23:45, J. McRee Elrod: Angelina Joseph asked: Every now and then I see the word Bibframe in emails. Is it replacing MAR= C? How is that going to be? You will have answers from those more in the loop than I, but there is my *very* biased answer. Bibframe is a work in progress, so no one knows if/when it will replace MARC. ... LC's Sally McCallum on May 24 informed the VBIBFRAME community thus: http://listserv.loc.gov/cgi-bin/wa?A2=ind1305L=bibframeT=0P=43920 And this is but one example of the openness of the Bibframe development process of which I am very impressed. We catalogers do have a chance to monitor and influence the development of our future toolset. There are several first rate info sci people working on this but as Mac wrote there seems to be a lack of frontline cataloger input at this point (not absent, just a minority). Michael Mitchell Technical Services Librarian Brazosport College Lake Jackson, TX Michael.mitchell at brazosport.edu
Re: [RDA-L] Bibframe
Thanks to everyone on clarifying what exactly BibFrame is. I printed out the link that Sally sent out. Mac, and all who responded to me on this, thank you. --angelina joseph -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Mitchell, Michael Sent: Wednesday, May 29, 2013 7:53 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Bibframe -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg Sent: Tuesday, May 28, 2013 11:38 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Bibframe 28.05.2013 23:45, J. McRee Elrod: Angelina Joseph asked: Every now and then I see the word Bibframe in emails. Is it replacing MAR= C? How is that going to be? You will have answers from those more in the loop than I, but there is my *very* biased answer. Bibframe is a work in progress, so no one knows if/when it will replace MARC. ... LC's Sally McCallum on May 24 informed the VBIBFRAME community thus: http://listserv.loc.gov/cgi-bin/wa?A2=ind1305L=bibframeT=0P=43920 And this is but one example of the openness of the Bibframe development process of which I am very impressed. We catalogers do have a chance to monitor and influence the development of our future toolset. There are several first rate info sci people working on this but as Mac wrote there seems to be a lack of frontline cataloger input at this point (not absent, just a minority). Michael Mitchell Technical Services Librarian Brazosport College Lake Jackson, TX Michael.mitchell at brazosport.edu
Re: [RDA-L] Bibframe
BibFrame refers to the Library of Congress program, Bibliographic Framework Initiative that is indeed exploring a transition from the MARC format. Please check their website for more information: http://www.loc.gov/bibframe/ They also have a listserv you are welcome to join. - Barbara Tillett, JSC Chair On Tue, May 28, 2013 at 3:42 PM, Joseph, Angelina angelina.jos...@marquette.edu wrote: Every now and then I see the word “Bibframe” in emails. Is it replacing MARC? How is that going to be? ** ** *-- angelina* Angelina Joseph Cataloging Librarian Ray Kay Eckstein Law Library Marquette University Milwaukee, WI 53201 Ph: 414-288-5553 Fax: 414-288-5914 email: angelina.jos...@marquette.edu ** ** -- Dr. Barbara B. Tillett, Ph.D. Chair, Joint Steering Committee for Development of RDA
Re: [RDA-L] Bibframe
Thank you, Barbara. --angelina joseph From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of JSC Chair Sent: Tuesday, May 28, 2013 2:51 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Bibframe BibFrame refers to the Library of Congress program, Bibliographic Framework Initiative that is indeed exploring a transition from the MARC format. Please check their website for more information: http://www.loc.gov/bibframe/ They also have a listserv you are welcome to join. - Barbara Tillett, JSC Chair On Tue, May 28, 2013 at 3:42 PM, Joseph, Angelina angelina.jos...@marquette.edumailto:angelina.jos...@marquette.edu wrote: Every now and then I see the word Bibframe in emails. Is it replacing MARC? How is that going to be? -- angelina Angelina Joseph Cataloging Librarian Ray Kay Eckstein Law Library Marquette University Milwaukee, WI 53201 Ph: 414-288-5553tel:414-288-5553 Fax: 414-288-5914tel:414-288-5914 email: angelina.jos...@marquette.edumailto:angelina.jos...@marquette.edu -- Dr. Barbara B. Tillett, Ph.D. Chair, Joint Steering Committee for Development of RDA
Re: [RDA-L] Bibframe
It may be awhile before it all comes to pass despite the decree that it should be in approximate sync with RDA. A recent question on the discussion list: Will it be possible to use a BIBFRAME authority to link a BIBFRAME Work describing a FRBR Work to a BIBFRAME Work description of a FRBR Expression? Maybe, but our students just want to find three sources for the report that's due tomorrow. Michael Mitchell Technical Services Librarian Brazosport College Lake Jackson, TX Michael.mitchell at brazosport.edu From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of JSC Chair Sent: Tuesday, May 28, 2013 2:51 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Bibframe BibFrame refers to the Library of Congress program, Bibliographic Framework Initiative that is indeed exploring a transition from the MARC format. Please check their website for more information: http://www.loc.gov/bibframe/ They also have a listserv you are welcome to join. - Barbara Tillett, JSC Chair On Tue, May 28, 2013 at 3:42 PM, Joseph, Angelina angelina.jos...@marquette.edumailto:angelina.jos...@marquette.edu wrote: Every now and then I see the word Bibframe in emails. Is it replacing MARC? How is that going to be? -- angelina Angelina Joseph Cataloging Librarian Ray Kay Eckstein Law Library Marquette University Milwaukee, WI 53201 Ph: 414-288-5553tel:414-288-5553 Fax: 414-288-5914tel:414-288-5914 email: angelina.jos...@marquette.edumailto:angelina.jos...@marquette.edu -- Dr. Barbara B. Tillett, Ph.D. Chair, Joint Steering Committee for Development of RDA
Re: [RDA-L] Bibframe
Angelina Joseph asked:
Every now and then I see the word Bibframe in emails. Is it replacing MAR=
C? How is that going to be?
You will have answers from those more in the loop than I, but there is
my *very* biased answer.
Bibframe is a work in progress, so no one knows if/when it will
replace MARC.
IMNSHO it is a *giant* step backward, in substituting English names
for language neutral MARC field tags (in the form bf:title), all in
the name of being more consistent with Web data. Seems to ma XML MARC
would fill that need. There is also the matter of the ambiguity of
language, leading to wrong use of the element names. (Remember the
now storied cataloguer who enter the donor in Dublin Core's
contributor?)
Bibframe has Works and Instances, as opposed to WEM, so will be little
if any better than MARC for RDA. Expressions are treated as works.
There was talk of including relationship in authorities (read access
points), meaning an an authority for each role, and one assumes
multiple entries for the same person in the same Instance, e.g.,
director/actor, author/illustrator. I think that one has been
squashed. or at least reduced. (The access point in the data would
have a URI, pointing to the established form.)
There is talk of allowing only one ISBN per Instance, leading to
separate Instances for the same edition, e.g., different bindings,
simultaneous publication by more than one publisher. serials and sets
with an ISBN for each issue/volume, kits with multiple parts having
their own ISBN. No headway seems to have been made on that one.
My impression is that those doing the work have not been on the front
line of cataloguing, and are not fully aware of the messy nature of
the bibliographic universe.
There is talk of URIs being shared. e.g., if one library establishes
an authority its URI could be used by other libraries Iwhat if the
first library drops the authority when withdrawing the relevant
work?). The use of VIAF is also being talked about. (My name there
had four forms I think before I complained.)
Bibframe proponents assume technical ability and resources many small
libraries will lack. If implemented, there will be a divide between
have and have not libraries.
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Bibframe
28.05.2013 23:45, J. McRee Elrod: Angelina Joseph asked: Every now and then I see the word Bibframe in emails. Is it replacing MAR= C? How is that going to be? You will have answers from those more in the loop than I, but there is my *very* biased answer. Bibframe is a work in progress, so no one knows if/when it will replace MARC. ... LC's Sally McCallum on May 24 informed the VBIBFRAME community thus: http://listserv.loc.gov/cgi-bin/wa?A2=ind1305L=bibframeT=0P=43920
Re: [RDA-L] BIBFRAME model document announced
Thomas Brenndorfer said: In several early chapters in RDA there is only a thin blue line separating the movement from manifestation attributes to item attributes, and from work attributes to expression attributes. For an example of a boundary, see the blue separator Other Identifying Attributes of Expressions above RDA 6.9 (Content Type). For RDA Ch. 4 (Providing Acquisitions and Access Information), the attributes can be applied to either manifestations or items. This can be seen more clearly in the RDA Element Set view (under the Tools tab), which has a hard FRBR breakdown of WEMIPFCBCOEP and all subordinate elements organized by attribute elements and then relationship elements. True, works and expressions are treated very close together in RDA. And it's certainly also true that the boundaries between the WEMI entities are not always clear-cut, and there is sometimes room for discussion and different interpretations. But I still find it very hard to accept that BIBFRAME in its first draft (if I understand it correctly) doesn't seem to accommodate for modeling a work in the abstract FRBR sense - at least not in the bibliographic part of BIBFRAME. Perhaps it would be possible to model a FRBR work in the Authority section of BIBFRAME, as obviously a FRBR work can be a subject. I share Robert Maxwell's concern, though, that BIBFRAME here seems to codify a certain form of technical implementation, namely that of bibliographic vs. authority data. A really modern data framework should, I believe, be more flexible than that. The report provides a good rationalization for its own approach, which is at a sufficiently high abstract level to account for data organization by other communities: The goal of the Bibliographic Framework Initiative is to develop a model to which various content models can be mapped. This recognizes that different communities may have different views of their resources and thus different needs for resource descriptions. This is especially pronounced as one leaves the book/text media and considers images (still and moving), cartographic resources, archival collections, and ultimately cultural artifact and museum collections. Many content models define hierarchical relationships that need to be restated in RDF graph terms and then simplified to the BIBFRAME model. For example, the origin of the Work/Instance aspects of the BIBFRAME can reflect the FRBR relationships in terms of a graph rather than as hierarchical relationships, after applying a reductionist technique to simplify things as much as possible. Formally reconciling the BIBFRAME modeling effort with an RDA-lite set of cataloging rules is a logical next step. (pg. 15 - http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf) Well, maybe it's just me, but I'm not really sure what they mean with reflecting the FRBR relationships in terms of a graph (...) after applying a reductionist technique. Some more information would have been nice. It would also have been good if the BIBFRAME paper gave some insight in the motives for digressing from FRBR. Because, although I expressed some doubts in my last mail, in fact I am certain that they've read the FRBR report... Also, I really don't like the word RDA-lite in this paragraph. BIBFRAME must also accommodate for RDA-full. 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
Re: [RDA-L] BIBFRAME model document announced
26.11.2012 12:17, James Weinheimer: Let's face it: the FRBR structure is bizarre and difficult even for trained catalogers to grasp. ... and to apply consistently end efficiently. The FRBR user tasks are from an earlier time, and in any case, the public hasn't been able to do them since keyword searching was introduced--even in our library catalogs. That has been quite awhile now and I have never seen or heard of anyone complaining. Those original tasks have been long forgotten and have now been superceded in a multitude of ways. You are turning more and more radical. Honest analysis - once it were done - might well confirm you, however. Besides, if somebody wants to navigate WEMI, it can be done now with the right catalog software. Once it were proved necessary. LT and GBS have both found some demand for it, and come up with their own solutions, not exactly along our lines of thinking and not exactly with much success (in the case of GBS at least). The first steps in the new format should be to make it in the simplest ways possible so that web creators can use our records as soon as possible. Wasn't that part of the motivation behind Dublin Core? I think it failed miserably because it did not create a format but left that to implementers. Foreseeably, each and every one of them came up with their own schemes and their own idiosyncratic syntaxes. The schema.org people are doing a somewhat better job in that they do not leave much to implementers. But then, their approach is very different from the idea of records as self-contained entities, and so it is difficult to see how to apply it in a library catalog context. Anyway, I really don't like this speculating around in this list with no input from those who should know more and might easily resolve errors in our wild guesses. Can this be called a discussion list? It is rather another Speakers' Corner, inconsequential at the end of the day. Not the first time though that I encounter this phenomenon. B.Eversberg
Re: [RDA-L] BIBFRAME model document announced
snip Anyway, I really don't like this speculating around in this list with no input from those who should know more and might easily resolve errors in our wild guesses. Can this be called a discussion list? It is rather another Speakers' Corner, inconsequential at the end of the day. Not the first time though that I encounter this phenomenon. snip How soon we get some input from Zephira (those who should know more...) will show us how much value they place on RDA. In the absence of any response, a certain amount of discussion seems entirely appropriate. On Mon, Nov 26, 2012 at 7:25 AM, Bernhard Eversberg e...@biblio.tu-bs.dewrote: 26.11.2012 12:17, James Weinheimer: Let's face it: the FRBR structure is bizarre and difficult even for trained catalogers to grasp. ... and to apply consistently end efficiently. The FRBR user tasks are from an earlier time, and in any case, the public hasn't been able to do them since keyword searching was introduced--even in our library catalogs. That has been quite awhile now and I have never seen or heard of anyone complaining. Those original tasks have been long forgotten and have now been superceded in a multitude of ways. You are turning more and more radical. Honest analysis - once it were done - might well confirm you, however. Besides, if somebody wants to navigate WEMI, it can be done now with the right catalog software. Once it were proved necessary. LT and GBS have both found some demand for it, and come up with their own solutions, not exactly along our lines of thinking and not exactly with much success (in the case of GBS at least). The first steps in the new format should be to make it in the simplest ways possible so that web creators can use our records as soon as possible. Wasn't that part of the motivation behind Dublin Core? I think it failed miserably because it did not create a format but left that to implementers. Foreseeably, each and every one of them came up with their own schemes and their own idiosyncratic syntaxes. The schema.org people are doing a somewhat better job in that they do not leave much to implementers. But then, their approach is very different from the idea of records as self-contained entities, and so it is difficult to see how to apply it in a library catalog context. Anyway, I really don't like this speculating around in this list with no input from those who should know more and might easily resolve errors in our wild guesses. Can this be called a discussion list? It is rather another Speakers' Corner, inconsequential at the end of the day. Not the first time though that I encounter this phenomenon. B.Eversberg -- Adger Williams Colgate University Library 315-228-7310 awilli...@colgate.edu
Re: [RDA-L] BIBFRAME model document announced
24.11.2012 11:37, Heidrun Wiesenmüller: ... BIBFRAME simply _must_ be able to model RDA data in the necessary granularity and specificity. That should indeed go without saying. And besides, it ought to be integrated with RDA documentation as well, so as to enable linking in both directions. When using the BIBFRAME documentation, as soon as it will replace MARC, it must be possible to find pertinent rules for any data element, and the other way. That means, BIBFRAME will have to become integrated into the Toolkit. As well as with other rules it will be employed to support. Data entry and editing have long since been in need of enhancements in these regards. Now, finally, the chances should be realized. And I mean, what chances does RDA stand for optimal implementation if there is suboptimal support at the input and editing stage. Or only unaffordable support! And that raises another question: Before engaging in heated debates about all sorts of big issues as well as detail, we need to know who will eventually be the owner of BIBFRAME and in what form and under what conditions it will be made available: liberally like MARC, or under a global monopoly licensing scheme like RDA. B.Eversberg
Re: [RDA-L] BIBFRAME model document announced
One of the first things I noticed was the example that showed Tunnel books as a subject. While this may reflect (incorrect) MARC 21 coding as 650, the resource/work being described is clearly not ABOUT tunnel books, it IS a tunnel book. The correct MARC coding of course would be either 655 and/or 380. Any new framework model needs to understand that genre/form is not the same as subject, and both need to be accommodated. ^^ 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 ~~
Re: [RDA-L] BIBFRAME model document announced
This is indeed rather unsettling. Funnily enough, they even take the FRBR report (1997 text, in the English version) as their example to show what BIBFRAME might look like (p. 16ff). But one wonders whether they've taken the trouble of actually reading it. The BIBFRAME entity work, it seems, is a mixture of the FRBR work and the FRBR expression. This doesn't seem helpful. To me, one of the most important lessons to be learned from FRBR is the importance of the work (in the FRBR sense) as a starting point for user navigation. In BIBFRAME, there doesn't seem to be a common node, to which the various expressions of the FRBR report (1997 and 2007 text, translations in various languages) could be linked - they would all be separate BIBFRAME works. Perhaps they could at least be linked together horizontally (Works can relate to other Works reflecting, for example, part / whole relationships, p. 8). The BIBFRAME instance sounds like the FRBR manifestation. FRBR item doesn't really seem to exist as an entity in its own right; it is supposedly covered by BIBFRAME holdings, which is an example for annotation, and therefore seen as something similar to cover art or a review. It should also be noted that Each BIBFRAME Instance is an instance of one and only one BIBFRAME Work. (p. 10), whereas in FRBR a manifestation may embody more than one expression. The distinctions between authority and annotation also seem rather shady to me. Subjects are given as examples for authority. Would that also include e.g. user tagging, or would this rather be annotation? Granted, this is only a first draft, and it is explicitly stated that the model is not complete (p. 8.). I also readily accept that BIBFRAME should have a wider horizon than just libraries. Among other things, this certainly means that it should be possible to have different levels of complexity (e.g. other parties might want a more simple way of representing data than we're used to) withoug becoming incompatible. But still, BIBFRAME simply _must_ be able to model RDA data in the necessary granularity and specificity. Heidrun Am 24.11.2012 00:34, schrieb Robert Maxwell: I haven't had a chance to look closely at the document yet, but it does disturb me that a team from Zephira appears to have, having thought about it for a few months, swept away nearly two decades of consideration by the best minds in the cataloging profession by apparently abandoning the FRBR model, as Mac points out below. I realize not everyone agrees with the FRBR model but I should think such a step should not happen simply because of a report from a consulting group. Sally McCallum said in her announcement that like MARC, [the model] must be able to accommodate any number of content models, which is certainly true, but one would think that at least one of those content models might be RDA, which was the entire impetus for hiring Zephira to come up with a new model for us. Since RDA is firmly based on FRBR and DOES include provisions for describing and linking to expressions, it does seem inappropriate that the new model should not provide for this entity. I have a hard time seeing how this model would be any better a fit for RDA than the current MARC model. Further, report's apparent continuation of a model that continues the division of the database into authority and instance (which I gather is more or less the equivalent of bibliographic records, see p. 10 of the report) seems extremely backward to me. In an ER linked data database we would have descriptions of the entities linked by relationship links. Bob 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. -Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of J. McRee Elrod Sent: Friday, November 23, 2012 3:41 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] BIBFRAME model document announced Posted to Bibframe: http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf Creative Work - a resource reflecting a conceptual essence of the cataloging item. Instance - a resource reflecting an individual, material embodiment of the Work. Authority - a resource reflecting key authority concepts that have defined relationships reflected in the Work and Instance. Examples of Authority Resources include People, Places, Topics, Organizations, etc. Annotation - a resource that decorates other BIBFRAME resources with additional information. Examples of such annotations include Library Holdings information, cover art and reviews. Are we to gather that RDA's Work is still a work
Re: [RDA-L] BIBFRAME model document announced
At one level I don't see the work and instance discussion in the paper of any greater significance than RDA's penchant for preferring a content vs carrier distinction in the organization of the earlier chapters in RDA. In several early chapters in RDA there is only a thin blue line separating the movement from manifestation attributes to item attributes, and from work attributes to expression attributes. For an example of a boundary, see the blue separator Other Identifying Attributes of Expressions above RDA 6.9 (Content Type). For RDA Ch. 4 (Providing Acquisitions and Access Information), the attributes can be applied to either manifestations or items. This can be seen more clearly in the RDA Element Set view (under the Tools tab), which has a hard FRBR breakdown of WEMIPFCBCOEP and all subordinate elements organized by attribute elements and then relationship elements. The report provides a good rationalization for its own approach, which is at a sufficiently high abstract level to account for data organization by other communities: The goal of the Bibliographic Framework Initiative is to develop a model to which various content models can be mapped. This recognizes that different communities may have different views of their resources and thus different needs for resource descriptions. This is especially pronounced as one leaves the book/text media and considers images (still and moving), cartographic resources, archival collections, and ultimately cultural artifact and museum collections. Many content models define hierarchical relationships that need to be restated in RDF graph terms and then simplified to the BIBFRAME model. For example, the origin of the Work/Instance aspects of the BIBFRAME can reflect the FRBR relationships in terms of a graph rather than as hierarchical relationships, after applying a reductionist technique to simplify things as much as possible. Formally reconciling the BIBFRAME modeling effort with an RDA-lite set of cataloging rules is a logical next step. (pg. 15 - http://www.loc.gov/marc/transition/pdf/marcld-report-11-21-2012.pdf) 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: November 24, 2012 5:37 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] BIBFRAME model document announced This is indeed rather unsettling. Funnily enough, they even take the FRBR report (1997 text, in the English version) as their example to show what BIBFRAME might look like (p. 16ff). But one wonders whether they've taken the trouble of actually reading it. The BIBFRAME entity work, it seems, is a mixture of the FRBR work and the FRBR expression. This doesn't seem helpful. To me, one of the most important lessons to be learned from FRBR is the importance of the work (in the FRBR sense) as a starting point for user navigation. In BIBFRAME, there doesn't seem to be a common node, to which the various expressions of the FRBR report (1997 and 2007 text, translations in various languages) could be linked - they would all be separate BIBFRAME works. Perhaps they could at least be linked together horizontally (Works can relate to other Works reflecting, for example, part / whole relationships, p. 8). The BIBFRAME instance sounds like the FRBR manifestation. FRBR item doesn't really seem to exist as an entity in its own right; it is supposedly covered by BIBFRAME holdings, which is an example for annotation, and therefore seen as something similar to cover art or a review. It should also be noted that Each BIBFRAME Instance is an instance of one and only one BIBFRAME Work. (p. 10), whereas in FRBR a manifestation may embody more than one expression. The distinctions between authority and annotation also seem rather shady to me. Subjects are given as examples for authority. Would that also include e.g. user tagging, or would this rather be annotation? Granted, this is only a first draft, and it is explicitly stated that the model is not complete (p. 8.). I also readily accept that BIBFRAME should have a wider horizon than just libraries. Among other things, this certainly means that it should be possible to have different levels of complexity (e.g. other parties might want a more simple way of representing data than we're used to) withoug becoming incompatible. But still, BIBFRAME simply _must_ be able to model RDA data in the necessary granularity and specificity. Heidrun Am 24.11.2012 00:34, schrieb Robert Maxwell: I haven't had a chance to look closely at the document yet, but it does disturb me that a team from Zephira appears to have, having thought about it for a few months, swept away nearly two decades of consideration by the best minds in the cataloging profession by apparently abandoning the FRBR model, as Mac
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 15/05/2012 17:53, Jonathan Rochkind wrote: snip Frankly, I no longer have much confidence that the library cataloging community is capable of any necessary changes in any kind of timeline fast enough to save us. Those that believe no significant changes to library cataloging or metadata practices are neccesary will have a chance to see if they are right. 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. /snip I think many share your fears. I certainly do, but it is important not to give up hope. The problem as I see it is that while everyone agrees that we should move forward, we don't even know which direction forward is. Some believe it is east, others west, others north, others up, others down. Nobody knows. Is the basic problem in libraries the way our data is currently recorded and maintained? For those who believe this, then it would mean that if libraries changed their format and cataloging practices, things would be better. But this will be expensive and disruptive. That is a simple fact. And undertaking something like that during such severe economic times makes it even more difficult. So, it seems entirely logical that people ask whether this *really will* help or whether those resources would be better used to do something else. In fact, this is such a natural question, not asking it makes people raise their eyebrows and wonder if there really is an answer. This is why I keep raising the point of the business case. It is a fundamental, basic task. And another fact is, if we want to make our records more widely available in types of formats that others could use, it can be done right now. Harvard is doing it with their API: http://blogs.law.harvard.edu/dplatechdev/2012/04/24/going-live-with-harvards-catalog/ They say their records are now available in JSON using schema.org, in DC or in MARC, although all I have seen is MARC so far. Still, Kudos to them! It is a wonderful beginning! So it is a fact that the library community does not have to wait for RDA, FRBR or even the changes to MARC to repurpose their data. Would it be perfect? Of course not! When has that ever had anything to do with anything? Everyone expects things to change constantly, especially today. A few years of open development using tools such as this would make the way forward much clearer than it is now. Then we could start to see what the public wants and needs and begin to design for *them* instead of for *us*. If we find that there is absolutely no interest in open development of library tools, that would say a lot too. To maintain that RDA and FRBR are going to make any difference to the public, or that they are necessary to get into the barely-nascent and highly controversial Linked Data, is simply too much to simply accept. Each represents changes, that's for sure, but theoretical ones that happen almost entirely behind the scenes, and all whose value has yet to be proven. All this in spite of the incredible developments going on right under our noses! Therefore, it seems only natural to question whether RDA, FRBR and Linked Data truly represent the direction forward or are they actually going in some other direction. On a more positive note, I think there are incredible opportunities for libraries and librarians today. -- *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
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 15/05/2012 17:53, Jonathan Rochkind wrote:
Frankly, I no longer have much confidence that the library cataloging
community is capable of any necessary changes in any kind of timeline
fast enough to save us.
There is no question that change is needed. The question is, are RDA
records coded in MARC21 the needed change?
__ __ J. McRee (Mac) Elrod (m...@slc.bc.ca)
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 15/05/2012 02:52, Karen Coyle wrote: snip 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. /snip I don't believe that is correct. That kind of search result should be a programming decision: whether to dedupe or not. It seems to me that a record with France three times in the record could easily display three times in a search result if you want it to. With relevance ranking, or ranking by date, etc. it makes little sense to display the same record three different times, although I am sure you could. Having a record display more often makes sense only with some kind of browse heading display but I have never seen that with a keyword result. This is a great example of how our current subject heading strings just don't function today, and they haven't ever since keyword was introduced. Computerized records work much better with descriptors than with traditional headings, for instance, your example would be something like: Topical Subjects: Working class, Dwellings, Housing Geographic Subject Area: France. Here, there is no question since France appears only once in the subjects. Seen in this light, our subject headings are obsolete but nevertheless, I believe our subject headings with subdivisions provides important options found nowhere else, as I tried to show in the posting I mentioned in my previous message. But really, how the subject headings function must be reconsidered from their foundations, otherwise they really are obsolete. The dictionary catalog really is dead, at least as concerns the public. -- *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
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: May 14, 2012 8:53 PM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF All that to say that if we are not going to display our records in alphabetical order by their headings, then I'm not sure if creating headings during cataloging makes all that much sense. Or at least, not the kinds of headings that we do create, which are designed to be viewed in alphabetical order. You are supposed to see Hamlet before you see Hamlet. French. Hamlet. German. Hamlet. German. 1919 Maybe you don't see Hamlet first, but the logic of adding on to the right hand side of the heading implies that the order conveys something to the user that facilitates finding what he is looking for. Thus, I question to creation of headings that are designed to be encountered in alphabetical order unless we adopt an ordered display around those headings. And if we think it is important to adopt such a display, we need to understand the implications for system design. There are numerous effects of the alphabetical browse display of headings in online systems that force catalogers and systems designers to make all sorts of unexpected decisions and difficult choices and workarounds. And even at that, the conventions that bring us those headings are often found out of context. For example, some of those headings with extra bits at the end exist to differentiate entities, and otherwise appear arbitrary without much relation to the headings around them which omit the extra bits. End-users have their complaints browsing a catalog index. They complain when they expect to find different records attached to each unique heading, but instead find that the record happened to have several headings that all began with the same words. Multiple indexes in online catalogs fracture and distort the intended effect of browsing headings. For the four ILS's I've worked with and customized I've had to make choices about MARC index mapping that would mitigate these issues: 1. Author Browse may or may not contain name-title headings for works and expressions. These headings could be pulled from related or analytical or series added entries. Should subject name-title headings be included? What about title SEE references to these headings? One system I used actually reconstructed the 1XX+240 heading on-the-fly. And what about persons and corporate bodies as subjects? Shouldn't the user benefit from seeing all related works together? This is why FRBR is so important. So much of the indexing is built around a cacophony of different implicit relationships, with little that is explicit to the end-users in terms of building expectations of what should be found with what. Being clear about the relationships matter, because that information needs to survive as catalogs records and indexes are torn apart and rebuilt in any number of different ways - we can't assume the implicit logic that exists when all card catalog and heading data are found together in context. 2. Title Browse often doesn't include authority information such as SEE and SEE ALSO references, so much of the information available in authority records is effectively lost. Should Title Browse draw in all titles, such as series titles or subject titles? I always mapped these together because I felt it wrong for an end-user to decide upon a title AND a relationship when searching (i.e., the end-user knows the title, but may not know it's a series title - why expect the end-user to be forced to choose between Title Browse and Series Browse?) 3. Subject Browse - similar to the issue above about end-users being forced to choose indexes, an end-user needs to differentiate William Shakespeare as author from William Shakespeare as subject ahead of time to find all the records attached to that name. The records are not found together with a single search in many cases. In an early system I had with minimal authority control, there were actually two system generated authority records for William Shakespeare - one as an author and one as a subject. There is a benefit to maintenance when one record per entity is updated, but the end-user may not encounter all the benefits because of the bewildering choices of indexes and the truncated and chopped up displays of bibliographic and authority data in online catalogs. Once web-based catalogs appeared, there were choices that could be made as well when a heading is clicked. In the case of a related name-title work heading, I had three choices in one system: A. Click the heading and bring up only those records attached to the heading. B. Click the heading and have a keyword search initiated using all the words in the heading (not good with long and unique
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 5/14/2012 8:52 PM, Karen Coyle wrote: 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: Sure you can use the headings in the MARC records to establish record retrieval order in an rdbms. All of our ILS/OPACs that return MARC records in headings order and are based on rdbms DO it. If the literal headings aren't structured right so that the rdbms' natural order will be right, the standard software solution is to automatically construct a 'sort key' from the headings. This is a pretty standard solution used all the time in many scenarios, it's not a significant burden or problem. I am a bit mystified by your arguments here about what rdbms can or can't do, and am not sure what you are trying to do with them. They don't match what software engineers using rdbms actually do. Also, you keep saying dbms (database management system), when I think you mean to be specifically talking about rdbms (RELATIONAL dbms); dbms is a more general term that can apply to just about anything that stores data persistently, but your arguments (which I don't agree with) seem to specifically be about databases that use SQL and are based on relational algebra -- that's rdbms specifically, not 'dbms'. I certainly agree that the way our data is currently recorded and maintained in MARC is not suitable for contemporary desired uses, as I've suggested many times before on this list and others and tried to explain why; it's got little to do with rdbms though. Jonathan
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 15/05/2012 16:50, Jonathan Rochkind wrote: snip I certainly agree that the way our data is currently recorded and maintained in MARC is not suitable for contemporary desired uses, as I've suggested many times before on this list and others and tried to explain why; it's got little to do with rdbms though. /snip Although MARC needs to change, and has needed it for a very long time, I don't see how changing the format would improve the subject headings. The semantics are there already, so searching would remain the same. It is the display of the multiple search result which has disintegrated. I think there are lots of ways that the displays could be improved for the public--primarily by making them more flexible and could be experimented with now--but even then, there will need to be a major push from public services to get the public to use and understand what the subject searches are. All of it has been effectively forgotten by the public. For a whole lot of reasons, library subject searches will always be substantively different from what what people retrieve from a full-text search result and while librarians can understand this, it is a lot harder for the public. -- *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
Re: [RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On 5/15/2012 11:34 AM, James Weinheimer wrote: Although MARC needs to change, and has needed it for a very long time, I don't see how changing the format would improve the subject headings. I did not mean to say that changing from MARC to somethign else, by itself, would do anything at all to subject headings. I chose my phrase carefully, the way our data is currently recorded and maintained in MARC. Several things about the way our data is currently and recorded and maintained (which we currently do in MARC) ought to be changed. Subject headings aren't even one of the main ones, although the way they are done could certainly be improved to be more powerful in software environments. It is a large and complicated topic. One we've spent collectively years arguing about on this list. Frankly, I no longer have much confidence that the library cataloging community is capable of any necessary changes in any kind of timeline fast enough to save us. Those that believe no significant changes to library cataloging or metadata practices are neccesary will have a chance to see if they are right. 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
Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
13.05.2012 19:49, Karen Coyle: 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. You've done a very concise and elucidating description of the calamity, and there certainly needs to be discussion about it. 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.) 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? 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. B.Eversberg
Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
-Original Message- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Bernhard Eversberg Sent: May 14, 2012 5:29 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF 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. Scenario 2 is MARC, which relies upon authorized access points for machine linking and is what most people will be using for RDA in the short term, and will be testing on. Scenario 3 is card catalogs, which relies upon filing rules. Scenario 1 relies upon entities just linking to entities, not necessarily relying on mechanisms such as volatile and difficult-to-manage authorized access points. Thomas Brenndorfer Guelph Public Library
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] [BIBFRAME] RDA, DBMS and RDF
On 5/14/2012 10:45 AM, Karen Coyle wrote: No, I'm saying that JSC made a claim that RDA was developed on RDBMS principles Where do you find this claim? I've seen documentation that FRBR (and by extension RDA) was developed based on entity-relational modelling. That's not the same thing as 'rdbms principles'. Entity-relational modelling is compatible with, and indeed even the foundation of, RDF too. Jonathan
Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
Karen said:
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...
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/
___} |__ \__
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
[RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
[I will split my response in to several parts]. On Mon, May 14, 2012 at 10:45 AM, Karen Coyle 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] These are somewhat strong claims, which may require some weakening before they are entirely valid. If [a] and [b] are both true, it must necessarily be true that in card catalogs records were displayed in order by the heading that was searched. In a strong reading could imply that when searching a physical card catalog by a heading of a specific kind (e.g. subject) , there would be no card found that would would not be in alphabetical order for that subject. But if the catalog was interfiled, an entry on a different field might interrupt the ordering for the specific field that were searched for, a contradiction. Thus, a weaker reading, that allows for interruptions of other records that are not in order of the searched for field must be intended.
Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
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 designer matt@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/
___} |__ \__
[RDA-L] Part 2: Efficiency of DBMS operations Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On Mon, May 14, 2012 at 10:45 AM, Karen Coyle 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] [These are somewhat strong claims, which may require some weakening before they are entirely valid. I will not unpack the term record here.] 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. It is difficult to work out what the intended reading of [e] is. The use of the term sets in retrieved sets, if interpreted in a mathematical sense, which would indeed make the concept of ordering nonsensical, as the elements within sets are unordered. However, since the claim is made in support of claims about possible efficiency, and since this is an attribute of possible systems, this reading cannot be the intended one. All of the major types of DBMS implementations have some form of ordering, internally, and in the query language. It is trivially true that in SQL based databases, the order in which the results of queries are retrieved is unspecified if you do not specify the order in which you want results to be returned, but even if we restrict ourself to these kinds of databases, this is not sufficient to support the strong claim. However, even though what the order in which the results might be unspecified, results are returned in *some* order, one after another. [e] thus cannot provide support for [c] and [d]. The internal arrangement of database records on disk is generally in some kind of linear order- to a first approximation, the records are stored one after the other in some order. This internal order may be as simple as the order in which the records were added to the database, or it may be an order based on the content of one of the fields of the record. If not otherwise specified, the order in which records are returned is based on this internal order*. For example, the Relational DBMSs Oracle and PostgresSQL both allow for records to be clustered (ordered on disk) so as to make retrieval in that order extremely efficient. Object Oriented DBMSs are usually quite efficient at following links to related records, and many will optimize based on patterns of retrieval order. Some OODBMS-like systems in the NoSQL family are entirely memory resident, making disk access irrelevant. Hierarchical databases like IDMS can be very fast at following the chains around which they are organized. Since we can efficiently retrieve records, in some specified order, using some DBMS, we have a counter-example to [c]. The claim can be weakened to a claim of possible inefficiency, but that is not unexpected in an ILS context :-) Claim [f] may or may not be considered to hold; one can replicate the database record once for each keyword that occurs, which is roughly equivalent to KWIC, which of course, trades space efficiency for time. If records are not replicated, keyword access to an indexed field may require a separate disk access for every record that matches the keyword (when the match is not at the start of the string). Often read requests will be ordered so that disk head movement is minimised; where this happens this is faster than purely random access. If the entire database is memory resident, or if all relevant records are in cache, the overhead of disk access is irrelevant. In this case [f] does not hold. I hope this isn't too confusing, Simon * In some situations involving multiple tables, some systems may return records in a different order if no specific order is requested. This is due to decisions that the DBMS makes on the fastest way of answering the query. Since not asking for results to be returned in a specific order tells the system that you don't care about ordering, the system may choose to use different algorithms when running your query. This extra freedom to optimize is why the order of results is unspecified by default.
Re: [RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
On Mon, May 14, 2012 at 2:18 PM, Karen Coyle li...@kcoyle.net wrote: On 5/14/12 9:33 AM, Simon Spero wrote: [I will split my response in to several parts]. On Mon, May 14, 2012 at 10:45 AM, Karen Coyle 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] These are somewhat strong claims, which may require some weakening before they are entirely valid. If [a] and [b] are both true, it must necessarily be true that in card catalogs records were displayed in order by the heading that was searched. there was no 'record' in the card catalog, nor a search in the sense that I mean. The search in b is a database search. In the card catalog you had cards, and you had alphabetical order. There really wasn't anything resembling a database search, which is an action against an index that results in a retrieved set of something stored in a database (which could be bib records or it could be headings, if you store and index those separately). The start anywhere and go backwards and forwards through the alphabet on strings at the top of cards that are left-anchored, and see the heading and the other information on the card is not something you get in most library catalogs. Mac's catalog is an interesting mix -- it's a search, not a heading browse, and each heading appears on a line with its record, even if more than one heading is retrieved with the search. In a strong reading could imply that when searching a physical card catalog by a heading of a specific kind (e.g. subject) , there would be no card found that would would not be in alphabetical order for that subject. But if the catalog was interfiled, an entry on a different field might interrupt the ordering for the specific field that were searched for, a contradiction. I don't get this at all. Maybe an example would help? The card is the record. A card catalog is searched by finding the drawer[s] marked as holding entries beginning with the correct initial letters; finding the first match within a drawer (using any algorithm for search in a sorted random access file). For subject access, the correct search string may require the use of an ancillary large red books. Suppose that the card catalog is searched by subject where multiple inverted headings are relevant, and that there is an author whose last name files after the first subject, but before the inverted subjects, and that the catalog has records by author and by subject filed together in the same dictionary catalog. Values for the records for the author may appear in the subject area of the card that are not in alphabetical order by subject. Simon
Re: [RDA-L] Part 1: Order of records Re: [RDA-L] [BIBFRAME] RDA, DBMS and RDF
I think the question is referring back to filing rules of the card catalog. I'm not certain how closely they met the conditions of the strong reading because I'm not entirely certain of the original query myself. From the 1956 LC filing rules, p. 140 has the following statements regarding the interaction of subject entries with other entries: I. The proper order of entries when the names of a person, place and thing are identical is: A. Person; B. Place; C. Subject [other than a specific subject that is arranged after its own author and added entries]; D. Title. Example: Stone, Samuel [author] Stone, Thomas [author] Stone, Pa. [name of place] STONE [name of an object] Stone[a title beginning with the word] II. Any author entry may have its own subject entry. When this is the case, the subject entry follows directly after its own author and added entries. [Clarifying text elided] Example (some entries elided): Stone, Thomas [author] Stone, Thomas [added entry] STONE, THOMAS [subject] Stone, Pa. [place as author] Stone, Pa. [place as added entry] Stone, Pa. Dept. of Ed. [subordinate body as author] Stone, Pa. Dept. of Ed. [subordinate body as added entry] STONE, PA. DEPT. OF ED. [subordinate body as subject] STONE, PA. [place as subject] STONE, PA. - BIOG.[place with subdivision as subject] III. [A sequence dealing strictly with subjects and their various subdivisions, qualifications, and inverted formulations - clustering by group but not yielding a strict alphabetic sequence: ART - HISTORY precedes ART - 17th CENTURY precedes ART - ALBANIA.] John F. Myers, Catalog Librarian Schaffer Library, Union College 807 Union St. Schenectady NY 12308 518-388-6623 mye...@union.edumailto:mye...@union.edu Karen Coyle wrote: I don't get this at all. Maybe an example would help? Quoting Simon Spero: [snip] In a strong reading could imply that when searching a physical card catalog by a heading of a specific kind (e.g. subject) , there would be no card found that would would not be in alphabetical order for that subject. But if the catalog was interfiled, an entry on a different field might interrupt the ordering for the specific field that were searched for, a contradiction.
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
