Representative expressions of an aggregating work

RSC Document
March 2020

Representative expressions of an aggregating work
Submitted by Gordon Dunsire, RSC Technical Team Liaison Officer

Paper for discussion at April 2020 Asynchronous RSC Meeting

Print Friendly, PDF & Email

Tagged . Bookmark the permalink.

4 Responses to Representative expressions of an aggregating work

  1. kelleym says:

    I agree that users are interested in these attributes. My one concern is with the potential for misleading results in discovery systems for situations where multiple elements have multiple values. For a simple example, if one of the aggregated works has a representative expression language of French and date of 19th century and the other has English and 18th century, a user looking for French and 18th century would be unhappy with the result. The option to “Record a value of an Expression: language of expression that is common to all of the expressions that are aggregated.” would seem to be one way to address that problem, although there are many situations where you could record more than one value for one or more of these elements without causing problems. You could also envision a system that could do some sort of bundling of characteristics that go together for use when it isn’t practical to describe the aggregated works separately.

  2. Ryan Tamares says:

    Comments from AALL – Summary of discussion and comments:

    The stilted language of LRM along with the language of the exposition in this paper made for tough sledding. The concepts in the paper could be explained much more clearly, especially with the use of examples. Such examples would help clarify the application of representative expression of aggregating works. Based on AALL discussion of the document, even seasoned law catalogers would have trouble using the document as it stands to determine how legal publications such as law reporters and law digests would fall under these categories.

    That said, there are some in favor of the two recommendations and “sub-recommendations” in the paper to add specific optional instructions for representative expression elements for aggregating works and to Update relevant Toolkit Guidance content to reflect the use of representative expressions for aggregating works.

  3. Timothy Ryan Mendenhall says:

    In the appendix, page 15, covering the clean version of Appendix 6 on Aggregates, “title page” is given as an example of the content of an aggregating expression. On page 2 of this paper, it is stated “No attribute elements for an expression are applicable to an aggregating expression because an aggregating expression has no intrinsic characteristics that are worth recording.” If a title page contains a title in a specific language/script, as well as a date and a place of publication, would these not be intrinsic characteristics worth recording for the expression?

  4. Keith Knop says:

    Comments from MLA:

    In general we agree that being able to transfer representative expression elements from aggregated works to an aggregating work is helpful to users. There are a couple of situations where a blanket application of the template given in appendix 1 to all of the elements listed there results in situations that could benefit from additional discussion and guidance.

    One issue raised was with language of representative expression. In a case where an aggregating work aggregates works expressed in multiple languages, its not clear where recording only one of several languages would be desirable, yet the phrasing of the first option seemed to some of us to encourage that interpretation.

    There was more extensive discussion about date of representative expression. The date question differs from language in that aggregating works and expressions cannot have languages, so it is generally clear where the language information comes from.

    Aggregating works can, however, have dates. If multiple work-level date elements are available to record, that seems to call for careful attention to clarity. If our goal is to be helpful to users (and catalogers) we need to be very sensitive to the situations where recording the date of work of the aggregating work is more helpful than transferring a date of representative expression of one or more aggregated works.

    To quote one commenter:

    “For example, one might, in 2020, aggregate the complete works of Webern as a sound recording, utilizing performances recorded in 1965, 1982, and 1997. However, it doesn’t make sense to me to use 1965, 1982, or 1997 as the date of representative expression for that aggregating work. It makes sense to me to use 2020, the date the expressions were aggregated[…]even though this date only applies to the aggregating expression and not to the aggregated expressions (as far as I can tell; the beta RDA Toolkit definition of ‘date of expression’ is vague, but does refer to ‘the date of the recording of an event’).

    We already do this to some degree, even though our current rules lack the finesse of the LRM aggregates model. We are used to recording access points such as:
    Haydn, Joseph, 1732-1809. Works. 1950
    Haydn, Joseph, 1732-1809. Works. 1958

    Those dates in the access points do not refer to the ‘date of notation for a score’ (another beta RDA definition of date of expression), they refer to the date all these scores of Haydn’s works were aggregated.”

    On the other hand, there are situations where the date of the aggregating work is not known or not significant compared to the dates of the aggregated expressions, in which case applying the shortcuts described here would be desirable.

Leave a Reply