Cataloging print monographs which are aggregates

[briesenberg07]

2023-11-06:
I've created four sets of description sets for the same print monograph, using four approaches for describing aggregates. Three of the four approaches are taken from @pan-zhuo 's draft guidance on describing aggregates, the fourth was suggested during template-review meetings. I'm outlining the very minimal description sets below ('OPTION A' - 'OPTION E') along with links to the data (RDF/XML with property labels commented in) and the guidance document.

Outline of current approaches

OPTION A

See option_a.rdf in uwlib-cams/Sandbox
See draft guidance

• aggregate manifestation
  • has expression manifested
  • exemplar of manifestation
  • has title proper
  • uwrdaext:HasLcClassificationPartA
  • uwrdaext:hasLcClasificationPartB
  • has identifier for manifestation (nomen resource)
  • has copyright date
  • has media type
  • has carrier type
• aggregated works
  • has expression of work
  • has preferred title of work
  • has author person
• aggregated expressions
  • has work expressed
  • has manifestation of expression
  • has preferred title of expression
  • has content type
  • has language of expression
  • has script
• item
  • has manifestation exemplified
  • has preferred title of item
  • has identifier for item
  • is holding of (collection manifestation resource)

OPTION B

See option_b.rdf in uwlib-cams/Sandbox
See draft guidance

• aggregating work
  • has manifestation of work
  • has preferred title of work
  • has extension plan
  • has content type of representative expression
  • has language of representative expression
  • has script of representative expression
• aggregate manifestation
  • has work manifested
  • has exemplar of manifestation
  • has title proper
  • uwrdaext:HasLcClassificationPartA
  • uwrdaext:hasLcClasificationPartB
  • has identifier for manifestation (nomen resource)
  • has copyright date
  • has media type
  • has carrier type
  • has contributor person to aggregate
• item
  • has manifestation exemplified
  • has preferred title of item
  • has identifier for item
  • is holding of (collection manifestation resource)

OPTION C

See option_c.rdf in uwlib-cams/Sandbox
See draft guidance

• aggregating work
  • has manifestation of work
  • has preferred title of work
  • has extension plan
  • has content type of representative expression
  • has language of representative expression
  • has script of representative expression
• aggregate manifestation
  • has expression manifested
  • has exemplar of manifestation
  • has title proper
  • uwrdaext:HasLcClassificationPartA
  • uwrdaext:hasLcClasificationPartB
  • has identifier for manifestation (nomen resource)
  • has media type
  • has carrier type
• aggregated works
  • has expression of work
  • has preferred title of work
  • has author person
• aggregated expressions
  • has work expressed
  • has manifestation of expression
  • has preferred title of expression
  • has content type
  • has language of expression
  • has script
• item
  • has manifestation exemplified
  • has preferred title of item
  • has identifier for item
  • is holding of (collection manifestation resource)

OPTION D

No test data at this time...
See draft guidance

OPTION E

See option_e.rdf in uwlib-cams/Sandbox
See draft guidance

• aggregating work
  • has manifestation of work
  • has preferred title of work
  • has extension plan
  • has content type of representative expression
  • has language of representative expression
  • has script of representative expression
• aggregate manifestation
  • has work manifested
  • has exemplar of manifestation
  • has title proper
  • uwrdaext:HasLcClassificationPartA
  • uwrdaext:hasLcClasificationPartB
  • has identifier for manifestation (nomen resource)
  • has media type
  • has carrier type
• aggregated works
  • has manifestation of work
  • has preferred title of work
  • has author person
• item
  • has manifestation exemplified
  • has preferred title of item
  • has identifier for item
  • is holding of (collection manifestation resource)

[briesenberg07]

With apologies for the fact that at this point, my questions about RDA aggregates in Sinopia and the approach thus far are fairly general and somewhat vague...

...if possible I'd like feedback on the following (or any other feedback!) from the resource-template testing group and any MARC2RDA members with interest.

• Are all the current options well-formed RDA (that is, am I missing any obvious problems)?
• Are there thoughts on which option(s) are best for each of collection, augmentation, and parallel aggregates?
• Can these options cover aggregates for the print monograph format, or are other approaches needed?
• The current description sets for these options are very minimal, additional elements will no doubt be desired in subsequent description sets--notes on specific additional desired elements are welcome.
• Where an aggregating work is not described, where to provide an extension plan? (Provide this for each work which is realized by an aggregated expression? Dispense with this element?? etc.)
• Is it desirable to also test option D? Would this option ever be needed?

Resource template testers, MARC2RDA members: @AdamSchiff @gerontakos @junghaelee @JianPLee @cspayne @CECSpecialistI @lake44me @SitaKB @GordonDunsire @tmqdeborah @corialanus @szapoun

See also crystalyragui/MARC2RDA#354

[CECSpecialistI]

Hi Benjamin! I see this and have added it to the top of the agenda for MARC2RDA tomorrow. We may not be able to answer all these questions, but we can review them, get them on the group's radar, and make a start.

[tmqdeborah]

I have not had enough time to go over everything in detail, but here are my thoughts at this point. I'm sorry that my formatting, below, isn't great.

Are all the current options well-formed RDA (that is, am I missing any obvious problems)?

• I don’t see an Option D.

Are there thoughts on which option(s) are best for each of collection, augmentation, and parallel aggregates?

• For augmentation aggregates (single expression with supplementary content), Option A (aggregated expression and work) is most useful.

• For parallel aggregates (single work with parallel expressions), Option A, modified (aggregated expressions and single work) is sometimes enough, but other times (e.g., if the point of the manifestation is to provide the parallel expressions, e.g., for teaching purposes) Option C (aggregated expressions and single work + aggregating work) can be useful.

• For collection aggregates with a limited number of aggregated expressions, Option A (aggregated expressions and their works) is enough, unless subjects relating to the collection itself are needed, in which case Option C is best.

• For collection aggregates with too many aggregated expressions for it to be feasible to describe them all separately, Option B (aggregating work only) is often enough.

• In all cases, if supplementary content is present, it should be recorded in appropriate manifestation elements. If aggregated expressions/works and their related agents are not described, then those agents should be recorded using appropriate contributor to aggregate relationships.

Can these options cover aggregates for the print monograph format, or are other approaches needed?

• These options are appropriate for all types of materials, including volumes that carry textual content of static works.

The current description sets for these options are very minimal, additional elements will no doubt be desired in subsequent description sets--notes on specific additional desired elements are welcome.

• Single expressions, parallel expressions, and collections can all be augmented by supplementary content; so, your templates should all include Manifestation elements for that content.

• I don’t see authorized access point elements for any of the entities.

• Option B, C, and E are missing the Work: aggregator element

Where an aggregating work is not described, where to provide an extension plan? (Provide this for each work which is realized by an aggregated expression? Dispense with this element?? etc.)

• Yes, I recommend that you provide an appropriate value of extension plan for every work described.

Is it desirable to also test option D? Would this option ever be needed?

• This option would be needed if you knew or suspected that an aggregating work plan is embodied in more than one aggregate manifestation. In this situation, you can:

• describe the aggregating work and the aggregating expression

• describe one or more of the aggregated expressions and their works and related agents

• relate the aggregated expressions to the aggregating expression using the Expression: aggregated by / aggregates relationship instead of to the aggregate manifestation using Expression: manifestation of expression / expression manifested relationship

• relate the aggregating expression to the aggregate manifestation using the Expression: manifestation of expression / expression manifested relationship

• This provides a shortcut that allows you to only have to relate the set of aggregated expressions once to the aggregating expression and then relate that aggregating expression to each aggregate manifestation that embodies it, instead of having to relate each of the aggregated expressions separately to each aggregate manifestation that embodies the aggregating work that is the plan for that set of aggregated expressions.

• It could be very useful to use this option when describing many or all of the aggregated expressions that are aggregated by an aggregating work that is embodied in multiple equivalent aggregate manifestations (e.g., hardcover, paperback, electronic: ePub, PDF, Kindle)

• It would never be useful to use it when an aggregate manifestation embodies only one augmented aggregated single expression, no matter how many equivalent manifestations are available

• It might be useful to use it when parallel expressions are embodied in multiple equivalent aggregate manifestations.

• Note that, in this situation, it would be unnecessary (though allowed) to relate any of the multiple aggregated expressions to any of the equivalent aggregate manifestations.

[GordonDunsire]

Are all the current options well-formed RDA (that is, am I missing any obvious problems)?

• The options all seem to conform with well-formed RDA. @tmqdeborah can advise if RIMMF can import them.

Are there thoughts on which option(s) are best for each of collection, augmentation, and parallel aggregates?

• The example is an augmented collection aggregate; that is, it is a collection aggregate that is augmented overall (by the Introduction). We haven't discussed hybrid aggregates in much detail, but I suspect there is a natural order of precedence for applying each kind of aggregate "molecule" (perhaps parallel then collection then augmentation?). In this case, the augmented expression is secondary to the set of collected expressions and may not be secondary to any one collected expressions. If it is primarily described as a collection aggregate, option C is best. Then to secondarily describe the augmentation aggregate, we need the aggregating work, not the primary aggregated work/expression; that is, option B. But option B is subsumed into option C, so it is a one-step process for this kind of hybrid. I haven't looked into other kinds of hybrid, such as a collection of short stories with an introduction to each: a collected augmentation aggregate ;-) @briesenberg07 : can templates be nested in sinopia? can we build a set of hybrid aggregates templates that re-use the kinds of aggregate templates?

• Should we discuss the impact of the manifestation having a collective title? The options document uses an arbitrary cut-off of "3" for distinguishing options for collection manifestations, but in practice it is better to take other factors into account (aka cataloguer's judgement).

Where an aggregating work is not described, where to provide an extension plan? (Provide this for each work which is realized by an aggregated expression? Dispense with this element?? etc.)

• I agree with @tmqdeborah that extension plan should be a mandatory element for a basic Work template. No work, no plan.

[briesenberg07]

Many thanks to @GordonDunsire and @tmqdeborah for the feedback above. Beginning to dig into this, starting with Deborah's feedback---

💬 I don’t see an Option D.

It's true -- apologies for this. I don't think anyone has created any sample data yet to demonstrate OPTION D

💬 For parallel aggregates (...) other times (e.g., if the point of the manifestation is to provide the parallel expressions, e.g., for teaching purposes) Option C (aggregated expressions and single work + aggregating work) can be useful.

A single aggregated work, with two (or more) aggregated expressions, and aggregated work, as below (I believe). Not sure whether this needs its own option (OPTION F?)...

-

💬 For collection aggregates with a limited number of aggregated expressions, (...) [if] subjects relating to the collection itself are needed, (...) Option C is best.

Could OPTION E work in this case as well? This would provide an aggregating work for subjects relating to the collection itself.

❓ RELATED: OPTION E seems attractive to me as a way to provide information about aggregated works such as related agents and subjects without needing to describe aggregated expressions. But I'm curious whether we will find that we need to say more about aggregated expressions than representative expression elements will allow.

💬 For collection aggregates with too many aggregated expressions for it to be feasible to describe them all separately, Option B (aggregating work only) is often enough.

I need to create more description sets using this option to understand it better. So far, a primary drawback here seems to be the fact that contributors to aggregated works can only be given using the very general property 'contributor agent to aggregate'.

💬 In all cases, if supplementary content is present, it should be recorded in appropriate manifestation elements. (...) Single expressions, parallel expressions, and collections can all be augmented by supplementary content; so, your templates should all include Manifestation elements for that content.

I need to get a grip on which elements these are. Recording descriptions of supplementary content is important, doing so without minting additional work/expression entities will likely be desired in many cases! Can you point me in the right direction here?

💬 I don’t see authorized access point elements for any of the entities.

We are experimenting 🚧 with creating Nomen resources for authorized access points - see the rdaNomen:accessPoint RT.

💬 Yes, I recommend that you provide an appropriate value of extension plan for every work described.

To clarify, in cases where we describe an aggregating work and aggregated work(s), should an extension plan value be given for all of these?

🔬 ASIDE/point of order... is the term 'aggregated works' acceptable? I believe that expressions are aggregated, not the works which they express... But it's so much easier to say 'aggregated works' than 'works which are expressed in aggregated expressions' or similar...

@briesenberg07 to-dos:

• "Option B, C, and E are missing the Work: aggregator element"
  • Confirm presence in templates
  • Consider updating aggregates guidance - at present, this includes information about WEMI-linking elements and very limited information about other elements

[corialanus]

Theo @gerontakos what I should have said this morning (still half asleep I think) was that at this point we have decided to have a Library specific controlled vocabulary in Alma. We have used the 931 MARC tag with the values:
augmentation aggregate
collection aggregate
non-aggregate
parallel aggregate

This is still a 'work in progress' as we haven't finished working through our policy statements for aggregates yet.

[szapoun]

At the National Library of Greece, we will use a local field also. We have not decided yet, but to keep rda related fields together we are thinking of creating a 339 field

[tmqdeborah]

Replies to further questions from @briesenberg07<https://github.com/briesenberg07> 💬 **I don’t see an Option D.**

It's true -- apologies for this. I don't think anyone has created any sample data yet to demonstrate [OPTION D](https://github.com/uwlib-cams/sinopia_maps/blob/751156b041a4cafff757edc9e2ae6f0105b9c06a/md/describing_printMonograph_aggregates.md#option-d)

[[DF]]: I note that in your diagram for [Option D](https://github.com/uwlib-cams/sinopia_maps/blob/751156b041a4cafff757edc9e2ae6f0105b9c06a/md/describing_printMonograph_aggregates.md#option-d), you link the aggregated expressions to both the aggregating expression (aggregated by) and the aggregate manifestation (manifestation of expression). You can certainly do this, but the whole point is that if you provide the expression relationships you do not need to also provide the expression to manifestation relationships. I suggest that you add another aggregate manifestation and item to your diagram indicate the purpose of the aggregates/aggregated by relationship, e.g.: 💬 **For collection aggregates with a limited number of aggregated expressions, (...) [if] subjects relating to the collection itself are needed, (...) Option C is best.**

Could [OPTION E](https://github.com/uwlib-cams/sinopia_maps/blob/751156b041a4cafff757edc9e2ae6f0105b9c06a/md/describing_printMonograph_aggregates.md#option-e) work in this case as well? This would provide an aggregating work for subjects relating to the collection itself.

[[DF]]: No, because Option E does not provide aggregated expressions, and it is the presence of parallel expressions that are important in a parallel aggregate. Remember that every expression/work that is embodied with other expressions/works in an aggregate manifestation can be embodied separately by itself in a single expression manifestation or with different expressions/works in a different aggregate manifestation. So, when you describe an aggregated expression/work, you should treat it just as you would a single expression/work (i.e., whenever possible describe both the expression and the work). In the diagram below, one of the expressions that are embodied by an aggregate manifestation is also embodied by itself in a non-aggregate (i.e., ‘single-expression’) manifestation. ❓ **RELATED: OPTION E seems attractive to me as a way to provide information about aggregated works such as related agents and subjects without needing to describe aggregated expressions. But I'm curious whether we will find that we need to say more about aggregated expressions than representative expression elements will allow.** [[DF]]: If you are describing an aggregated work, then I strongly suggest that you also describe its aggregated expression, even though you will be replicating data already provided in representative expression elements for the aggregating work because, e.g.: - the aggregated expression/work might appear separately in another manifestation, as indicated in the diagrams, above - there is no way to know which of the values of the representative expression elements that are provided for an aggregating work apply to which of the expressions of the aggregated works. Although it is permitted to apply [Option E](https://github.com/uwlib-cams/sinopia_maps/blob/751156b041a4cafff757edc9e2ae6f0105b9c06a/md/describing_printMonograph_aggregates.md#option-e) (aggregate manifestation + aggregating work + aggregated work), I would suggest not doing so. 💬 **For collection aggregates with too many aggregated expressions for it to be feasible to describe them all separately, Option B (aggregating work only) is often enough.**

I need to create more description sets using this option to understand it better. So far, a primary drawback here seems to be the fact that contributors to aggregated works can only be given using the very general property 'contributor agent to aggregate'.

[[DF]: You can use the (slightly) more specific subproperties of ‘contributor agent to aggregate’ (e.g., contributor agent of still image, etc.) The RSC aggregates working group advocated for specific relationships corresponding to the existing agent to WE relationships, but it was felt that if it was necessary to provide those specific WE relationships, then you should do so via descriptions of the appropriate WE entities. This means that a search on an agent (e.g., a person) could find links to works --> expressions --> manifestations or directly to aggregate manifestations, e.g.: Lewis, C.S. Author person of (a work) “Out of the silent planet” “Perelandra” “That hideous strength” Contributor person of text of (an aggregate manifestation) “Christian reflections” “They asked for a paper” In this situation, the user does not know that Lewis is the author of the content of the aggregate manifestation, only that he contributed text (could be only an introduction, or an essay, or he might be an editor of content); which means that they have to go to a description of the manifestation to find out more. 💬 **In all cases, if supplementary content is present, it should be recorded in appropriate manifestation elements. (...) Single expressions, parallel expressions, and collections can all be augmented by supplementary content; so, your templates should all include Manifestation elements for that content.**

I need to get a grip on which elements these are. Recording descriptions of supplementary content is important, doing so without minting additional work/expression entities will likely be desired in many cases! Can you point me in the right direction here?

[[DF]]: The relevant elements are listed below - [Manifestation: accessibility content](https://access.rdatoolkit.org/Content/Index?externalId=en-US_ala-8bf95674-3203-3ba8-a55d-50a44343cb2d) - [Manifestation: colour content](https://access.rdatoolkit.org/Content/Index?externalId=en-US_ala-26e5e1f2-b7fb-383b-954a-b2560eb6eb40) - [Manifestation: illustrative content](https://access.rdatoolkit.org/Content/Index?externalId=en-US_ala-126a56dc-d07f-34bf-9e42-0bfa48a3e574) - [Manifestation: sound content](https://access.rdatoolkit.org/Content/Index?externalId=en-US_ala-6c008de5-4b49-34ac-bf74-e5f70015e748) - [Manifestation: supplementary content](https://access.rdatoolkit.org/Content/Index?externalId=en-US_ala-9d596c05-acc2-39b5-b52a-3274c90ab41d) With the addition of [Manifestation: note on manifestation](https://access.rdatoolkit.org/Content/ContentById/8b78ad49-96c5-404d-be16-cc04f45e04dd) to record a contents note. 💬 **Yes, I recommend that you provide an appropriate value of extension plan for every work described.**

To clarify, in cases where we describe an aggregating work and aggregated work(s), should an extension plan value be given for all of these?

[[DF]]: Yes, an extension plan value should be given for all of them (the aggregating work and any described aggregated works) 🔬 **ASIDE/point of order... is the term 'aggregated works' acceptable? I believe that expressions are aggregated, not the works which they express... But it's so much easier to say 'aggregated works' than 'works which are expressed in aggregated expressions' or similar...** [[DF]]: Well, you won’t find that term (aggregated work) in the TK, but you will find “works that are aggregated” and I believe that “aggregated work” is an acceptable shorthand for that phrase. Some people struggle with distinguishing between “aggregating work" and "aggregated work” however, so in more official settings it might be better to use “works that are aggregated” or ”expressions that are aggregated”. It is also useful to double-check any written use of the two terms “aggregating work" and "aggregated work” to be sure they have not been mixed up (which happens quite often to me) - - - - - - - - Deborah Fritz

[tmqdeborah]

I apologize for the poor formatting of my reply and for the missing diagrams. I replied to the email directly and won't try that again.

Here are the two missing diagrams:

1. I suggest that you add another aggregate manifestation and item to your diagram [for Option D] to indicate the purpose of the 'aggregates/aggregated by' relationship, e.g.:
   

2. In the diagram below, one of the expressions that are embodied by an aggregate manifestation is also embodied by itself in a non-aggregate (i.e., ‘single-expression’) manifestation.

@tmqdeborah

[briesenberg07]

Thanks very much for the further responses @tmqdeborah !

[briesenberg07]

Picking up on @GordonDunsire 's response above, with appreciation for the feedback:

💬 Should we discuss the impact of the manifestation having a collective title? The options document uses an arbitrary cut-off of "3" for distinguishing options for collection manifestations, but in practice it is better to take other factors into account (aka cataloguer's judgement).

Is the question whether or not the presence of a collective title can inform decisions about how to describe an aggregate? This seems to make sense to me, although it isn't immediately clear to me which option the presence of a collective title might argue for.

If there is a collective title, does this argue for considering all (or more) of the aggregated works and expressions as 'primary' (even if less than 3 WEs)?

💬 The options document uses an arbitrary cut-off of "3" for distinguishing options for collection manifestations

Does this refer to the recommentation to use option B for "A collection aggregate where more than three (primary) expressions are aggregated"? Most everything in the guidance document at this point should be considered draft and subject to change/improvement, including that part.

💬 can templates be nested in sinopia? can we build a set of hybrid aggregates templates that re-use the kinds of aggregate templates?

I don't think I completely understand the idea but I can say a few things about Sinopia templates which might clarify:

• A Sinopia resource template includes property templates, values are entered in property templates as literals, IRIs, or IRIs using lookups or dropdown menus. All property-value pairs entered in a resource template describe a single resource* with a given rdfs:Class.
• *Sinopia does offer a 'nested template' option, where a secondary template is nested within a property template. In this case, the property values entered in the nested template describe a second resource. But that resource is identified by a blank node, not an IRI (a feature of the software).
• Properties cannot be added to resource templates 'on the fly'. Any property which needs to be available for use in a template must be added to the template prior to opening it for editing.

[GordonDunsire]

The presence of a collective title that is distinct from any of the 'collected' titles is, in many contexts, a strong indication that an aggregating work should be minted. However, there is little data utility in doing this if the only statement for the aggregating work is:

• aggregatingWork has preferred title of work 'Collective title of aggregate manifestation' .

because it is likely that it is already stated:

• aggregateManifestation has title proper 'Collective title of aggregate manifestation' .

[Someone could develop a set of inference rules to generate aggregatingWork from aggregateManifestation on this basis.]

This does not apply to a collective title that is the same as a collected title, typically in the case of an augmentation aggregate. Note that the RDA says 'collective title' is 'usually different from the titles of the expressions and works that are embodied by an aggregate', but does not further elaborate on what 'usually' implies. ISBD for Manifestation has attempted to clarify this by saying 'collective title' is 'the overall title of a manifestation that is an aggregate'. That is, ISBDM prioritizes the title function within the manifestation (and ensures that the function is the principle of representation or how the manifestation represents itself). This separates out the title function within the 'resource'; that is, deriving a title of expression and work that can be used in the construction of access points of expression and work. The resulting access points for related works and expressions (both aggregating and aggregated) can look confusing at first, but we think they are more effective in a wider information retrieval context: see Emma (1971; Penguin Books; volume). In this example, there are work/expression aaps under 'Blythe' for 'Introduction' and 'Emma' which reflect the cultural significance of this particular aggregate.

However, I haven't checked RDA policy statements to see how this is treated in practice.

I think 'rule of 3' approaches should be replaced by cataloguer's judgement, taking into account the wider context of an aggregate and entity-based cataloguing, including the means of metadata production. For example, if I am cataloguing '20 poems of Robert Burns' I would expect, if not demand, the existence of descriptions of works and representative expressions for every Burns poem ever produced or published. I would select and link (click) the descriptions of the 20 expressions embodied in the aggregate and mint and link the aggregating work. btw, I used to work with the Scottish Poetry Library, and this is exactly what they did (albeit in a pre-FRBR 'analytical cataloguing' framework). It was a regular go-to source for the press and would-be authors seeking to quote the full text of 'To a mouse': the Library would give the enquirer a list of 30 or so anthologies where it could be found (this is before Project Gutenberg when all of the poems were published online).

I'm interested in the 'nested' profile idea because of the presentations I gave at ALA Midwinter 2019:

• Application profiles and cataloging a manifestation
• A deeper dive into application profiles and policy statements

Some of this has been built-in to RIMMF. The 'nesting' is not so much hierarchical as additive, and the main utility is staged augmentation of the description set for an entity in workflows, and the management of description granularity.

I think this is of interest to the transform as well as current metadata production. In some sense the transforms for subfields within a tag are mini application profiles (for the legacy application) - they select the properties to map to, and what string encoding scheme to apply, if any. There are sets of such mini profiles that have common components that form a broader profile, and so on. The technology might be different, but the conceptualization is the same (I think :-)

[briesenberg07]

Another aggregates question:

The question of making 'has subject' statements on an aggregating work came up recently. It makes sense to me that subjects for an aggregating work may be assigned in (what I see as) a somewhat intuitive manner. My line of thinking runs something like:

• It's a collection of essays about dolphins, the subject term 'dolphins' should be assigned
• In lieu of or in addition to assigning this term to an aggregated work or works which are described, the value may be assigned to the aggregating work
• This makes sense (to me) because a plan to aggregate works about dolphins has subject dolphins

Essentially my understanding is that if it's a subject of the aggregate as a whole, the 'has subject' statement can be made on the aggregating work. But, is this a correct understanding?

[GordonDunsire]

@briesenberg07: your analysis is correct. It is consistent with the RDA guidance on Representative expressions of an aggregating work - The values of ... elements for an aggregating work are derived from one or more expressions that are aggregated. Subject is already a Work element, so no need for a representative expression element, but the principle is the same: the subject of an aggregating work is the common subject of the works that are aggregated. As in other cases, cumulation of subjects changes the overall subject: a work on child education may be independently aggregated by a work on children and a work on education. The same work may also be aggregated by a work on manifestations published by the same publisher, a work on works created by the same author, etc. where the aggregating plan is not based on subject.

The same analysis applies to collection works: the focus of a collection may be subject-based, or it may be based on the characteristics of collected items, such as ownership, their manifestations, such as publisher, their expressions, such as language, and their works, such as category.

In both cases, the subject of a gathering of expressions or items may be independent of the subject(s) of the gathered works.

A work with the subject dolphins may be aggregated by a work with the subject:

• dolphins (that is, works about dolphins)
• works written by the same author
• expressions in French
• manifestations published by the same agent

I think there are LCSH and Dewey Decimal classifications for each of these examples? They can certainly be represented in Universal Decimal, colon, etc.

In addition, a work with the subject dolphins may be collected by a work with the subject:

• items (previously) owned by the same agent

[This is a great rabbit-hole, but it's deep and if you go down far enough, you arrive back at the surface ...]

[AdamSchiff]

The overall aggregating work may be about dolphins as a group, but the individual aggregated works could be about specific species of dolphins. This would be quite common for a collection of scientific papers. Adam Adam L. Schiff Principal Cataloger University of Washington Libraries (206) 543-8409 ***@***.***

…

________________________________ From: Benjamin Riesenberg ***@***.***> Sent: Tuesday, November 21, 2023 6:28 PM To: uwlib-cams/sinopia_maps ***@***.***> Cc: Adam L Schiff ***@***.***>; Mention ***@***.***> Subject: Re: [uwlib-cams/sinopia_maps] Cataloging print monographs which are aggregates (Discussion #180) Another aggregates question: The question of making 'has subject' statements on an aggregating work came up recently. It makes sense to me that subjects for an aggregating work may be assigned in (what I see as) a somewhat intuitive manner. My line of thinking runs something like: * It's a collection of essays about dolphins, the subject term 'dolphins' should be assigned * In lieu of or in addition to assigning this term to an aggregated work or works which are described, the value may be assigned to the aggregating work * This makes sense (to me) because a plan to aggregate works about dolphins has subject dolphins Essentially my understanding is that if it's a subject of the aggregate as a whole, the 'has subject' statement can be made on the aggregating work. But, is this a correct understanding? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/uwlib-cams/sinopia_maps/discussions/180*discussioncomment-7637226__;Iw!!K-Hz7m0Vt54!l312qjwN3nMs-daUo6N0SpEOM3v2_VvIUZd2tWyFfDtnGjFdKgOpSIxFH7BSeq0eBBepcTa3o5nKBuIeAHHhGps$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ADFBVB4VTRIMG3QFCJELY4TYFVPMRAVCNFSM6AAAAAA7ABRYCKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMMZXGIZDM__;!!K-Hz7m0Vt54!l312qjwN3nMs-daUo6N0SpEOM3v2_VvIUZd2tWyFfDtnGjFdKgOpSIxFH7BSeq0eBBepcTa3o5nKBuIecXBNU10$>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tmqdeborah]

If the overall aggregating work is about dolphins as a group, but the individual aggregated works are about specific species of dolphins, then I would suggest that you:

• assign the subject "dolphins" to the aggregating work and also assign the headings for specific species of dolphins to that work, especially if the aggregated works are not described separately or if only some of them are described
• assign the headings for the specific species of dolphins to the appropriate individual aggregated works if they are described