Planet Cataloging

July 20, 2017

Terry's Worklog

MarcEdit 7 Keycode Documentation

Something that comes up a lot is the lack of key combinations or pathways to using functions in MarcEdit.  I’ll admit, the program is very mouse heavy.  So, as part of the accessibility work in MarcEdit 7, I’m taking a long look at how access to all functions can be accommodated via the keyboard.  This means that for MarcEdit 7, I’m mapping out all keycode combinations (the ALT+[KEY]) paths and the more traditional shortcut key combinations) for each window in MarcEdit.  When it’s finished, I’ll make this part of the application documentation.  Before I get too far along, I wanted to show what this looks like.  Please see:

Does this look like it will be helpful? 


by reeset at July 20, 2017 09:31 PM

July 18, 2017

First Thus

Libraries in the Post-Scarcity Era by Balázs Bodó

This is a very interesting article about pirate libraries–a fact of life whether we like it or not.

Source: Libraries in the Post-Scarcity Era by Balázs Bodó :: SSRN


by James Weinheimer at July 18, 2017 02:34 PM

Terry's Worklog

MarcEdit 7: Preferences Wireframes and Ease of Use Features

This post relates to the previous posts:

  1. MarcEdit 7 visual styles: High Contrast:
  2. MarcEdit 7: Accessibility Options Part 2:

I’m continuing to flesh out new wireframes, and one of the areas where I’ll be consolidating some options is in the preferences window.  I’ve decided to reorganize the menu and some of the settings.  Additionally, I’m adding a new setting: Ease of Access. 

Here’s the Initial Wireframes demonstrating the new menu layout


Ease of Use:

This is a new section developed to support Accessibility options.  At this point, these are the options that I’m working on:


While MarcEdit will respect the operating system’s accessibility settings (i.e., if you’ve scaled fonts, etc.), but these settings directly affect the MarcEdit application.  In this section, you’ll find the themes (and I’m working out a way to provide a wizardry way to create themes and find ones that have been created), feedback options (right now, if this is selected, you’ll get audible clicks letting you know that an action has occurred), and Keyboard options.  I’m spending a lot of time mapping the current keyboard options, with the intention that I’ll try to map all actions to some keyboard combination.  These settings tell MarcEdit if this information should show up in the Tooltips, as well as rich descriptions about an operation.  The last thing that I’ll likely add is a set of links to topics for users looking for accessible friendly fonts, etc. 

I think that the reorganization should help to provide some clarity in the settings and will help me in thinking about the first run wizard – and hopefully the currently planned accessibility options will provide users with a wider range of options. 

Questions, comments, let me know.


by reeset at July 18, 2017 06:16 AM

July 17, 2017


Wikipedia the WebJunction way

2017-07-30 Wikipedia-yellow-OCLC

In the past decade, Wikipedia’s reach has expanded. It’s the fifth most-visited platform globally.[1] And the quality has stabilized. A 2012 Oxford University study comparing Encyclopedia Britannica to Wikipedia found no significant difference in quality or reliability between the articles they compared. However, research suggests that asymmetries in the demographic profile of the existing pool of editors, which are 80–90% white males, has led to biases and underdeveloped content areas.[2]

To improve the encyclopedia and address these gaps, volunteers and Wikimedia Foundation staff have collaborated to host outreach programs and editing events. These have seen successes, but there’s still room for improvement. Only some of these programs have focused on galleries, libraries, archives and museums (GLAM, in Wikimedia terminology), and none of the outreach has been specifically geared to public libraries and their important role as champions of information access and mainstays in serving their local communities.

The time has come for an effective, focused training program that brings Wikipedia to US public libraries.

WebJunction will be filling this gap by spearheading an online training program for up to 500 US public library staff to learn Wikipedia from September to November 2017. The program addresses the need for training tools that are specific to the learning needs of public library staff, which is what WebJunction does best. This training program will bring public libraries into the Wikipedia community so that library staff can dovetail their service goals and skills with the Wikipedia vision of building a comprehensive information reference source that’s freely and widely accessible on the open web.

And with US public library staff learning Wikipedia, information seekers everywhere are bound to be better informed, more digitally literate and able to access more library services and materials.

A bridge to Wikipedia for public libraries

In 2016, OCLC launched the Wikipedia + Libraries: Better Together project, funded by a Knight Foundation News Challenge grant and the Wikimedia Foundation. The project’s purpose? To build bridges between public librarians and Wikipedians.

Wikipedia + Libraries is different from other Wikipedia editing tutorials; it’s specific to the service goals and professional development needs of 21st-century US public libraries.

Starting 13 September 2017, WebJunction will host a ten-week online training program covering Wikipedia editing literacies and programming best practices. The course will champion, and build upon, the range of ways that librarians are already engaging Wikipedia—you can read about some of these activities in WebJunction’s Librarians Who Wikipedia interview series.

There will be a preview webinar about the program on 19 July from 3:00 pm – 4:00 pm. US EDT.

How WebJunction fits in and how YOU can fit in

WebJunction brings the best of adult learning and online education to public libraries. It makes sense for library staff to learn deliberately and actively, in ways that benefit their community members.

Participants in the online training program will learn how to edit in a supportive cohort of peers familiar with the demands of public library work. Course materials will include sessions and activities that are fresh and relevant to their work as information professionals serving the public.

How can public library participation help improve Wikipedia?
Click To Tweet

Please spread the word to public library staff about the Wikipedia + Libraries: Better Together project:

  • Registration for up to 500 public library staff to enroll in the free, ten-week online training program Wikipedia + Libraries: Better Together will open on 19 July; there will be six live online sessions during the ten-week course that will last 13 Sept. – 15 Nov. 2017.
  • To learn more about the Wikipedia + Libraries training program, attend the preview webinar Wikipedia For Libraries: Preview the Possibilities, Discover the Opportunities on 19 July; enrollment is currently open for this free webinar.

Learning to Wikipedia isn’t only about boldly editing. It’s a way for public librarians—you!—to contribute to a dynamic community in practical ways, among your library contemporaries with WebJunction.

By the end of the Wikipedia + Libraries online training program, public librarians will have learned how to bring best practices in public librarianship to the open web, and have added a few pages to the Wikipedia instructional playbook in doing so.


[1] Source: Last accessed, July 11, 2017

[2] Hill and Shaw, “The Wikipedia Gender Gap Revisited”; Ross, “Wikipedia’s Gender Gap”; “2011 Editor’s Survey.”

“2011 Editor’s Survey.” Wikimedia Foundation, 2011.

Hill, Benjamin Mako, and Aaron Shaw. “The Wikipedia Gender Gap Revisited: Characterizing Survey Response Bias with Propensity Score Estimation.” Edited by Angel Sánchez. PLoS ONE 8, no. 6 (June 26, 2013): e65782. doi:10.1371/journal.pone.0065782.

Ross, Sage. “Wikipedia’s Gender Gap.” Wikimedia Blog, February 1, 2011.

Wagner, Claudia, Eduardo Graells-Garrido, David Garcia, and Filippo Menczer. “Women through the Glass Ceiling: Gender Asymmetries in Wikipedia.” EPJ Data Science 5, no. 1 (December 2016). doi:10.1140/epjds/s13688-016-0066-4.

The post Wikipedia the WebJunction way appeared first on OCLC Next.

by Monika Sengul-Jones at July 17, 2017 02:19 PM

July 16, 2017

Terry's Worklog

MarcEdit 7: Accessibility Options Part 2

I’ve been working a bit more around this notion of creating “themes” to improve visible accessibility options.  This started with an initial implementation that included the default interface and then a High Contrast interface.  Over the past few days, I’ve been getting a wide range of feedback, and one of the things that is becoming apparent is that folks would like to have a wide range of preferences.  So, this afternoon, I spent time taking the hardcoded default and high contract themes, and rewriting all non-default UI implementations as themes. 

Theming Work

When I think about theming, I immediately start thinking about the operating system themes, or themes that you can download for browsers.  At this point, we aren’t talking about anything quite so complex.  In fact, until I get feedback, I’ll be keeping theming light weight – but I think that in the long run, this might actually make them more useful.

How do they work?  Essentially, a theme is going to be the implementation of an XML file.  Here’s the dark (high contract) theme written out in the new xml theme structure.

<?xml version=”1.0″ encoding=”utf-8″ ?>
   <name>Dark (High Contrast) Theme</name>
     <!–Use HTML web color codes for these values–>
       Override values
          <behavior> [set to always, hover, none]

As you can see, the initial implementation of theming is very limited.  Essentially, users can theme font color and background colors globally, at the MarcEditor level, and override options for menus and links found within the program.  This may (and likely) will be extended prior to the release of MarcEdit 7, but I don’t anticipate it being enhanced a lot.  While the new GUI rendering engine makes this kind of work easier, I don’t want to develop an entire rendering process around this method until I know there is more than a passing interest.

What this means, however, is that I can quickly create new themes.  Right now, I’ve implemented this in the Options dialog.  You can see the current line of thinking below:


Using the Main Windows of MarcEdit 7 as the example page, I’ll run through the current themes that I’ve marked up:

Default Theme (hardcoded):


Dark (High Contrast) Theme:


Dark Gray Theme:


White Theme:


All these themes were created using the theming xml files.  As I say, if I get feedback, I’ll look to expand this as we move towards the official release. 

Questions?  Comments?


by reeset at July 16, 2017 03:37 AM

July 14, 2017

Terry's Worklog

MarcEdit 7 visual styles: High Contrast

An interesting request made while reviewing the Wireframes was if MarcEdit 7 could support a kind of high contrast, or “Dark” theme mode.  An Example of this would be Office:



Some people find this interface easier on the eyes, especially if you are working on a screen all day. 

Since MarcEdit utilizes its own GUI engine to handle font sizing, scaling, and styling – this seems like a pretty easy request.  So, I did some experimentation.  Here’s MarcEdit 7 using the conventional UI:



And here it is under the “high contrast” theme:



Since theming falls into general accessibility options, I’ve put this in the language section of the options:


However, I should point out that in MarcEdit 7, I will be changing this layout to include a dedicated setting area for Accessibility options, and this will likely move into that area.

I’m not sure this is an option that I’d personally use as the “Dark” theme or High Contrast isn’t my cup of tea, but with the new GUI engine added to MarcEdit 7 with the removal of XP support – supporting this option really took about 5 minutes to turn on.

Questions, comments?


by reeset at July 14, 2017 03:50 PM

July 13, 2017


Recognizing leaders in our library community


During this year of OCLC’s 50th anniversary, it has been fun to remember all the ways in which OCLC has come together and grown as a global library cooperative. The OCLC staff have been collecting and sharing many images from the archives over the past few months, giving us all the chance to join in this celebratory journey. The photos are truly fabulous, representing many artifacts that are near and dear to my heart, including the beehive terminal and the catalog cards. BUT, the photos that are the most meaningful, and the most telling of our story as a cooperative, are the many photos of member librarians over the years.

OCLC has more than 16,000 member libraries in more than 120 countries around the world. If you consider the number of library staff working collectively across those member institutions, you can imagine what a powerful network that is. And we all know that librarians can make things happen. When we harness that creativity, commitment and passion, achievements like those that OCLC has had over the years become too many to count.

That’s why, each year, OCLC supports several community awards to recognize librarians who excel in their profession. We had the opportunity to recognize these community leaders at the ALA Annual Conference in Chicago this past June.

I hope you’ll join me in congratulating them and reflecting on all the other colleagues in your professional life who have made a difference in your library and our larger community.

OCLC is pleased to support these community programs that advance and recognize excellence in librarianship. It is my honor to spotlight these five community leaders and their noteworthy accomplishments:

Peter Bae

Virginia Boucher/OCLC Distinguished ILL Librarian Award

Peter Bae, Circulation Services Director at Princeton University’s Firestone Library, is this year’s recipient. This award recognizes outstanding professional achievement and leadership in interlibrary loan and document delivery. And, as most know, we at OCLC have a special place in our hearts for interlibrary loan and international cooperation and sharing. Peter’s ongoing research, presentations and publications as a member of IFLA’s Document Delivery and Resource Sharing Section and the STARS Section of RUSA have fostered communication and collaboration across the global resource sharing community.

Timothy Cole

Frederick G. Kilgour Award for Research in Library and Information Technology

Named after the founder and first president of OCLC, this award is particularly meaningful to us at OCLC because it represents Mr. Kilgour’s commitment to library innovation through outstanding research and development. Timothy Cole is this year’s recipient. Timothy is head of the Mathematics Library and Professor of Library and Information Science at the University of Illinois at Urbana–Champaign. His research in digital libraries, metadata and linked data frameworks has significantly enhanced discovery and access of scholarly content. Timothy is also recognized for his significant contributions to the World Wide Web Consortium, the Digital Library Federation and the Open Archives Initiative.

Amed Demirhan

John Ames Humphry/OCLC Forest Press Award

Amed Demirhan is the 2017 recipient of this award, which honors exceptional contributions to international librarianship. Amed is General Manager Director at the Barzani National Memorial in Erbil, Iraq, where he is building a library and museum to collect and share resources on Kurdistan and modern Kurdish history. His earlier endeavors include revitalizing the library at the American University of Nigeria into a 21st century facility and establishing the Hawler Library at the University of Kurdistan, Iraq’s first independent English-language university, in 2006. We at OCLC share his passion for international library cooperation.

Carla D. Hayden

Melvil Dewey Medal

Carla D. Hayden, the United States’ Librarian of Congress, is being honored with the Dewey Medal, which recognizes creative leadership in library management, training, cataloging and classification. Her two decades of exemplary leadership of the Enoch Pratt Free Library in Baltimore, Maryland, set an example of the role that librarians play in the community, opening the system’s libraries for refuge during a time of civic strife. She is also recognized for her inspiring leadership while President of the American Library Association in 2003–2004, and very significantly, her historic appointment in September 2016 as the first woman and first African-American to be named Librarian of Congress.

Hope Olson

Margaret Mann Citation

Hope Olson is being honored for outstanding professional achievement in cataloging. Hope is Professor Emerita at the University of Wisconsin–Milwaukee, where she served as Professor, Associate Dean and Interim Dean before her retirement in 2013. She also taught in the School of Library and Information Studies at the University of Alberta from 1990 to 2003. She is active in professional organizations and editorial boards, and published a book in 2002. The Margaret Mann Citation includes a scholarship donation to a library school chosen by the award recipient; Hope has chosen the University of Alberta.

Congratulations to the 2017 OCLC Award Winners!
Click To Tweet

Congratulations to Peter, Timothy, Amed, Carla and Hope, and thank you for all that you have contributed to the community.

I’d also like to say congratulations and thank you to all staff at OCLC member libraries, for supporting the cooperative in meeting this significant 50-year milestone. Happy anniversary OCLC!

The post Recognizing leaders in our library community appeared first on OCLC Next.

by Sandy Yee at July 13, 2017 04:32 PM

Terry's Worklog

MarcEdit 7: MARC Tools Wireframe

The changes aren’t big – they are really designed to make the form a little more compact and add common topics to the screen.  The big changes are related to integrations.  In MarcEdit 6.x, when you run across an error, you have to open the validator, pick the correct validation option, etc.  This won’t be the case any longer.  When the tool determines that the problem may be related to the record structure – it will just offer you option to check for errors in your file…no opening the validator, not picking options.  This should make it easier get immediate feedback regarding any structural processing errors that the tool may run up against.

MARC Tools Window Wireframe #1:


The second write frame collapses the list into an autocomplete/autosuggest options, moves data around and demonstrates some of the potential integration options.  I like this one as well – though I’m not sure if having the items in a dropdownlist with autocomplete would be more difficult to use than the current dropdown list.  I also use this as an opportunity to get ride of the Input File and Output file labels.  I’m not sure these are always necessary, and I honestly hate seeing them.  But I know that iconography maybe isn’t the best way to express meeting.  I think attaching tooltips to each button and textbox might allow me to finally let these labels go.

MARC Tools Wireframe #2:



Based on feedback, it sounds like the labels are still desired.  So here is wireframe #3 with a slight modification to allow for labels in the window.

MARC Tools Wireframe #3:



by reeset at July 13, 2017 06:03 AM

July 12, 2017

Terry's Worklog

MarcEdit 7 progress notes and changes

** Originally posted to the MarcEdit Listserv **

While I’ve got a couple of clean up things to do with MarcEdit 6.x, I’ve been starting the process of revising MarcEdit 7.0.0.alpha.  At this point, there is a version running new code.  I’ve spent the past few evenings reorganizing the main window, pulling some things apart, and beginning the process of redoing code.  So far, this what’s been completed:

New MarcEdit 7 Main window:


This is what the main window looks like.  I’ll be creating a 4 column interface.  Scaling works much better than in the previous version of MarcEdit, as I’m using a different layout engine.  The topics in the top – those are wide open.  These were the ideas I thought of as short cuts to either help pages or parts of the program.  In some cases, I’ll be creating “wizards” that answer each of these questions so users get pointed in the correct direction (at least, that’s the plan).  In working through this interface, you’ll notice the menus have changed.  This means that menu entries have changed a lot (location wise).  I’m going to be looking at setting up shortcut keys to everything for keyboard access, but here’s the new layout I’ve drawn up:

Tools Menu:


You’ll notice many menus now have secondary menus – MARC Processing Tools for example, now includes all items like MARCSplit, MARCJoin, etc.  This moves items down a level, and I realize that’s not what you always want to do.  I’m hoping that what will help with this is the help textbox on the right hand corner.


This is in MarcEdit 6.3.x, and is being expanded in MarcEdit 7.  If you, for example, type the words Join – you will be able to open MARCJoin directly from this window.


Say you want to merge some records…just type – merge records and you get:


An error message you don’t recognize:


Or you just want to know how to get started:


Or maybe, you’ve had a hard day and just want to look at cats:


The help system is being developed to allow for pseudo natural language searching.  To start with, it will be English only, but by the time MarcEdit 7 comes out, you should be able to write queries in about any language and hopefully get back useful responses.  I’m hoping that users gravitate towards this method of accessing commands or using the keyboard shortcuts, or the new Last Used Tools options so that the menu restructuring doesn’t cause usability issues.  But I’m definitely interested in feedback.


The plugin menu works mostly the same as before, with the primary difference being that the plugin manager now is found under plugins (probably should have always have been)


Help menu has been updated significantly.  You’ll notice that I’ve moved access to the Hex editor, shorting configuration settings (for when you get a new computer) and the restarting into 32-bit mode to allow for integration with Connexion into this menu.  You’ll also notice a new option – the troubleshooting wizard.  This is a new tool that walks through a set of questions where you can copy error messages, error numbers, etc. and the tool will point you the right direction or run the correct validation routines for you (so you don’t have to guess).  This is something that should improve with feedback, and should be in the first release that I make available to users for testing.

Also, please note that you can see that this version of MarcEdit is being built against .NET 4.6.  This means that this version officially won’t run on Windows XP.


MARCNext Window


The MARCNext and About windows have been dislodged from the main window.   This means that if you click MARCNext, it displays in its own window.  I did this because it gives me more room to grow this resource a bit easier. 

About Window:


In looking through the program, one of the main activities that I’ll be doing is hopefully addressing UI issues, doing better integration of functionality added during the 4 years MarcEdit was in the 6.x series (from a code perspective, some things are kind of bolted on, rather than integrated) and reduce redundancy.  Most folks may not know it, but MarcEdit has 4(!) different z39.50 clients, each using different code, in the program.  The Mac version has one, and it does all the things that the 4(!) in the windows version currently does.  Those are the kinds of redundancies that I’ll be addressing as I clean the tool.

Oh, and performance.  Just moving MarcEdit to the new framework has seen some improvements.  Without optimizations, I was testing breaking on a simple file I have of 120,000 random MARC records.  After multiple runs and averaging the results, I’m seeing that:

  1. MarcEdit 6.3.x: ~5975 recs / sec.
  2. MarcEdit 7.0.0 ~7213 recs / sec.

Once I start optimizing code, I’m pretty sure we’ll see this continue to improve.  The gist here is that by moving the program forward (and dropping XP support), I should be able to finally include a number of tools related to graph processing as well as see a significant speed improvement with the software. 

Finally – you’ll notice the icon has changed.  I don’t know if this will be a permanent change as I like the current MarcEdit icon (I’ve used it for almost 17 years now).  I’ve changed it while I’m developing MarcEdit 7 so that I can tell the difference between the two versions of the software while working on my laptop. 

More later…


by reeset at July 12, 2017 09:07 PM

025.431: The Dewey blog

International Dewey Users Meeting at IFLA 2017

The annual International Dewey Users Meeting (and breakfast) will be held in conjunction with the World Library and Information Conference (IFLA) in Wrocław, Poland, on Tuesday, 22 August, at 8:00-9:30 a.m. in Centennial Hall, Oval 33. Come join us to hear presentations from members of the Dewey editorial team and from Peter Werling, CEO of PANSOFT, producer of Dewey software, on:

  • Updates to the classification approved by the DDC Editorial Policy Committee
  • Tips for searching OPACs with Dewey numbers
  • Putting history information in the history box in WebDewey
  • New features in Dewey applications

We will also have the opportunity to hear from our translation partners.

Register for this and other OCLC IFLA Events.

by Rebecca at July 12, 2017 03:19 PM

July 10, 2017

Terry's Worklog

MarcEdit 7 Main Window Wireframes and other notes

I’ve been thinking about the new UI for MarcEdit 7.  I haven’t decided yet if the main window should have the ribbon or keep the menus (menus seem most appropriate for the MARC Tools and Main Window) – but the main thing I wanted to do with the new UI in MarcEdit 7, is to try and find ways to surface tools based on common questions/actions; as well as push the last used tools up.  I’ll keep the user defined buttons (I like those, I use them all the time).  One of the other things I’ll likely end up doing, presently I keep the MARCNext toolset framed in the main windows (as well as the about window). I’ll be pushing those into their own windows as the way it currently works – it complicates updates.  Also, all fonts will be updated from 8.5 point (the default) to 10.5 pt.  I’d like to set the default font to the Google Noto Fonts, but distributing the font is out of the question (the font set is 450 mbs in total — but maybe I can include something in the installer to allow users to select this font for download if they want…I’ll have to think about it).  With that, I’ll be improving the accessibility functionality so that users can continue to easily update font sizes.  In fact, I’ll be changing the window that shows when you first install to be a series of questions (rather than showing the preferences).  The questions will be:

  1. Preferred Font/Size: I’ll show current settings and sample of typography
  2. MARC Flavor:  You tell me are you using MARC21 or something else
  3. Default Z39.50/SRU servers (you’ll have a list of known servers to select from this way you have servers in the tool at the beginning)
  4. Link to the Tutorials/Help


After this, you’ll have the option to select the preferences and update all of the options.  But I’m looking for ways to make this easier so when users install MarcEdit 7 for the first time, you don’t have to look for specific settings (specifically fonts).

Feedback is welcome.



  • * Note — this wireframe is for the windows/Linux version.  Some of these concepts will make it to the MarcEdit Mac version — but I try to keep that development in line with Apples UI recommendations when possible.


by reeset at July 10, 2017 02:35 PM

MarcEdit 6.3 Windows Update

As noted this week – I’ve updated MarcEdit 6.3. The updates are as follows:


* Enhancement: Exact Match searching in the Extract, Delete Selected Records tool

* Enhancement: Exact Match searching in the Find/Replace Tool

* Enhancement: Work updates in the Linked data tool to support the new MAC proposal

* Update: Performance improvements in the editor for loading large files faster. This was planned for MarcEdit 7, but I decided to make the change so that the final versions that support XP include this work.

* Update: Context Search additions/improvements

* Bug Fixes including: API updates (streaming function for exporting tab delimited was throwing an error), merge update when using 022$a as a query index, etc.)

* Plugin-framework updates: This requires making a change to the Interfaces that allows plugins and marcedit to speak to each other. I’ll be updating all plugins as a result. Newer versions of MarcEdit will update your plugins automatically

* Accessibility changes (couple forms weren’t scaling correctly with large fonts, large resolutions – this has been corrected)

Please note *you must update any plugins* after this update. If you don’t update, you must *decline* the plugin updates when offered. I had to update the plugin framework, which includes the Interface host file. This should mean anything to anyone, but the gist is, I had to change an assembly signature so once the update happens, you will have to update your plugins. I believe I’ve updated all the plugins that are currently in use. If I’ve missed something, let me know.

Updates are available via the automatic updates or from

Questions, let me know.


by reeset at July 10, 2017 04:32 AM

July 09, 2017

Coyle's InFormation

The Work

I've been on a committee that was tasked by the Program for Cooperative Cataloging folks(*) to help them understand some of the issues around works (as defined in FRBR, RDA, BIBFRAME, etc.). There are huge complications, not the least being that we all are hard-pressed to define what a work is, much less how it should be addressed in some as-yes-unrealized future library system. Some of what I've come to understand may be obvious to you, especially if you are a cataloger who provides authority data for your own catalog or the shared environment. Still, I thought it would be good to capture these thoughts. Of course, I welcome comments and further insights on this.

There are at least four different meanings to the term work as it is being discussed in library venues.


First there is the concept that every resource embodies something that could be called a "work" and that this work is a human creation. The idea of the work probably dates back as far as the recognition that humans create things, and that those things have meaning. There is no doubt that there is "work-ness" in all created things, although prior to FRBR there was little attempt to formally define it as an aspect of bibliographic description. It entered into cataloging consciousness in the 20th century: Patrick Wilson saw works as families of resources that grow and branch with each related publication;[1] Richard Smiraglia looked at works as a function of time;[2] and Seymour Lubetzky seems to have been the first to insist on viewing the work as intellectual content separate from the physical piece.[3]

"Work Description"

Second, there is the work in the bibliographic description: the RDA cataloging rules define the attributes or data elements that make up the work description, like the names of creators and the subject matter of the resource. Catalogers include these elements in descriptive cataloging even when the work is not defined as a stand-alone entity, as in the case of doing RDA cataloging in a MARC21 record environment. Most of the description of works is not new; creators and subjects have been assigned to cataloged items for a century or more. What is changed is that conceptually these are considered to be elements of the work that is inherent in the resource that is being cataloged but not limited to the item in hand.

It is this work description that is addressed in FRBR. The FRBR document of 1998 describes the scope of its entities to be solely bibliographic,  specifically excluding authority data:
"The present study does not analyse those additional data associated with persons, corporate bodies, works, and subjects that are typically recorded only in authority records."
Notably, FRBR is silent on the question of whether the work description is unique within the catalog, which would be implied by the creation of a work authority "record".

"Work Decision"

Next there is the work decision: this is the situation when a data creator determines whether the work to be described needs a unique and unifying entry within the stated cataloging environment to bring together exemplars of the same work that may be described differently. If so, the cataloger defines the authoritative identity for the work and provides information that distinguishes that work from all other works, and that brings together all of the variations of that work. The headings ("uniform titles") that are created also serve to disambiguate expressions of the same work by adding dates, languages, and other elements of the expression. To back all of this up, the cataloger gives evidence of his/her decision, primarily what sources were consulted that support the decision.

In today's catalog, a full work decision, resulting in a work authority record, is done for only a small number of works, with the exception of musical works where such titles are created for nearly all. The need to make the work decision may vary from catalog to catalog and can depend on whether the library holds multiple expressions of the work or other works that may need clarification in the catalog. Note that there is nothing in FRBR that would indicate that every work must have a unique description, just that works should be described. However, some have assumed that the FRBR work is always a representation of a unique creation. I don't find that expressed in FRBR nor the FRBR-LRM.

"Work Entity"

Finally there is the work entity: this is a data structure that encapsulates the description of the work. This data structure could be realized in any number of different encodings, such as ISO 2709 (the underlying record structure for MARC21), RDF, XML, or JSON. The latter two can also accommodate linked data in the form of RDFXML or JSON-LD.

Here we have a complication in our current environment because the main encodings of bibliographic data, MARC21 and BIBFRAME, both differ from the work concept presented in FRBR and in the RDA cataloging rules, which follow FRBR fairly faithfully. With a few exceptions, MARC21 does not distinguish work elements from expression or manifestation elements. Encoding RDA-defined data in the MARC21 "unit record" can be seen as proof of the conceptual nature of the work (and expression and manifestation) as defined in FRBR.

BIBFRAME, the proposed replacement for MARC21, has re-imagined the bibliographic work entity, departing from the entity breakdown in FRBR by defining a BIBFRAME work entity that tends to combine elements from FRBR's work and expression. However, where FRBR claims a neat divison between the entities, with no overlapping descriptive elements, BIBFRAME 2.0 is being designed as a general bibliographic model, not an implementation of FRBR. (Whether or not BIBFRAME achieves this goal is another question.)

The diagrams in the 1998 FRBR report imply that there would be a work entity structure. However, the report also states unequivocally that it is not defining a data format.(**) In keeping with 1990's library technology, FRBR anticipates that each entity may have an identifier, but the identifier is a descriptive element (think: ISBN), not an anchor for all of the data elements of the entity (think: IRI).

As we see with the implementation of RDA cataloging in the MARC21 environment, describing a work conceptually does not require the use of a separate work "record." Whether work decisions are required for every cataloged manifestation is a cataloging decision; whether work entities are required for every work is a data design decision. That design decision should be based on the services that the system is expected to render.  The "entity" decision may or may not require any action on the part of the cataloger depending on the interface in which cataloging takes place. Just as today's systems do not store the MARC21 data as it appears on the cataloger's screen, future systems will have internal data storage formats that will surely differ from the view in the various user interfaces.

"The Upshot"

We can assume that every human-created resource has an aspect of work-ness, but this doesn't always translate well to bibliographic description nor to a work entity in bibliographic data. Past practice in relation to works differs significantly from, say, the practice in relation to agents (persons, corporate bodies) for whom one presumes that the name authority control decision is always part of the cataloging workflow. Instead, work "names" have been inconsistently developed (with exceptions, such as in music materials). It is unclear if, in the future, every work description will be assumed to have undergone a "work name authority" analysis, but even more unreliable is any assumption that can be made about whether an existing bibliographic description without a uniform title has had its "work-ness" fully examined.

This latter concern is especially evident in the transformations of current MARC21 cataloging into either RDA, BIBFRAME, or From what I have observed, the transformations do not preserve the difference between a manifestation title that does not have a formal uniform title to represent the work, and those titles that are currently coded in MARC21 fields 130, 240, or the $t of an author/title field. Instead, where a coded uniform title is not available in the MARC21 record, the manifestation title is copied to the work title element. This means that the fact that a cataloger has carefully crafted a work title for the resource is lost. Even though we may agree that the creation of work titles has been inconsistent at best, copying transcribed titles to the work title entity wherever no uniform title field is present in the MARC21 record seems to be a serious loss of information. Or perhaps I should put this as a question: in the absence of a unform title element, can we assume that the transcribed title is the appropriate work title?

To conclude, I guess I will go ahead and harp on a common nag of mine, which is that copying data from one serialization to another is not the transformation that will help us move forward. The "work" is very complex; I would feel less concerned if we had a strong and shared concept of what services we want the work to provide in the future, which should help us decide what to do with the messy legacy that we have today.


* Note that in 1877 there already was a "Co-operation committee" of the American Library Association, tasked with looking at cooperative cataloging and other tasks. That makes this a 140-year-old tradition.
"Of the standing committees, that on co-operation will probably prove the most important organ of the Association..." (see more at link)

** If you want more about what FRBR is and is not, I will recommend my book "FRBR: Before and After" (open access copy) for an in-depth analysis. If you want less, try my SWIB talk "Mistakes Have Been Made" which gets into FRBR at about 13:00, but you might enjoy the lead-up to that section.


[1] Wilson, Patrick. Two Kinds of Power : an Essay on Bibliographical Control. University of California Publications: Librarianship. Berkeley, Los Angeles, London: University of California Press, 1978.
[2] Smiraglia, Richard. The Nature of “a Work”; Implications for the Organization of Knowledge. Lanham: Scarecrow Press, 2001.
[3] Lubetzky, Seymour. Principles of Cataloging. Final report. Phase I. In: Seymour Lubtezky: writings on the classical art of cataloging. Edited by Elaine Svenonius and Dorothy McGarry. Englewood, CO, Libraries Unlimited. 2001

by Karen Coyle ( at July 09, 2017 07:20 PM

July 07, 2017

025.431: The Dewey blog

Dewey Breakfast Recap

The Dewey team had a successful ALA Annual. Thanks to those of you who joined us Saturday morning for a hearty Dewey Update Breakfast! Attendees heard about updates to the DDC approved at EPC Meeting 140, were taught some tips for searching Dewey numbers in WorldCat, and learned about changes to the display of history information in WebDewey.

I started off presenting the highlights from EPC Meeting 140, discussing approved exhibits on topics such as sustainability, the West Bank and Gaza strip, Nilo-Saharan languages and peoples, computer science, and exercises from martial arts. Make sure to read the previous blog post for more detail on these and other matters discussed at the meeting.

Next, Juli Beall demonstrated some strategies for searching by Dewey numbers at, either alone or in conjunction with other search terms. The site doesn’t make explicit how to search on Dewey numbers, but you can use the index label dd: to do so (e.g., dd:025.431). An asterisk (*) can be used to truncate terms, so dd:616* will retrieve everything classed in the hierarchy of 616 Diseases, although it could be more helpful to narrow that search using a subject term ( uses a Boolean “AND” between terms unless otherwise specified). Juli’s example of su:diabetes dd:616*, for example, retrieved everything about diabetes in that hierarchy.

Finally, I presented examples of cases where we’ve changed how history information displays in WebDewey. Many of those changes are live now. We continue to implement these changes throughout the schedules, and we’ll blog about them in more detail later. Thanks to all who helped make this a great ALA Annual!

by Alex at July 07, 2017 07:27 PM

Terry's Worklog

MarcEdit 7 Update Notes

I’ll be officially cutting the new branch of MarcEdit 7 for all the code in the project following the next release of MarcEdit 6.3.x.  The first thing I’ll be doing is updating all the dependencies to the new version of .NET 4.6.x essentially ending Windows XP support for MarcEdit 7.  I’ll be updating namespaces, and prepping the files for a first alpha release.  The very early releases will be preview releases for those that code against MarcEdit interested in testing the new namespaces, and for IT folks interested in testing the new installers, as this will also be the first version to include installers that can provide installation either in the current, traditional setup, or as a user.  The way I’ll be providing installation will be much the same way google does it.  Rather than selecting an download, users will download a single installer (likely an exe).  The installer will ask the user if you want to install for everyone (must be an admin) or just for the current user.  If you pick everyone, it will check your operating system, and download the appropriate installer.  This installer will require that you authenticate as an admin.  If you choose just the current user, it will check your operating system and will download the installer to install just within your user space (non-admin).  From the users perspective, the program will work exactly the same.  I’ll also include some detailed instructions for IT administrators that want to download the MSI files directly – this way folks that manage software via software distribution tools can still do that.  Additionally, to make management easier for IT folks, each version of MarcEdit will have its own SKU (or product code).  This is important when managing software distribution and one of the reasons most IT folks hate the way Google manages Chrome (all versions share the same ID). 

Once MarcEdit 7 alpha is available, I’ll likely post updates to MarcEdit 6.3.x and MarcEdit 7 concurrently until about Sept. 2017.  At that point, I’ll freeze 6.3.x.  That will be the final version supporting XP, and then will focus on updating MarcEdit 7.  Additionally, I’ll likely be posting a few wireframes of how I envision changing MarcEdit 7’s interface.  I will be updating the Main Window, the MARC Tools and the MarcEditor.  In fact, the MarcEditor will likely shift from the current menus, to the more traditional ribbon interface that you now see in most Windows applications, while the MacOS update will continue to follow Mac UI design guidelines.

Questions, let me know.


by reeset at July 07, 2017 01:51 PM