Progress report on the use of RDA unconstrained element set for display labels

RSC/NARDAC/2020
March 13, 2020

Progress report on the use of RDA unconstrained element set for display labels
Submitted by Thomas Brenndorfer, NARDAC Representative to the RSC

Paper for discussion at April 2020 Asynchronous RSC Meeting

Print Friendly, PDF & Email

Tagged , , . Bookmark the permalink.

5 Responses to Progress report on the use of RDA unconstrained element set for display labels

  1. Nancy Mitchell Poehlmann says:

    Questions for discussion: Q2: I agree that the labels could reside in the element refernce box.
    Q3a: Yes, this is not a problem.
    Q3b: I prefer the list of “proposed” labels, more than the list of “other possible” labels.
    Q3c: Yes.
    Q3d: Again, I prefer the list of “proposed” labels, more than the list of “other possible” labels.
    Q4: Yes, I prefer the “proposed friendly labels.”
    Q5: Yes, the “possible friendly labels” are easier to understand.
    Q9: As in Q5, I prefer the simpler forms–the repetitive label is harder to understand, I believe.

  2. Robert L. Maxwell says:

    Questions for discussion:

    Q1: The unconstrained label looks strange in MARC *only* if it appears at the end of the string. MARC does not require this. The unconstrained label works perfectly well if it appears at the beginning of the string:

    100 1_ $i Has author: $a Austen, Jane, $d 1775-1817.

    We already do this in authority records. All it would take would be a policy change to use subfield $i at the beginning of fields in bibliographic records instead of subfield $e at the end.

    Q3. Agree, not a problem.

    Q8. This may be heresy, but you could use the word “name” instead of “nomen” in these labels. Or just leave “nomen” off. E.g., instead of “has language of nomen”, just “has language”

    Q9. Or simplest of all, instead of “arranger agent” just “arranger”.

  3. Timothy Ryan Mendenhall says:

    General comment: can a link to the spreadsheet mentioned several times throughout the text be added to the text?

    Discussion questions:
    Q1: I think there is definitely a case for non-verbalized labels in the current cataloging ecosystem, although I’m also in favor of keeping things simplified by avoiding a proliferation of possible labels. The non-verbalized labels would likely be needed, at least in an Anglophone context, for any display to end users / library patrons. It’s less clear to me that there is much of a need for the verbalized labels outside of the context of data modeling.
    Q3: I think that these suggestions which entail reusing labels are largely welcome, and will benefit end users if implemented. The one concern I would have is that label reuse may make some work on the backend a bit more challenging if systems are not set up to provide at-a-glance both the shorter friendly label and the longer unconstrained label. In particular, I’m thinking about developing templates and profiles in systems like Sinopia, although this may come into play in RIMMF as well–if it’s not easy to distinguish between the many elements sharing a common label, it could be difficult to create a template. Otherwise I find the proposed simplified labels are indeed far more friendly.
    Q7: I don’t know if it’s possible to anticipate the “friendliness” of the proposed labels if they are translated into other languages, and doubt that this is something fruitful to consider when creating English-language “friendly” labels. Each language community will likely have a different path to generating friendlier element labels.

  4. Ryan Tamares says:

    Comments from AALL:

    Comment 1. I applaud the efforts to come up with user friendly labels. Yes to all the questions, except 3d. We should make user friendly labels as clear and simple as possible, without loss of any necessary functionality.

    As a general question: Why are constrained text string labels needed at all, since they are all represented by URIs. Aren’t the constrained labels chiefly for machines not human beings?

    Comment 2. I thank the RSC for their intent to redo some labels in RDA because even though much of RDA’s structure is about the machine, humans still have to make choices with that structure as we build application profiles that interact increasingly with machines and we need to be able to understand what we’re doing as we create those interactions in the near-ish future. Folks have complained from the start about some labeling in RDA (3R) and this strikes me as a useful process [and hopefully iterative] to work on both fronts (that of the machine and that of the human) simultaneously to clean language up a bit.

  5. Keith Knop says:

    MLA comments:

    In general, yes to the discussion questions except as noted.

    1. In the long term, from a MARC perspective, I think the smarter thing to do would be to stop using $e and record this data in $i as it is in nearly all other contexts, e.g. 100 1_ $i Has author: $a Austen, Jane, $d 1775-1817. Assuming that does not happen, though, a nonverbalized version is almost mandatory to make any sense at all. There may be other standards where a simple(r) noun would also be contextually required.

    4. Yes. In the case of the “has … agent of” labels I’m not sure the inversion is necessary and “has contributor of choreography” seems to me a little more natural than “has choreography contributor,” but I think both are intelligible.

    7. Some of these simplifications, while idiomatic in English, are probably not grammatically plausible in all languages. For instance, “date of birth” and “birthdate” would both be “date de naissance” in French. This likely holds true for any language where nouns cannot directly be used adjectivally.

    9. Qualified yes. The word “agent” seems unnecessary in all the examples given. Using only “arranger” instead of “arranger of music” or “music arranger” seems to me to omit helpful information. Agreed on commissioner vs commissioning body and the remainder.

Leave a Reply