 |
 |
Joe, if I were you I wouldn't defer to designers of discovery interfaces, but would be actively engaging with what essentially should be viewed as part of the same workflow -- from receipt of materials through user services. As a cataloger, you ARE a designer of major part of the discovery interface; it can't be separated from the cataloging data. And that means that you ARE responsible for how the catalog data serves users through the library system. If the results aren't good, the entire workflow needs to be involved in making it better. kc On 7/27/15 2:25 PM, Joseph Kiegel wrote: > > I agree we need both. The proposal makes no assumptions about display > or indexing. It is simply a model to encode information recorded from > the piece and to provide a link to related series works. Designers of > discovery interfaces can do as they will with the data. > > Joe > > *From:*Bibliographic Framework Transition Initiative Forum > [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle > *Sent:* Monday, July 27, 2015 2:02 PM > *To:* [log in to unmask] > *Subject:* Re: [BIBFRAME] Proposal for treatment of series in BIBFRAME > > Joe, > > However, that doesn't mean that you can't have an identifier for the > series. In fact, that is a good argument FOR an identifier, if, as you > say, the name of the series isn't reliable as a way to identify > members of the series. Identifiers and transcribed strings have > different purposes, and don't cancel out each other. If you need both, > you supply both. I think, though, that it would be a good idea to have > a clear understanding of the respective roles of each of these types > of information. I've long thought that transcribed data should be > clearly marked as such for users, especially when it conflicts with > user expectations (e.g. when the transcribed string includes a typo), > and may not be appropriate as the general user display. The role that > transcription has played in the past as the preferred form in the > catalog record is due to the fact that there wasn't a way to display > clearly identified different versions of certain data elements, > especially in the card/string oriented bibliographic record. That's no > longer the case, so a transcribed string can be explicitly coded as a > transcribed string, and doesn't have to be the preferred user display > or the preferred source of indexing. Those users who need the detail > of transcription should be able to see it, but there is no reason for > it to predominate in cases where it actually makes finding things, > like members of a series, more difficult. > > kc > > On 7/27/15 11:16 AM, Joseph Kiegel wrote: > > If all series were as simple as Penguin Classics, then storing > information in an identifier would meet library needs. But that is > not the case. There is a library (internal) use case for having a > record of the form of series on manifestations, for the purpose of > maintenance. This isn’t met by an identifier, even an identifier > that has non-preferred forms of the name (because you still don’t > know which piece has which name—important for determining series > title changes). Series may be quite changeable, including random > variation caused by publishers’ lack of consistency and errors. > The series proposal is meant to deal with the complexity found in > the bibliographic world and library practice to handle this > complexity over time. > > Joe > > *From:*Bibliographic Framework Transition Initiative Forum > [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle > *Sent:* Thursday, July 23, 2015 6:25 PM > *To:* [log in to unmask] <mailto:[log in to unmask]> > *Subject:* Re: [BIBFRAME] Proposal for treatment of series in BIBFRAME > > Joe, as stated, the RDA rules are "technology neutral." I don't > think that they say that a string can't be represented by an > identifier so that one doesn't have to write "Penguin Classics" > over and over again when recording the series, any more than it > would state that one couldn't select a series title from a list of > existing series titles. Any string that is likely to be repeated > could be assigned an identifier. In fact, this is often what > happens inside a database management system for repeated strings, > especially those that are indexed, so it is already a fact of our > existing systems. > > One thing I think that we have failed to do (as a profession) is > to bridge the gap between the intent of the cataloging rules and > the actual functioning of the technology that will manage the data > that is created in the cataloging workflow. If the cataloging > rules require "recording series information", does that mean that > the information is intended for display? for search? what kind of > search? "Recording" doesn't answer those questions, but they do > need to be answered. A lot happens, or should happen, after the > cataloging data is created, and we don't seem to have a clear > specification of what that is. > > kc > > On 7/22/15 8:34 AM, Joseph Kiegel wrote: > > There is a need for both. Cataloging codes, like RDA, require > recording series information, and that is why > bb:seriesStatement is needed. Some libraries (but not all) > additionally provide a link to a related series work, and that > is best done, of course, with an identifier. Neither of these > two mechanisms replaces the other: both are necessary. > > Joe > > *From:*Bibliographic Framework Transition Initiative Forum > [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle > *Sent:* Wednesday, July 22, 2015 8:00 AM > *To:* [log in to unmask] <mailto:[log in to unmask]> > *Subject:* Re: [BIBFRAME] Proposal for treatment of series in > BIBFRAME > > Nate, I buy that as long as there are only two options: > > 1. series statement that is a plain string > 2. series entity with an identifier > > It makes little sense to create a blank node when an identity > can be created. True, there will not be authoritative > identifiers for all (or even most?) series, but merging can > take place over time until most series have a useful identifier. > > The bottom line is that there is no reason not to identify > series where one can. > > kc > > On 7/22/15 6:35 AM, Trail, Nate wrote: > > It’s pretty clear that sometimes a series is just a > statement and sometimes it can be a work in its’ own > right, so we need both bf:seriesStatement and > bf:series/bf:Work to accommodate both. > > Nate > > *From:*Bibliographic Framework Transition Initiative Forum > [mailto:[log in to unmask]] *On Behalf Of *Karen Coyle > *Sent:* Tuesday, July 21, 2015 11:39 AM > *To:* [log in to unmask] > <mailto:[log in to unmask]> > *Subject:* Re: [BIBFRAME] Proposal for treatment of series > in BIBFRAME > > Joe and Theo, > > This is clearly a well-thought out bit of work. I assume > that the blank node solution is viable, but I wonder if > you contemplated another possibility: that the series is a > bibliographic entity on its own that has a relationship > with monograph? This would make sense given that: > - a series is a work in its own right > - there can be catalog entries for the series itself > - some series have authority records > > The advantage of this solution is that it identifies a > series with a persistent identifier that would allow one > to link all members of the series, e.g. to show a list of > monographs in the series. The disadvantage is that it has > to solve these problems: > 1. what to do with series that usually do not get > authority control (e.g. the publishers' series) (my take: > treat them as entities and give them an ID) > 2. at what "level" to link a series to a bf:Instance (the > bf:Work for the series?) > > The #2 question there is one that is even more complex > with FRBR, but is true for all multi-entity bibliographic > models, which is that bibliographic relationships need to > be made between entities and it isn't always clear which > entities are appropriate for the relationship. In this > case, the series as a bf:Work is manifested as a group of > bf:Instance's with a "partOf" relationship. There's no > single publication that is the bf:Instance of the series. > Perhaps this has already been resolved in how serials are > handled in BIBFRAME, though. Hopefully someone can weigh > in on that. > > kc > > On 7/20/15 10:33 AM, Joseph Kiegel wrote: > > Series are complex and need a more detailed treatment > than has been provided to date. Theo Gerontakos and I > have written a proposal with a way to handle them. It > is attached, and also available at: > > http://www.lib.washington.edu/msd/pubcat/ld/uw-series-proposal > > Joe Kiegel > > > > > > > -- > > Karen Coyle > > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > > > > > -- > > Karen Coyle > > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > > > > -- > > Karen Coyle > > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > > > -- > Karen Coyle > [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net > m: +1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 -- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600