I don't think that there is an RDA equivalent, but I think this is because RDA makes no claims to be anything beyond an element list (unlike previous cataloging codes) and it relies on this four-convention model (RDA 24.4) for presenting elements. Looking at RDA from the outside, and acknowledging this four-convention model, I can see that some might have argued that the "list of chapter headings, songs, parts, etc." under FRBR 4.3.9 is more appropriately viewed as a structured description of contained works or expressions and so should be dealt with under RDA 25.1.1.3.
What this seems to mean in practice is that whenever 24.4 is invoked in an RDA instruction, two possible coding structures are likewise invoked: identifiers and preferred access points entail an entity-relationship-entity structure whereas structured and unstructured descriptions entail an entity-attribute structure. Again, I'm only proposing this interpretation. I arrive at it by sort of reverse-engineering RDA. Ed -----Original Message----- From: Karen Coyle [mailto:li...@kcoyle.net] Sent: Thursday, March 11, 2010 10:30 AM To: Ed Jones Cc: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: RE: [RDA-L] Contents of Manifestations as Entities Quoting Ed Jones <ejo...@nu.edu>: > But I think it _is_ in FRBR. I read "list of chapter headings" > under "FRBR 4.3.9 Attributes of an expression: Summarization of > content" (which I rendered as <hasContents>) as synonymous with > "table of contents": > > 4.3.9 Summarization of Content > > A summarization of the content of an _expression_ is an abstract, > summary, synopsis, etc., or a list of chapter headings, songs, > parts, etc., included in the _expression_. > > (FRBR, p. 37. http://www.ifla.org/files/cataloguing/frbr/frbr_2008.pdf) Great, Ed. Thanks! Now, can we find that in the RDA element set? Look at 7.10.1.1 in RDA: "A summarization of the content is an abstract, summary, synopsis, etc., of the content of a resource." (Note that it stops at "synopsis, etc.") And yes, there's a "summarization of the content" in the RDA list for the Expression. RDA doesn't mention TOC's , nor do any of the examples show a TOC, so it still isn't clear to me if TOC's go here in RDA... but for the reasons I've given before I'd be inclined to extend this data element by adding some sub-elements for 1) summary (=MARC 520) 2) TOC (=MARC 505). That would give the cataloger a choice when there are included works -- either treat them as related works, or create a simple TOC. IS THIS ALLOWED IN RDA? Or does RDA always treat included works ONLY as related works, not as a TOC? (OMG, I think I'm back to where I started. Will it all be this hard?!) Note: I have two documents that do MARC to RDA that I must have found somewhere on the JSC pages, but in the one that has "Summarization of the content" it is blank where a MARC field would go. I suspect these documents are just drafts. Thanks again for hanging in there with all of my meanderings and false directions, Ed. A+++ for effort and tenacity. :-) kc > > Ed > > -----Original Message----- > From: Resource Description and Access / Resource Description and > Access [mailto:rd...@listserv.lac-bac.gc.ca] On Behalf Of Karen Coyle > Sent: Thursday, March 11, 2010 9:03 AM > To: RDA-L@LISTSERV.LAC-BAC.GC.CA > Subject: Re: [RDA-L] Contents of Manifestations as Entities > > Quoting Ed Jones <ejo...@nu.edu>: > >> I guess my problem is I don't see a problem. It makes perfect sense >> to me that FRBR treats these as relationships between entities when >> it is useful to do so and as attributes of expressions when it is >> useful to do so. > > That does make sense, but it isn't in FRBR. In FRBR there are no > contents as attributes of expression, just "Whole/Part > Expression-to-Expression Relationships" (p. 71) I would favor having > such an attribute, for some of the reasons I give below. > > > Each of these treatments can be expressed >> formally. It also makes sense to me that RDA discusses these >> alternatives in a single place, since RDA routinely offers four >> alternative ways of expressing content in its elements: >> identifiers/preferred access points/structured >> descriptions/unstructured descriptions. RDA deliberately does not >> address display or data structures, but there is nothing to prevent >> users of RDA from devising or adopting schemes that treat >> identifiers and preferred access points as relationships between >> works (and/or expressions), and structured and unstructured >> descriptions as attributes of expressions. Both can be espressed as >> triples, if desired, just different triples: >> >> <frbrWork><contains><frbrWork> [relationship between works] >> >> <frbrExpression><hasContents><string> [attribute of expression] >> > > That latter is exactly what I went looking for when all of this > discussion got started. There isn't a "has contents" attribute of > expression in RDA nor in the RDA elements. Oddly, there isn't even an > Expression-to-Expression "has contents" in the RDA text but the list > of relationships provided by JSC is more complete. Now, we've been > told that in fact all of those relationships are [any WEMI > entity]/[specific WEMI entity]. The list of Group1 entity > relationships (http://kcoyle.net/rda/group1rels.txt) has > > Contained in (Expression) > Contained in (item) > Contained in (Manifestation) > Contained in (Work) > Contains (Expression) > Contains (Item) > Contains (Manifestation) > Contains (Work) > > Meaning it would be possible to have a Manifestation that contains > either Works or Expressions. (Works being analogous to a 7XX, I > believe.) So here's what I see: > > 1) we have a "contains" that can have as its object any one of WEMI. > 2) the object of this "contains" is an entity, by definition. An > entity is either W,E,M, or I. > 3) the examples in chapters 25 and 27 show strings for individual > Works and Manifestations, but in fact all of the examples in the RDA > text show strings. I have to assume that in a machine-readable record, > those strings would be coded in some way as actual entities, and, for > example, the Work entity would have an established Work title, and > other elements as appropriate. It would also have a relationship to a > creator entity. In non-ER terms, like MARC, this could look like a > 1XX/245, 7XX $a $t, or whatever else is enough to identify the Work. > 4) the string that looks like a table of contents is not an entity. > Having the object of "contains" sometimes be an entity and sometimes > be a free text string is decidedly sub-optimal for data processing, > because it means that you have two entirely different kinds of data > that are the object of the same relationship. I assume this is there > for legacy reasons, and therefore in a data carrier I would probably > prefer to create the attribute you mention above to carry legacy data. > 5) the obvious down side of the E-R version is that the contained Work > entities, if they have not already been established, need to be > established, and that means determination of the preferred Work title > and name form. > 6) if there is a reason to provide the table of contents as > transcribed information, we don't seem to have a place for that. I > don't know how we would do chapter numbering, or chapters that aren't > generally considered individual works. Perhaps this is somewhere in > RDA -- it doesn't jump out at me from the data elements, which is what > I am most familiar with. > > kc > > > > -- > Karen Coyle > kco...@kcoyle.net http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
