RDA-L

 View Only
last person joined: 2 days ago 

Open discussion of RDA, RDA Toolkit, and related topics

Other title information and more in the official Toolkit

  • 1.  Other title information and more in the official Toolkit

    Posted Jan 25, 2021 01:19 PM
    So, let's give the new RDA-L a try...!

    With the now official Toolkit, I'm often not sure whether things which I find odd are intentional or simply mistakes.  At present, I'm exceedingly puzzled by the elements other title information and parallel other title information. In the original Toolkit, both were presented as subordinate to title. See 2.3.1.1 where it says „For the purpose of resource description, titles are categorized as follows: ...". The list which follows includes title proper, parallel title proper, other title information and parallel other title information.

    But in the official Toolkit, other title information and parallel title information are not shown as subelements of title of manifestation: Neither does the list at 73.88.03.17 include these elements, nor are they given as narrower elements at the bottom of the page for title of manifestation.  I cannot see any reason why other title information should no longer be seen as a kind of title information. So why is it now presented as something completely separate?

    And there is another odd thing: If we look at the page for other title information, the only related element is parallel other title information, which is given as a narrower element. Again, I don't understand: To my mind, these are disjunct classes. Either something is classified as other title information or it is classified as parallel other title information.

    I just checked: The same situation applies to title proper, where parallel title proper is given as a narrower element. But I'd argue that you cannot have title proper mean two different things at the same time. Either it is a broad element which covers both what we traditionally call title proper and parallel title proper, or it is on a narrower level and makes a clear distinction between title proper and parallel title proper. I think you cannot have it both ways.

    Of course we can imagine an application which simply doesn't want to make the distinction between title proper and parallel title proper.  That's fine, but in this case I think that one needs to go one level up and use the broader element title of manifestation (or maybe use manifestation title and responsibility statement).

    I feel my head starting to spin again. And I'm not really sure whether I was able to make myself clear... could you follow my train of thoughts? And if so, what do you think? Is there a very good reason for this which I was only to dumb to grasp?

    Heidrun


    ------------------------------
    --
    ---------------------
    Prof. Heidrun Wiesenmueller M.A.
    Stuttgart Media University
    Nobelstrasse 10, 70569 Stuttgart, Germany
    www.hdm-stuttgart.de/bi
    ------------------------------


  • 2.  RE: Other title information and more in the official Toolkit

    Posted Jan 25, 2021 02:08 PM
    Heidrun, I could follow your thoughts.  And I think it's a good question.  With a quick look, it does seem to me that all of those should be narrower elements of title of manifestation.  Perhaps further thought or someone else's perspective will give another answer, but it's a good question to raise.

    ------------------------------
    Stephen McDonald
    Digital Initiatives Librarian
    Tufts University
    ------------------------------



  • 3.  RE: Other title information and more in the official Toolkit

    Posted Jan 26, 2021 12:52 PM
    The manifestation statement element Manifestation: manifestation title and responsibility statement  appears to have replaced "title of manifestation" from the original toolkit as the broader categorical term. The option is given to record "title of manifestation," "title proper" and "other title information" as separate elements when they are included in a "manifestation title and responsibility statement." In this reading, they're considered distinct components rather than subelements of the manifestation statement.

    The element "title proper" does appear to be naming both a category of title and an instance of that category, i.e., "the title of manifestation that is selected for preference in a specific application or context."  "Parallel title proper" would be a subelement of the category but not of the instance. It might be clearer to have "preferred title proper" and "parallel title proper" as subelements of "title proper."

    Stephen

    --
    Stephen Hearn, Metadata Strategist
    Data Management & Access, University Libraries
    University of Minnesota
    170A Wilson Library (office)
    160 Wilson Library (mail)
    309 19th Avenue South
    Minneapolis, MN 55455
    Ph: 612-625-2328
    Fx: 612-625-3428
    ORCID:  0000-0002-3590-1242





  • 4.  RE: Other title information and more in the official Toolkit

    Posted Jan 26, 2021 02:07 PM
    Stephen,

    Thanks for the input, but I don't think this does the trick.

    The new manifestation statements are a separate, alternative way of recording certain information. Instead of using the granular elements which we're all used to, we can now transcribe the whole thing as an undifferentiated chunk. But this doesn't mean that title proper, other title information and statement of responsibility are components of the element manifestation title and responsibility statement.  Compare the presentation of the publication statement, which *is* made up of three components called "subelements "(36.03.73.72)  - this looks completely different.

    But it is important to note that the options which you quoted are placed under the heading "Precording". These options tell you that instead of using the chunky element manifestation title and responsibility statement you might choose to use the old-fashioned granular elements.

    Heidrun

    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 5.  RE: Other title information and more in the official Toolkit

    Posted Jan 26, 2021 02:16 PM
    Postscript:

    I agree that your suggestion of distinguishing between  "preferred title proper" and "parallel title proper" would solve one of the problems.

    Also, I find we need to be very careful with our wording: On the one hand, the official Toolkit uses the term "narrower element", e.g. place of manifestation has the narrower element place of publication. On the other hand, it talks about "subelements" (i.e. components), e.g. publication statement has the subelements  place of publication, name of publisher and date of publication. So in the one case it is a hierarchy and in the other it is a part-whole relationship.  This is really tricky.

    Heidrun





    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 6.  RE: Other title information and more in the official Toolkit

    Posted Jan 25, 2021 07:10 PM
    Dear Heidrun,

    I was able to follow your thoughts. Please stop making sense!

    Best,

    Jeff





  • 7.  RE: Other title information and more in the official Toolkit

    Posted Jan 26, 2021 02:13 PM
    Back in 2017 I wrote "After LRM has been incorporated (whatever that means) into RDA, a new version of RDA will be issued in April 2018. It will be fascinating to watch what theoretical and linguistic acrobatics result." I see the confusion Heidrun highlights as an example of these conceptual pretzel knots.

    To my thinking, proponents of the LRM/RDA construct seem to have slipped from library science into library religion. One believes or one does not. If one believes, no effort is spared in attempting to create a logically consistent, comprehensible narrative out of the LRM/RDA/Toolkit concoction. 

    Jeff

    ------------------------------
    Jeff Edmunds
    Digital Access Coordinator
    Penn State University Libraries
    ------------------------------



  • 8.  RE: Other title information and more in the official Toolkit

    Posted Jan 26, 2021 02:35 PM

    I just noted a third problem in this context, which I believe is due to the missing hierarchy between other title information and title of manifestation.  Compare the page for title proper with that for other title information. Can you spot the basic rule? I think it should correspond to this text in the original Toolkit: "Apply the basic instructions on recording titles at 2.3.1."

    When we look at title proper, this seems to be the relevant option (first option under "Recording an unstructured description", 26.39.92.47):  "Record a value of Manifestation: title of manifestation." (We need to disregard the odd phrasing, obviously.)

    But this option doesn't exist for other title information. There are options for a situation when there is more than one piece of other title information under "Recording", and there are some weird looking options under "Recording an unstructured description", which I cannot make head or tail of, but this one--the important one--seems to be missing.

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 9.  RE: Other title information and more in the official Toolkit

    Posted Jan 26, 2021 07:48 PM

    Unless I missed it elsewhere in this discussion, "Other title information" and its "Parallel" offspring have no range applied to them. These are attribute elements, not relationship elements pointing to Nomen. And have been since at least the May 2020 version of the text, according to my notes. I see other examples of attribute elements isolated in this manner, like "Sound characteristic."

     

    The question for me is, why aren't the strings recorded for "Other title information" and like elements treated as Nomens? The subtitle "choice and design in the Iliad" has as much 'label-ness' as the title proper "Homer's cosmic fabrication." Granted, subtitles aren't reused as "Title proper" elements often are-think access points for works/expressions.

     

    --

    Mark K. Ehlert                                 Alma: NA02
    Cataloging and Metadata Librarian          Primo VE: NA02

    O'Shaughnessy-Frey Library, University of St. Thomas

    <http://www.stthomas.edu/libraries/>

     

      "Experience is by industry achieved // And perfected by

    the swift course of time"--Shakespeare, "Two Gentlemen of

    Verona," Act I, Scene iii

     

     






  • 10.  RE: Other title information and more in the official Toolkit

    Posted Jan 27, 2021 09:15 AM
    All

    Why is the element called 'other title information' and not just 'other title'? The label of this long-established element indicates, in my opinion, an acknowledgement that not all instances of other title information are titles.

    The Definition and Scope section of Manifestation: other title information gives the definition as "A word, character, or group of words or characters that appears in conjunction with, and is subordinate to, a title proper of a manifestation."

    The definition does not imply that other title information is a title.

    The Prerecording section states:

    "A value of this element may include a phrase that appears on a manifestation as an addition to a Manifestation: title proper that is indicative of the character, contents, and other aspects of a manifestation, including its creation.

    A value usually appears in the same metadata Work: recording source as a value of title proper.

    A value of this element may include a value of a Manifestation: title of manifestation that is not a title proper."

    The Prerecording section points out that other title information may be the source of a title that is not selected as a title proper, but it may also include other information that is not usually considered to be a title or has not utility as a title.

    The Prerecording section includes two options for recording the information in another element. The options are not mutually exclusive.

    The first option supports the recording of some or all of 'other title information' as a Manifestation: title of manifestation or subtype (so, for example, Manifestation: variant title of manifestation may be used).

    The second option supports the recording of a transcription of 'other title information' within the broader element Manifestation: manifestation title and responsibility statement.

    Of course, the instructions in the Recording section support the recording of a transcription for the element itself.

    Overall, this covers the cases of extracting a title (treated as a nomen) to support access, or transcribing the whole of the 'other title information' as part of a broader element or in a co-extensive element.

    The changes between the original Toolkit and the new Toolkit arise from clarifying the distinction between 'recording' and 'transcribing', implementing the new LRM Nomen entity, and retaining continuity.

    The element label 'title proper' is retained for continuity and familiarity. It is the same as 'preferred title of manifestation', and there is a cross-reference in the Glossary: preferred title of manifestation See: title proper. The Manifestation: title proper Definition and Scope section gives the definition of title proper as "A nomen that is a title of manifestation that is selected for preference in a specific application or context."

    Manifestation: other title information and Manifestation: parallel other title information are not 'disjunct classes'. The RDA entities are examples of disjoint classes; an instance of one of the entities cannot be an instance of another entity. This is stated in the LRM.

    Some applications prefer to treat 'parallel' information without distinguishing it from 'proper' information. Other applications want to record only one 'proper' element, and to record 'parallel' elements for the same information presented in a different language. Within that, different applications may want to make a different choice as to which piece is 'proper': the first instance on the source of information? the instance that is in the preferred language of the agent? a throw of the dice?

    For that reason, all 'parallel' elements in RDA are subtypes of the 'proper' element. This allows metadata statements that use parallel elements to be 'dumbed-up' to statements that use the 'proper' element:

    M has parallel title proper "My title"
    implies:
    M has title proper "My title"
    M has title of manifestation "My title"
    M has appellation of manifestation "My title"

    All implied statements are valid if the original statement is valid. An application that makes one of these implied statements a 'real' statement can interoperate with another application at the level of the lowest common denominator element.

    An element subtype is not a sub-element; the distinction made in the original TK carries over to the new TK (Glossary):

    element subtype: A narrower category of an element.
    sub-element: An element that is a component of a larger element that aggregates data values from two or more elements.

    In short, 'other title information' is not always a 'title' and when it is, it can be recorded as a 'title'.

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



  • 11.  RE: Other title information and more in the official Toolkit

    Posted Jan 27, 2021 12:21 PM

    Gordon,

    I thank you for the courtesy of explaining. This saves me the time to report the oddities as mistakes via the feedback form.

    For the time being, I'll just reply to the first half of your mail (I haven't worked out the second part yet).

    Let me first point out that in German, other title information is traditionally called "Zusatz zum Sachtitel", i.e. "addition to title proper" and, as far as I know, has always been considered as some form of title information. The definition in the RAK rules read: "Explanations, extensions, or limitations of the topical designation which are mentioned in connection with a topical designation are called additions to title proper." (In German: "Als Zusatz zum Sachtitel werden Erläuterungen, Erweiterungen oder Einschränkungen der sachlichen Benennung bezeichnet, die im Zusammenhang mit einer sachlichen Benennung genannt sind."). To my mind, this is also implied by the ISBD where other title information is to be found in the title and statement of responsibility area.

    I've tried hard to think of cases where other title information is not a title. Checking the ISBD consolidated, I find that there are some cases which are recorded as other title information without being, strictly speaking, a title. One case in point is notated music, where the ISBD says: "Statements of key, numbering, date of composition, and medium of performance that appear with a distinctive title are treated as other title information." Perhaps one could also claim that certain other things (e.g., "a novel") do not have the character of a true title.

    But this is, to my mind, an entirely academic discussion and far removed from the realms of real cataloging. I would argue that cataloging tradition has decided to treat such things as title information-that's why we catalog it in this position of the ISBD. (By the way: Many other things are now seen as being up to the decision of the communities. Why shouldn't this be?)

    But for the sake of the argument, let's accept that there needs to be a distinction between two kinds of other title information. I'll try to follow your guidance.

    At least for the present, the German-speaking community won't use the new manifestation statements, so this option canot be applied. Then if I understand your explanation correctly, what we need to do for a large part of the cases (when the other title information has the character of a title) is to record it not as other title information, but in a different element, namely either as title of manifestation or as variant title of manifestation.

    In current bibliographic formats there is no data field for the broad title of manifestation. Instead, we have more granular fields for title proper, other title information, variant title etc. If my actual cataloging is supposed to conform to the official Toolkit, then I would have to record these bits of information in the data field for variant title. Using MARC as an example, I would use 246 instead of 245 $b.

    What would this mean, in practice? Firstly, catalogers would have to decide in each case whether the other title information they are looking at has the character of a title or not (which in many cases, certainly wouldn't be a clear-cut decision), and then record it either in 246 or 245. If it is recorded in 246, the presentation in the catalog would change and the other title information would no longer be presented where it belongs, namely in conjunction with the title proper. This would certainly go against the principle of representation, as we're supposed to represent things as they represent themselves.

    The alternative would be to record it as other title information, after all, even though it does have the character of a title. You pointed out the relevant option under "Recording": "Record an unstructured description by transcribing text and spoken word content from a manifestation (…)." We're probably all agreed that this is the only sensible thing to do, and the sentence "A value of this element may include a value of a Manifestation: title of manifestation that is not a title proper" seems to allow it. But still, it does not really fit the LRM model as titles should be treated as relationships to the Nomen entity.

    So in fact I could either try to be true to the model, which would mean additional work in distinguishing the two kinds of other title information and lead to unhelpful catalog displays. Or I could ignore the theory and lump them all together in the meagre and completely isolated other title information element.

    I say "meagre", because there is almost no guidance for catalogers here apart from the instruction to transcribe it. As it isn't treated as an element subtype of title of manifestation, there is no link to important basic rules for the treatment of titles (e.g., abridging long titles or the treatment of typographical errors), which of course are relevant for other title information as well.

    So, the official Toolkit and the theoretical model behind it turns out not support real-world cataloging, but rather to hinder it. 

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 12.  RE: Other title information and more in the official Toolkit

    Posted Jan 27, 2021 12:54 PM

    Heidrun says:

     

    Let me first point out that in German, other title information is traditionally called "Zusatz zum Sachtitel", i.e. "addition to title proper" and, as far as I know, has always been considered as some form of title information.

     

    Bob:

     

    This is also the case in the Anglo-American tradition. Other title information has always-until now-bee considered as some form of title information. This was a substantive change that should not have been slipped in as a part of the 3R project without some community discussion, however much it might make sense to some of the writers of the new RDA.

     

    Bob

     

    Robert L. Maxwell
    Ancient Languages and Special Collections Librarian
    6728 Harold B. Lee Library
    Brigham Young University
    Provo, UT 84602
    (801)422-5568

     






  • 13.  RE: Other title information and more in the official Toolkit

    Posted Jan 27, 2021 05:16 PM

    I'm having difficulty understanding what the problem is in this situation. Apart from the wording in the new RDA that is admittedly not easy to comprehend, the essence of the element still seems to be the same as it was in "old" RDA and even in AACR2. The options seem to be saying that we can record what we see on the resource as an instance of "other title information" AND/OR as an instance of "title of manifestation". This parallels our traditional treatment of the data in MARC: we record it in 245 $b AND/OR in 246 $a(n,p) as seems most appropriate for the specifics of the data and the needs of our catalogs.

     

    Kevin M. Randall

    Principal Serials Cataloger

    Northwestern University Libraries

    Northwestern University

    www.library.northwestern.edu

    kmr@northwestern.edu

    847.491.2939

     

    Proudly wearing the sensible shoes since 1978!

     






  • 14.  RE: Other title information and more in the official Toolkit

    Posted Jan 28, 2021 01:45 PM

    Kevin,

    You need to help me a bit with MARC, as I'm not completely fluent there (we don't use it for recording here, but only as an exchange format): In which situations would you record other title information in 246? If you're thinking of the cases when other title information is taken from another source of information, then this would be a different criterion which has nothing to do with the „title-ness".

    Apart from my general objections to the new treatment and the deviation from a long-standing cataloging tradition, I note that almost all instructions have gone from the element page. As I've already pointed out, due to the isolation of the element, there is no link to the basic rules for recording titles, although at least some of them certainly do apply to other title information as well. Other, more specialized rules, have also gone (e.g., this bit: „If an original title appears on the same source of information as a title proper, and it is in the same language as the title proper, record it as an other title information."). And if the main option only tells us to transcribe „text and spoken word content from a manifestation", I do not find this terribly helpful.

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 15.  RE: Other title information and more in the official Toolkit

    Posted Jan 31, 2021 05:30 AM

    I'm still not quite sure which cases of recording other title information in 246 Kevin was referring to -- maybe something like this?

    245 00 $aLibrary resources market place : $bLRMP.

    246 10 $aLRMP

    But in this case, I believe the 246 is only used for reasons of indexing (to produce what we used to call an added entry). The initialism is still treated as other title information and appears as such in the catalog display.

    But tet me come back to my argument that the information given to a cataloger who needs to record other title information in the official Toolkit is less than satisfactory.

    For example, imagine the cataloger comes across a typo in some bit of other title information which cannot considered to be a title. The options for „Titles that contain errors" (86.60.19.97) cannot be applied because we aren't talking about a title here, and (as I already pointed out) catalogers aren't referred to this section. (By the way, did you notice that it is now possible to transcribe a corrected version instead? This is at 08.19.72.80: „Record a value that corrects a typographical error.")

    We only get options to transcribe something (the wording is rather vague) according to the transcription guidelines we choose to use, e.g., at 75.93.75.28:

    „Record an unstructured description by transcribing text and spoken word content from a manifestation using Guidance: Transcription guidelines. Guidelines on normalized transcription."

    But for our cataloging problem, this doesn't help at all, because the guidelines on normalized transcription do not include an instruction for how to treat typos.

    Now people might say this isn't a problem after all, because everybody knows what do with other title information anyway, and they wouldn't need to look in the Toolkit for this. But what about somebody who wasn't lucky enough to learn RDA in the times of the original Toolkit? Also, I think that a proper cataloging code needs to be exhaustive and must also cover basic things.

    If the official Toolkit fails to do this, then it would be up to every community to invest a lot of time in adding all that's needed, but unfortunately isn't there. In my example, this would be a policy statement saying that, e.g., the version with the typo is to be transcribed, but a corrected version is to be recoded as... well, what exactly? You couldn't use the element note on title, as it's not about a title, so you'd have to use the broader note on manifestation.

    I'm not saying that adding all this is impossible (although I note that LC/PCC hasn't done so yet... I wonder if they've been aware of this problem at all). But I find it very hard to understand why all this additional work (for every community!) should be necessary, just to satisfy an extremely theoretical and academic distinction between different kinds of what we call other title information.

    Heidrun

    P.S.: I feel a bit like talking to myself as there aren't many replies. I hope that my mails in this matter have, nevertheless, been helpful for some of the people transcribed to this list, and that I'm not going on everybody's nerves.



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 16.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 07:16 AM

    Heidrun,

     

    Now that we have made the move to the new ALA platform, I receive (and read!) all your messages to the list. However, you explain everything so succinctly that I never have anything to add.

     

    I too am puzzled with regard to Other title information the new Toolkit. As far as I have always understood, "Other title information" is the part of the title that is not the title proper and not the statement of responsibility. That's why it's other title information and why we transcribe it in the title area in ISBD and the 245 in MARC. There is other stuff on title pages in and around the physical area of the title that we do not transcribe and would not consider part of the title like prices, dedications, bible verses, quotations, etc. (well, you might include a dedication in a note).

     

    Jessica Janecki






  • 17.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 02:06 PM
    Heidrun,

    Speaking for myself, your posts are definitely helpful, and I hope you continue.

    I've not followed the revamped Toolkit  closely, but was pretty familiar with the original.

    Your posts are definitely helping me get a better sense of the revamped Toolkit, and of its shortcomings (which seem to be legion).


    Nick Bennyhoff, MS (He/Him/His)

    Technical Services Manager

    St. Charles City-County Library

    77 Boone Hills Drive, St. Peters, MO 63376

    P: 636-441-2300 ext. 1567

    mylibrary.org

     

    Our Mission:

    The Library inspires, informs, and enhances connections across St. Charles County.








  • 18.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 02:39 PM
    On 1/31/2021 3:30 AM, Heidrun Wiesenm??ller via ALA Connect wrote:

    > P.S.: I feel a bit like talking to myself as there aren't many
    > replies. I hope that my mails in this matter have, nevertheless, been
    > helpful for some of the people transcribed to this list, and that I'm
    > not going on everybody's nerves.

    I have nothing to add, but am definitely reading the posts (or trying to
    - I confess what you and Gordon say often goes over my head!).

    --
    Lisa Hatt
    Cataloging | DeAnza College Library
    hattlisa@fhda.edu | 408-864-8459




  • 19.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 04:44 AM
    Speaking of things in another language or script, I was trying to find a definition of "dumbing-up", but other than an example from Gordon, I could only find this, in a 2013 paper by Alan Danskin: "Rich RDA metadata linked as sub-properties of less granular elements can be dumbed-up into simple Dublin Core for applications that don't want RDA ("Turtle Dreaming")."

    Frankly, it didn't help. Could anyone on the list explain for me, plesae?


    Regards,

    Alan


    Dr Alan MacLennan
    Lecturer
    School of Creative and Cultural Business
    Robert Gordon University
    Garthdee Rd, Aberdeen AB10 7QE
    T: 01224 263910 F: 01224 263553 E: a.maclennan@rgu.ac.uk

    The Robert Gordon University, a Scottish charity registered under charity number SCO 13781


    Robert Gordon University, a Scottish charity registered under charity number SC 013781.

    This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Robert Gordon University.

    Thank you.






  • 20.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 05:03 AM

    Alan,

    I assume that basically what is meant is that if you have, e.g., a title proper, a parallel title and a variant title, you could map each of them to the Dublin Core element „Title". So as a result, you'd have three separate instances of this broad element, with the differences between the more granular RDA elements lost ("dumbing-up").

    Gordon now argues (I think) that it would be a problem to have certain kinds of other title information on its own in a DC Title element.

    But of course, there is another, much more sensible way: If you have both a title proper and other title information, you could combine this and put them together in the DC Title element (e.g., separated by a full stop).

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 21.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 05:48 AM
    Or, perhaps, a colon? Thanks, Heidrun!


    Regards,

    Alan


    Dr Alan MacLennan
    Lecturer
    School of Creative and Cultural Business
    Robert Gordon University
    Garthdee Rd, Aberdeen AB10 7QE
    T: 01224 263910 F: 01224 263553 E: a.maclennan@rgu.ac.uk

    The Robert Gordon University, a Scottish charity registered under charity number SCO 13781


    Robert Gordon University, a Scottish charity registered under charity number SC 013781.

    This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Robert Gordon University.

    Thank you.






  • 22.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 07:25 AM
    All

    The term 'dumbing-up' is a neologism introduced around 10 years ago.

    It is based on the term 'dumb-down' used by the Dublin Core Metadata Initiative (DCMI), itself a specialization of "dumb down". Merriam-Webster defines "dumb down", as "to lower the level of difficulty and the intellectual content of something", and "to lower the general level of intelligence".

    DCMI used the term in the late 20th century to denote "a principled way of viewing a complex metadata description through the lens of a simpler representation". DCMI no longer uses the term, and it is, in a sense, a misnomer in the context of linked data.

    In linked data, a semantic "broader" hierarchical relationship between two properties (equivalent to fields/elements in a non-linked data environment) can be indicated using a basic 'sub-property of' relationship between the narrower and broader properties:

    PropertyA is sub-property of PropertyB
    ("variant title" is narrower than "title")

    Classes or entities can be linked using a sub-class relationship:

    Class1 is sub-class of Class2

    Controlled terms can be linked using a broader relationship:

    ConceptA has broader concept ConceptB

    In all cases, the hierarchy can stretch across multiple levels:

    PropertyA is sub-property of PropertyB is sub-property of PropertyC is sub-property of PropertyD

    I have referred to this elsewhere as a 'sub-property ladder' because it can be used to broaden a metadata statement that uses one of the properties into a statement that uses any of the broader properties. This action can be carried out automatically, without expensive human intervention. There is a simple 'reasoner' or 'inference' rule that states:

    If property A is used in a metadata statement, every metadata statement that uses a broader property can be inferred by replacing the property in the original statement with a broader property.

    Statement 1: X propertyA Y
    Statement 2: propertyA subPropertyOf propertyB
    Implies Statement 3: X propertyB Y

    I attempted :-) a non-technical explanation in an old blog post, now in the Internet Archive, Using the sub-property ladder.

    All of the RDA elements are arranged in one or two such sub-property ladders. This allows data that uses a fine-grained element to interoperate with data that uses a more coarse-grained element.

    Extending out beyond RDA is done with maps, such as the Map from RDA properties to IFLA LRM or the Map from RDA properties to Dublin Core Terms.

    For example, one branch of the RDA 'title' elements hierarchy, in conventional top/broad to bottom/narrow order, is:

    RDA "parallel title proper"
    broader RDA "title proper"
    broader RDA "title of manifestation"

    The DC map adds:

    broader DCT "title"

    The LRM map adds a separate branch:

    broader LRM "has appellation"

    As I pointed out earlier, this allows:

    <Manifestation has parallel title proper "My title">
    to autogenerate <DC resource has title "My title">
    or <LRM thing has title "My title">

    Note that there is not just one mono-hierarchy. The relationships form a net, not a tree. RDA itself is poly-hierarchical with respect to agent relationship elements because one hierarchy reflects the element hierarchy and a second hierarchy reflects the Agent class hierarchy.

    While the semantics of hierarchical elements refine 'down' the hierarchy, the data content is processed 'up', hence the term 'dumb-up' or 'dumbing-up'.

    While I think it is always useful for a cataloguer to understand what happens to the metadata statements they create, it is not necessary. All this technical stuff can be handled by appropriately-trained staff (sometimes known as system librarians and developers). However, the metadata has to be appropriate and be formulated according to standards that support such processing. So a "dumb" cataloguer (in this linked data sense) should do what the standard and local application profiles or policy statements tell them to do, and then let the machine do the heavy lifting.

    I assume the references to punctuation that concatenates other title information are about ISBD. According to the ISBD Consolidated edition, "other title information" is preceded by space-colon-space when it is combined with other elements. On the other hand, "parallel other title information" may be preceded by space-colon-space or by equals, depending on what the other elements are. Apologies if you are talking about some other 'string encoding scheme'.

    btw, the pre-3R German for "other title information" in the RDA Registry is 'Titelzusatz', which Google translates as 'title addition'.

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



  • 23.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 08:42 AM
    In simpler terms, I believe dumb-up means "losing some metadata detail" (dumb) "by classing information at a higher level of the heirarchy" (up).

    ------------------------------
    Stephen McDonald
    Digital Initiatives Librarian
    Tufts University
    ------------------------------



  • 24.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 08:56 AM
    Thanks, Stephen. I hope this is clarifying the matter for others, and I'm not just wasting everyone's time.


    Regards,

    Alan


    Dr Alan MacLennan
    Lecturer
    School of Creative and Cultural Business
    Robert Gordon University
    Garthdee Rd, Aberdeen AB10 7QE
    T: 01224 263910 F: 01224 263553 E: a.maclennan@rgu.ac.uk

    The Robert Gordon University, a Scottish charity registered under charity number SCO 13781


    Robert Gordon University, a Scottish charity registered under charity number SC 013781.

    This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Robert Gordon University.

    Thank you.






  • 25.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 09:03 AM
    Actually, your question and Gordon's answer did clarify things for me.  Gordon's explanation is useful for the specific information and application to the new RDA toolkit, but I found the need to, er, dumb it down to in my own head because I won't be able to recall all of that to explain to someone else.

    ------------------------------
    Stephen McDonald
    Digital Initiatives Librarian
    Tufts University
    ------------------------------



  • 26.  RE: Other title information and more in the official Toolkit

    Posted Feb 02, 2021 08:53 AM
    Wow. Thanks, Gordon. I think my lectures on RDA may have to omit some "heavy lifting", as well!

    Robert Gordon University, a Scottish charity registered under charity number SC 013781.

    This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Robert Gordon University.

    Thank you.






  • 27.  RE: Other title information and more in the official Toolkit

    Posted Feb 03, 2021 05:11 AM
    All

    I like Stephen's 'simpler terms' definition of 'dumb-up'. With some clarification of terminology (i.e. 'classing', 'higher'), I propose:

    dumbing-up: A process which creates or transforms metadata at a broader level of an element hierarchy and loses detail accommodated at a narrower level.

    To clarify, this is not a proposal to add the term to the RDA Glossary; it is not used in the RDA guidance or instructions. It is a useful shorthand for a technical process that is essential to developing applications between communities that use RDA and other element hierarchies at different levels of refinement and detail. It allows those communities to create metadata that is effective for local users and to share it for non-local users.

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



  • 28.  RE: Other title information and more in the official Toolkit

    Posted Jan 28, 2021 11:28 AM

    Gordon,

    I did some more thinking about the second part of your mail, where you explained about the relationship between the 'proper' and the parallel elements.

    I assume we're agreed that broader and narrower elements (element subtypes) are in a generic relationship, i.e. the relationship between a class and its types or kinds. The German DIN norm for thesauri defines this as a hierarchical relationship between two concepts, of which the subordinate concept has all the attributes of the superordinate concept plus at least one more (specifying) attribute.

    I grant that this works for most of the elements in question, e.g. the parallel designation of edition is defined as „A designation of edition in another language or script". So this has all the attributes of designation of edition plus the attribute „in another language or script". (I find this oddly put -- other than what? The definition would only make sense in connection with the 'proper' element. I'll come back to this later.)

    But the same is not true for title proper and parallel title proper, because title proper is defined as the preferred title of manifestation (the actual wording is different, I'm using the cross-reference from the Glossary here). This means, at least in our current practice, that there is a built-in cardinality of one: Just like the Highlander, there can only be one preferred title of manifestation in any system. So in my opinion, it is logically unsound to define the parallel title proper as „a title proper in another language or script". It cannot have all the attributes of title proper plus „in another language or script", because if it did, there would be two preferred titles at the same time, and this isn't allowed.

    If we imagine a system which doesn't want to distinguish between 'proper' and parallel elements, there wouldn't be much of a problem in the case of designation of edition, when this data were imported into MARC, because this is a repeatable element. E.g., for „Ungekürzte Ausgabe" and „Unabridged version", there would only be a slight mistake in coding, with the English version ending up in the wrong subfield.

    But if two titles were marked as „title proper", this wouldn't work as there is only one slot for title proper in MARC. So I think RDA definitely needs an additional hierarchical level here, e.g. a new „main title" element with the subtypes title proper and parallel title proper.

    I'd prefer to have a different solution for the other 'proper' and parallel elements, as well. Because due to the way they are presented now, the main thing seems to be lost: that they always appear as a couple, a triple, etc. (it doesn't make sense to talk about a parallel designation of edition if there is no 'proper' one), and that they are related in a special way. 

    I already pointed out that I find the phrasing „in another language or script" problematic. This kind of definition also does not capture the main thing of the parallelity: the two designations of edition must have the same meaning. If I had „Unabridged version" on the one hand, and „2., überarbeitete Auflage" [2nd, revised edition] on the other, I wouldn't treat the second one as a parallel designation of edition, although it certainly is „a designation of edition in another language or script".

    Admittedly, this isn't a very likely example to appear with real-life resources. But still, I think the definitions of the Toolkit fail to explain the character of this phenomenon. I also think the phenomenon would be much easier to understand if 'proper' and parallel elements were presented on the same hierarchical level, as sibling elements.

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 29.  RE: Other title information and more in the official Toolkit

    Posted Jan 28, 2021 09:53 PM

    Yesterday, I wrote:

    -----------

    I assume we're agreed that broader and narrower elements (element subtypes) are in a generic relationship, i.e. the relationship between a class and its types or kinds. The German DIN norm for thesauri defines this as a hierarchical relationship between two concepts, of which the subordinate concept has all the attributes of the superordinate concept plus at least one more (specifying) attribute.

    I grant that this works for most of the elements in question, e.g. the parallel designation of edition is defined as „A designation of edition in another language or script". So this has all the attributes of designation of edition plus the attribute „in another language or script". (I find this oddly put -- other than what? The definition would only make sense in connection with the 'proper' element. I'll come back to this later.)

    -------------

    But it has just occurred to me that this is, of course, nonsense.

    Rather, the situation is like this: A parallel designation of edition is in another language or script than the corresponding 'proper' designation of edition, i.e. we have a designation of edition in language A or script a and a parallel designation of edition in language B or script b.

    So, the parallel element doesn't have all the attributes of the proper element plus the feature "in another language". But rather, these two elements are on the same hierarchical level. They are siblings, because they have all other attributes in common and are only distinguished by language or script.

    If a broader/narrower relationship is felt to be necessary in the official Toolkit, then there would need to be a new element covering „designation of edition in any language or script". The children of this would be designation of edition and parallel designation of edition.

    Summing up: The presentation of parallel elements as narrower elements of the 'proper' ones isn't logically sound, and this is true for all of them (not only for title proper and parallel title proper). I think this really needs to be looked into and remedied.

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 30.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 05:12 AM
    All

    ISBD Consolidated edition may shed some light.

    1.3 Other title information
    Other title information consists of a word or phrase, or a group of characters, appearing in conjunction with and subordinate to the title proper, a parallel title or titles of individual works contained in the resource. Other title information can include variant titles appearing on the same source as the title proper.

    1.3.2
    A statement of other title information can include a statement of responsibility, the name of a publisher, or details relating to other descriptive elements (e.g. an edition statement) when such a statement is linguistically an integral part of the other title information.
    Any information appearing as other title information that includes one of the mandatory elements (e.g. a statement of responsibility) is included either as other title information or elsewhere in the description. Additional other title information is included if it is necessary for identification or otherwise considered important to users of the catalogue.

    ISBD examples include:

    "situation en 1972"
    "pastels, lavis, gouaches, esquisses"
    "comédie"
    'a novel based on the television series "The Avengers"'

    This is reflected in MARC 21 Bibliographic

    245 $b Remainder of title ... includes parallel titles, titles subsequent to the first (in items lacking a collective title), and other title information.

    MARC 21 examples:

    "La Oficina = Das Büro" (parallel)
    "facts or fiction" (other title information)
    "[proceedings]" (ISBD 1.3.3.2))
    "scale 1:20000" (other title information)
    "basic level" (subtitle not included in title proper)

    The ISBD namespace declares isbd:P1006 "has other title information" as a subproperty ("narrower") of isbd:P1012 "has title".

    The results of data consolidation by dumbing up the ISBD and MARC 21 examples are:

    M has title "situation en 1972"
    M has title "pastels, lavis, gouaches, esquisses"
    M has title "comédie"
    M has title 'a novel based on the television series "The Avengers"'
    M has title "La Oficina = Das Büro"
    M has title "facts or fiction"
    M has title "[proceedings]"
    M has title "scale 1:20000"
    M has title "basic level"

    This is noise for most applications using ISBD linked data.

    I was a member of the group that developed the ISBD namespace. The declaration was made to reflect traditional professional opinion. However, the noisy result of implementing that point of view was not intended by the ISBD Review Group.

    I am fortunate to be a member of the group that is developing a potential new version of ISBD that is an implementation of the IFLA LRM. In the first stage of the project, the group is focusing on the LRM Manifestation entity. This will be an opportunity to rectify the error. I think the main options are to remove the declaration from the new ISBD namespace, or to change the definition to explicitly state that 'other title information is a title'.

    RDA initially followed the ISBD approach. The 3R Project was an opportunity to review the semantics of the "other title information" element and resolve the problem. The factors that were considered include the treatment of a title as an appellation and an instance of the LRM Nomen entity, and the definition of "other title element" in ISBD, MARC 21, and RDA which avoids saying that it 'is a title'. The 3R Project treated this as a legacy element, retained for continuity and compatibility. I do not think it is really required, because the values that it typically takes are better recorded using the prerecording options:

    Record a Manifestation: manifestation title and responsibility statement to reflect the principle of representation and support the identify user task. The Toolkit points out that these data can be keyword-indexed but no further consistent data processing can be assured.

    Extract and record a value of Manifestation: title of manifestation (or subtype such as Manifestation: parallel title proper or Manifestation: variant title of manifestation. These data can be dumbed-up, etc. and used in alphabetic title browse indexes to support the find task.

    There is no problem here; there was, but it has been resolved. There is no link to instructions for recording a title because the element is not a title. There are no specific instructions for correcting typos because the value of the element is not intended for processing as a title, and the principle of representation can be applied.

    The RDA "parallel" elements are also legacy elements that are retained for continuity, etc. They are not really necessary.

    The "parallelness" may be recorded in a normalized transcription of a Manifestation: manifestation title and responsibility statement, which may be a clearer reflection of the context ("parallel to what"?).

    The "appellation-ness" may be recorded in a "variant" elements.

    The selection of one of the values as the 'preferred' or 'proper' value is recorded in a preferred/proper element. RDA allows different agencies to make different choices of preference.

    Agency 1 may record:

    M has name of publisher "Deutsche Nationalbibliothek"
    M has parallel name of publisher "German National Library"

    Agency 2 may record:

    M has name of publisher "German National Library"
    M has parallel name of publisher "Deutsche Nationalbibliothek"

    The "parallel" statements can be dumbed-up, according to RDA, to:

    M has name of publisher "German National Library"
    M has name of publisher "Deutsche Nationalbibliothek"

    There is no need for a broader element.

    The fact that 'there is only one slot for title proper in MARC' is not relevant to the discussion. RDA does not say, and has never said, that the cardinality of 'proper' elements is 1. I assume that MARC 21 is reflecting the authority control paradigm of selecting one value as 'preferred' and the rest as 'variant'. That is not the only way; bi-lingual agencies may want to refine the cardinality to 'within a specific language or script'.

    The original RDA definition of 'title proper' is "A chief name of a manifestation ...". The use of the indefinite article indicates an expectation from the get-go that different agencies will make different choices.

    The inclusion of "other language or script" in the definitions of parallel elements is an issue. RDA tries to avoid value dependencies: situations where the value recorded in one element is dependent on a value recorded in another element. Value dependecies interfere with semantic dependencies, such as hierarchical arrangement of the elements. This is one of the reasons why it is unlikely that new 'parallel' elements will be added to RDA. Retaining the existing elements means balancing continuity with clarity; the compromise that was applied in the new RDA Toolkit is to standardize parallel value dependencies as 'another language or script'. This can only be interpreted in the context of a local choice by the "agent who creates the metadata" of preferred language etc. Orientation and training will support continuing use of this traditional approach.

    So there is a qualifying refinement in "another language or script"; it refines the choice of language or script preferred by an agency, and the full meaning can only be applied within a specific application of RDA.

    The concept of 'parallel' as 'translation' is interesting. It may be useful to consider the relationship between 'parallel' elements and 'parallel aggregate', defined as "An aggregate that embodies expressions of a single work". The LRM models the title page, etc. of a manifestation as the expression of a work that is aggregated with the rest of the content in the manifestation. This is usually ignored and not recorded in most applications; the creator of the title, other title information, statement of responsibility, publication statement, etc. (i.e. a publisher) is of no interest. Instead, the content of the title page, etc. is treated as the expression of a metadata work and transcribed and transformed into descriptive metadata according to the principle of representation. A parallel title page, etc. can therefore be regarded as a translation (a different expression of the same metadata work).

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



  • 31.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 08:58 AM
    Thank you, Gordon.  That detailed explanation does clarify things in my own head.

    It occurs to me that there are quite a few elements that the 3R project considers legacy which could be better handled by other elements.  Might it be useful to create a list of these elements?  If an implementation were to avoid the legacy elements, it would greatly reduce the number of elements which needed policy and workflow statements.

    ------------------------------
    Stephen McDonald
    Digital Initiatives Librarian
    Tufts University
    ------------------------------



  • 32.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 10:24 AM
    All

    In response to Stephen's question:

    The 3R Project and preparatory development of RDA Toolkit identified a number of elements whose function and utility are covered by existing or new elements introduced for other reasons. These elements are compatible with RDA's implementation of the IFLA LRM, so there is no reason to deprecate them.

    They are retained as part of RSC's policy to minimize disruption to current cataloguing practices. However, there is an expectation that those practices will evolve as application of the new Toolkit spreads, and that some of these elements will be considered redundant enough to retire them (through deprecation). Accordingly, these elements have been internally categorized by RSC as "soft-deprecated". The intention is to review them in due course, when it seems appropriate to do so.

    I'm sure that some of this has been reported in RSC documents, but there is an explanatory reference in Notes on the April 29, 2020 RDA Toolkit Release:

    "These elements are retained for legacy purposes, but their use is not recommended and they will not be developed further."

    Each element that is soft-deprecated has an optional instruction to use another, preferred element. The option is preceded by a 'boilerplate' guidance paragraph:

    "The following option is recommended."

    This is 'global' Toolkit application guidance, and is only applied to soft-deprecated/legacy elements. The phrasing is unique, and is designed to be consistent across every occurrence; for an example see parallel other title information. This allows the sentence to be used in Search to identify the current soft-deprecated elements. Enter the sentence including the quotes, and limit the search to "RDA Only".

    The result is 91 hits, all elements, and all unique (I think; there seems to be a problem with browsing beyond page one of the results :-(. There is only one recommended option for each element. Other prerecording options may follow, but it is only a display artefact; the boilerplate phrasing is intended to emphasize the first option that is displayed.

    Manifestation: other title information is not currently soft-deprecated. No option is recommended over any others in the Prerecording section.

    A policy statement agency is free to accept the recommendation to use another element in context ("apply the option") or place a "do not use" policy statement at the top of the element page. An application profile can simply ignore the soft-deprecated element (this is where I think a specific list or selector might be helpful); legacy data can be mapped to the recommended element.

    Moving from soft- to full deprecation involves using the element label as an alternate label to the recommended element, and 'de-activating' the deprecated element. The definition of the deprecated element is effectively broadened and any refinement is lost. I am sure RSC will consult with the RDA communities when the time comes.

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



  • 33.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 01:57 PM

    Gordon,

    I'm aware that MARC 245 $b is not only used for other title information, but I don't see what that has to do with the discussion. In the recording format I use (the Pica format), there is a specific subfield which is only used for other title information. Other elements are recorded in separate fields (e.g. parallel titles).

    I also do not see the examples you give under „M has title" as really problematic. We shouldn't forget that it's a characteristic of other title information that it never comes on its own, but is always connected to a title proper (in fact this is required by the definition in the Toolkit). I believe that neither catalogers nor users have difficulties in seeing the combination of both as a title or at least title-ish. If there is a problem at all, it only arises if we take them forcibly apart -- so, in fact, only if you atomize it into separate statements as Linked Data is wont to do.

    I find it quite astonishing that you recommend not using other title information any longer, and instead use a manifestation title and responsibility statement element. I know that work is being done on implementing manifestation statements in MARC in a rather gruesome looking 881 (https://www.loc.gov/marc/mac/2020/2020-dp06.html), but personally, I do not have any interest in making use of the new manifestation title and responsibility statement element at all. Why is this supposed to be an improvement (apart from perhaps, in the context of automated processes)?

    For me, it would mean going back to pre-ISBD times and the practice of, e.g., the Prussian Instructions. According to this early German cataloging code, such information was copied exactly in the order found on the resource. So, in one case, the description would start with the statement of responsibility, and in the next it might start with the title proper. The ISBD, however, introduced a standardized order of these elements, and I think this is still very useful for catalog displays. And if it's about showing the exact design of the title page, users would be much better served by a scan.

    Also, we should certainly expect users to combine words from the title proper and other title information in their search. That's why, in German catalogs, other title information is routinely included in the title keyword index. There isn't much point, but if we wanted to, we could easily make all other title information available in a browse index as well. So, no, I do not see any reason for recording words which are presented as other title information as something else.

    Interestingly, we seem to have very different perceptions of what we consider as „noise". As I said, I'm not at all worried about treating other title information as a kind of title. On the other hand, many parts of the words in the official Toolkit for me are just that -- noise. Whenever I read in it, I'm continously stripping away words in my mind which don't seem to have much meaning, or at least, no meaning which would be helpful to a real-world cataloger.

    As I already said, another thing that bothers me is how many useful instructions have been removed. For other title information, it's not only the basic rules like how to treat typos and whether you're allowed to shorten it, but also the rules about supplying other title information in certain cases (e.g., for cartographic resources) or this rule: „If an original title appears on the same source of information as a title proper, and it is in the same language as the title proper, record it as an other title information." Admittedly, this is a very special instruction, but still -- it was considered useful enough to be included in the original Toolkit.

    I fear that this is a general tendency in the official Toolkit. As another example, take the exception for serials at 2.4.1.4: „Record a statement of responsibility identifying an editor of a serial only if the name of the editor is considered an important means of identifying the serial (e.g., if a particular person edited the serial for all or most of its existence; if the person's name is likely to be better known than the title of the serial)." For some time, this had been turned into an option for diachronic works in the Beta Toolkit (leaving out the bit in brackets). I did object to this via the feedback form, in fact, because you wouldn't want to do this for multipart items published over time (which are also considered to be diachronic works). But the option wasn't changed, as I had intended. Instead, it has now gone completely -- although it is not only in line with a long-standing cataloging tradition, but also eminently sensible.

    I am aware that communities would be free to add this option as a policy statement, but again it's hard to see why they should need to go to this trouble. Wouldn't it be the job of the RDA Toolkit to provide things like that?

    I'm glad to hear that my take on parallel elements has given you some food for thought. But I'd certainly not be happy if this phenomenon should in future be treated in the context of aggregates and metadata works. I think this would complicate matters up to a degree where only a very small number of people would be able to understand this. And to my mind, this certainly cannot be what a cataloging standard should aim at.

    Heidrun



    ------------------------------
    Heidrun Wiesenmüller
    Stuttgart Media University
    ------------------------------



  • 34.  RE: Other title information and more in the official Toolkit

    Posted Feb 01, 2021 05:18 PM
    On 2/1/2021 11:57 AM, Heidrun Wiesenm??ller via ALA Connect wrote:

    > I find it quite astonishing that you recommend not using other title
    > information any longer, and instead use a manifestation title and
    > responsibility statement element. I know that work is being done on
    > implementing manifestation statements in MARC in a rather gruesome
    > looking 881

    Too bad that the subfields couldn't have some (English) "mnemonicity",
    such as copyright being in $c (instead of $b), distribution in $d
    (instead of $e), edition in $e (instead of $f), frequency in $f (instead
    of $g), series in $s (instead of $n), title in $t (instead of $o)... I
    suppose the idea was to keep certain categories of information next to
    each other and this plus the decision to put the subfields in
    alphabetical order (other than $i) meant the number of pieces in each
    group would overflow the banks (as it were) of trying to match the
    initial letters, but I feel like it may be harder to get a grip on this
    way. (The fact that $t is *not* title here in contrast to, say, 7xx
    fields, definitely annoys me a bit.)

    --
    Lisa Hatt
    Cataloging | DeAnza College Library
    hattlisa@fhda.edu | 408-864-8459