New Dewey MARC discussion paper available for comment

By now, you’re probably used to citing Edition 23 in MARC records when cataloging with Dewey. Edition 23 was introduced in 2011, and what you see today in WebDewey is still considered Edition 23. Since the DDC is now maintained via continuous updates rather than discrete editions, we have no plans to have an Edition 24. That means just citing a number as being from Edition 23 becomes less and less useful over time, since numbers can change within an edition (that was true in the past too, but is more acute now).

To address this, the editorial team has put forth a discussion paper to the MARC Advisory Committee (MAC) outlining the problem. We’ve suggested a way forward that largely preserves current practice if you’re using a print version (whether print on demand or older print editions) and uses dates in a new subfield if you’re using an electronic version (like WebDewey).

The full paper is available on the Library of Congress’s MARC Standards site. There are some discussion questions at the end—we’d love your feedback on these or any other aspect of the paper. Note that since this is a discussion paper rather than a formal proposal, MAC will not be deciding whether or not to implement the outlined changes right away, but rather how to proceed. This is a great chance for you to be involved in that discussion.

What would this change mean for your workflow? Are there other approaches we should consider? You’re welcome to leave comments here or send them to [email protected]. Please have feedback in by Monday, June 22 in time for MAC to consider.

Comments

[Ann]

Have you considered a new 1st indicator to code for the online Dewey?
As you say, all ongoing usage is now coded as 082 0_ |2 23 - which becomes less useful over time.
And, it does seem as though the online edition is sufficiently different to be given its own code.
People using the POD versions, could continue to use the current '0' code with the |2 subfield.

This would remove the necessity for the |2 subfield for online DDC sourced classification numbers.

I'm not a fan of using the |e subfield - I feel that cataloguers are likely to look at the various 'letter' subfields as relating to the classification itself, rather than information about it. I'd prefer to use a |3 subfield for a date (users of POD would then have both the |2 and the |3 in natural sequence)

From a practical point of view - how important is it to code the date down to the actual day? Most LMS will not have the capacity to automatically generate this field based on the day the 082 was created (or edited), so this is going to require a cataloguer to manually add this.

082 fields with indicative classifications are frequently generated from CIP records and/or vendor cataloguing. I think it's unlikely these are closely checked against the online DDC - as the classification is indicative, rather than exact. So generating an exact date for the classification may actually be misleading.

My suggestion is that year is sufficient - with no need to go down to month/day.
Yes DDC changes over time - but not that rapidly. If spans of 7+ years in the print editions (including classifications which have changed over time) haven't required date indication - it seems unlikely to be a significant issue for the cataloguing community.

[Alex]

Thank you for this feedback, Ann. MAC was scheduled to discuss the paper today, but it's been pushed to tomorrow since we ran out of time. We heard from someone else suggesting a new first indicator value, so that's a good point for us to consider.

Regarding specificity of the date, you're absolutely right that any individual Dewey class is unlikely to change much in rapid succession, so I agree that year will be sufficient in most cases. The ISO format we're recommending will allow that, so you might think of the ability to add month and date as a possibility rather than a requirement. Especially for libraries that want to go beyond the year, I anticipate classifiers will make use of macros, Connexion constant data, etc. to fill that in.