> -----Original Message----- > From: Resource Description and Access / Resource Description and Access > [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle > Sent: January 9, 2012 1:42 PM > To: RDA-L@LISTSERV.LAC-BAC.GC.CA > Subject: Re: [RDA-L] Some comments on the Final Report of the FRBR Working > Group on Aggregates > > Quoting "Brenndorfer, Thomas" <tbrenndor...@library.guelph.on.ca>: > > > > The confusion seems to arise from the unique "many-to-many" > > relationship of the expression to the manifestation. As soon as the > > "many" kicks in for multiple expressions embodied in one > > manifestation, the notion of the structural relationship of "parts" > > unfortunately also kick in, but it shouldn't be necessary to invent > > some new vertical whole-part relationship when this happens, as this > > would convey the same information as the existing primary > > relationship. > > But the horizontal whole/part does exist. If the vertical > relationships are enough to convey that, why does FRBR/RDA have the > horizontal parts and what were they intended for? Maybe THAT's the > source of the confusion. >
Because there are many-to-many relationships that are horizontal as well as the many-to-many primary relationship unique to expressions and manifestations. For the case of the aggregating expression, going over it again ... An expression may be embodied in a manifestation. That expression could be accompanied by other expressions embodied in the same manifestation. That's a vertical many-to-one scenario-- expression(s) to manifestation. One doesn't need a special whole/part relationship for this, because the primary relationship (a vertical relationship) establishes this. The resulting aggregating expression has whole-part relationships to each constituent expression. That's a horizontal many-to-one scenario. That aggregating expression also has vertical relationship to the manifestation. It could have another vertical relationship to another manifestation (an e-resource version of a print publication for example). The two types of relationships (horizontal and vertical) are like check-off lists for all the possible bibliographic relationships. Going further ... That original single expression may also have been published in a >>different set<< of expressions in another manifestation (creating a different aggregating expression). That original expression may have other structural or content relationships to yet other expressions (different horizontal relationships, such as 'adaptation of' or 'revised as' or 'translation of'). More many-to-many relationships are being fulfilled. That original expression could also be published in different manifestations (different vertical relationships -- now we're in that vertical many-to-many territory). But that original expression will only ever "realize" one and only work (and inherit its attributes). So horizontally and vertically, that original expression can have multiple relationships, except upwards to the one work that it realizes. From a display point of view, there are a lot of variables to consider. In browse lists currently, analytical title entries are confusing. In author browses, name-title headings juxtapose with the titles found under the author's name. Title browses can be a bit better, but the nature of the relationship of one title to another is not clear until each record is examined in more detail. Keyword searches will bring up brief record displays where the analytical titles in the Content notes or added entries are obscured. The LibraryThing approach is what I favor -- have a web page for each entity, and populate that web page with all the attributes and relationships associated with that entity. If it's the work, show the available expressions (and manifestations), but also show the horizontal structural and content relationships, so one can navigate both vertically and horizontally. There is some redundancy in navigating horizontally to the aggregating work and then down to the same manifestation, but then one would be able to see all the other associated works in the aggregating work, and explore outwards from them. Smarter systems may even highlight these kinds of whole-part and vertical relationships, and perhaps go beyond LibraryThing by tackling manifestation and item records. In my system, availability information at the item level already influences screen display-- the user is directed to the available copies first. Our NoveList widget alerts users to similar titles based upon presence in the catalog (this is at the manifestation level). If all the FRBR relationships were present, the system could alert the presence of associated works at the highest level and direct users to particular combinations of relationships, with appropriate deduplication. (Some of the FRBR-lite utilities like LibraryThing for Libraries already do some of this). Thomas Brenndorfer Guelph Public Library
