Planet Cataloging

January 18, 2018

Terry's Worklog

MarcEdit 7: The great [Normalization] escape

working out some thoughts here — this will change as I continue working through some of these issues.

If you follow the MarcEdit development, you’ll know that last week, I posted a question in a number of venues about the affects of Unicode Normalization and its potential impacts for our community.  I’ve been doing a little bit of work in MarcEdit, having a number of discussions with vendors and folks that work with normalizations regularly – and have started to come up with a plan.  But I think there is a teaching opportunity here as well, an opportunity to discuss how we find ourselves having to deal with this particular problem, where the issue is rooted, and the impacts that I see right now in ILS systems and for users of tools like MarcEdit.  This isn’t going to be an exhaustive discussion, but hopefully it helps folks understand a little bit more what’s going on, and why this needs to be addressed.


So, let’s start at the beginning.  What exactly are Unicode normalizations, and why is this something that we even need to care about….

Unicode Normalizations are, in my opinion, largely an artifact of our (the computing industry’s) transition from a non-Unicode world to Unicode, especially in the way that the extended Latin character sets ended up being supported.

So, let’s talk about character sets and code pages.  Character sets define the language that is utilized to represent a specific set of data.  Within the operating system and programming languages, these character sets are represented as code pages. For example, Windows provides support for the following code pages:    Essentially, code pages are lists of numeric values that tell the computer how to map a  representation of a letter to a specific byte.  So, let’s use a simple example, “A”.  In ASCII and UTF8 (and other) code pages, the A that we read, is actually represented as a byte of data.  This byte is 0x41.  When the browser (or word processor) sees this value, it checks the value against the defined code page, and then provides the appropriate value from the font being utilized.  This is why, in some fonts, some characters will be represented as a “?” or a block.  These represent bytes or byte sequences that may (or may not) be defined within the code page, but are not available in the font.

Prior to Unicode implementations, most languages had their own code pages.  In Windows, the US. English code page would default to 1252.  In Europe, if ISO-8859 was utilized, the code page would default to  28591.  In China, the code page could be one of many.  Maybe “Big-5”, or code page 950, or what is referred to as Simplified Chinese, or code page 936.  The gist here, is that prior to the Unicode standard, languages were represented by different values, and the keyboards, fonts, systems – would take the information about a specific code page and interpret the data so that it could be read.  Today, this is why catalogers may still encounter confusion if they get records from Asia, where the vendor or organization makes use of “Big-5” as the encoding.  When they open the data in their catalog (or editor), the data will be jumbled.  This is because MARC doesn’t include information about the record code page – rather, it defines values as Unicode, or something else.  So, it is on catalogers and systems to know the character set being utilized, and utilized tools to convert the byte points from a character encoding that they might not be able to use, to one that is friendly for their systems.

So, let’s get back to this idea of Normalization Forms.  My guess is that much of the Normalization mess that we find ourselves in is related to ISO-8859.  This code page and standard has been widely utilized in European countries, and provides a standard method of representing extended Latinate characters [those between 129-255], though, Normalizations also affect other languages as well.  Essentially, the unicode specification included ISO-8859 to ease the transition, but also provide new, composed code points for many of the characters.  And Normalizations were born.

Unicode Normalizations, very basically, define how characters are represented.  There are 4 primary normalization forms that I think we need to care about in libraries.  These are (

  1. NFC – The canonical normalization, which will replace decomposed characters with composed code points.
  2. NFD – The canonical normalization, but in which data is fully decomposed
  3. NFKC – A normalization that utilizes a full compatibility decomposition, followed by the replacement of sequences with their primary composites, if possible.
  4. NFKD – A normalization that utilizes a full compatibility decomposition.


Practically, what does this mean.  Well, it means that a value like: é can be represented in multiple ways.  In fact, this is a good example of the problems that having differing Unicode Normalization Forms is having in the library community.  In the NFC and NFKC notation, this value é is represented by a single code point, that represents the letter and its diacritic fully.  In the NFD and NFKD notations, this character is represented by code points that correspond to the “e” and the diacritic separately.  This has definite implications, as composed characters make indexing of data with diacritical marks easier, whereas, decomposed characters must be composed to index correctly.

And how does this affect the library community.  Well, we have this made up character encoding known as MARC8 (  MARC8 is a library specific character set (doesn’t have a code page value, so all rendering is done by applications the understand MARC8) that has no equivalent outside of the library.  Like many character sets with a need to represent wide-characters (those with diacritics), MARC8 represented characters with diacritics by utilizing decomposed characters (though, this decomposition was MARC8 specific).  For librarians, this matters because the U.S. Library of Congress, when providing instructions on support for Unicode in MARC records, provided for the ability to round-trip between MARC8 and UTF8 and back (  This round-tripability comes at a cost, and that cost is that data, to be in sync with the recommendations, should only be provided in the NFKD notation.  This has implications however, as current generation operating systems are are generally implemented utilizing NFC as the internal representation for string data, and for programmers, who have to navigate challenges within their languages, as in most cases, language functions that deal with concepts like in-string searching or regular expressions, are done using settings that make them culturally aware (i.e., allows searching across data in different normalizations), but the replacement and manipulation of that data is almost always done using ordinal (binary) matching, which means that data using different normalization forms are not compatible.  And quite honestly, this is confusing the hell out of metadata people.  Using our “é” character as an example – a user may be able to open a program or work in a programming language, and find this value regardless of the underlying data normalization, but when it comes to making changes – the data will need to match the underlying normalization; otherwise, no changes are actually made.  And if you are a user that is just looking at the data on the screen (without the ability to see the underlying binary data or without knowledge of what normalization is being used), you’d rightly start to wonder, why didn’t the changes complete.  This is the legacy that round-trip support for MARC-8 has left us within the library community, and the implications of having data moving fluidly between different normalizations is having real consequences today.

Had We Listened to Gandalf

Can holding on with caption -- Run you fool

The ability to round-trip data from MARC-8 to UTF8 and back seemed like such a good idea at the time.  And the specifications that the U.S. Library of Congress lays out were/are easy enough  to understand and implement.  But we should have known that it was going to be easy, and that in creating this kind of backward compatibility, we were just looking for trouble down the road.

Probably the first indication that this was going to be problematic was the use of Numeric Character Reference (NRC) form to represent characters that exist outside of the MARC-8 repertoire.  Once UTF8 became allowed and a standard for representation of bibliographic data, the frequency in which MARC-8 records began to be littered by NRC representations (i.e., &#xXXXX; notation) increased exponentially, as too did the number of questions on the MarcEdit list for ways to find better substitutions for that data – primarily, because most ILS providers never fully adopted support for NRC encoded data.  Looking back now, what is interesting, is that many of the questioned related to the substitution of NRC notations can be traced to the utilization of NFC normalized data and the rise in the presence of “smart” characters generated in our text editing systems.  Looking at the MarcEdit archive, I can find multiple entries from users looking to replace NRC data elements that exist, simply because these elements represented the composed data points, and were thus, in compatible with MARC-8.  So, we probably should have seen this coming…and quite honestly, should have made a break.  Data created in UTF8 will almost always result in some level of data change when being converted back to MARC8…we should probably have just accepted that was a likely outcome, and not worried about the importance of round-tripability.

But….we have, and did, and now we have to find a way to make the data that we have, within the limitations of our systems, work.   But what are the limitations or consequences when thinking about the normalization form of data?  The data should render the same, right?  The data should search the same, right?  The data should export the same, right?  The answer to those questions, is that this shouldn’t matter, if the local system was standardizing the normalization of data as it is added or exported from the system, but in practice, it appears that few (if any systems) do that, so the normalization form of the data can have significant impacts on what the user sees, can discovery, or can export.

What the user sees

Probably the most perplexing issues that arise related to the normalization form of data, arise in how the data is rendered to the user.  While normalization forms have a binary difference, the system should be able to accommodate these differences aren’t visible to the user.  Throughout this document, I’ve been using different normalized forms of the letter “é”, but if the browser and the operating system are working like they are suppose to – you – as the reader shouldn’t be aware of these differences.  But we know that this isn’t always the case.  Here’s one such example:


The top set of data represents the data seen in an ILS prior to export.  The bottom shows the data once reimported, but the Normalization form had shifted from NFC to NFKD.  The interface being presented to the user has chosen to represent the data as bytes to flag that the data is represented as a decomposed character.  But this is jarring to the user as they probably should care.

The above example is actually not as uncommon as you might think.  In experimenting with a variety of ILS systems, changes in Normalization form can often have unintended effects for the user…and since it is impossible to know which normalization form is utilized without looking at the data at the binary level – how would one know when changes to records will result in significant changes to the user experience.

The short answer, is you can’t.  I started to wonder how OCLC treats Unicode data, and if internally, OCLC normalized the data coming into and out of its system.  And the answer is no – as long as the data is valid, the characters, in whatever normalization, is accepted into the system.  To test this, I made changes to the following record:  First, I was interested if any normalization was happening when interacting with OCLC’s Metadata API, and secondly, I was wondering if data brought in with different normalizations would impact searching of the resource.  And, the answers to these questions are interesting.  First, I wanted to confirm that OCLC accepted data in any normalization provided (as was relayed to me by OCLC), and indeed that is the case.  OCLC doesn’t do any normalization, as far as I can tell, of data going into the system.  This means that a user could download a master record, and make no other change to the record but updating the normalized form, and replace that record.  From the users perspective, the change wouldn’t be noticeable – but at the data level, the changes could be profound.  Given the variety of differences in how different ILS system utilize data in the different Unicode normalization forms, this likely explains some of the “diacritic display issue” questions that periodically make their way on the MarcEdit listserv.  Users are expecting that their data is compatible with their system because the OCLC data downloaded is in UTF8 and their system supports UTF8.  However, unknown to the cataloger, the reliance of data existing in a specific normalized form may cause issues.

The second question I was interested in, as it related to OCLC, was indexing.  Would a difference in normalization form cause indexing issues.  We know that in some systems, it does.  And for many European users, I have long recommended using MarcEdit’s normalization options to ensure that data converted to UTF8 utilizes the NFC normalization – as it enables local systems to index data correctly (i.e., index the letter + diacritic, rather than the letter then diacritic, then other data).  I was wondering if OCLC would demonstrate this kind of indexing behavior, but curiously, I found OCLC had trouble indexing any data with diacritical values.  Since I’m sure that isn’t the expected result, I’ve reached out to see exactly what is the expectation for the user.

Indexing implications

As noted above, for years now, I’ve recommended that users who utilize Koha as their ILS system configure MarcEdit to utilize the NFC normalization as the standard data output when converting data between MARC-8 and UTF-8.  The reason for this has been to ensure that data indexes correctly rather than flatly.  But maybe this recommendation should have been more broadly.  While  I didn’t look at every system, one common aspect of many of the systems that I did look at show, is that data normalized as NFKD tends to not index a representation of data as diacritical value.   They either normalize all diacritical data way, or they index the data as it appears in the binary – so for example, a record like this: évery would index as e_acute_very, i.e., the indexed value would be a plan “e”, but if the data appeared in NFC notation, the data would be indexed as an é (the combined character) allowing users to search for data using the letter + diacritic.  How does your system index its data?  It’s a question I’m asking today, and wondering how much of an impact normalization form has without the ILS, as well as outside the ILS (as we reuse data in a variety of contexts).  Since each system may make different assumptions and indexing decisions based on UTF8 data presented – its an interesting question to consider.

Export implications

The best case scenario is that a system would export data the same way that its represented in the system.  This is what OCLC does – and while it likely helps to exasperate some of the problems I see upstream with systems that may look for specific normalizations, its regular and expected.  Is this behavior the rule?  Unfortunately it is not.  I see many examples where data is altered on export, and often times, the diacritic related, the issue can be traced to the normalized form of the original data.  Again, the system probably should care which form is provided (in a perfect work), but if the system is implementing the MARC specification as written (see LC guidance above), then developing operations around the expectation of NFKD formed would likely led to complications.  But again, you’d likely never know until you tried to take the data out of the system.

Thinking about this in MarcEdit

So if you’ve stayed with me this long, you may be wondering if there is anything that we can do about the problems, short of getting everyone to agree that we all normalize our data a certain way (good luck).  In MarcEdit, I’ve been looking at addressing this question in order to address the following problems that I get asked about regularly:

  1. When I try to replace x diacritic, I can find the instances, but when I try to replace, only some (or none) are replaced
  2. When I import my data back into my system, diacritics are decomposed
  3. How can I ensure my records can index diacritics correctly


The first two issues are ones that come up periodically, and are especially confusing to users because the differences in data is at a binary level – so hard to see.  The last issue, MarcEdit has provided a 1/2 answer for.  It has always provided a way to set normalization when converted data to UTF8, but once there, it assumes that the user will provide the data in the form that they require (I’m realizing, this is a bad assumption).

To address this problem, I’m providing a method in MarcEdit that will allow the user to force the normalization of UTF8 data into a specific normalization, and will enable the application to support search and replace of data, regardless of the normalized form of a character that a user might us.  This will show up in the MarcEdit preferences.  Under the MARCEngine settings, there are options related to data normalization.  These show up as:


MarcEdit has included support for sometime to set normalization when compiling data.  But this doesn’t solve the problem when trying to edit, search, etc. records in the MarcEditor or within the other areas of the program.  So, a new option will be available – Enforce Defined Normalization.  This will enable the application to save data in the preferred normalization and also force all user submitted data through a wrapper that will enable edit operations to be completed, regardless of the normalized form a user may use when searching for data or the underlying normalization form of the individual records.  Internally, MarcEdit will make this process invisible, but the output created will be records that place all UTF8 characters into the specified normalization.  This seems to be a good option, and its very unlikely that tomorrow, the systems that we use will suddenly all start to use UTF8 data the same way – and taking this approach, they don’t have to.  MarcEdit will work as a bridge to take data in any UTF8 normalization, and will ensure that the data outputted all meets the criteria specified for the user.

Sounds good – I think so.  But it makes me a little nervous as well.  Why – because OCLC takes any data provided to it.  In theory, a record could switch normalizations multiple times, if users pulled data down, edited them using this option, and uploaded the data back to the database.  Does this matter?  Will it cause unforeseen issues?  I don’t know – I’m asking OCLC.  I also worry that allowing users to specify normalization form could have cascading issues when it comes to record sharing.  No everyone uses MarcEdit (nor should they) and its hard to know what impact this makes on other coding tools, etc.  This is why this function won’t be enabled by default – but will need to be turned on by the user – as I continue to inquire and have conversations about the larger implications of this work.  The short answer is that this is a pain point, and a problem that needs to be addressed somehow.  I see too many questions and too many records where the normalization form of the data plays a role in providing confusing data to the user, confusing data to the cataloger, or difficulties in reusing or sharing the data with other systems/processes.  At the same time, this feels like a band-aid fix until we reach a point in the evolution of our systems and metadata that we can free ourselves from MARC-8, and begin to think only about our data in UTF8.


So what should folks take away from all this?  Let’s start with the obvious.  Just because your data is in UTF8, doesn’t mean that its the same as my data in UTF8.  Normalization forms of data, a tool that was initially used to ease the transition of data from non-Unicode to Unicode data, can have other implications as well.  The information that I’ve provided, are just examples of challenges that make there way to me due to my work with MarcEdit.  I’m sure other folks have had different experiences…and I’d love to hear these if you want to provide them below.



by reeset at January 18, 2018 07:12 PM


Three tools for building better bridges


The theme for our upcoming Resource Sharing Conference in Jacksonville, Florida, is “Bridging Communities.” I think that’s a great way to describe the work that resource sharing librarians do in an inspiring way—we create paths to get people to the information they need, often crossing obstacles and boundaries that are otherwise impassable. In many cases, we build those bridges using unique information literacy talents that librarians bring to the table.

Technology, data, and people

As we reviewed the conference topics with the Program Committee, we thought about the different types of solutions that resource sharing librarians bring to the table. What became clear is that different situations will call for different tools in order to get from where you are to where your community needs you to be.

  • Access to the right technology. Early in the computer revolution, there was legitimate concern about the “digital divide.” At first, that meant having access to computers at all and, later, to the internet. Libraries often helped bridge those divides for users—and still do. Today, though, more people than ever have access to computers (or smartphones) and the web. But they may not understand what information is available to them, how to find it, and how to get their hands on it. We have more ways than ever before to help our users connect with the knowledge they need to move forward. Getting the right technology in place is important for both our users and for us as librarians. A few of the topics we’ll hear about in this area include managing copyright in an ILL setting, using resource sharing services with special collections, and document delivery for graduate students.
  • Data that informs change. We’re really excited about how many presentations were submitted that reference how data is being used to inform change. The common thread being that change management can be designed directly into data collection programs. Several elements of the IDS Project will be discussed along those lines. We’ll also hear from your colleagues about data tools that optimize workflows, data visualization, the validity of ILL statistics, and variations in reporting metrics.
  • The personal touch. In some cases, even the right technology and data need a bit of friendly help. In many cases, we find that resource sharing librarians make a real impact by providing a personal touch for users’ most complex challenges. We learn to listen carefully, ask probing questions, and really try to understand how to help. Along these lines, we’ll hear presentations about providing services for patrons with disabilities, helping patrons identify available resources, and tips for difficult requests.

How are you using ILL to build bridges to your community?
Click To Tweet

I’m also thrilled that our keynote speaker will address this last concept.

Celeste Headlee is the author of the book, We Need To Talk – How to Have Conversations That Matter. She is the Executive Producer and host of On Second Thought at Georgia Public Broadcasting in Atlanta and is a former anchor of NPR shows, including Tell Me More, Talk of the Nation, All Things Considered, and Weekend Edition. Her TEDx Talk, “10 ways to have a better conversation,” was listed as one of the most watched TED Talks in 2016 by CNBC.

Celeste will help us think about how, in an age of short bursts of text and video, we can concentrate on having real, meaningful conversations that help move our personal and professional lives forward. That’s a skill that resource sharing librarians rely on and one that we can all develop more fully.

I’m looking forward to seeing you at the conference in March and listening to your ideas. Our experiences are the resource we can share with each other to get better at building better bridges.

The post Three tools for building better bridges appeared first on OCLC Next.

by Katie Birch at January 18, 2018 04:48 PM

January 17, 2018

TSLL TechScans (Technical Services Law Librarians)

Librarians to play increasing role in OER

A survey of more than 2700 faculty members shows that there is an increase of instructors using OER over traditional textbooks. An article in Inside Higher Ed reports on the survey findings:

The "Opening the Textbook" survey, published by the Babson Survey Research Group today, reports that the number of faculty members at two- and four-year institutions using OER as textbooks has nearly doubled in the last year -- from 5 percent in 2015-16 to 9 percent in 2016-17.Awareness of OER -- openly licensed and freely accessible teaching and learning materials -- has also increased. Twenty-nine percent of faculty described themselves as "aware" or "very aware" of OER this year, up from 25 percent last year and 20 percent the year before. The proportion that reported they had never heard of OER fell from 66 percent in 2014-15 to 56 percent this year.
However as Jeff Seaman, co-director of the Babson Survey Research Group, mentioned in the article, awareness of OER is still low and there are additional barriers such as finding and evaluating currency of materials.

Raising awareness, finding resources, and updating materials are all very familiar responsibilities for librarians. That is whNicole Allen, the director of open education for SPARC, a coalition that supports open policies and practices in education and research, predicts that librarians will "play an increasingly important role in helping faculty members find and evaluate OER content."

The comments following the article further press this point. Librarians are natural resource experts to faculty. One librarian mentions LibGuides as a tool to educate on open sources. Another librarian mentions that "incentivizing for faculty is key."

The full article is available at

by (Rachel Purcell) at January 17, 2018 05:47 PM

January 12, 2018

Terry's Worklog

MarcEdit Unicode Question [also posted on the listserv]

** This was posted on the listserv, but I’m putting this out there broadly **
** Updated to include a video demonstrating how Normalization currently impacts users **

Video demonstrating the question at hand:


So, I have an odd unicode question and I’m looking for some feedback.  I had someone working with MarcEdit and looking for é.  This (and a few other characters) represent some special problems when doing replacements because they can be represented by multiple codepoints.  They can be represented as a letter + diacritic (like you’d find in MARC8) or they can be represented as a single code point.

Here’s the rub.  In Windows 10 — if you do a find and replace using either type of normalization (.NET supports 4 major normalizations), the program will find the string, and replace the data.  The problem is that it replaces the data in the normalization that is presented — meaning, that, if in your file, you have data where your system provides multiple codepoints (the traditional standard with MARC21 — what is called the KD normalization) and you do a search where the replacement using a single code point, the replacement will replace the multiple code points with a single code point.  This is apparently, a Windows 10 behavior.  But I find this behaves differently on Mac system (and linux) — which is problematic and confusing.
At the same time, most folks don’t realize that characters like é have multiple iterations, and MarcEdit can find them but won’t replace them unless they are ordinally equivalent (unless you do a case insensitive search).  So, the tool may tell you it’s found fields with this value, but that when the replacement happens, it reports replacements having been made, but no data is actually changed (because ordinally, they are *not* the same).
So, I’ve been thinking about this.  There is something I could do.  In the preferences, I allow users to define which unicode normalization they want to use when converting data to Unicode.  This value only is used by the MarcEngine.  However, I could extend this to the editing functions.  Using this method, I could for data that comes through the search to conform to the desired normalization — but, you still would have times, again, where you are looking for data say that is normalized in Form C, you’ve told me you want all data in Form KD, and so again, é may not be found because again, ordinally they are not correct.
The other option — and this seems like the least confusing, but it has other impacts, would be to modify the functions so that the tool tests the Find string and based on the data present, normalizes all data so that it matches that normalization.  This way, replacements would always happen appropriately.  Of course, this means that if your data started in KD notation, it may end up (would likely end up, if you enter these diacritics from a keyboard) in C notation.  I’m not sure what the impact would be for ILS systems, as they may expect one notation, and get another.  They should support all Unicode notations, but given that MARC21 assumes KD notation, they may be lazy and default to that set.  To prevent normalization switching, I could have the program on save, ensure that all unicode data matches the encoding specified in the preferences.  That would be possible — it comes with a small speed costs — probably not a big one — but I’d have to see what the trade off would be.
I’m bringing this up because on Windows 10 — it looks as those the Replace functionality in the system is doing these normalizations automatically.  From the users perspective, this is likely desired, but from a final output — that’s harder to say.  And since you’d never be able to tell if the Normalization has changed unless you looked at the data under a hex editor (because honestly, it shouldn’t matter, but again, if your ILS only supported a single normalization, it very much would) — this could be a problem.
My initial inclination, given that Windows 10 appears to be doing normalization on the fly allowing users to search and replace é in multiple normalizations — is to potentially normalizing all data that is recognized as UTF8, which would allow me to filter all strings going into the system, and then when saving, push out the data using the normalization that was requested.  But then, I’m not sure if this is still a big issue, or, if knowing that the data is in single or multiple code points (from a find a replace persepctive) is actually desired.
So, I’m pushing this question out to the community, especially as UTF8 is becoming the rule, and not the exception.

by reeset at January 12, 2018 10:37 PM

January 11, 2018

Terry's Worklog

MarcEdit Updates (All versions)

I’ve posted updates for all versions of MarcEdit, including MarcEdit MacOS 3.

MarcEdit 7 (Windows/Linux) changelog:
  • Bug Fix: Export Settings: Export was capturing both MarcEdit 6.x and MarcEdit 7.x data.
  • Enhancement: Task Management: added some continued refinements to improve speed and processing
  • Bug Fix: OCLC Integration: Corrected an issue occuring when trying to post bib records using previous profiles.
  • Enhancement: Linked Data XML Rules File Editor completed
  • Enhancement: Linked Data Framework: Formal support for local linked data triple stores for resolution

One of the largest enhancements is the updated editor to the Linked Data Rules File and the Linked Data Framework. You can hear more about these updates here:

MarcEdit MacOS 3:

Today also marks the availability of MarcEdit MacOS 3. You can read about the update here: MarcEdit MacOS 3 has Arrived!

If you have questions, please let me know.


by reeset at January 11, 2018 05:35 AM

MarcEdit MacOS 3 has Arrived!

MarcEdit MacOS 3 is the latest branch of the MarcEdit 7 family. MarcEdit MacOS 3 represents the next generational update for MarcEdit on the Mac and is functionally equivalent to MarcEdit 7. MarcEdit MacOS 3 introduces the following features:

  1. Startup Wizard
  2. Clustering Tools
  3. New Linked Data Framework
  4. New Task Management and Task Processing
  5. Task Broker
  6. OCLC Integration with OCLC Profiles
  7. OCLC Integration and search in the MarcEditor
  8. New Global Editing Tools
  9. Updated UI
  10. More


There are also a couple things that are currently missing that I’ll be filling in over the next couple of weeks. Presently, the following elements are missing in the MacOS version:

  1. OCLC Downloader
  2. OCLC Bib Uploader (local and non-local)
  3. OCLC Holdings update (update for profiles)
  4. Task Processing Updates
  5. Need to update Editor Functions
    1. Dedup tool – Add/Delete Function
    2. Move tool — Copy Field Function
    3. RDA Helper — 040 $b language
    4. Edit Shortcuts — generate paired ISBN-13
    5. Replace Function — Exact word match
    6. Extract/Delete Selected Records — Exact word match
  6. Connect the search dropdown
    1. Add to the MARC Tools Window
    2. Add to the MarcEditor Window
    3. Connect to the Main Window
  7. Update Configuration information
  8. XML Profiler
  9. Linked Data File Editor
  10. Startup Wizard

Rather than hold the update till these elements are completed, I’m making the MarcEdit MacOS version available now so that users can be testing and interacting with the tooling, and I’ll finish adding these remaining elements to the application. Once completed, all versions of MarcEdit will share the same functionality, save for elements that rely on technology or practices tied to a specific operating system.

Updated UI

The MarcEdit MacOS 3 introduces a new UI. While the UI is still reflective of MacOS best practices, it also shares many of the design elements developed as part of MarcEdit 7. This includes new elements like the StartUp wizard with Fluffy Install agent:


The Setup Wizard provides users the ability to customize various application settings, as well as import previous settings from earlier versions of MarcEdit.


Updates to the UI

New Clustering tools

MarcEdit MacOS 3 provides MacOS users more tools, more help, more speed…it gives you more, so you can do more.


Download the latest version of MarcEdit MacOS 3 from the downloads page at:


by reeset at January 11, 2018 05:01 AM

January 08, 2018

025.431: The Dewey blog

Numbers with Two Sets of Standard Subdivisions

From time to time you may have run across a Dewey number with two sets of standard subdivisions. For example:

  • 470.01–470.09 Standard subdivisions of Italic languages vs. 470.1–470.9 Standard subdivisions of Latin
  • 646.7001–646.7009 Standard subdivisions of management of personal and family life vs. 646.701–646.709 Standard subdivisions of grooming
  • 947.0001–947.0009 Standard subdivisions of eastern Europe vs. 947.001–947.009 Standard subdivisions of Russia

You may be surprised to find out there are more than three dozen such standard subdivision pairs in Dewey. Most of them are found in the 400s, 800s, and 900s.

Up to this time, it has not been possible to distinguish between the members of these pairs in WebDewey’s number building engine. If you were adding standard subdivisions at 646.7, for example, the number building engine automatically assumed you wanted 646.7001–646.7009 Standard subdivisions of management of personal and family life because that span came first. If you wanted to use 646.701–646.709 Standard subdivisions of grooming instead, you would have to use Edit Local and the record for the resulting number would not show how the number should have been built, were it possible to build it correctly.

But now—ta da!—the number building engine will allow you to distinguish between the two sets of standard subdivisions. In these cases only, at the appropriate point in your number building, click and add the standard subdivision span you want. You will then be taken to the appropriate standard subdivision span. When you click and add a standard subdivision notation from this span, it will be added with the correct number of zeros.

Let’s consider three examples—one from the 400s, one from the 800s, and one from the 900s.

Example 1. How can we build 470.143 Semantics of Latin? We go directly to 470.1–470.9 and click Start:


This takes us to Table 4 Subdivisions of Individual Languages and Language Families, based on the note that notation from Table 1 is to be used as modified under T4—01–09:


From there we navigate to, and then add, T4—0143 Semantics:


This allows us to build the correct number:


When we click Save, we generate a correct and informative MARC 765 field (you can see the 765 fields in built number records by clicking MARC at the top of the WebDewey screen):

765 0# $b 47 $a 470.1 $c 470.9 $z 4 $s 0143 $u 470.143

Example 2. Our investigation here will focus on 840.01–840.09 Standard subdivisions of literatures of Romance languages vs. 840.1–840.9 Standard subdivisions; collections in more than one form; history, description, critical appraisal of works in more than one form of French literature. If we want to build 840.03 for encyclopedias of Romance language literatures, we navigate to 840.01–840.09 and click Start:

This takes us to Table 1 Standard Subdivisions:


Clicking T1—03, and then Add, gives us the desired number:


When we save this number, we get the following 765 field:

765 0# $b 84 $a 840.01 $c 840.09 $f 0 $z 1 $s 03 $u 840.03

What if instead we wanted to build the number for encyclopedias of French-language literature? This time we start with 840.1–840.9, which takes us to Table 3B—01–07 Standard subdivisions:


Since the standard subdivision we want to add is not modified under Table 3B, we navigate to T1—03 and add our standard subdivision from there:


When we save this number, we get the following 765 field:

765 0# $b 840 $a 840.1 $c 840.9 $z 1 $r 0 $s 3 $u 840.3

But if we want to build 840.8 or 840.9 or any of their subdivisions, we should navigate to the appropriate notation within the context of Table 3B and add that notation. For example, to build the number for collections of French literary texts about holidays we navigate to T3B—0801–0809 and click Add:


Following the directions there, we navigate to T3C—334 Holidays and add that notation:


This results in building the number 840.80334:


When we save this number, we get the following 765 fields:

765 0# $b 840.8 $f 0 $z 3B $a 0801 $c 0809 $z 3C $s 334 $u 840.80334

765 0# $b 840 $a 840.1 $c 840.9 $z 3B $r 0 $s 8 $u 840.8

Example 3. Now we look at building a standard subdivision number for Germany, from the span under 943.001–943.009, which we distinguish from standard subdivisions of central Europe from the span under 943.0001–943.0009. More specifically, we wish to build the number for the history of Turks in Germany. We begin by clicking Start at 943.001-943.009:


This takes us directly to the Table 2 notation for Germany, which we add:


This takes us, in turn, to the standard subdivisions in the add table under 930–990:


From here we add in turn 930-990:0041-0049, T5—943, and T6—9435, to give us 943.0049435:


When saved, the resulting 765s are:

765 0#  $b 943.004943 $z 5 $a 943 $z 6 $r 943 $s 5 $u 943.0049435

765 0#  $b 943.004 $a 930 $c 990 $w 930 $c 990 $y 1 $a 0041 $c 0049 $z 5 $s 943 $u 943.004943

765 0#  $b 943 $a 943.001 $c 943.009 $w 930 $c 990 $y 1 $t 004 $u 943.004

765 0#  $b 9 $a 943.001 $c 943.009 $z 2 $s 43 $u 943

Unfortunately, we are aware of a problematic set of circumstances, namely, when a 900 number is being built using the add table under 930–990 and the standard subdivision range with fewer zeros applies. There are three subcases. First, if the standard subdivision being added is special notation in the add table under 930–990 and or if it is built using an add note in that add table, everything should be fine; for example, consider what we have just seen in building the number for the history of Turks in Germany, which uses special notation 930–990:0041–0049. (Recall that standard subdivisions of central Europe are on three zeros at 943.0001–943.0009, thus making standard subdivisions of Germany at 943.001–943.009 the standard subdivision range with fewer zeros.)

Second, but what if we wanted to build the number for an encyclopedia of German history, i.e., 943.003, where notation 930–990:003 Dictionaries, encyclopedias, concordances is found in the add table, but it is not special notation, nor is it built using an add note in that add table? We begin by clicking Start at 943.001-943.009 and then add T2—43. After this we are given the chance to add from 930–990:001–009. If we then click 930–990:003, we get the correct number, but the 765 field will (appropriately enough) reflect that the 003 came from the add table under 930–990, when its source should be Table 1. (For help in determining when to use standard subdivisions notation in an add table and when to go straight to Table 1, see this previous blog post). We can get the correct number, but only at the expense of an incorrect 765 field.

The third subcase occurs when the standard subdivision being added is not special notation in the add table under 930–990, is not built using an add note in that add table, and doesn’t display as a single notation in that add table. For example, if we wanted to build the number for a journal of German history, we begin by clicking Start at 943.001-943.009 and then add T2—43. After this we are given the chance to add from 930–990:001–009. But the notation for journals occurs only as part of a range, 930–990:005–006. Under these circumstances, we have no choice but to navigate to T1—05 Serial publications. When we click and add T1—05, the result will include an extra zero, which must be corrected using Edit Local. This subcase also includes all the subordinate Table 1 notations not explicitly listed in the add table under 930–990 (e.g., T1—0202 Synopses and outlines, T1—083 Young people). Again, the only option is to navigate to the desired notation in Table 1 and to correct the number of zeros in the resulting number using Edit Local.

by Rebecca at January 08, 2018 06:38 PM