RDA-L

 View Only
last person joined: 15 days ago 

Open discussion of RDA, RDA Toolkit, and related topics
  • 1.  Musical roles in RDA

    Posted 14 days ago
    Dear collective wisdom,

    I have a question that we are struggling with in a project in the Netherlands. The project is called Podiumkunst.net (site only in Dutch) and aims to fashion a central website where visitors can search and find resources in the performing arts, from, e.g., manuscript or printed scores to audio recordings - and resources related to specific musical or theatrical performances. It has been decided to adopt RDA for modeling the metadata for this website.

    Now, one crucial part in modeling the metadata that is concerned with music and theatre is the role which a given person plays in a performance. Of course, in RDA, there are several roles available, such as composer (of a musical work), conductor (of an expression of that work), dancer (in the expression of a ballet work).

    For the performer in an expression of a work there are, it appears, significantly less terms available for roles. The terms 'singer' and 'instrumentalist' are available, but more specific terms like 'pianist', 'soprano', 'violinist' etc. are, it seems, not available.

    There is, in RDA, of course, the medium of performance of musical content. But, if we understand correctly, that is especially intented for the musical work and (notated) expression - but not for the (performed) expression. Put differently, an agent can be related to an expression of a work, but that agent cannot be further defined/specified by what role that agent has.

    In theatre, the situation is different again, as 'role' has a somewhat different meaning there: the agent/person 'John Williams' might, for example, perform the 'role' of Hamlet in the play.

    I hope this makes sense... would anyone have any insights on this topic?
    yours,

    --

    Thomas Op de Coul

    Mediabeheerder / muziekweb.nl


    M 06 - 424 76 535
    Kamer 3.02

    Werkdagen: di, wo, vr


    Media Parkboulevard 1, 1217 WE  Hilversum
    Postbus 1060, 1200 BB  Hilversum | beeldengeluid.nl 



  • 2.  RE: Musical roles in RDA

    Posted 14 days ago

    Hello Thomas,

    First of all, you are correct that RDA itself does not get more specific than "singer" or "instrumentalist" in terms of agent-to-expression relationships for musical performances. If you consider it vital to include the specific instrument/voice role of that performer, you have a few options, depending on exactly what your final product is intended to look like. The simplest option is to provide that information in a note. In the context of MARC cataloging, that level of specificity is usually given in a participants note, which might look something like this:

    Dynamis Ensemble (Birgit Noite, flute ; Rocco Parisi, clarinet/bass clarinet ; Paolo Casiraghi, clarinet ; Sergio Armaroli, percussion ; Candida Felici, piano ; Dominique Chiarappa-Zyrd, violin ; Teresa Felici, violoncello) ; Javier Torres Maldonado, conductor.

    However, if you want everything to be structured data, you could consider extending RDA with your own elements (and probably labels for those elements as well, since the RDA element names do not exactly trip off the tongue…) at whatever level of specificity you require. So for example, you could extend, say, the element Expression: instrumentalist person with narrower elements for violinists, guitarists, etc.:

    • instrumentalist person [RDA element]
      • guitarist person [custom element]
      • oboist person [custom element]
      • violinist person [custom element]
      • …
    • singer person [RDA element]
      • alto person [custom element]
      • soprano person [custom element]
      • …

    Medium of performance of musical content is not going to be much help in that context-though of course you might wish to include it in its own right-simply because, as an attribute element, it describes an expression without relating it to any other entity. However, I do want to note that there is nothing intrinsically limiting it to notated music expressions, and the Music Library Association Best Practices for RDA recommend routinely recording it for performed expressions as well.

    As for the different meanings of "role" in the context of theater, again the simplest option is to record that information in a note. Here practices vary, but it is fairly common for opera recordings to have a participants note that specifies the character instead of (or in addition to) a voice type, e.g. "Joyce DiDonato (Donna Elvira)."

    However, if you want that data to be structured and actionable, there is one particular hurdle to overcome, which is that fictional characters and non-human "agents" are both outside the scope of RDA. It is, however, possible to link an RDA entity to a non-RDA entity using the very generic "related entity of…" elements, which, again, you could extend with your own more specific narrower elements. So to use your example of John Williams playing the role of Hamlet in Hamlet, and assuming for the sake of simplicity you use Wikidata for theatrical characters, you might end up with a pair of relationships like this:

    <some specific performance of Hamlet> <has actor person> <John Williams>

    <John Williams> <has related entity of person> <Q2447542>



    ------------------------------
    Keith Knop
    Head, Music Cataloging
    University of Georgia
    ------------------------------



  • 3.  RE: Musical roles in RDA

    Posted 13 days ago

    Colleagues

    Some wider context to Keith's good advice may help.

    RDA provides the Community Resources section of RDA Toolkit to accommodate the requirements for finer element granularity in RDA communities. If a community develops a set of refinements to existing RDA elements, it can be published in the Toolkit and maintained with the same technical infrastructure.

    There are two significant issues that the music community must resolve in developing a set of refinements for the RDA element 'instrumentalist person' ***.

    I am assuming that if an instrument is used in a recorded performance, then there must be an instrumentalist who plays it.

    The first issue is the scale (pun intended :-) of any set of instruments/instrumentalists that is required for international use across all music genres. The IAML Medium of Performance Vocabulary has nearly 400 entries for instruments arranged in several hierarchies. I don't know how many entries for instruments there are in Library of Congress Medium of Performance Thesaurus for Music, but it is of a similar magnitude, and there are similar hierarchies. 400 instruments corresponds to 400 instrumental roles and 400 custom elements. Each custom element must have a distinct label (for example 'bagpipe player person' , a clear definition, and appropriate scope notes. For integration in RDA Toolkit, the custom element hierarchies (for example 'woodwind player person') must be semantically coherent.

    The second issue is that both the IAML and Library of Congress vocabularies are in widespread use, and should be consolidated into a single set of instrumental roles and a single hierarchical structure to support the international RDA music community. I did some work on this several years ago, on behalf of the Permanent UNIMARC Committee,  and identified matches, gaps, and mismatches if the vocabularies were to be merged. Unfortunately, this has not yet been followed up by IAML or MLA. A merged list is obviously useful for interoperability of the RDA 'medium of performance' element.

    I  do not think there are any RDA Toolkit technical barriers to resolving these issues.

    *** The primary function of RDA element labels is to provide a unique string that distinguishes one element from another and to indicate appropriate hierarchy structures between elements. This is not always 'user-friendly' for anglophone cataloguer agents, but RIMMF has shown that cataloguing interfaces can easily display different labels for different users. The more difficult process is to develop a set of unambiguous labels that are a one-to-one match with the RDA labels (that is, synonyms).

    The need for 'agent' and 'collective agent' instrumentalist elements in RDA was discussed by RSC and members of the music cataloguer community during the 3-R project. There are sufficient examples, such as two persons playing a single bagpipe (one on chanter, one on bag inflation :-), to support their inclusion.



    ------------------------------
    Gordon Dunsire
    ------------------------------



  • 4.  RE: Musical roles in RDA

    Posted 13 days ago
    Edited by Thomas Op De Coul 13 days ago
    Dear Keith and Gordon,
    Thank you so much for your generous comments on my question! That certainly is excellent food for thought for our project.
    As regards a vocabulary for Medium of Performance, I'm not sure if any of you are at the IAML in Salzburg, but one member of our projectgroup, Eric van Balkum, has given a presentation there on a multilingual thesaurus of vocabulary/thesaurus that was developed by him and myself, initially intended for Podiumkunst.net. Here, the scale is significantly larger, amounting to about 3.000 terms... Time will tell if that is too much of a good thing, but you can find it, provisionally, here:
    And it will in due time be included on the Dutch 'network of terms' which contains several vocabularies in LOD format:
    Thanks again!
    Thomas







'; if ($discussionImgModal.length == 0) { $("form").append(modalHtml); $discussionImgModal = $("#discussion-img-modal"); $discussionImgModal.find(".close").on('click', function () { $discussionImgModal.modal("hide"); }); } loadImage($discussionImgModal, source, title); } }); function loadImage($discussionImgModal, source, title) { var discussionImg = $discussionImgModal.find("#modalImg")[0]; discussionImg.onload = function () { $discussionImgModal.modal("show"); }; discussionImg.src = source; $discussionImgModal.find("#caption").html(title); } var replyInlineParam = HigherLogic.Util.getParameterByName('ReplyInline'); if (!HigherLogic.Util.stringIsNullOrWhiteSpace(replyInlineParam)) { var $replyInline = $('.reply-inline[data-message-key="' + replyInlineParam + '"]'); if ($replyInline.length > 0) { openEditor($replyInline); } } $('.reply-inline').on('click', function () { hl_common_ui_blockUI(); var $this = $(this); if ($('.inline-reply-snippet').length > 0) { hl_common_ui_unBlockUI(); $('.inline-reply-snippet').find('.modal.inline-confirm').modal('show'); $('.inline-reply-snippet').find('.modal.inline-confirm').data('reply-id', $this.prop('id')); } else { openEditor($this); } }); function openEditor($this) { $('.inline-reply-snippet').remove(); var postData = { MessageKey: $this.data('message-key'), currentUrl: window.location.href }; HigherLogic.Util.post( '/higherlogic/ui/mvc/eGroups/eGroups/GetReplyInline', JSON.stringify(postData), 'html' ).done(function (data) { var redirectUrl = $(data).data('redirect-url'); if (redirectUrl) { // gives return location for unauthenticated user redirect to login redirectUrl = hl_common_util_updateQueryStringParameter(redirectUrl, 'ReturnUrl', encodeURIComponent(window.location.href)); // gives return location for unsubscribed user redirect to subscribe window.location.href = hl_common_util_updateQueryStringParameter(redirectUrl, 'PostByLink', encodeURIComponent(window.location.href)); return; } $this.closest('li').append(data); var $div = $('#' + $(data).first('div').prop('id')); var bottomOfDiv = $div.offset().top + 500; $('html, body').animate({ scrollTop: bottomOfDiv - $(window).height() }, 1000); hl_common_ui_unBlockUI(); }); } });