Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Karen, This is fun, but I ought to be working. Me> Work is not defined in AACR or AACR2. Karen> "Uniform title. 1. The particular title by which a work that has appeared under varying titles is to be identified for cataloguing purposes." (AACR2) "The title of the work is the word, phrase, or group of characters naming the work. There may be one or more titles associated with a work. If the work has appeared under varying titles (differing in form, language, etc.), a bibliographic agency normally selects one of those titles as the basis of a ?uniform title? for purposes of consistency in naming and referencing the work." (FRBR_2008.pdf) Work isn't defined (neither are any of WEMI), but the uniform title was/is a title representing the work. (And not to be confused with the uniform title *heading*, which is a uniform title plus qualifiers, like language, edition, etc. -- which seems to be something like an expression.) Me> Right. Uniform title is defined. Work is mentioned, but remains undefined. Thus, one reason for remaking AACR2 into RDA: to formally define basic concepts and work on from those concepts. Karen> I believe that author/uniform title authority records are being considered representations of works in some quarters (e.g. www.fla.fi/frbr05/McCallumTEXT.pdf). Me> Right. MARC/AACR2 A/UT authority information works well as a de facto work authority record. If one extends this a bit, it works well for expressions, too. It could work fairly well for music, serials, certain "classic" textual works, maybe some other things in which UTs are well-established and appreciated. Karen> In the Work entity, there is a title field, which is the title of the Work. So in the case of our Moby Dick, what would be the title of the Work? If you have different Works that represent, say, an 1852 edition, a 1997 edition with a preface by Smith, and another that is a 2003 edition with a preface by Jones, would they have the same work title? but different Work entity identifiers? Me> Not right. They [the edited works that include the work Moby Dick along with other works such as introductions, etc.] would have different work titles and different identifiers. And if the editors did any editing of the text of Moby Dick itself, then they'd contain different expressions of Moby Dick, too (unless their work as editors of the text was too insignificant to be concerned about.) Using in a general way the example of MARC/AACR2 authority records for an authority + uniform title, you'd create records that asserted the existence of the work entities, provide a unique number to identify the entity, a name or names for human usability, additional information to make the assertion itself clearly. You'd have one for Melville's Moby Dick. Another for each of the named editions you want to identify as aggregated works. (The number of situations in which this will be valuable will be few, but those few time may be important to the communities that most often use these works. And one could just associate these particular aggregated works (editions of a work with relevant apparatus) at the manifestation level. I believe this is the position, more or less, of the other IFLA discussion paper, the Aggregates as Manifestations, the O'Neill & Žumer Proposal: http://www.ifla.org/files/cataloguing/frbrrg/aggregates-as-manifestations.pdf The argument for this is that there is no pressing need for any other, richer association. No need to create work records for _these_ aggregates. I think that is right in almost all cases. But in some cases it may make sense to group the pieces together under a new aggregate work. Nice talking with you. Matthew
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Quoting "Beacom, Matthew" : Work is not defined in AACR or AACR2. "Uniform title. 1. The particular title by which a work that has appeared under varying titles is to be identified for cataloguing purposes." (AACR2) "The title of the work is the word, phrase, or group of characters naming the work. There may be one or more titles associated with a work. If the work has appeared under varying titles (differing in form, language, etc.), a bibliographic agency normally selects one of those titles as the basis of a ?uniform title? for purposes of consistency in naming and referencing the work." (FRBR_2008.pdf) Work isn't defined (neither are any of WEMI), but the uniform title was/is a title representing the work. (And not to be confused with the uniform title *heading*, which is a uniform title plus qualifiers, like language, edition, etc. -- which seems to be something like an expression.) I believe that author/uniform title authority records are being considered representations of works in some quarters (e.g. www.fla.fi/frbr05/McCallumTEXT.pdf). In the Work entity, there is a title field, which is the title of the Work. So in the case of our Moby Dick, what would be the title of the Work? If you have different Works that represent, say, an 1852 edition, a 1997 edition with a preface by Smith, and another that is a 2003 edition with a preface by Jones, would they have the same work title? but different Work entity identifiers? kc RDA, well, I only replied to your point about the FRBR WEMI/IMEW model being read in both directions. There are a lot of implications for RDA, but I didn't address any of them. I really don't know enough about the current state of RDA to express a useful opinion. So I didn't. I think the model I described clearly does allow for the sort of grouping of entities under a work heading that is represented by the openlibrary catalog or OCLC's FictionFinder, which is roughly similar in the organization of display: work level information, then list of manifestations. I'd prefer a tree structure with work level information showing the work requested and a path to related works that are derived but considered new works such as dramas, movies, video games based on the work, and a path to expressions of the work--in this case that would be by language of translation or significant (i.e. scholarly) editions, then manifestations that relate to the identified expressions. Additionally, I'd like to see pathways to discover additional content that is popularly associated with the work; a good example of that would be illustrations. Faceted browse tools would work well with this. And since desires have no end, I'd also like to see pathways that lead to other relat! ed works that are dependent on the work but are in a relation of commentary on the work--books and articles about Moby Dick. Neither openlibrary or FictionFinder do any of this now. But now I am no longer talking about just the WEMI/IMEW model. And I'll stop. Matthew Beacom -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Karen Coyle Sent: Monday, March 22, 2010 1:22 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas Quoting "Beacom, Matthew" : Karen, You said: From the FRBR model we know that a manifestation is the embodiment of an expression. From the manifestation, we infer another level of thinking about the item in hand, another abstraction, the FRBR expression. Going up the IMEW ladder, we see there is no gap where the expression should be. The expression is simply an inference we make from the manifestation according to the model. It's a formality. According to the model, an expression for the augmented/supplemented/whatevered Moby Dick exists. It must. And from the expression, let's call it "Moby Dick+a E", we infer the work, "Moby Dick+a W", again, according to the model. So working up the IMEW model, we see the augmented/supplemented/whatevered Moby Dick that I'm calling "Moby Dick+a" is a work, an expression, a manifestation and item. I'll have to read through this a few more times, but this puts you in the "work of works" camp: http://www.ifla.org/en/events/frbr-working-group-on-aggregates Unfortunately, I don't think this serves the user well, who may be looking for "Moby Dick" and not "Moby Dick+a". It's also not how Work is defined in AACR or RDA. So I'd like to understand what the user would see having done a search on Moby Dick. It seems like they'd see what we have today, which is a long list of different versions. Personally, I'd rather see something like: http://upstream.openlibrary.org/works/OL102749W/Moby_Dick And I don't think your model allows that. kc Coming down the WEMI model, we skipped over the expression level. Why? I think it is because of a couple of thing
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Karen, You said: "Unfortunately, I don't think this serves the user well, who may be looking for "Moby Dick" and not "Moby Dick+a". It's also not how Work is defined in AACR or RDA. So I'd like to understand what the user would see having done a search on Moby Dick. It seems like they'd see what we have today, which is a long list of different versions. Personally, I'd rather see something like: http://upstream.openlibrary.org/works/OL102749W/Moby_Dick And I don't think your model allows that." A couple of things. The possibility for confusion is why you have to denote both "Moby Dick" and "Moby Dick+a" and any other combinations that include "Moby Dick" in terms of the WEMI model. If you one and not the other or piggy-back one to the other, then it'll be hopeless for the user and the cataloger. No one will make any sense of it. Work is not defined in AACR or AACR2. RDA, well, I only replied to your point about the FRBR WEMI/IMEW model being read in both directions. There are a lot of implications for RDA, but I didn't address any of them. I really don't know enough about the current state of RDA to express a useful opinion. So I didn't. I think the model I described clearly does allow for the sort of grouping of entities under a work heading that is represented by the openlibrary catalog or OCLC's FictionFinder, which is roughly similar in the organization of display: work level information, then list of manifestations. I'd prefer a tree structure with work level information showing the work requested and a path to related works that are derived but considered new works such as dramas, movies, video games based on the work, and a path to expressions of the work--in this case that would be by language of translation or significant (i.e. scholarly) editions, then manifestations that relate to the identified expressions. Additionally, I'd like to see pathways to discover additional content that is popularly associated with the work; a good example of that would be illustrations. Faceted browse tools would work well with this. And since desires have no end, I'd also like to see pathways that lead to other relat! ed works that are dependent on the work but are in a relation of commentary on the work--books and articles about Moby Dick. Neither openlibrary or FictionFinder do any of this now. But now I am no longer talking about just the WEMI/IMEW model. And I'll stop. Matthew Beacom -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Karen Coyle Sent: Monday, March 22, 2010 1:22 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas Quoting "Beacom, Matthew" : > Karen, > > You said: > > From the FRBR model we know that a manifestation is the embodiment > of an expression. From the manifestation, we infer another level of > thinking about the item in hand, another abstraction, the FRBR > expression. Going up the IMEW ladder, we see there is no gap where > the expression should be. The expression is simply an inference we > make from the manifestation according to the model. It's a > formality. According to the model, an expression for the > augmented/supplemented/whatevered Moby Dick exists. It must. And > from the expression, let's call it "Moby Dick+a E", we infer the > work, "Moby Dick+a W", again, according to the model. So working up > the IMEW model, we see the augmented/supplemented/whatevered Moby > Dick that I'm calling "Moby Dick+a" is a work, an expression, a > manifestation and item. I'll have to read through this a few more times, but this puts you in the "work of works" camp: http://www.ifla.org/en/events/frbr-working-group-on-aggregates Unfortunately, I don't think this serves the user well, who may be looking for "Moby Dick" and not "Moby Dick+a". It's also not how Work is defined in AACR or RDA. So I'd like to understand what the user would see having done a search on Moby Dick. It seems like they'd see what we have today, which is a long list of different versions. Personally, I'd rather see something like: http://upstream.openlibrary.org/works/OL102749W/Moby_Dick And I don't think your model allows that. kc > > Coming down the WEMI model, we skipped over the expression level. > Why? I think it is because of a couple of things common to how we > think. First, when we use the WEMI model in this top-down direction, > we tend to reify the abstractions and look for "real" instances of > them. Second, when we move down the WEMI model, we deduce the next > level from the "evidence" of the one above or evidence from the > physical world. Since the abstract levels of the FRBR WEMI model > provide no evidence for deduction, and there is no evidence of an > expression in the item, and all there is to rely on is the model's > claim that "there be expressions here," the
[CODE4LIB] Identities, Terminologies, xID
Xiaoming, n...@identities is weekly handled by Ralph. He also proposed a dashboard prototype below, which may be of use. l...@terminologies is updated every 6 months, and handled by http://www.oclc.org/research/activities/termservices/default.htm The last piece of the puzzle is xID: how often are those files updated? Ya¹aqov On 3/21/10 4:37 PM, "LeVan,Ralph" wrote: > I'm open to suggestions, Ya'aqov. > > I've been talking up the idea of some sort of dashboard for our services. > Display uptime and response time. It will be tougher to automatically detect > a database update and report it. I'll give that some thought for stuff > running over my software stack. > > This seems like the right forum to solicit other suggestions. Has anyone done > this before? It seems like there ought to be some lists lying around > somewhere of information that would be helpful to service consumers. > > Ralph > > -Original Message- > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Ziso, > Ya'aqov > Sent: Sunday, March 21, 2010 1:09 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] WorldCat Terminologies > > I'm certain that as Ralph indicated, this file has been kept weekly > up-to-date. > The html page header will be, eventually, fixed as well to reflect accurately > the file's last update and its SRU searchability. The fact remains that for > all: terminologies/identities/xISSN/xISBN >> WC-DEVNET is the customer support > and quality control. > > We have no other address for maintenance, and possibly OCLC Research's > dedicated staff lack such address as well. Yes, these experimental services > reside on OCLC servers. > > Unfortunately, given this customer support model, OCLC Research will be > constantly put in a defensive position and all we can do is flag problems and > maintain this loop. > > (unless any of you has an idea for a loophole and, please, bring it on!) > Ya'aqov > > > > > > -Original Message- > From: Code for Libraries on behalf of Jonathan Rochkind > Sent: Sun 3/21/2010 12:19 AM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] WorldCat Terminologies > > Yeah, the statement that it's a static copy from 2006 would have stopped me in > my tracks if I had somehow happened accross the page, which I probably > wouldn't have, but now I've bookmarked it so I might find it again -- but will > probably forget that it's REALLY up to date even though it says 2006 on it. > Nice catch Karen. > > Karen, that looks to me like an HTML front-end for an SRU service, I bet it's > got an SRU api. Which one of these days I'll get around to figuring out how to > write code for. > > From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Karen Coyle > [li...@kcoyle.net] > Sent: Saturday, March 20, 2010 11:29 AM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] WorldCat Terminologies > > Quoting "LeVan,Ralph" : > >> > I hate to muddy the waters, but I can't resist here. >> > >> > Research also exposes a copy of the LC NAF at >> > http://alcme.oclc.org/srw/search/lcnaf >> > >> > It gets updated every Tuesday night. > > Unfortunately, that page states right up front: > > "A static copy of LC's Name Authority File from February of 2006" > > That might confuse visitors. Maybe a quick revision is in order? :-) > > Also, API access? > > kc > >> > >> > This is something I've been maintaining for years and is what >> > Identities points at when you ask to see the NAF record associated >> > with an Identities record. >> > >> > This particular service has none of the linked-data-type bells and >> > whistles I'm putting into VIAF and Identities, but easily could, if >> > there was interest. I believe I've made the indexing on it >> > consistent with what I do in Identities. >> > >> > Looking at the configuration file for the load of this database, I >> > am omitting records with 100$k, 100$t, 100$v, 100$x or any 130 >> > fields. I'm sure Ya'aqov (or other similarly expert Authority >> > Librarian) could tell you why I am omitting them, because I can't >> > off the top of my head. >> > >> > This service is actually running as a long established model of how >> > similar services should run in Research. While it is not running on >> > a machine operated by our production staff, it is automatically >> > monitored by them, they have restart procedures in places when the >> > service becomes unresponsive and problems are escalated by email >> > when the restart fails to fix the problem. (Those emails come to me >> > and where they get treated appropriately.) >> > >> > Let me know if there are questions about any of this. >> > >> > Ralph >> > >>> >> -Original Message- >>> >> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of >>> >> Ya'aqov Ziso >>> >> Sent: Friday, March 19, 2010 3:29 PM >>> >> To: CODE4LIB@LISTSERV.ND.EDU >>> >> Subject: Re: [CODE4LIB] WorldCat Termi
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Karen, You said: "How are the WEM of each separate resource here connected? In other words, do you have a Work entity defined for "preface" that links to an expression entity for "preface", and do they all have identifiers? (This really needs a diagram!) It seems like somewhere you need: (Expression) preface --> expresses --> (Work) preface That would have to exist outside of this particular description, right?" Yes. But I think it would look more like this. (Expression) preface to Moby Dick by named author for Moby Dick+a edition date --> expresses --> (Work) preface to Moby Dick by named author for Moby Dick+a edition date I just want to avoid confusing people with a diagram that looks like there may be one (work) called preface for all instances of prefaces. And you would need the same sort of connections for Moby Dick and the poem by Hart Crane in this situation. Each work that is contained in the whole work of works needs (or can have) the WEMI structure. And so do the whole work of works. Crane's poem is a work. Melville's novel is a work. Somebody's preface to the "Moby Dick+a" work is a work. They all need to be understood as works. But we can always make judgments about what we want to bother with. One might skip the effort of asserting a work entity for an undistinguished and unsigned preface to anything, and in some other case someone else may make that effort. Matthew Beacom -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Karen Coyle Sent: Monday, March 22, 2010 1:52 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas Quoting "Beacom, Matthew" : > > Work: Moby Dick with preface, appendices, Hart Crane poem (I'd call > this an aggregate work) >Includes: (Work) preface (by someone) >Includes: (Work) Poem (by Hart Crane) >Includes: (Work) Moby Dick (by Herman Melville) > Expression: Moby Dick with preface, appendices, Hart Crane poem >Includes: (Expression) preface (by someone) >Includes: (Expression) Poem (by Hart Crane) >Includes: (Expression) Moby Dick (by Herman Melville) > Manifestation: Moby Dick with preface, appendices, Hart Crane poem >Contains: (Work/Expression) preface (by someone) >Contains: (Work/Expression) Poem (by Hart Crane) >Contains: (Work/Expression) Moby Dick (by Herman Melville) kc > > Other expression groups of the above could be those same works > translated to French or Russian or Chinese. One could think of > others, but they might all get more complicated than straight > translation. > > Other manifestation groups of the above could be a hard bound deluxe > edition, a hard bound trade edition, a trade paper edition and a > mass market edition with the only physical differences being covers > and paper quality/size. Add a few proprietary e-versions, if you want. > > With regard to RDA, I think you are still working with a more or > less traditional catalog model that begins with inventory control of > physical items in a collection (whether tangible or virtual, > whether local or distributed.) The new aspects of RDA enhance our > ability to connect the items to one another at the manifestation, > expression and work levels. > > I don't think RDA goes as far as you want it to go. But I'm not sure > there is any other model to follow. One has to connect > abstractions like work to actual items one can use. A reference to > a work without some linkage to an item that embodies it is a dead > end. > > Matthew Beacom > > -Original Message- > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf > Of Karen Coyle > Sent: Monday, March 22, 2010 1:10 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas > > Quoting Jonathan Rochkind : > >> A big mistake, if it means what we think it means, that RDA has decided >> that a given Manifestation can not contain several Expressions. > > I'm not sure they've actually stated that, although that seems to be > the implication. I think they intend for you to use the "contains" > and "contained in" relationship that can apply to any WEMI entity. And > this is where RDA's implementation of FRBR becomes difficult when I > try to think of how to present this to the user -- > > Work: Moby Dick > Expression: Moby Dick with preface, appendices, Hart Crane poem >Contains: (Work/Expression) preface >Contains: (Work/Expression) Hart Crane Poem > Manifestation: Moby Dick with preface, appendices, Hart Crane poem >?Contains: preface >?Contains: Hart Crane Poem > > While there may be some logic here, it seems like this just reproduces > the "unit card" view that we have today, with a manifestation and > added entries. I don't know what entity the "contains" hangs off of, > or if it can be related both to the expression and the manifestation.
[CODE4LIB] Reposting - Sorry! Code4Lib Journal Issue 9 now available!
Please excuse cross posting, and please feel free to share! :-) Editorial Introduction – Moving Forward Carol Bean http://journal.code4lib.org/articles/2569 Welcoming new editors, and reflecting on the sustainability factor. A Principled Approach to Online Publication Listings and Scientific Resource Sharing Jacquelijn Ringersma, Karin Kastens, Ulla Tschida and Jos van Berkum http://journal.code4lib.org/articles/2520 The Max Planck Institute (MPI) for Psycholinguistics has developed a service to manage and present the scholarly output of their researchers. The PubMan database manages publication metadata and full-texts of publications published by their scholars. All relevant information regarding a researcher’s work is brought together in this database, including supplementary materials and links to the MPI database for primary research data. The PubMan metadata is harvested into the MPI website CMS (Plone). The system developed for the creation of the publication lists, allows the researcher to create a selection of the harvested data in a variety of formats. Querying OCLC Web Services for Name, Subject, and ISBN Ya’aqov Ziso, Ralph LeVan, and Eric Lease Morgan http://journal.code4lib.org/articles/2481 Using Web services, search terms can be sent to WorldCat’s centralized authority and identifier files to retrieve authorized terminology that helps users get a comprehensive set of relevant search results. This article presents methods for searching names, subjects or ISBNs in various WorldCat databases and displaying the results to users. Exploiting WorldCat’s databases in this way opens up future possibilities for more seamless integration of authority-controlled vocabulary lists into new discovery interfaces and a reduction in libraries’ dependence on local name and subject authority files. Challenges in Sustainable Open Source: A Case Study Sibyl Schaefer http://journal.code4lib.org/articles/2493 The Archivists’ Toolkit is a successful open source software package for archivists, originally developed with grant funding. The author, who formerly worked on the project at a participating institution, examines some of the challenges in making an open source project self-sustaining past grant funding. A consulting group hired by the project recommended that — like many successful open source projects — they rely on a collaborative volunteer community of users and developers. However, the project has had limited success fostering such a community. The author offers specific recommendations for the project going forward to gain market share and develop a collaborative user and development community, with more open governance. Using Cloud Services for Library IT Infrastructure Erik Mitchell http://journal.code4lib.org/articles/2510 Cloud computing comes in several different forms and this article documents how service, platform, and infrastructure forms of cloud computing have been used to serve library needs. Following an overview of these uses the article discusses the experience of one library in migrating IT infrastructure to a cloud environment and concludes with a model for assessing cloud computing. Creating an Institutional Repository for State Government Digital Publications Meikiu Lo and Leah M. Thomas http://journal.code4lib.org/articles/2563 In 2008, the Library of Virginia (LVA) selected the digital asset management system DigiTool to host a centralized collection of digital state government publications. The Virginia state digital repository targets three primary user groups: state agencies, depository libraries and the general public. DigiTool’s ability to create depositor profiles for individual agencies to submit their publications, its integration with the Aleph ILS, and product support by ExLibris were primary factors in its selection. As a smaller institution, however, LVA lacked the internal resources to take full advantage of DigiTool’s full set of features. The process of cataloging a heterogenous collection of state documents also proved to be a challenge within DigiTool. This article takes a retrospective look at what worked, what did not, and what could have been done to improve the experience. Wrangling Electronic Resources: A Few Good Tools Brandy Klug http://journal.code4lib.org/articles/2634 There are several freely available tools today that fill the needs of librarians tasked with maintaining electronic resources, that assist with tasks such as editing MARC records and maintaining web sites that contain links to electronic resources. This article gives a tour of a few tools the author has found invaluable as an Electronic Resources Librarian. CONFERENCE REPORT: Code4Lib 2010 Birong Ho, Banurekha Lakshminarayanan, and Vanessa Meireles http://journal.code4lib.org/articles/2717 Conference reports from the 5th Code4Lib Conference, held in Asheville, NC, from February 22 to 25, 2010. The Code4Lib conference is a collective volunteer effort of the Code4Lib community o
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Quoting "Beacom, Matthew" : Work: Moby Dick with preface, appendices, Hart Crane poem (I'd call this an aggregate work) Includes: (Work) preface (by someone) Includes: (Work) Poem (by Hart Crane) Includes: (Work) Moby Dick (by Herman Melville) Expression: Moby Dick with preface, appendices, Hart Crane poem Includes: (Expression) preface (by someone) Includes: (Expression) Poem (by Hart Crane) Includes: (Expression) Moby Dick (by Herman Melville) Manifestation: Moby Dick with preface, appendices, Hart Crane poem Contains: (Work/Expression) preface (by someone) Contains: (Work/Expression) Poem (by Hart Crane) Contains: (Work/Expression) Moby Dick (by Herman Melville) How are the WEM of each separate resource here connected? In other words, do you have a Work entity defined for "preface" that links to an expression entity for "preface", and do they all have identifiers? (This really needs a diagram!) It seems like somewhere you need: (Expression) preface --> expresses --> (Work) preface That would have to exist outside of this particular description, right? kc Other expression groups of the above could be those same works translated to French or Russian or Chinese. One could think of others, but they might all get more complicated than straight translation. Other manifestation groups of the above could be a hard bound deluxe edition, a hard bound trade edition, a trade paper edition and a mass market edition with the only physical differences being covers and paper quality/size. Add a few proprietary e-versions, if you want. With regard to RDA, I think you are still working with a more or less traditional catalog model that begins with inventory control of physical items in a collection (whether tangible or virtual, whether local or distributed.) The new aspects of RDA enhance our ability to connect the items to one another at the manifestation, expression and work levels. I don't think RDA goes as far as you want it to go. But I'm not sure there is any other model to follow. One has to connect abstractions like work to actual items one can use. A reference to a work without some linkage to an item that embodies it is a dead end. Matthew Beacom -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Karen Coyle Sent: Monday, March 22, 2010 1:10 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas Quoting Jonathan Rochkind : A big mistake, if it means what we think it means, that RDA has decided that a given Manifestation can not contain several Expressions. I'm not sure they've actually stated that, although that seems to be the implication. I think they intend for you to use the "contains" and "contained in" relationship that can apply to any WEMI entity. And this is where RDA's implementation of FRBR becomes difficult when I try to think of how to present this to the user -- Work: Moby Dick Expression: Moby Dick with preface, appendices, Hart Crane poem Contains: (Work/Expression) preface Contains: (Work/Expression) Hart Crane Poem Manifestation: Moby Dick with preface, appendices, Hart Crane poem ?Contains: preface ?Contains: Hart Crane Poem While there may be some logic here, it seems like this just reproduces the "unit card" view that we have today, with a manifestation and added entries. I don't know what entity the "contains" hangs off of, or if it can be related both to the expression and the manifestation. I need to think about this more, but I don't see how this lets us provide a non-unit card view for users, which is what I was hoping we were working toward. Although perhaps the idea is to build that on top of the unit card view, after taking apart the records... It might wok, I really want to try to model this. Wish we could get some folks together for a 1/2 day somewhere and JUST DO IT. kc Riley, Jenn wrote: What the RDA folks (that is, the folks who have created RDA, the JSC members) said (some of them off-list to me), is that if your manifestation is an aggregate, then your Expression must be an equal aggregate. So the Expression is pretty much one-to-one with the Manifestation. (And I think we were all seeing a many-to-many.) I see this conclusion as RDA's, but not FRBR's. The FRBR report explicitly says there can be a many-to-one relationship between Expressions and a Manifestation (that is, a Manifestation can embody several Expressions), and the V/FRBR project takes that at face value and does not impose the additional restriction that a Manifestation contains an equal aggregate. RDA may impose that restriction, but that's their implementation of FRBR, and the V/FRBR project as *not* an RDA implementation doesn't feel bound by that decision. Obviously I think that RDA has made a mistake in adding in a requirement that "if your manifestation is an agg
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Karen, Is see your depiction of the Moby Dick example Work: Moby Dick Expression: Moby Dick with preface, appendices, Hart Crane poem Contains: (Work/Expression) preface Contains: (Work/Expression) Hart Crane Poem Manifestation: Moby Dick with preface, appendices, Hart Crane poem ?Contains: preface ?Contains: Hart Crane Poem This way: Work: Moby Dick with preface, appendices, Hart Crane poem (I'd call this an aggregate work) Includes: (Work) preface (by someone) Includes: (Work) Poem (by Hart Crane) Includes: (Work) Moby Dick (by Herman Melville) Expression: Moby Dick with preface, appendices, Hart Crane poem Includes: (Expression) preface (by someone) Includes: (Expression) Poem (by Hart Crane) Includes: (Expression) Moby Dick (by Herman Melville) Manifestation: Moby Dick with preface, appendices, Hart Crane poem Contains: (Work/Expression) preface (by someone) Contains: (Work/Expression) Poem (by Hart Crane) Contains: (Work/Expression) Moby Dick (by Herman Melville) Other expression groups of the above could be those same works translated to French or Russian or Chinese. One could think of others, but they might all get more complicated than straight translation. Other manifestation groups of the above could be a hard bound deluxe edition, a hard bound trade edition, a trade paper edition and a mass market edition with the only physical differences being covers and paper quality/size. Add a few proprietary e-versions, if you want. With regard to RDA, I think you are still working with a more or less traditional catalog model that begins with inventory control of physical items in a collection (whether tangible or virtual, whether local or distributed.) The new aspects of RDA enhance our ability to connect the items to one another at the manifestation, expression and work levels. I don't think RDA goes as far as you want it to go. But I'm not sure there is any other model to follow. One has to connect abstractions like work to actual items one can use. A reference to a work without some linkage to an item that embodies it is a dead end. Matthew Beacom -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Karen Coyle Sent: Monday, March 22, 2010 1:10 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas Quoting Jonathan Rochkind : > A big mistake, if it means what we think it means, that RDA has decided > that a given Manifestation can not contain several Expressions. I'm not sure they've actually stated that, although that seems to be the implication. I think they intend for you to use the "contains" and "contained in" relationship that can apply to any WEMI entity. And this is where RDA's implementation of FRBR becomes difficult when I try to think of how to present this to the user -- Work: Moby Dick Expression: Moby Dick with preface, appendices, Hart Crane poem Contains: (Work/Expression) preface Contains: (Work/Expression) Hart Crane Poem Manifestation: Moby Dick with preface, appendices, Hart Crane poem ?Contains: preface ?Contains: Hart Crane Poem While there may be some logic here, it seems like this just reproduces the "unit card" view that we have today, with a manifestation and added entries. I don't know what entity the "contains" hangs off of, or if it can be related both to the expression and the manifestation. I need to think about this more, but I don't see how this lets us provide a non-unit card view for users, which is what I was hoping we were working toward. Although perhaps the idea is to build that on top of the unit card view, after taking apart the records... It might wok, I really want to try to model this. Wish we could get some folks together for a 1/2 day somewhere and JUST DO IT. kc > > Riley, Jenn wrote: >>> What the RDA folks (that is, the folks >>> who have created RDA, the JSC members) said (some of them off-list to >>> me), is that if your manifestation is an aggregate, then your >>> Expression must be an equal aggregate. So the Expression is pretty >>> much one-to-one with the Manifestation. (And I think we were all >>> seeing a many-to-many.) >>> >> >> I see this conclusion as RDA's, but not FRBR's. The FRBR report explicitly >> says there can be a many-to-one relationship between Expressions and a >> Manifestation (that is, a Manifestation can embody several Expressions), and >> the V/FRBR project takes that at face value and does not impose the >> additional restriction that a Manifestation contains an equal aggregate. RDA >> may impose that restriction, but that's their implementation of FRBR, and >> the V/FRBR project as *not* an RDA implementation doesn't feel bound by that >> decision. >> >> Obviously I think that RDA has made a mistake in adding in a requirement >> that "if your manifestation is an aggregate, then your Expression must be an >> equal aggrega
[CODE4LIB] Code4Lib Journal - Issue 9 now available!
Please excuse cross posting, and please feel free to share! :-) Editorial Introduction – Moving Forward Carol Bean http://journal.code4lib.org/articles/2569 Welcoming new editors, and reflecting on the sustainability factor. A Principled Approach to Online Publication Listings and Scientific Resource Sharing Jacquelijn Ringersma, Karin Kastens, Ulla Tschida and Jos van Berkum http://journal.code4lib.org/articles/2520 The Max Planck Institute (MPI) for Psycholinguistics has developed a service to manage and present the scholarly output of their researchers. The PubMan database manages publication metadata and full-texts of publications published by their scholars. All relevant information regarding a researcher’s work is brought together in this database, including supplementary materials and links to the MPI database for primary research data. The PubMan metadata is harvested into the MPI website CMS (Plone). The system developed for the creation of the publication lists, allows the researcher to create a selection of the harvested data in a variety of formats. Querying OCLC Web Services for Name, Subject, and ISBN Ya’aqov Ziso, Ralph LeVan, and Eric Lease Morgan http://journal.code4lib.org/articles/2481 Using Web services, search terms can be sent to WorldCat’s centralized authority and identifier files to retrieve authorized terminology that helps users get a comprehensive set of relevant search results. This article presents methods for searching names, subjects or ISBNs in various WorldCat databases and displaying the results to users. Exploiting WorldCat’s databases in this way opens up future possibilities for more seamless integration of authority-controlled vocabulary lists into new discovery interfaces and a reduction in libraries’ dependence on local name and subject authority files. Using Cloud Services for Library IT Infrastructure Erik Mitchell http://journal.code4lib.org/articles/2510 Cloud computing comes in several different forms and this article documents how service, platform, and infrastructure forms of cloud computing have been used to serve library needs. Following an overview of these uses the article discusses the experience of one library in migrating IT infrastructure to a cloud environment and concludes with a model for assessing cloud computing. Creating an Institutional Repository for State Government Digital Publications Meikiu Lo and Leah M. Thomas http://journal.code4lib.org/articles/2563 In 2008, the Library of Virginia (LVA) selected the digital asset management system DigiTool to host a centralized collection of digital state government publications. The Virginia state digital repository targets three primary user groups: state agencies, depository libraries and the general public. DigiTool’s ability to create depositor profiles for individual agencies to submit their publications, its integration with the Aleph ILS, and product support by ExLibris were primary factors in its selection. As a smaller institution, however, LVA lacked the internal resources to take full advantage of DigiTool’s full set of features. The process of cataloging a heterogenous collection of state documents also proved to be a challenge within DigiTool. This article takes a retrospective look at what worked, what did not, and what could have been done to improve the experience. Wrangling Electronic Resources: A Few Good Tools Brandy Klug http://journal.code4lib.org/articles/2634 There are several freely available tools today that fill the needs of librarians tasked with maintaining electronic resources, that assist with tasks such as editing MARC records and maintaining web sites that contain links to electronic resources. This article gives a tour of a few tools the author has found invaluable as an Electronic Resources Librarian. CONFERENCE REPORT: Code4Lib 2010 Birong Ho, Banurekha Lakshminarayanan, and Vanessa Meireles http://journal.code4lib.org/articles/2717 Conference reports from the 5th Code4Lib Conference, held in Asheville, NC, from February 22 to 25, 2010. The Code4Lib conference is a collective volunteer effort of the Code4Lib community of library technologists. Included are three brief reports on the conference from the recipients of conference scholarships. -- Carol Bean beanwo...@gmail.com
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Quoting "Beacom, Matthew" : Karen, You said: From the FRBR model we know that a manifestation is the embodiment of an expression. From the manifestation, we infer another level of thinking about the item in hand, another abstraction, the FRBR expression. Going up the IMEW ladder, we see there is no gap where the expression should be. The expression is simply an inference we make from the manifestation according to the model. It's a formality. According to the model, an expression for the augmented/supplemented/whatevered Moby Dick exists. It must. And from the expression, let's call it "Moby Dick+a E", we infer the work, "Moby Dick+a W", again, according to the model. So working up the IMEW model, we see the augmented/supplemented/whatevered Moby Dick that I'm calling "Moby Dick+a" is a work, an expression, a manifestation and item. I'll have to read through this a few more times, but this puts you in the "work of works" camp: http://www.ifla.org/en/events/frbr-working-group-on-aggregates Unfortunately, I don't think this serves the user well, who may be looking for "Moby Dick" and not "Moby Dick+a". It's also not how Work is defined in AACR or RDA. So I'd like to understand what the user would see having done a search on Moby Dick. It seems like they'd see what we have today, which is a long list of different versions. Personally, I'd rather see something like: http://upstream.openlibrary.org/works/OL102749W/Moby_Dick And I don't think your model allows that. kc Coming down the WEMI model, we skipped over the expression level. Why? I think it is because of a couple of things common to how we think. First, when we use the WEMI model in this top-down direction, we tend to reify the abstractions and look for "real" instances of them. Second, when we move down the WEMI model, we deduce the next level from the "evidence" of the one above or evidence from the physical world. Since the abstract levels of the FRBR WEMI model provide no evidence for deduction, and there is no evidence of an expression in the item, and all there is to rely on is the model's claim that "there be expressions here," then we don't see the expression as real. Working up from the item, the step at the expression level is more clear and more clearly a formal part of the modeling process. It isn't a different decision about expression, it is a different view of the model that allows us to more clearly see the expression. Is this way of thinking, useful? It may be, when or if we think the editorial work that created the augmented/etc. Moby Dick, is worth noting and tracking. Consider for instance the 150 the anniversary edition of Moby Dick published by the Northwestern University Press in 1991. It may make sense and provide some utility for readers for cataloger's to consider this edition a different work than the Norton Critical Edition, 2d edition, of Moby Dick. Because we like to relate a work to a creator of the work when we can, I'll point out the creator of each of these works is the editor or editorial group that edited the text of Moby Dick-if they did that--and compiled the edition. And we might distinguish them by use of the editor's name or the publisher's as we do in this case. Returning to "Moby Dick+a" for a moment, I want to point out a complexity that I skipped over so far. There is more than one work involved in "Moby Dick+a." The first is the edition itself, "Moby Dick+a," a second is "Moby Dick," itself, a third would be the introduction written for this edition, etc. It would be possible to have the same work/expression of "Moby Dick" in two different "edition-works" of Moby Dick. If the same text of "Moby Dick" is simply repeated in a new context of apparatus--introductions, afterwords, etc., one could have a work/expression "Moby Dick+a" and another "Moby Dick+b" that each contains the same work/expression, "Moby Dick." What makes sense to me is noting and tracking both of these--the edited augmentation and the core work. Other works within the augmented work may also be worth noting, etc., but how far one would follow that path depends on the implementation goals. Matthew Beacom -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas
Quoting Jonathan Rochkind : A big mistake, if it means what we think it means, that RDA has decided that a given Manifestation can not contain several Expressions. I'm not sure they've actually stated that, although that seems to be the implication. I think they intend for you to use the "contains" and "contained in" relationship that can apply to any WEMI entity. And this is where RDA's implementation of FRBR becomes difficult when I try to think of how to present this to the user -- Work: Moby Dick Expression: Moby Dick with preface, appendices, Hart Crane poem Contains: (Work/Expression) preface Contains: (Work/Expression) Hart Crane Poem Manifestation: Moby Dick with preface, appendices, Hart Crane poem ?Contains: preface ?Contains: Hart Crane Poem While there may be some logic here, it seems like this just reproduces the "unit card" view that we have today, with a manifestation and added entries. I don't know what entity the "contains" hangs off of, or if it can be related both to the expression and the manifestation. I need to think about this more, but I don't see how this lets us provide a non-unit card view for users, which is what I was hoping we were working toward. Although perhaps the idea is to build that on top of the unit card view, after taking apart the records... It might wok, I really want to try to model this. Wish we could get some folks together for a 1/2 day somewhere and JUST DO IT. kc Riley, Jenn wrote: What the RDA folks (that is, the folks who have created RDA, the JSC members) said (some of them off-list to me), is that if your manifestation is an aggregate, then your Expression must be an equal aggregate. So the Expression is pretty much one-to-one with the Manifestation. (And I think we were all seeing a many-to-many.) I see this conclusion as RDA's, but not FRBR's. The FRBR report explicitly says there can be a many-to-one relationship between Expressions and a Manifestation (that is, a Manifestation can embody several Expressions), and the V/FRBR project takes that at face value and does not impose the additional restriction that a Manifestation contains an equal aggregate. RDA may impose that restriction, but that's their implementation of FRBR, and the V/FRBR project as *not* an RDA implementation doesn't feel bound by that decision. Obviously I think that RDA has made a mistake in adding in a requirement that "if your manifestation is an aggregate, then your Expression must be an equal aggregate." But that's their business, I guess. Jenn Jenn Riley Metadata Librarian Digital Library Program Indiana University - Bloomington Wells Library W501 (812) 856-5759 www.dlib.indiana.edu Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] Variations/FRBR project releases FRBR XML Schemas
Karen, You said: "One thing I am finding about FRBR (and want to think about more) is that one seems to come up with different conclusions depending on whether one works down from Work or works up from Item. The assumption that an aggregate in a bound volume is an Expression seems to make sense if you are working up from the Manifestation, but it makes less sense if you are working down from the Work. If decisions change based on the direction, then I think we have a real problem!" The direction one moves in with the WEMI/IMEW model doesn't change the result of using the model in the way you mean. It doesn't invalidates the model or shows a serious problem with the model. It shows that people can often trace complexities of relationships in one direction better than they can in another. So it is a good practice to use the model in both directions when trying to understand it or apply it. Let's use your case (more or less) as an example. Consider that we have a published work--Moby Dick--that has additional material published with it, an introduction, a poem, whatever. That extra material published with the work Moby Dick doesn't exist _with_ the text of Moby Dick until we descend down WEMI to the manifestation level. Here's one place confusion enters. What happened to the expression? We just skipped over it. As if it didn't exist. What about the item? We have that in hand. It exists. It's our evidence for the rest. We have analyzed this bibliographic situation from W to I, but we have a gap at expression. That's confusing. There may be something wrong with the model, but before we investigate that, let's look at the situation in reverse, from I to W. The evidence I have is in my hand. I'm holding the item. It says it is Moby Dick, it has an intro and other stuff with a block of text that looks like it could be Moby Dick. We'll assume for now that it is. From the item, I infer the manifestation. (Jonathan and others would very sensibly call this manifestation the set of all the more or less interchangeable items, but I prefer to think of it as an _idea_ we have about a set of like items. To me, it doesn't make the best sense to think of the manifestation as a physical entity--a set; it's more useful to think of it as an idea we have about a set of physical entities. This approach keeps the focus on the FRBR manifestation as an abstraction. It avoids reifying the concept, which, I think, is a source of much confusion about the FRBR WEMI model.) >From the FRBR model we know that a manifestation is the embodiment of an >expression. From the manifestation, we infer another level of thinking about >the item in hand, another abstraction, the FRBR expression. Going up the IMEW >ladder, we see there is no gap where the expression should be. The expression >is simply an inference we make from the manifestation according to the model. >It's a formality. According to the model, an expression for the >augmented/supplemented/whatevered Moby Dick exists. It must. And from the >expression, let's call it "Moby Dick+a E", we infer the work, "Moby Dick+a W", >again, according to the model. So working up the IMEW model, we see the >augmented/supplemented/whatevered Moby Dick that I'm calling "Moby Dick+a" is >a work, an expression, a manifestation and item. Coming down the WEMI model, we skipped over the expression level. Why? I think it is because of a couple of things common to how we think. First, when we use the WEMI model in this top-down direction, we tend to reify the abstractions and look for "real" instances of them. Second, when we move down the WEMI model, we deduce the next level from the "evidence" of the one above or evidence from the physical world. Since the abstract levels of the FRBR WEMI model provide no evidence for deduction, and there is no evidence of an expression in the item, and all there is to rely on is the model's claim that "there be expressions here," then we don't see the expression as real. Working up from the item, the step at the expression level is more clear and more clearly a formal part of the modeling process. It isn't a different decision about expression, it is a different view of the model that allows us to more clearly see the expression. Is this way of thinking, useful? It may be, when or if we think the editorial work that created the augmented/etc. Moby Dick, is worth noting and tracking. Consider for instance the 150 the anniversary edition of Moby Dick published by the Northwestern University Press in 1991. It may make sense and provide some utility for readers for cataloger's to consider this edition a different work than the Norton Critical Edition, 2d edition, of Moby Dick. Because we like to relate a work to a creator of the work when we can, I'll point out the creator of each of these works is the editor or editorial group that edited the text of Moby Dick-if they did that--and compil
Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas
A big mistake, if it means what we think it means, that RDA has decided that a given Manifestation can not contain several Expressions. Riley, Jenn wrote: What the RDA folks (that is, the folks who have created RDA, the JSC members) said (some of them off-list to me), is that if your manifestation is an aggregate, then your Expression must be an equal aggregate. So the Expression is pretty much one-to-one with the Manifestation. (And I think we were all seeing a many-to-many.) I see this conclusion as RDA's, but not FRBR's. The FRBR report explicitly says there can be a many-to-one relationship between Expressions and a Manifestation (that is, a Manifestation can embody several Expressions), and the V/FRBR project takes that at face value and does not impose the additional restriction that a Manifestation contains an equal aggregate. RDA may impose that restriction, but that's their implementation of FRBR, and the V/FRBR project as *not* an RDA implementation doesn't feel bound by that decision. Obviously I think that RDA has made a mistake in adding in a requirement that "if your manifestation is an aggregate, then your Expression must be an equal aggregate." But that's their business, I guess. Jenn Jenn Riley Metadata Librarian Digital Library Program Indiana University - Bloomington Wells Library W501 (812) 856-5759 www.dlib.indiana.edu Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
Re: [CODE4LIB] Variations/FRBR project relases FRBR XML Schemas
On Sun, 21 Mar 2010, Karen Coyle wrote: One thing I am finding about FRBR (and want to think about more) is that one seems to come up with different conclusions depending on whether one works down from Work or works up from Item. The assumption that an aggregate in a bound volume is an Expression seems to make sense if you are working up from the Manifestation, but it makes less sense if you are working down from the Work. If decisions change based on the direction, then I think we have a real problem! It's a *reference model*. People are going to apply it differently, for what works in their situation. It is pointless to assume that we will ever get everyone to agree on a single implementation -- it's either too complex and waste's people time for stuff they don't care about, or it's not complex enough and doesn't handle your special situations and strange edge cases. Build the system that makese sense for your needs, and use FRBR as guidelines on issues to consider, basic requirements, etc. It is not an API spec. It is not an interchange format. RDA, on the other hand, is more concrete -- it has specific cataloging instructions on how to deal with specific situations. (and well, in the case of aggregates as new expressions without a resultant new work, as I've come to understand from this discussion, rules that might not comply with FRBR) With the RDA toolkit, you even have a specific implementation. ... Maybe my take on the situation is different because I don't deal with bibliographic objects. Technically, by FRBR, I don't even deal with Items, as it's all digital. (and I don't want to try to answer if little bits of magnetic film spread across my disk arrays make up an 'Item', as then I have to consider things being new Items when my disk array decides to move data around because a drive starts to fail) ... as such, there's no way in hell I'm going to be able to mesh my resultant catalogs with most other people's catalogs (and to do so, wouldn't make sense for the users). I also have to try to mesh other catalogs with our federation, where we just don't have the funding to re-catalog every object, so I'm just trying to see how each catalog fits within a common model, so I know how to talk to each system and how the granularity of their results compares to the results from other systems. I specifically have to plan for everyone coming up with their own systems; some are spectacularly bad. (A new database table every year or month, so we don't hit limits within our database. Multiple related tables, but not actually assigning foreign keys between them. Over 10k tables, with each catalog table storing both current and deprecated data and no way to easy way to select just the deprecated data without going through an overly cumbersome abstraction interface (which merges in constants as stored in other yet other tables) ... and each of the catalog tables has no fixed specification.) ... I'm with Jenn on this -- different groups can set set up their little idealized implementations of FRBR, as is being done with RDA, and the different groups working on their implementation can ignore them when it doesn't fit with their needs. More concrete systems *are* needed, or we're going to end up with a near-infinate number of variations, but some people are going to find it easier to deal with a more restrictive model, where they don't have to deal with complexity; and others are going to have strange edge cases that don't fit within the restrictions that require that same complexity. The final vote on if people accept the restrictions of RDA will be if they decide to adopt it, or if they have to go with some other implementation. -Joe
