RDA Models for Authority Data

6JSC/TechnicalWG/5
3 August 2015

RDA Models for Authority Data

 

 

Submitted by Gordon Dunsire, Chair, JSC Technical Working Group

Print Friendly, PDF & Email

Tagged , , , . Bookmark the permalink.

21 Responses to RDA Models for Authority Data

  1. John Myers says:

    I was quite pleased that by-and-large, I understood the paper. The WG did solid and balanced work in exploring theory, explaining different schema, and providing illustrative examples. For the most part, the recommendations feel sound. Further comments below

  2. John Myers says:

    Recommendation 1: My sense is that the WG’s approach is a better transition from our historical treatment of data structures to the future “brave new world.” As the paper explains though, it is at odds with the approach taken by BibFrame.

    • Kathy Glennan says:

      I agree with this recommendation, especially since RDA needs to work in more than one “environment”. I also like the concept of avoiding the proliferation of entities.

  3. John Myers says:

    Recommendation 2: this seems appropriate, given the direction in which the FRBR-LRM is moving.

  4. John Myers says:

    Recommendation 3a & b: Again, these seem appropriate, although this represented one of the more challenging sections for me to understand.

    • Kathy Glennan says:

      3a) I have no objection to further investigation, but I am concerned that this hasn’t been part of RDA from the beginning (presumably for good reasons).

      3b) I don’t think I object to this, but it does raise the question about the long-term vision for how the RDA Registry and the RDA instructions are supposed to be related.

  5. John Myers says:

    Recommendation 4a & b: It is hard to argue against further investigation. I also note that I have previously advocated for a “entity agnostic” environment, where the Group 1 & Group 2 (as well as the soon to be deprecated Group 3) entities would exist on a more-or-less level playing field. I have a prominent “Yes, yes, yes!” notation beside the penultimate paragraph of page 8 regarding the paper’s assessment that, “This blurs the distinctions between the ‘primary’ RDA entities … and the ‘secondary’ associated entities …”

    • Kathy Glennan says:

      4a) Agree.

      4b) ALA put forward some Appendix K relationship designators as part of 6JSC/ALA/43 that addresses some of this (see proposed section K.3.4, Relationship Designators to Relate Different Names of a Person)

  6. John Myers says:

    Recommendation 5: This is the most problematic of the recommendations. I understand the motivation, and it is a reasonable outcome in a linked data environment. But it still feels a little bit of “A bridge too far” at this point. At what point does RDA become so generalized and the cataloging community sufficiently dependent on application profiles that it fades into the background? We have a long history of “the rules are the rules,” where this approach is more along the lines of MARC development where a community articulates a need to park a specific piece of data, the parking place is incorporated into the structure, but the actual content standard is left to particular communities to develop.

    • Kathy Glennan says:

      The application profile solution is all fine and good — as long as it’s in place before the instructions are removed from “RDA proper” and everyone who needs to use it knows where to find it and how to apply it.

      I do share John’s concern above that many, many things could move to an application profile level. I think we want to avoid the long term result of having RDA as a bare, relatively meaningless outline, with all the “real” instructions living in various application profiles.

  7. John Myers says:

    Recommendation 6: This seems entirely in sync with the internationalization goal of RDA.

  8. Matthew Haugen says:

    So far as I understand it, I support the recommendations of this proposal.

  9. Steve Kelley says:

    I probably understand it even less. I think I support the recommendations of this proposal, but I’m not sure.

  10. Kathy Glennan says:

    Note that in contrast to the Aggregates WG paper, this one explicitly states an assumption that RDA will comply to FRBR-LRM.

  11. Robert Bratton says:

    Let me ask a stupid question.

    “Recommendation 5 : The RDA instructions for constructing AAPs should be replaced with general guidelines for assigning Nomen s for applications supporting the user task explore, as part of the development of guidelines and instructions for creating Nomen data.”

    Who will create and govern these application profiles?

    I share John Myers’ concern of straying too far from “the rules are the rules.”

    • kelleym says:

      I agree with the comments that there are dangers in moving too much to application profiles. Who is going to create them? Over-reliance on application profiles may lead to vacuums in some areas. I have seen OLAC struggle to find the people power to meet the demand for more guidance on cataloging media. There are more resources to maintain instructions and guidelines at the RDA level than in most small communities. In addition, instructions that are developed centrally only have to be done once for everybody. That said, the flexibility of application profiles is appealing. What is the right balance between the big tent approach that RDA is trying to take and the need for some actual substance in the rules rather than just a container for a lot options.

  12. Diane Napert says:

    This paper seems reasonable though I admit to having difficulties with some sections. Perhaps more examples would have helped. Recommendation #5 seems like a big move, therefore Kathy’s point is important, everyone needs to know the “where” and “how” (presumably before it occurred)
    I find myself wondering if these changes would make training more complicated and whether that is in contrast to the original intention of simplifying cataloging (in this case, authority)
    The terms “nomen” and “appellation” do not lend themselves to the spirit of using everyday language, even though in this context they are not intended for the general public

  13. kelleym says:

    This make sense to me and I think there’s the potential to do a lot of interesting things. I like the idea of adding things like family name and given name as sub-elements of name of person, which will give us more manipulable data. The issue of changing nomen values and “preferred” forms seems knotty, but for some functions it’s hard to see how you can get around having to pick a single “preferred” form for display. It’s easy to see how a computer could pick out disambiguating supplementing information for an AAP on the fly. It’s a little harder with the actual name or title string. One possibility with the generalization of nomens for our traditional approach is that if all the strings for the way the name appears on different manifestations were known, a computer could calculate both preponderance of usage and recent trends. It could also possibly take into account the language of the name and do things like offer alternate versions with the original name and with the name as it commonly occurs in English in a context sensitive way. As part of the OLAC Movie & Video Credit Annotation Experiment (help us out at http://olac-annotator.org/), I am doing a lot of comparing of transcribed names and AAPs. It’s easy to see that having this data could do a lot for typo correction, as well as automating the addition of cross-references.

Leave a Reply
https://alcts.ala.org/ccdablog/?p=2323
alcts.ala.org
crawl=CC-MAIN-2019-18
76793
application/http; msgtype=response
sha1:5HN6VIHMSQZRN7ASIJMK2AFXCZWEFTXO
<urn:uuid:15345945-5c37-4e97-9cbb-5079a3232ab7>
2019-04-24T20:06:32Z
216.80.72.149
text/html
sha1:QJIF7E34W3CM3P7JWYF7DRFNMWYETLDL
<urn:uuid:47dc0b37-adb9-4f08-9799-ee043c2887d7>
https://alcts.ala.org/ccdablog/?p=2323
response
<urn:uuid:13beff63-efe6-4e14-8735-747d299f7950>
isPartOf: CC-MAIN-2019-18
publisher: Common Crawl
description: Wide crawl of the web for April 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-63-222-147.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/