Apr 042014

One of the new functions in MarcEdit is the inclusion of a Field Edit Data function.  For the most part, batch edits on field data has been handled primarily via regular expressions using the traditional replace function.  For example, if I had the following field:

=999  \\$zdata1$ydata2

And I wanted to swap the subfield order, I’d use a regular expression in the Replace function and construct the following:
Find: (=999.{4})(\$z.*[^$])(\$y.*)
Replace: $1$3$2

This works well – when needing to do advanced edits.  The problem was that any field edits that didn’t fit into the Edit Subfield tool needed to be done as a regular expression.  In an effort to simplify this process, I’ve introduced an Edit Field Data tool.


This tool exposes the data, following the indicators, for edit.  So, in the following field:
=999  \\$aTest Data

The Edit Field Data tool could interact with the data: “$aTest Data”.  Ideally, this will potentially simplify the process of doing most field edits.  However, it also opens up the opportunity to do recursive group and replacements.

When harvesting data, often times subjects may be concatenated with a delimiter, so for example, a single 650 field may represent multiple subjects, separated by a delimiter of a semicolon.  The new function will allow users to capture data, and recursively create new fields from the groups.  So for example, if I had the following data:
=650  \7$adata – data; data – data; data – data;

And I wanted the output to look like:
=650  \7$adata – data
=650  \7$adata – data
=650  \7$adata – data

I could now use this function to achieve that result.  Using a simple regular expression, I can create a recursively matching group, and then generate new fields using the “/r” parameter.  So, to do this, I would use the following arguments:
Field: 650
Find: (data – data[; ]?)+
Replace: $$a$+/r
Check Use Regular Expressions.


The important part of the above expression is in the Replacement syntax.  To tell MarcEdit that the recursion should result in a new line, the mnemonic /r is used at the end of the string to tell the tool that the recursion should result in a new line.

This new function will be available for use as of 4/7/2014. 


 Posted by at 8:44 pm
Mar 192014

After posting the update last night, a user noted that the Delimited Text Translators 008 generation utilized some older defaults that were causing some validation issues.  So, I’ve posted a limited update to correct this specific problem.

If you have automatic updating turned on, MarcEdit will prompt you automatically.  Otherwise, you can download from:


 Posted by at 9:38 pm
Mar 182014

New MarcEdit has been posted.  Here’s the notes:

  • RDA Helper: Enhancement — Added option to determine if the 040$e is added, in accordance with the PCC Hybrid records documentation.
  • RDA Helper: Enhancement — Updated the GMD generation to take into account additional field data in an attempt to account for accompanying data (rather than alternative forms)
  • CDS-ISIS: Enhancement — Updated the process to account for some additional conversion options.  Updated the field remapping.  I.E., changing from 003=>999, 003,999.
  • CDS-ISIS: Bug Fix — When using the advanced option, appending an initial subfield was being dropped.  Fixed.
  • MarcEditor: Enhancement — Added a new Edit function; Remove Empty Fields/Subfields.  This is used to fix errors in a file, where empty fields or subfields are present.

The update is available either via the automatic update or via URL at:


 Posted by at 7:29 pm
Mar 022014

I’m happy to report that I finally completed work on the latest MarcEdit update.  This change provides updates specifically to the RDA Helper and MarcEdit’s implementation/interaction with the OCLC WorldCat Metadata API.  The full list of changes can be found below. 

  • RDA Helper: Modified the way that the 260/264 conversion occurs, to bring it more in line with the current practice and examples.  This includes retaining the 264$c and creating a second 264\4 when the program can determine that the data defined in the 260$c is a copyright statement.
  • RDA Helper: Added a qualifier option for the 015/020/024/027.  You can turn this on or off (default is off)
  • RDA Helper: I’ve updated some of the abbreviations
  • RDA Helper: Fixed a bug in the 260/264 processing that didn’t always clean up superficial punctuation during the translation process.
  • OCLC Integration: OCLC Search – I’ve added the ability to search by indexes oclc number, issn, isbn as a single or Boolean search.
  • OCLC Integration: In the configuration area, I’ve added some addition error checking.
  • OCLC Integration: In the configuration and batch records update section, I’ve added an option to Lookup your Holdings Codes.  This will show all your institutions valid holdings codes (something that folks have sometimes had trouble finding).  This makes use of the OCLC Metadata API, specifically the Holdings retrieval code.
  • OCLC Integration:  I’ve added the holdings retrieval code to the OCLC API Library.  This code has been synced to github.
  • OCLC Integration: Local Bibliographic Records Support.  This is what I’m still working on.  The program will allow you, on search, to now choose the option to download a local bib record (rather than the OCLC bib record) if one is available.  This allows users who are using OCLC WMS or have Local Bibliographic Records, the ability to create, update, and delete these records. 
  • OCLC Integration: I’ve added the local bibliographic data records code to the OCLC API Library.  This code has been updated to github.


If you have MarcEdit, you can download the program via the automated update tool, or you can download directly from:


 Posted by at 1:28 pm
Feb 272014

Since OCLC made their Metadata APIs available, I’ve spent a good deal of time putting them through their paces and looking for use cases that these particular API might solve, and if/how MarcEdit might be an appropriate platform to take advantage of some of this new functionality.  Looking over the new Metadata API, it’s pretty easy to see where the focus was on – providing some capacity to have read/write access to the WorldCat database, primarily the global and local bibliographic data.  In addition, the API provided the ability to set institutional holdings on records, though not work with Local Holdings Records.

For that reason, the first round of MarcEdit development utilizing these API was focused primarily on working with the master bibliographic and institutional holdings records.  These are two areas where I tend to receive regular queries from users in the mist of reclamation projects or weeding projects and needing to make changes to hundreds or thousands of records in the WorldCat database.  The new APIs allowed me to provide an answer to the two most common questions: 1) Can I batch update/delete holdings on a particular OCLC records and 2) can I batch upload records to OCLC.  While I’d definitely argue (and I think OCLC probably would agree) that these APIs are not designed to be used with batch operations in mind (i.e., they are slow) – they finally offered a way to communicate with the WorldCat database in real-time…and regardless of performance, this feels/is a big win for libraries that choose to work with OCLC.  If you are interested in how this initial work was implemented, you can read about it here: http://blog.reeset.net/archives/1245

After releasing the first MarcEdit builds and making subsequent refinements to the integration work, I’ve had the opportunity to speak with more OCLC WMS users and individuals that make use of the Local Bibliographic Data files and decided that it was time to start working on adding support for this type of data.

The challenge with working with Local Bibliographic Data records is that there is no way (at least through the API) to know if a record has a local bibliographic record attached, without multiple queries and making a set of special calls to the API about a specific OCLC number.  This means that for all intensive purposes, the process of working with local bibliographic data in MarcEdit assumes one of two things:

  1. That the user knows what data has these records
  2. That the user is likely creating new ones.

Secondly, I’ve tried to integrate this new functionality into the existing tools developed for use with the other OCLC Metadata APIs.  So for example, users looking to query a set of records and retrieve the attached local bibliographic records now will see a new option on the OCLC Search box that denotes if the master or local bibliographic record should be extracted.


The problem, is at this point, MarcEdit doesn’t know if a local bibliographic record actually exists.  Certainly, the tool could pre-query every oclc number returned as part of a search, but that approach exponentially increases the back and forth communication between MarcEdit and OCLC via the API, and remember, this isn’t an API that feels designed for batch operations.  So, rather than query, MarcEdit provides an option to download the local bibliographic record if it is present.  If this checkbox isn’t selected, the program will download the master bibliographic record for edit.  For users looking to create a local bibliographic record, the process is the same.  Local bibliographic records must be attached to a master OCLC number – so a user would query a record, check to download the local bibliographic record, and then attempt the download.

When downloading a local bibliographic file, MarcEdit will prompt users, asking if the tool should automatically generate a local bibliographic file for edit in MarcEdit if one doesn’t exist on a master record.


To generate new records, MarcEdit utilizes a new template within the application – local_bib_record_template.mot.  The template contains the following data:

=LDR  00000n   a2200000   4500
=004  [OCLC_NUM]
=940  \\$a[OCLC_CODE]

This template looks slightly different than a normal MarcEdit template, in that it includes a number of data points that MarcEdit will automatically generate as part of the record generation process.  This is necessary because specific data must be present in order for a local bibliographic record to be valid.  For example, a local bibliographic record must have the OCLC number that it’s attached to – data that is found in the 004.  The 935 represents a local system generated number, a number MarcEdit generates as a timestamp indicating record creating time, and finally, the 940 includes the organizational code, or the code that normally would appear in the 040 of a bibliographic record.  This information is stored and used as part of the API profile, so MarcEdit includes that data in the record generation process.

A local bibliographic record is in many ways like the master bibliographic record, just with data only applicable to an institution.  OCLC has a set of documentation around what kinds of data can be stored in these records.  Using a test record in WorldCat, I extracted the following example:


In this record, the data breaks down in the following way:

  • 001 – this is the unique lhd control number
  • 004 – this is the oclc number for the master bibliographic record that this local record is attached to
  • 005 – this is the transaction data; this data must match when updating records as OCLC uses this as a point of validation.
  • 500, 790 – in this record, these are the local data fields…data that is separate from the master bibliographic record and visible only to my users who see our local bibliographic data.
  • 935 – this is a locally defined system number – when MarcEdit generates this number, it is a system timestamp.
  • 940 – this is the institution code.

As one can see, a local bibliographic record can be fairly brief (or verbose depending on the notes added to the record).

To update/create/delete a local bibliographic holdings file (single or batch) – a user would start with a local bibliographic record.  Even delete operations require the record – you cannot just pass the lbd a control number or list of oclc numbers – at least at this point.  The API requires the record to be sent through the service as a type of validation.

Updating this data requires using the Add/Delete/Update Local Bibliographic Data option:


Selecting this option will open the following window:


When dealing with Local Bibliographic data, the option will be selected, and the option to delete those records is also presented.  Users not working with local bibliographic data will see the same dialog, but the Process as Local Bibliographic Records option will be left unchecked and the Delete Records option will not be visible.  At this point, users can process their records, and MarcEdit will return the response codes provided by the API to determine if the updates were successful or not.

My guess is, that like the first pass through the API, the use of these methods and tools that make use of them will be refined with time and use, but I think that they provide a good start.  Of course, at this point, I’ve reached the limit  in terms of functionality that the Metadata API provides.  In looking at this toolset, it’s pretty clear that at this point, these API were primarily envisioned for individual, real-time editing of the WorldCat database.  I have a feeling that the batch holdings tools, and now the ability to upload bibliographic and local bibliographic data in batches probably fall outside of the identified use cases when OCLC first released these to the public.  But they work, though a little slowly, and provide some capacity to work directly with the WorldCat database.  At the same time, the API is limited and missing key features that folks are currently asking for – most notably the ability to work with local holdings data, the ability to validate records, and a better process for search and discovery (as the present Search API are woefully inadequate for nearly any, but for the most vanilla uses).  Hopefully, by doing some simple integration work in MarcEdit and providing some useful tools around the Metadata API, it can provide a catalysis for additional work, additional functionality, and additional innovation on the side of OCLC – and continue to push the cooperative to provide more transparent and deeper access to the WorldCat resources and holdings.

Finally, the functions discussed here will be made available for download on March 2.


 Posted by at 11:13 pm

MarcEdit 5.9 Update

 MarcEdit  Comments Off
Feb 172014

I’ve posted a new update to MarcEdit.  Change list is as follows:

  • Enhancement: Add_Field_Stream API — Added character encoding typing to ensure compatibility with script languages.
  • Enhancement: Delete_Field_Stream API — Added character encoding typing to ensure compatibility with script languages.
  • Enhancement:  Added enhanced error checking code and debugging options to OCLC functions.
  • Enhancement: Added option to use RDA encoded work forms for users using MarcEdit to create new records.

To utilize the new RDA work forms, you need to check a new option in the MarcEdit Preferences.  Open the Preference window, select MarcEditor Preferences, and Check the Use RDA Templates option (see below).  Then click OK.  When you select a new record template from within the MarcEditor, the program will utilize the RDA template for the material type if available.

The update can be downloaded via the automatic updating tool, or at:



 Posted by at 10:19 pm

MarcEdit 5.9 Update

 MarcEdit  Comments Off
Feb 022014

I had a few free cycles this past weekend, and decided to close a few enhancement requests.  Nothing earth shattering.  Here’s the list:

Version: 5.9.75

  • Enhancement: Swap Field Function — Modified the tool so that when swapping a multiple subfields to a single subfield. I.E., 245ahb to 999a
  • Enhancement: Merge Function — Updated the weighting so that the program does a better job when main titles match, but other data does not. This is by creating a secondary match criteria that uses the presence and match of subsequent data.
  • Enhancement: Merge Function — Updated the tool so that records with multiple titles (due to Romanization or transliteration) can be matched (before, they were often ignored if multiple titles were present).
  • Enhancement: Delete Function — Updated the function so that the Remove if does not match can take a regular expression. This has always been supported in the code, but disabled via the UI for additional testing.
  • Enhancement: MARCSplit Function — padded the numeric values used when generating filenames to allow for better sorting.
  • Enhancement: MARCSplit Function — Before processing, the program will evaluate the destination directory and if split files already exist, will give you the option to preserve the files by incrementing the count of the file naming convention. I.E., if you have a file where the last split file is named msplit00000012.mrc, the program will start the next split operation at msplit00000013.mrc.
  • Enhancement: Add the following streaming functions to the COM:
    • Marc2XML_Stream
    • Add_Field_Stream
    • Delete_Field_Stream

If you have the automatic updates configured – you should be prompted to update the next time you run MarcEdit.  Otherwise, you can download the update from:



 Posted by at 10:48 pm
Dec 252013

Merry Christmas!  I hope that everyone has a wonderful holiday, full of happiness, family, and rest.  I’ve been spending the past couple of days wrapping up my last Christmas present – this one to the MarcEdit community…a shiny new update.  In what has become a bit of a holiday tradition, I try and use the Christmas update to handle a few nagging issues as well as introduce something unexpected and new.  Some years that’s harder than others.

This year, I decided to tackle an issue that is becoming more problematic with each new computer refresh cycle – that being challenges arising from the proliferation of 64-bit Windows systems.  The challenge isn’t with MarcEdit itself, the challenge is when MarcEdit works with 3rd party programs or components that I don’t control.

When I designed MarcEdit, I designed it to be processor independent.  If a user is on a 32-bit system, MarcEdit would run in 32-bit mode.  If a user was on a 64-bit system, the program would run in 64-bit mode.  For the application, this works great.  The problem arises when MarcEdit has to utilize 3rd party tools and services.  This directly impacts one popular MarcEdit plugin – the OCLC Connexion plugin.  This plugin allows users to import data from their Connexion local save file, process the data in MarcEdit, and then save the data back to the Connexion save file.  And for users of 64-bit systems, this plugin has been unavailable for use.  The reason is that OCLC utilizes Microsoft Access’s database format to store the local Connexion data.  The component to read the MS Access file format, an operating system component distributed with Windows (or installed when a user installs Office), is a 32-bit component.  Microsoft has gone on record saying that they won’t be updating this component, and has advised developers to just build programs targeting 32-bit systems if they need to access database components.  This is what Connexion does, but in MarcEdit, there are some good reasons from a speed and optimization perspective, to utilizing the native data types when on 32 and 64 bit systems.  So, for a long-time, this restriction essentially prevented users on 64-bit systems from using this plugin.

Well, I’ve been researching a potential solution for some time, and I’ve come up with one.  As of today, I’ve introduced a 32-bit mode in MarcEdit.  Users have the option to select this mode, and MarcEdit will create a pocket, virtualized environment allowing the application to run as a 32-bit application and thus, utilize the plugin.  At this point, I’m not giving users the option to always run MarcEdit in 32-bit mode…I’m not sure I ever will.  But this option will give users the ability to work with the Connexion plugin, regardless of they system type.  I’ve recorded a youtube video demonstrating how this new function works.


I’m hoping that this enhancement will also lead to the ability to utilize this approach to provide improved debugging, but I will have to continue to do a little more research. 

As you can imagine, this update also includes updates to the OCLC Connexion Plugin.  If you want to use it, you will need to either download it from the plugin manager…or, if you already have it – delete the existing plugin and download the new one using the plugin manager. 

MarcEdit update notes:

  • Bug Fix: Copy Field: When data is present in the Find Text box to define conditional Copy Field operations, the Find data is ignored. This has been corrected.
  • Bug Fix: Extract/Delete Records: When calculating the display field, MarcEdit utilizes the non-filing character indicators when extracting title data for display. However, if the non-filing data is incorrect, then an error can occur. This has been corrected.
  • Enhancement: Validate URLs: Users now have the ability to select a non-variable field to be the display field in the status reports.
  • Enhancement: OCLC Connexion Plugin: Corrected the 008 data processing so that the data is valid when moving between the Connexion data file and MarcEdit. Previously, MarcEdit didn’t process this data which caused the data to be invalid when imported into MarcEdit since OCLC stores two extra bytes in the field. The data is now cleaned and fixed when moving data between the Connexion data file and MarcEdit.
  • Enhancement: OCLC Connexion Plugin: Updated the user interface.
  • Enhancement: OCLC Connexion Plugin: Improved the Error Handling and the messages that users receive on error.
  • Enhancement: OCLC Connexion Plugin: Improved the status thread handling so error and status messages are not covered up.
  • New Feature: MarcEdit 32-bit Mode: When users migrated to a 64-bit environment, the Connexion Plugin ceased to function because it relied on a 32-bit operating system component, a component Microsoft has said will not be supported in 64-bit mode. To allow users to continue to use tools like the OCLC Connexion plugin, MarcEdit now has a 32-bit mode, a service that essentially creates a virtual 32-bit environment around the MarcEdit application, allowing the program the ability to utilize 32-bit components while running on a 64-bit system.
  • Merry Christmas!!!

If you have automated updates enabled, the program will prompt you to update the next time you use the program.  Otherwise, you can download the updates from:

Merry Christmas,


 Posted by at 1:09 am

MarcEdit 5.9 Update

 MarcEdit  Comments Off
Nov 242013

Couple of updates related to the RDA Helper and Task generator.  Here’s the change list:

  • Bug Fix: RDA Helper: GMD corrections related to the GMD.
  • Bug Fix: RDA Helper: Fixed a miss spelling that would occur under specific circumstances around sound recordings.
  • Bug Fix: FAST Generation: When processing FAST Headings, there are cases where the LDR can be deleted.  This is corrected.
  • UI Enhancement: Modified the Batch Processing tool so that the description in the new folder dialog reflects the description better.
  • Enhancement: Copy Field: When copying data from a control field to a non-control field, you now have the ability to specify a subfield.
  • Bug Fix: Task List: When adding a Swap Field task, two options were not being saved.  This has been fixed.

Additionally, I reposted the API documentation (that was removed when my Oregon State Accounts were deleted).  They can be found at: http://marcedit.reeset.net/software/api_docs/



 Posted by at 8:39 pm
Nov 052013


I wanted to note that I’ve updated this post to correct/clarify two statements within this post. 

  1. The requirement of 2 wskeys
  2. Terms of use

OCLC has two wskey structures.  For those developers that have been working with OCLC for a long time and have a wskey for their search services, OCLC can decommission your former key and create a new one that supports all functionality or they can give you a second key for the Metadata API.  For new users, you simply need to request a key that includes specific functionality.  In MarcEdit, I will continue to keep the key’s separate for configuration purposes, but this value can be the same.

Secondly – related to terms of use.  I need to clarify – if you are developer and have been using the WorldCat Platform Services outside of the Search API, the terms to use this service as a developer are no different from the other licensing terms you or your institution may have agreed to.  However, if you are a cataloger, the terms to retrieve/create a developer key are very likely different from the terms of service associated with your license related to the cataloging service.  Users need to be aware of these differences because your organization may/will care.


I’ve been starting to work on a couple of different write-ups around working with the OCLC Metadata API (http://oclc.org/developer/services/worldcat-metadata-api) – my general impressions and some specific improvements that really need to be in place to make this resource more usable.  But I also have realized that I have neglected to give any kind of write-up about using the API within MarcEdit, save for an early YouTube video.  So, I’m taking a little bit of time here to jot down some information related to how the API can be utilized within MarcEdit.


So a little bit of background.  Over the past couple of years, I’ve been looking for opportunities to make use of the great work that OCLC Research does in exposing some interesting new data streams to the library community.  When OCLC first released their classify service a number of years ago, I believe I was probably one of the first people to grab it and integrate it into a product that could be used within existing cataloging workflows.  This year, I expanded the service to include integration with OCLC’s FAST headings service.  While OCLC’s services do have some baggage attached (in terms of who is allowed to use them), the baggage is pretty small and they provide real value to the library community.  Providing them through MarcEdit made a lot of sense.

The same can be true of OCLC’s new Metadata API.  For a number of years, I’ve been having individuals in the user community looking for the ability to interact directly with WorldCat, specifically around the ability to set and delete holdings.  The API provides this functionality, in addition to the ability to add and edit bibliographic records, as well as functionality around local data records.  For the first round of integration, I’ve limited my work primarily to dealing with holdings and bibliographic data.  I’ll be looking for people interested in the local data functionality and see how MarcEdit might be augmented to support that as well.

Early Use cases

Part of the reason I chose to work and support the specific API actions that I did was due to existing use cases.  Processing around E-books and E-Resources have lead users within the MarcEdit community to make a couple common requests related to OCLC and WorldCat.  Specifically, users are asking to:

  1. Automate the process of setting holdings
  2. Automate the upload of new records without using Connexion
  3. Automate Headings validation

The API provides the ability to address the first two questions, and I hope with time, OCLC will make some of their heading validation services available to support the 3rd request.  But for now, MarcEdit’s development has really been focused around supporting these two specific use cases.

First Impressions

I’ll take some time to provide some additional feedback in a few days, but my first impressions were mixed.  One the one hand, interacting with the service once I understood what the API expected in terms of requests and responses was pretty straightforward.  On the other hand, very little documentation exists.  Often times, I would initiate purposeful errors because simple things, like acceptable schemas, are left undocumented but are provided in an error message.  Unfortunately, the missing documentation definitely complicates working with the service, as things related to validation, reasons for authentication errors, etc. simply are not documented and whose descriptions are fairly cryptic when reading as a response from the API.

However, I think anyone that does development probably is use to working with scarce documentation, and to OCLC’s credit, they have been very responsive in providing answers to the holes that currently exist in the documentation.  From my perspective, the most concerning aspect of the API right now is the authentication.  From a developer’s standpoint, the authentication process is easy enough.  For the user however, the process for getting keys to utilize tools built upon the services is fairly problematic because the process assumes that users are developers and forces key requests and management through that portal.  Likewise, these keys come with new terms of use outside of your traditional cataloging licensing and may (likely) will need to be vetted through an organizations legal council.  Again, this is primarily a problem for non-developers – who have relationships with OCLC in ways outside of the WorldShare Platform Services…but these are primarily the users that this integration  in MarcEdit targets (i.e., catalogers, not developers).  This honestly is my biggest concern with the service right now (that and that keys are tied to individuals, not institutions) – bigger than issues related to documentation, validation, and the somewhat cryptic nature of the feedback received through the API.

Using the API in MarcEdit

So, to use the OCLC Metadata API in MarcEdit, there are a couple things that you need to do.  First, you need to request your OCLC keys.  MarcEdit’s integration requires users the appropriate Wskeys:

  1. OCLC’s Search API Key
  2. OCLC’s Metadata API Key

For long-term OCLC Platform Users (think Search API) – this means requesting two keys due to the fact that the previous key format isn’t compatible with their new authentication system.  For new users, a single key should suffice.  Regardless, a key that can support OCLC’s Search functionality is required to support MarcEdit’s ability to query the WorldCat database.

Likewise, MarcEdit needs a key that can utilize the Metadata API key.  Again, for legacy API users, this will likely be a separate key – for new users – the search and metadata keys should be the same.  This key has two parts – there is the Key and a Secret key.  You need both to make requests.  Likewise, there are 3 other values that users need to know to utilize the Metadata API services, and that is what is called a principalID a principalIDNS, a schema, a holdings symbol and a 4 character holdings code.  All of these values need to be available in order to work with the various functions provided by the API.

Once you have these keys and supplemental information, you need to enter them into MarcEdit.  Users will be able to see the menu entries for many of the OCLC functions, but until a user has entered their OCLC key data into the MarcEdit preferences and validated the data – these functions will remain disabled.

In the Preference’s area, there is a new tab that has been setup to store data related to OCLC’s Metadata services.


From this screen, users can enter all the information that they will need in order to utilize the various Metadata and Search API functions.  MarcEdit will store this information in it’s configuration file, but does encrypt the data using a methodology that would make it impractical to reconstruct the key data.

After a user enters their data – the user should Click Apply, and then Validate.  The Validate process is what enables the OCLC API integration functions.  MarcEdit performs a couple API operations on an existing test record to determine if the information that user provided will support the required functionality.  As MarcEdit validates a key, it will turn the textbox either green (for validated) or red (to indicate a problem).

Example of a problem with a key

Example of all keys validated

Once the data has been validated – the OCLC Menu Items found in the Main Window and on the MarcEditor will be enabled.

Main Window – OCLC Functions

MarcEditor OCLC Functions

Using the OCLC API Functions

Hopefully, the functions are fairly straightforward to use and look identical regardless of where you interact with them within the application.  At present, MarcEdit provides a function for setting holdings and working with bibliographic data.

Setting Holdings

MarcEdit’s Holdings Tool

MarcEdit provides a straightforward tool for updating a user’s holdings for a batch of records.  MarcEdit’s holdings tool can process either MARC data, MarcEdit’s mnemonic data or a plain text file of OCLC numbers.  The tool does exactly what it says.  Using the information set in the Preferences, MarcEdit will pre-populate your Institution Code and Classification Schema.  Users then need to select an action.  MarcEdit’s batch tool can update or delete holdings, but will perform just one of those actions on all records within a designated file.  That means, you cannot upload a file that contains records that need to have holdings added and deleted.  The tool requires that these actions are isolated into discrete operations.

Update/Creating Bibliographic Data

MarcEdit’s Bibliographic Tool

When working with MarcEdit’s bibliographic updating/creation tool for WorldCat – this tool does allow users to work with files that contain records that are both new or updated.  OCLC’s system and MarcEdit evaluates records within a file and based on the presence or absence of an OCLC number in a record will determine if a bibliographic record is to be created or updated.  Of course, it’s not that simple – all bibliographic records passed through the API must be validated on the OCLC side, and at this point, that validation only occurs when the data is submitted for update or creation – a weakness that I hope at some point will be rectified since this causes a number of issues when working in a batch record environment.

Working within the MarcEditor

When working within the MarcEditor, the tools for working with Holdings and Bibliographic data are identical to outside.  The main difference is that the data being acted upon is the data in the MarcEditor.  This means that the MarcEditor needs to include one additional function, and that is the ability to retrieve data from WorldCat.  MarcEdit has the ability to search and download a record set from WorldCat for editing.

Searching WorldCat from Within the MarcEditor

The search tool provides a handy way for users to quickly retrieve data from WorldCat for edit.  However, this too underlines one of the glaring issues with the API – especially around record editing.  Traditionally, when catalogers work on a record, they can lock the record for editing.  This prevents other users from changing the record while they are working on it, and protects the transaction information in the 005 which OCLC requires for updating purposes.  When working with the API, there appears to be no way to lock a record.  This means that records can be downloaded, edited and then on upload, be invalid due to someone else making an edit that updates the 005 information.  And since OCLC doesn’t provide a method for validating information prior to upload, users won’t know that this problem has occurred until an upload is attempted.  Again, in order to make the API functionally equivalent to OCLC’s other editing services, there needs to be a way for catalogers to lock records for editing.

Where we go from here

This is really hard to say.  I believe that OCLC sees the release of the Metadata APIs as the first of a much larger portfolio of API services to provide programmatic support for their WorldShare endeavors.  So, it will be interesting to see how these develop.  At the same time, I’m really interested in seeing if the organization puts the type of resources behind the development of their API Services Portfolio to provide really meaningful services that librarians, developers, and 3-party library developers can work with, consume, or augment the wide range of data streams that they have available.  On the one hand, I’m hopeful that the release of the Metadata API signals are wider commitment to providing transparent access to a wide variety of services.  At the same time, the lack of development around the OCLC search API – which has seen only incremental changes since they were first released some 5 or so years ago – makes me wonder how much support within the larger organization exists around this type of work.  So I guess that is a question that remains to be answered.



 Posted by at 1:32 pm