6JSC/BL rep/2
1 August 2015
Simplification of RDA 2.7-2.10. Follow Up
6JSC/BL rep/2/Appendix B:
1 August 2015
Simplification of RDA 2.7-2.10. Follow up/Appendix B
Submitted by Alan Danskin, British Library
-
Recent posts
Recent comments
- Kathy Glennan on Expanding RDA 6.29.1.3, Laws Governing More Than One Jurisdiction
- Amanda Ros on Adding Controlled Vocabulary to RDA 3.19.6, Regional Encoding, and to the Glossary
- Amanda Ros on Adding Controlled Vocabulary to RDA 3.19.6, Regional Encoding, and to the Glossary
- Amanda Ros on Adding Controlled Vocabulary to RDA 3.19.6, Regional Encoding, and to the Glossary
- Amanda Ros on Adding Controlled Vocabulary to RDA 3.19.6, Regional Encoding, and to the Glossary
Archives
Comment policy
Only current CC:DA members and liaisons are authorized to comment on posts. Others who wish to contribute to CC:DA's discussions are invited to provide input by contacting the Chair, a member of the Committee, or their appropriate liaison.
New CC:DA members and liaisons will be assigned an account for the CC:DA Blog during the month of their initial appointment. For assistance with an account contact the CC:DA Webmaster.
All first-time comments on this site are moderated. We ask that all comments be relevant to the post to which they are directed and maintain professional courtesy.
All categories
Tag cloud
agenda ALA2012 ALA2013 ALA2014 ALA2015 ALA2016 ALA proposal Annual 2012 Annual 2013 Annual 2014 Annual 2015 Behrens Bourassa British Library Canadian Committee on Cataloguing Chair's report corporate bodies Dunsire European Regional Representative Glennan Iseminger JSC JSC rep Lapka Leonard Library of Congress McGrath Midwinter 2012 Midwinter 2013 Midwinter 2014 Midwinter 2016 minutes music Music Working Group (JSC) Myers OLAC PCC Rendall Reser response Robare Rolla RSC Shrader SnyderLinks
I think I can safely say that I like nothing in these proposals.
There seems to be a disconnect between the ideas discussed and the proposed changes.
Naming a new data element “colophon” is a terrible idea. Colophon is a well established concept. It was defined by AACR2, but it is conspicuously absent from RDA’s glossary. Should the definition be added to RDA?
I don’t like the proposal for transcribing vs. recording the copyright date. Recording copyright dates makes them potentially machine actionable vs. transcribing them. Why not make everyone happy — leave the instructions for recording copyright dates as is, and optionally allow for full transcription of all (or partial) copyright information?
As for the actual proposed changes to 2.7.4.4, etc., I don’t understand why you would remove the allowance to *optionally* add something. Options are good things. If you don’t want to optionally add things, then don’t do it.
I agree with the issues surrounding using “colophon” in a fairly non-standard way. (Especially since this term is already used several times in RDA with its traditional definition.)
Our response, therefore, should suggest an alternative term. What do you all recommend?
Some early thoughts from me:
* Actualization
* Execution
* Incription [but I think this has the same problem as “colophon”]
Agree that the use of colophon as proposed is problematic. It controvenes the standard dictionary definition as well as the definition found in Carter’s ABC for book collectors. It will be counterproductive to employ a commonly understood term in such a divergent fashion.
I feel like I must be missing something here, but I just don’t get the justification for this proposal. Also, it’s called “Simplification,” but the simplification seems to entail removing options while adding a new element called “colophon,” which appears to be two steps forward, one step back on the simplification front.
Regarding the proposed changes to 2.7.4.4, etc.
In its response to 6JSC/CCC/15, LC said (in part):
“When reviewing CCC’s proposal, we wondered about the necessity of an Optional Addition for 2.7.4.4, 2.8.4.4., 2.9.4.4, and 2.10.4.4 at all. Because the function is already indicated by the element name, the Optional Addition seems redundant.”
and:
“This added statement of function seems unnecessary for any implementation of RDA except a card catalog implementation.”
The JSC was sympathetic to this line of argument, which is how we got to this point in 6JSC/BL rep/2.
Thus, for the Optional Addition example in 2.9.4.4:
Guild Sound and Vision [distributor]
we would already have transcribed “Guild Sound and Vision” in an element labelled “distributor”.
I think this paper is both a proposal and a discussion paper.
The proposal: remove the optional addition from 2.7.4.4 [etc.]
The discussion paper: pretty much everything else.
Note that much of what this paper contains reflects the understanding that FR (and thus RDA) will be moving toward a greater use of relationships, instead of focusing on recording attributes. (And no, this won’t really work well in MARC!)
I assume that the JSC working principle will likely mean that any of the labor-intensive parts of this paper will be postponed until the JSC has a clearer idea of what changes will be required to keep RDA aligned with the FR consolidation.
However, that doesn’t mean that we should not pay careful attention to what is proposed in Appendix A and Appendix B. We should comment on everything we think is relevant.
Reading through Appendix B in particular, I’m struck by how this text does not match the current RDA style. While it’s easier to critique the style than the substance, I will try not to go down that rabbit hole.
On the other hand, reviewing this appendix is an instructive exercise, since the JSC will need to consider how to rewrite major sections of RDA to bring it in to line with the FRBR-LRM once that is finalized. I sense the need for an editor to be engaged in this process.
Appendix B, general editorial comments:
#1: The PPDM elements should be consistently presented in the same order. It appears that the basic recommendation is to move “production” last, but that is not implemented consistently.
#2: This seems like an opportune time to consistently use the term “transcribe” as it applies. For example, I think “transcribe” should be used in all of the 2.8 sub-instructions.
#3: In the alternatives to record a relationship (for example 2.8.4 & 2.10.5), consideration should be given as to whether the “instead of or in addition to” language should be consistently supplied.
#4: Definitions with their own instruction numbers: Generally, I think that 2.9.1 could be simplified as a single instruction which includes definitions for each of the terms. For example, see 18.1.4 which defines the terms and says how they are used. This situation is a bit different, but a similar approach would simplify the numbering and could potentially reduce the number of references to 2.9.5. This approach could be taken in the parallel instructions as well.
#5: The final example in 2.9.5 isn’t justified by any instruction (i.e., the wording in 2.8.2.4 didn’t make this appendix). I think that’s a problem.
On behalf of Francis Lapka, Yale Center for British Art
1. I vigorously support the paper’s proposal to add RDA entities for Place and Timespan, and to use these data elements to record places and dates of publication (etc.) as related entities. This change is logical and will help align RDA with other major cultural heritage metadata models (such as the CIDOC CRM). The warrant for recording place and date as (controlled) related entities is apparent in current cataloging practice, where we use MARC fixed fields to record dates and (in the special collections community) the MARC 752 to record controlled information about the place of publication.
2. I also whole-heartedly support the proposal to create an “Imprint” element to transcribe complete (unparsed) statements concerning publication, distribution, and manufacture. If we have a means to record places, agents, and dates as related entities, I don’t think we gain much by parsing the sub-components of imprint statements. Recording the information in the form and order that it appears, unparsed, would better serve the principle of representation.
The paper says to record multiple Imprint elements (where applicable) “in the order indicated …”. I wonder if we should consider, as a universal convention with any transcribed element, always recording the source of the transcription (in a related data element). This may sound onerous, but with a well-designed cataloging client and a default array of sources, it could be simple.
3. I generally support the proposal to create a Colophon element in which to transcribe complete (unparsed) statements concerning production. However the proposed name for the element is extremely problematic. Would it be so bad to label the element with something straightforward, such as “Transcribed production information.”
4. The changes that the paper proposes for copyright data are a step in the right direction. I agree that a copyright date – as data – should be an attribute of the Expression, not the Manifestation. I also agree that there may still be a use case for transcribing copyright information as an attribute of a Manifestation.
I wonder if RDA’s copyright guidelines might reflect the idea that there are two relevant pieces of data: date and agent. If we revise the copyright attribute for a Manifestation, might it not make sense to allow for transcribing information concerning both the date and agent? And why doesn’t RDA include a relationship designator for copyright holder (unless it does and I’m missing it)?
5. I confess I may not completely comprehend the sections of the paper concerning the deprecation of existing aggregate statements for PPDM information. It appears, however, that if all aspects of the paper are implemented, we would have at hand *three* methods for recording PPDM information: a) as related entities; b) as unparsed Imprint or Colophon transcriptions; or c) as transcribed sub-elements (parsed). I wonder if this is one alternative too many. While we have a ton of legacy descriptions with PPDM data in the form of parsed transcriptions, I don’t see much benefit in providing that option going forward.
In response to #4 above (2nd paragraph):
Per RDA 0.2.3, there are certain relationships and attributes that are out of scope. This includes:
attributes and relationships (associated with the entities person, family, corporate body, work, and expression) whose primary function is to support user tasks related to rights management.
6JSC/ACOC/8 (2013) proposed adding a copyright holder relationship. This was withdrawn because of that “out of scope” statement above.
Comments on transcribe/record tables
In the section numbered 3.5.2, there’s a comparison table for transcribing vs. recording date of publication. The one I think is problematic is “2.8.6.5/Block 1/” which removes the dash for an open ended date for a multipart monograph, serial or integrating resource. However, the final example in this table has a similar situation, and invokes 1.7.3 to add punctuation for clarity. Why isn’t that applicable to the earlier example as well?
In relation to transcribing the copyright date (section 3.6.2.1), the paper does not replicate the copyright symbol, apparently because this would be recorded in an element labelled “copyright date”. However, that doesn’t seem to match the definition of transcription. Currently we record redundant information in a distributor statement (“distributed by Hal Leonard”), even if we label that information as the distributor’s name. How is this situation different?
I don’t record that type of redundant information myself … I wouldn’t record “Published by” in a statement about a publisher, e.g. I’d just record “American Library Association”, not “Published by American Library Association”; I wouldn’t record “printed by” in statements about manufacturers; so I also wouldn’t record “distributed by” in the case above. Maybe I’ve been doing it wrong all along, but I’ve assumed that yes, that is redundant because the element itself tells whether it’s a publisher, distributor, or manufacturer. (Note: I do think it’s odd that RDA tells us to record the copyright or phonogram symbol in 2.11.1.3, since that, too, is redundant–the element itself tells us it’s a copyright date and in essence there’s no difference between a copyright date and a phonogram date, they both assert copyright in a work or expression. Yes, I know there’s a difference between a sound recording and anything else but we don’t have a special symbol for other non-print sorts of copyright assertions so I’m not sure that distinction is important in an element that generally labels itself as “copyright date”.)
I think the distinction between a copyright date and a phonogram copyright date is significant. Because these mean different things, they should be properly identified in our data. Creating a sub-element for phonogram copyright date would be another way to solve this problem.
I would like specific comments on the 5 recommendations contained in this paper. I will enter them as separate entries below.
Recommendation #1
JSC to consider re-designation of the 2.11 Copyright Date to Copyright Notice Date or Copyright Year
I have no particular preference about what to name this element, although I must admit that I have no problems with the current name, which certainly is in common use in American English.
However, if we’re interested in what international standards call this, there’s the term for MARC Bibliographic 264, 2nd indicator, “Copyright notice date”. On the other hand, there’s MARC Bibliographic 542 subfield $g “Copyright date”.
Recommendation #2
Future revisions of RDA should provide for the transcription of the Copyright Date
I think this is OK, as long as it’s not the exclusive choice.
Recommendation #3
Specify Copyright Date or Date of Copyright as a relationship between Expression and Timespan
It makes sense to model copyright date as a relationship to the expression.
I assume that as Timespan is developed, there will be a way to do this.
Recommendation #4
JSC to discuss whether it is appropriate for the RDA instructions/element set to specify core elements, or whether core elements are community defined in application profiles
Oh my, moving core elements to an application profile only would be a significant change.
This puts the tension in RDA development into sharp focus: what belongs in an international standard (RDA), and what should be able to vary based on the user community (application profiles).
I do see application profiles (say for American practice) taking on a greater role as RDA moves toward greater internationalization. Where do we draw the line about what belongs in RDA proper?
I do not agree with the idea the RDA should no longer specify core elements and leave it all up to application profiles. I think RDA itself needs to take some sort of stand and say “if you want to say you’re following RDA you at a minimum need to do these things.” Leaving that to application profiles it seems to me is totally wishy-washy. Application profiles should (as they do) say what elements communities might want to require beyond RDA core, but RDA itself needs to set some sort of standard of what RDA considers to be necessary for a description to be called an RDA description.
On behalf of John Attig
My assumption has been that application profiles could be defined for any user community — and that this would include a global “RDA” user community — which is where I think the core requirements belong. Core requirements are about how to apply RDA instructions, and therefore should be in an application profile. However, core requirements should apply to all users of RDA, and therefore should be in a global application profile. Moving RDA provisions to an application profile does not necessarily mean that they should be generally/globally applicable.
I believe that the JSC Chair has begun to construct such a global RDA application profile. If it does not yet include the core requirements, they need to be added.
Concur with Kathy’s and Bob’s comments. Without some concept of CORE, then one could produce a blank description and say it is RDA. (I suppose that’s one solution to universal bibliographic control — here is the RDA record suitable to describe everything (or anything), “But it’s empty” Yes, but it’s still RDA!)
Recommendation #5
JSC to consider formation of a Working Group on Timespan
Technical WG to consider appropriate place of Calendar
Sounds reasonable to me.
Comments from me and my colleagues at NLM:
We agree that ‘colophon’ is confusing terminology in the context of this proposal.
We find Appendix B to be confusing as written, partly because of the language and partly because of the many references to unwritten RDA chapters.
For 4.4, Recommendation 4, we think that a basic set of core instructions applicable across communities in the RDA instructions would be preferable, with enhancements and additions to be defined by specific communities.
We think that the instructions in Appendix B, 2.8.4.1, 2.10.5 should be an option, rather than the base instruction, or at the very least, that there should be an option to transcribe only first imprint statement rather than all of them.
We think there may be a typo in 4.3, and that it should refer to the 264 field rather than the 260 field.
We also think there may be a typo in Appendix B, 2.10.5, in the optional addition. It refers to place but we think it should refer to the name.
For the recommendation : 2.7.6.5 Multipart Monographs, Serials, and Integrating Resources
If the first issue, part, or iteration of a multipart monograph, serial, or integrating resource is “known”…
Not being experienced with unpublished serials, perhaps this makes sense to use “known”, since having the first issue be “available” might be more unlikely.
Peter, would it make sense to change the related language to “known” (from “available”) for published serials as well?
Some comments on section 3.6 of the paper.
3.6.1.2 Source of Copyright Date. RDA 2.11.1.2 says “Take information on copyright dates from any source” so the fact that the source is “usually” the copyright notice printed on the resource is not all that relevant to me. It is perfectly true in our practice we generally just copy down whatever copyright date accompanies the resource as published (e.g. a copyright date on the title page verso) but that’s just an assertion by the publisher, not necessarily the “real” copyright date of the work or expression, and under 2.11.1.2 I should think I would be justified in totally ignoring that and recording information from a source I thought had better evidence for the real copyright date (e.g. some sort of national copyright agency database). Perhaps this it the tension between *recording* copyright dates and *transcribing* copyright statements. When you record a copyright date you should take all of the evidence into account and that might mean you record some date other than what accompanies the published resource.
3.6.1.3 recording the copyright symbol. I already commented above on this. I agree it’s redundant.
3.6.2. The justification for recording copyright date as an attribute of the manifestation is that it is a piece of information that is actually found on a published item that helps identify the manifestation you have in your hand. This is not in my opinion a questionable justification. However, I agree that as evidence for what the copyright date in fact is, it isn’t necessarily the strongest evidence.
3.6.2.1. If a decision is to move forward with transcribing copyright date I strongly urge that statements about the copyright holder also be included as a statement of responsibility (the copyright holder is the entity responsible for asserting the copyright so I think it’s a kind of statement of responsibility, at least it’s very like one). If we’re going to transcribe let’s really transcribe what’s there. So I’d *transcribe* exactly as in the source:
If transcribed:
Example 1: ©2014 by World Scientific Publishing Co. Pte. Ltd.
Example 2: ©American Library Association 2014
Example 3: ©MMXV Tangled Bank Studios, LLC
Example 4: ©1980 Capitol Records Inc [or choose to transcribe the other statement]
Or to take a 19th century example: Entered according to Act of Congress, in the year 1833, by John Hayward, in the Clerk’s Office of the District Court of Massachusetts.
Bob, as noted in one of my comments above, this would entail removing a restriction from RDA 0.2.3.
Art catalogers within ARLIS/NA are by and large happy with 6JSC/BL/26 (2.7 Production Statement: Changing Method of Recording). Our chief reservation is about treating date as an element transcribed from the resource, rather than a recorded element; we believe it should be recorded, like other two elements.
We are slightly bemused by the two papers dealing with Simplification of RDA 2.7-2.10, because they appear to reverse the ground gained (from our perspective) in 6JSC/BL/26. As we interpret these two papers, they make provision for just two options for recording PPDM information:
Transcription (if information exists on the resource)
Recording a URI for a related entity (for place, producer name, and timespan)
This runs counter to the approach in 6JSC/BL/26, which is to record production information from any source. Are the two new data elements, Colophon and Imprint, intended to supplement the current PPDM elements, being used only for exact transcription from the resource, or are they intended to replace the current elements entirely (in which case, the ability to record much production information would be lost)? Clarification on this issue would be most welcome.
From Francis Lapka, Yale Center for British Art
I don’t think it’s correct to assume that the relationship to the Place and the Timespan has to be recorded as a URI. The BL paper says the opposite, on page 16 (in Appendix A): “It is assumed that the relationships can be expressed using any of the options currently permitted (the“four-fold path”)” – i.e. as URIs, access points, and structured or unstructured notes.
So in the end, the cataloger would still have the ability to *record* a related place, and I think this would accommodate the desire expressed by the ARLIS/manuscripts community to record such information in a non-transcribed form. This, in turn, would free up the Production elements in chapter 2 to be reserved for transcribed information – which is the approach that I prefer.
Comments from members of the Music Library Association’s Content Standards Subcommittee
Recommendation 1 – no objections to renaming the element
Recommendation 2 – all commenters agreed that phonogram dates and copyright dates should be treated separately. There was support for recording the copyright date, but dropping the requirement to precede the date with (p) or (c). However, if the (p) or (c) symbols were to be dropped, then a new sub-element for phonogram date would need to be created.
Colophon: The proposal uses “colophon” in an extremely problematic way.
Another comment from a Music Library Association member
I can definitely see a rationale behind providing a method to give a structured transcription of various aspects of publication/production data, particularly for archival or rare materials description. I don’t think completely disassembling the existing structure of RDA is the best way to do that, and it certainly doesn’t strike me as *simpler*.
The rare materials community engaged heavily with 6JSC/BL Rep/1 but provided relatively little feedback on these follow-up documents. Many of our comments on BL Rep/1 may still be pertinent. Support remains for separating transcribed PPDM statements and recorded elements/relationships, just as is done with transcribed statements of responsibility and recorded relationships to creators/contributors etc. Parsing statements into subelements is often difficult because of grammatical linkage, page layout, and lack of distinction between publication, distribution and manufacture functions in early materials, and other commonly encountered conventions (such as the use of addresses/signs/devices in place of publishers’ names, variations in spelling, archaic place names, abbreviations, piracies and forgeries, etc.) these transcribed statements support identification tasks, and do so better with less cataloger manipulation (transposition, interpolation, omission, correction, etc.). Meanwhile separately recorded elements, ideally with normalized/controlled data, better support finding (e.g. collocating all the works published by a certain publisher) and other secondary tasks such as data mining/mapping etc. Both approaches have importance in rare materials contexts, but other communities may emphasize one or the other. It is not clear which of the scenarios considered by this proposal best accomplishes these goals and accommodates these disparate user tasks.
1. Copyright: There seems to be agreement that recording copyright dates at the expression level vs. transcribing them at the manifestation level makes sense. Going further, we agreed with Bob Maxwell’s suggestion that we then should have the option to transcribe the whole statement in addition to the date. This might be for rare materials identification purposes, and for supplying data in other elements such as place of publication, author/publisher, etc. in addition to publication dates. This has typically been done as an optional note rather than in the MARC 26x. As with the PPDM statements, transcription may make sense mostly in rare materials contexts. If egencies need this data to satisfy legal or deposit obligations, recording copyright holder and copyright jurisdiction as related entities along with recording copyright date using normalized forms and potentially external sources would accomplish that better, though this brings up the scope issue at 0.2.3 more than transcription does.
2. Colophon/Imprint: Commenters agreed as to the value of transcribed statements for identification of manifestations, but dislike the terminology of Colophon; why not just continue to call them production statements, etc.? Imprint appeared to meet with less objection..
3. Deletion of optional addition: Commenters supported the removal of the optional addition of statement of function. Such transpositions and interpolations inhibit accurate transcription, and element names or relationship designators can indicate function.