RDA Accommodation of Relationship Data

3 August 2015

RDA Accommodation of Relationship Data



Submitted by Gordon Dunsire, Chair, JSC Technical Working Group

Print Friendly, PDF & Email

Tagged , , . Bookmark the permalink.

12 Responses to RDA Accommodation of Relationship Data

  1. Kathy Glennan says:

    As often happens with papers from the Technical Working Group, I need some help making sense of all of this. I look forward to your comments!

  2. Kathy Glennan says:

    Recommendation 1:

    I guess this analysis means that RDA doesn’t exactly support the NACO practice of citing URLs in authority records, if the cataloger decides to do so. Would making the relationship explicit between the identifier for the manifestation and the URL in RDA add any complexity in this context?

  3. Kathy Glennan says:

    Recommendation 2:

    I note that there are a number of definitions for “identifier” in the RDA Glossary (via the Toolkit). The two that do not mention surrogates now are those that do not get supporting authority records (manifestations and items).

    The “is described in (manifestation)” example here is a bit more expansive than I would have previously thought. Unfortunately RDA doesn’t really define “describes” in the context of the Appendix M relationship designators.

    I’m not sure I agree with the final sentence before “recommendation 2” on p. 6:
    “Data from the surrogate is used to construct an AAP for the related entity.”
    Data for AAPs can come from a number of different sources (expression records, reference sources, etc.), can’t they?

    • Robert L. Maxwell says:

      I agree, the language in the statement makes it sound like the data only come from the surrogate, but certainly evidence is gathered from many sources to create the AAP.

  4. Kathy Glennan says:

    Recommendation 3:

    I don’t completely agree with the analysis. For example, MARC 505 is tricky to map to RDA. Sometimes it is all about related manifestations, but what about a record that lists the three separate titles in Lord of the Rings in a 505, or one that lists the individual movements in the Peer Gynt suite? These are work (or possibly expression) contents.

    I think the recommendation is too constricting. It may be principled, but it would mean that certain data elements would have to be left out of a structured note if that information was not present in the manifestation in hand. For example, what if I want to provide imprint information about the original print resource when describing a microform reproduction — but my reproduction only includes the dates of the original? Presumably I could find out this information from external sources….

    • Robert L. Maxwell says:

      The recommendation also seems to be locked into the bibliographic record mindset, that is, what we do in a bibliographic record. I’d like to be able to make a structured note of the works within an aggregate work in a work authority record (or future work entity record), for example, which seems a legitimate need. Ditto for expression entity/authority records.

  5. Kathy Glennan says:

    Recommendation 4:

    Conceptually, I have viewed AAPs as a form of structured description, so on one level, I have no problem with this recommendation.

    However, what’s the fallout from making such a change? What’s the impact on catalogers if we conflate these instructions?

  6. Kathy Glennan says:

    Recommendation 5:

    Makes sense to me.

  7. Tina Shrader says:

    We at NLM agree that there’s no real difference between referring to a resource with a structured description vs. referring to it with an authorized access point. Both are structured strings, and having the instructions conflated makes sense to us.

    We also think that RDA should contain specific instructions for using URIs (as opposed to URLs) to identify related resources, and that the preference in using URIs should be for actionable URIs that identify resources themselves rather than surrogates (e.g. bibliographic or authority records).

    Finally, we agree that even text-based identifiers for surrogates (e.g. bibliographic or authority records) should not be used as identifiers for the resources themselves.

  8. Elizabeth O'Keefe says:

    The paper did a very good job of clarifying the differences between the different RDA approaches to relationships.

    I share the reservations of other commenters about Recommendation 3. If I understand it clearly, this would limit the source of data for a structured description of a related resource to the resource being described. The resource being described often contains insufficient information to identify the related entity; this is true for self-describing resources and doubly true for non-self-describing resources. In many cases, too, the resource being described does not even indicate the existence of a related entity; this might be because it didn’t exist at the time the resource was created (e.g. a parody or sequel, a print based on a painting,) or because whoever was responsible for the resource in hand wasn’t aware that a related resource existed. Identifying relationships to other resources not explicitly described in the entity in hand is part of the added value that catalogers bring to description, and should not be constrained by what appears in the entity in hand.

  9. Kathy Glennan says:

    Posting on behalf of Mark Scharff, Washington University in St. Louis:

    This is dense reading, and I am not sure I understand it (though I suspect that the lack of response might be from other folks sharing my problem). I’m particularly curious about the proposed conflation of structured descriptions and AAPs. I can understand in a general way how both share the same data elements; but an AAP for a musical work can involve elements that are not going to be part of a structured description of a resource, because they are not mentioned in the manifestation on which that structured description would be based. I’m also a bit nervous about the use of “or” in the new four-fold path #2, in that it can be read to mandate one or the other.

  10. Dominique Bourassa says:

    On behalf of John Attig:

    Recommendation 1: I see this as an important technical issue. Karen Coyle, on the BIBFRAME list, has been lamenting that librarians still don’t seem to understand what identifiers are. She believes that the “identifier” elements in RDA are not really identifiers, but are simply special sorts of text strings. These strings (e.g., ISBNs) can be the basis for an identifier, but you can’t transcribe an identifier — only a text string — and that is what RDA seems to be most interested in. I think the TechWG document is suggesting the same point, that we need to clarify the distinction between true identifiers that are used to represent relationships (and other things) and textual identifiers. This needs to be done, and I believe that ALA should support the recommendation.

    Recommendation 2: I seem to recall that the concept of a surrogate (i.e., a collection of metadata elements) was included in the definitions so that identifiers for authority records would qualify as identifiers for the entity. I think that the TechWG is correct that these things need to be kept separate. One example of this ambiguity that keeps coming up is whether an LCCN is an identifier for a manifestation (or expression or work) or for a particular collection of metadata representing the entity. While it is sometimes practical to say that it should be both, you can’t build a rigorous data structure without making a clear distinction. Again, I think that ALA should support the recommendation.

    As to the statement that “Data from the surrogate is used to construct the AAP”, I think that the document tends to narrow the scope of “surrogate” too much. In the case of the AAP, I would interpret the “surrogate” as a collection of metadata elements appropriate to the entity, but not limited to a manifestation (the entity in question may in fact be an expression or a work). If we define the collection of metadata rather broadly, I think that the statement is basically true.

    Recommendation 3: This recommendation represents the TechWG’s encounter with the same issues that the ALA Task Force on Describing Relationships has been struggling with and which are reported in 6JSC/ALA/41. Recommendation 3 is somewhat poorly worded, because the first part implies that all structured descriptions are at the manifestation level; however, by the end of the recommendation it is clear that what is being argued is the same principle stated by the ALA TF: that a structured description of a related entity should consist of elements describing that entity (i.e., a structured description of a related manifestation should be made up of elements describing the manifestation, etc.). The TechWG seems to leave open the door for structured descriptions of works — which is consistent with the desire of the ALA TF to continue to look at work-level contents notes. I think that ALA should note that Recommendation 3 is related to ALA/41 and is generally consistent with ALA/41 — or at least are both pointing in the same direction.

    Recommendation 4: Conflating structured descriptions and authorized access points simply means that these two categories share a common definition; both are constructed from RDA elements using a specific set of instructions. This does NOT mean that these two types of data constructs would be formulated using the SAME set of instructions: there could still be separate instructions for structured descriptions and for AAPs. This recommendation is trying to simplify the model — not the instructions.

    Recommendation 5 did not generate any comments and seems to be unobjectionable.

    In general, I think that ALA could support these recommendations. On the other hand, the devil (as always) is in the details of how the recommendations are implemented. And it is not clear how the recommendation are intended to be implemented; in most cases, the only thing that is clear is that the implementation is NOT a technical issue, but rather an issue involving the content of the instructions — which means that the TechWG has to leave it for the JSC to determine.

    I hope that these comments are somewhat helpful. I’ll let you decide whether it is worthwhile to add them to the blog post.


Leave a Reply