| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Discussion topic: Manuscripts across DCRM

Page history last edited by Deborah J. Leslie 10 years ago

This large topic is broken up into smaller discussion topics; this wiki page is being retired. 2014-04-22

 

Meeting 2013-06-20:

 

  • Tackled bracketing or non-bracketing of supplied text, the most significant disparity of manuscript treatment across manuals
  • A number of arguments were made for and against non-bracketing of supplied titles
  • The MSS group is requested to put forward their best written arguments on why non-bracketing of titles and other supplied text constitutes a material-specific need to deviate from the rest of the DCRM's

 

Comparison of Treatment of Manuscript Materials in DCRM

 

This chart compares the treatment of manuscript materials across DCRM modules. The DCRM Steering Group should look at the areas where the modules are not currently in agreement, and discuss whether a consistent approach is possible and/or desirable (whether across the board or in particular areas).

http://dcrmcompare.pbworks.com/w/page/55428555/FrontPage

 

Comments

Comments (3)

francis.lapka@yale.edu said

at 4:01 pm on Jun 20, 2013

A thought that doesn't contribute much to solving the present problem (bracketing of supplied titles): In a starting-from-scratch world, it might be preferable to indicate that a value is supplied by way of some encoding (that doesn't add characters--like brackets--to the value string itself). So we could have something like <title type="supplied">Some title</title>. In this way, the *display* of the value (with or without brackets) could be adjusted to fit the norms of the context.

I believe some other communities do this already. And RDA says (2.2.4): "When instructions specify transcription, indicate that the information is supplied from a source outside the resource itself: by means of a note (see 2.20) or by some other means (e.g., through coding or the use of square brackets)," so the door is left open for coding solutions.

But in MARC 245 there's no way to do anything like this.

Erin Blake said

at 8:01 am on Jun 21, 2013

I think you've hit it exactly, Francis: DCRM provides rules for *bibliographic* cataloging, which considers distinguishing between transcribed and devised text a key principle. It's not that supplied information has to be bracketed, it's that it has to be IDENTIFIED as supplied. Currently, in bibliographic cataloging, the only way you do that in the title proper is with square brackets. So, for better or worse, that's what we've got. If your system has another way to identify the information as supplied, then go for it. But if you're making a bibliographic record in 2013, international bibliographic standards say you indicate supplied information with square brackets.

Elizabeth O'Keefe said

at 11:36 am on Jun 21, 2013

One thing I was pondering after our meeting yesterday was the meaning of "bibliographic cataloging". It could mean some or all of the definitions below:

Describing single items versus describing collections

Describing published items (principally printed books, but by extension, scores, cartographic material, etc.) versus describing other types of items (manuscripts, archival materials, 3-d art and cultural objects, natural history specimens)

Describing items using conventions derived from the characteristics of printed books and other published items versus describing items using conventions derived from the characteristics of other types of material (manuscripts, archival materials, 3-D art and cultural objects, natural history specimens)

Encoding descriptions of items in MARC bibliographic format versus encoding in other data formats (EAD, VRA Core, CDWA, etc.)

I think it would help my team to think about this if we knew which definition(s) apply within the context of DCRM.

You don't have permission to comment on this page.