Yes, what Karen said. (Thanks, Karen!) That's exactly how we look at it. So a Manifestation does have Expressed Works in it (to answer your question Jonathan), just more than one in many cases. Since more than one is OK, no need for aggregates.
Jenn > -----Original Message----- > From: Resource Description and Access / Resource Description and Access > [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Karen Coyle > Sent: Monday, October 18, 2010 1:58 PM > To: RDA-L@LISTSERV.LAC-BAC.GC.CA > Subject: Re: [RDA-L] FRBRized data available for bulk download > > Quoting Jonathan Rochkind <rochk...@jhu.edu>: > > > > > > My understanding of the FRBR model is that it insists that _all_ > > manifestations belong to an expression which belongs to a work. This > is > > what leads to aggregates neccesarily being works -- you've got a > > manifestation in front of you which is clearly an aggregate. So the > > manifestation must be part of a work. > > If you look at the simple Group1 diagram: > http://archive.ifla.org/VII/s13/frbr/fig3-1.jpg > you see that a manifestation can manifest more than one expression. So > there are two (at least) ways to go: > > 1) consider the aggregate a manifestation and an expression and a > work; but that doesn't explain why manifestation and expression are > many-to-many > > 2) consider an aggregate a manifestation of more than one expression, > and each expression expresses a single work (note the arrows between > expression and work -- each expression can express only one work). > > It seems to me that the aggregate form (#1 here) completely negates > the separation between work, expression and manifestation -- we get > back to traditional cataloging where we've only got one "thing" -- > which is defined by the manifestation. It also means that once again > just about every publication becomes a separate "thing" and we are > back to showing our users long lists of bibliographic records for the > same text. If that's the goal, why did we bother with FRBR in the > first place? What does it gain us? > > kc > > > > > Possibly it would be better/more flexible to allow manifestations > that > > do not in fact belong to any expression or work; but I'm not sure, it > > gets confusing to think about. I think maybe a manifestation > > neccesarily has to belong to an expression and a work for the model > to > > make any sense -- but that doesn't mean the work it belongs to > actually > > needs to be _modelled_, it can just be an as-of-yet-un-modelled work, > > that will be modelled only when/if it is useful to do so. > > > > Curious how you are handling this in terms of the model exactly > though, > > I'm confused. > > > > Riley, Jenn wrote: > >> Hi Stephen and all, > >> > >> We’ve made an intentional decision for the V/FRBR project to not > >> use the concept of an aggregate work. The many-to-many nature of > >> Expression to Manifestation for our need adequately models the fact > >> that two symphonies were released on the same disc (for example). > >> For our purposes, there’s no practical (or even semantic in my > >> opinion) benefit to calling those two symphonies by two different > >> composers an aggregate Work. > >> > >> Like others have commented, I also have reservations about the > >> aggregate notion in FRBR as a whole. That has fed into the > >> practical decisions our project has made. > >> > >> Jenn > >> > >> > >> On 10/17/10 9:53 PM, "Stephen Hearn" <s-h...@umn.edu> wrote: > >> > >> For those who argue that FRBR defines aggregates as works, I wonder > >> if this is too atomic an approach. If there is an aggregate FRBR > >> work whose contents are expressed in an aggregate FRBR expression > >> and embodied in an aggregate FRBR manifestation, couldn't one > >> reasonably argue that the manifestation is really only the > >> embodiment of that aggregate work, and is rather a container for > >> the other, individuated FRBR works that Variations is working with? > >> Does Variations enable the description of the single aggregate > >> FRBR work that a given manifestation arguably represents? > >> > >> For example, a search on "octubafest" identifies two "work results" > >> with that word in the title, but they are individual pieces > >> (Octubafest march and Octubafest polka). Wouldn't FRBR consider the > >> aggregation manifested as "Octubafest 1981" and the others like it > >> to be works as well? > >> > >> That said, I've long considered the notion of aggregates as FRBR > >> works to be problematic, so I see a lot to admire in the Variations > >> approach. > >> > >> Stephen > >> > >> On Sun, Oct 17, 2010 at 3:04 PM, Riley, Jenn <jenlr...@indiana.edu> > wrote: > >> Dear Bernard and List, > >> > >> My apologies for not responding sooner; I'm impossibly behind in > >> reading listserv email. Comments below. > >> > >> > >>> Riley, Jenn wrote: > >>> > >>> > >>>> The Variations/FRBR [1] project at Indiana University has released > >>>> bulk downloads of metadata for the sound recordings presented in > our > >>>> Scherzo [2] music discovery system in a FRBRized XML format. > >>>> > >>>> > >>> Before digging into this any further, one question: How is the > >>> linking between works and expressions effected? On first > inspection, > >>> I find nothing in the expression data that would indicate the work. > >>> > >> > >> The XML format that defines this data (our project "efrbr" > >> definition; more information at > >> > <http://www.dlib.indiana.edu/projects/vfrbr/schemas/1.0/index.shtml>) > >> doesn't have the concept of a "record," just "entities" and > >> "relationships". The XML wrapper can include any combination of > >> entities and relationships - there's no requirement that it be, > >> say, Work-centric (show one Work and all the other FRBR entities > >> with relationships to that Work) or Manifestation-centric (show one > >> Manifestation and all the other FRBR entities with relationships > >> to that Manifestation), though you could easily use the format for > >> either of those purposes. Therefore the big .xml file that has all > >> the Expression data doesn't *have* to have relationships between > >> Expressions and Works to be valid. We simply chose to arbitrarily > >> break the data into individual XML files by entity and relationship > >> type, since there was enough data we knew we had to split it up > >> somehow to keep the file size to something remotely manageable, so > >> this seemed logical. It's just the raw data - a system using it > >> could index and store and update it however it likes. All the > >> relationships are there, though, spread across all of the files. > >> Relationships between Works and Expressions can be found in the > >> file realizedThrough.xml. > >> > >> > >>> I suspect the link to be via the file realizedThrough.xml, because > >>> between manifestation and expression, there's the file > embodiedIn.xml > >>> which seems to be the link between the two. However, I'd have > expected > >>> the relationship between E and M to be 1:n, yet it seems to be > >>> the opposite. > >>> Can you elaborate on this matter? > >>> > >> > >> You've switched to talking about the relationship between > >> Expression and Manifestation rather than Expression and Work, so > >> I'm a bit confused as to what you're asking, but I'll give it a > >> shot. You're correct that embodiedIn.xml lists relationships > >> between Expression and Manifestation. (Note "realized through" and > >> "embodied in" are terms right out of the FRBR report to describe > >> these relationships.) The relationship between Expression and > >> Manifestation is n:n (many to many). A given Expression be embodied > >> in any number of different Manifestations, and a given > >> Manifestation may embody any number of different Expressed Works. > >> In embodiedIn.xml, each element <efrbr:embodiedIn> describes the > >> relationship between one Expression and one Manifestation. This > >> statement, however, doesn't mean that's the only Manifestation of > >> that Expression, or the only Expression that appears on that > >> Manifestation. Instead, these are just tiny statements of fact. To > >> find all the Expressions on a given Manifestation (which is only > >> one of the many questions one might want to ask of this data), > >> you'd need look for all of the <efrbr:embodiedIn> statements that > >> have the URI for the Manifestation you care about in the @target > >> attribute. You can see some of these right at the beginning of the > >> file: > >> > >> <efrbr:embodiedIn > >> source="http://vfrbr.info/expression/1"; > >> target="http://vfrbr.info/manifestation/1"/> > >> <efrbr:embodiedIn > >> source="http://vfrbr.info/expression/2"; > >> target="http://vfrbr.info/manifestation/1"/> > >> <efrbr:embodiedIn > >> source="http://vfrbr.info/expression/3"; > >> target="http://vfrbr.info/manifestation/1"/> > >> <efrbr:embodiedIn > >> source="http://vfrbr.info/expression/4"; > >> target="http://vfrbr.info/manifestation/1"/> > >> > >> To find all the Manifestations a given Expression appears on, you'd > >> look in the data for all the <efrbr:embodiedIn> statements that > >> have the URI of the Expression you care about in the @source > >> attribute. Basically it's a whole bunch of very atomic data that > >> can be combined in any way to answer all sorts of different > >> questions: What Works are by this Person? What Manifestations were > >> published by publisher X? What Works were performed by Corporate > >> Body X (i.e., which Works have Expressions that have realized by > >> relationships to that Corporate Body)? Ad infinitum... > >> > >> > >>> Many thanks, > >>> B.Eversberg > >>> > >> > >> Hope this helps. > >> > >> Jenn > >> > >> ======================== > >> Jenn Riley > >> Metadata Librarian > >> Digital Library Program > >> Indiana University - Bloomington > >> Wells Library W501 > >> (812) 856-5759 > >> www.dlib.indiana.edu <http://www.dlib.indiana.edu> > >> > >> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com > >> <http://www.inquiringlibrarian.blogspot.com> > >> > >> > >> > >> ======================== > >> 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
