MarcEdit Linked Data Rules Files Enhancements

By reeset / On / In BibFrame, MarcEdit

I’m working on a couple enhancements to the MarcEdit Linked Data rules file to accommodate proposals being generated by the PCC regarding the usage of the $0 and the $1 in MARC21 records.  Currently, MarcEdit has the ability to generate $0s for any controlled data within a MARC record, so long as a webservice for the vocabulary has been profiled in the MarcEdit rules file.  This has allowed folks to begin embedding URIs into their MARC records…but one of the areas of confusion is where services like VIAF fit into this equation.

The $0, as described in MARC, should represent the control number or URI to the controlled vocabulary.  This will likely never (or in rare cases ever be), VIAF.  VIAF is an aggregator, a switching point, an aggregation of information and services about a controlled term.  It’s also a useful service (as are other aggregators), and this had led folks to start adding VIAF data into the $0.  This is problematic, because it dilutes the value of the $0 and makes it impossible to know if the data being linked is to the source vocabulary or an aggregating service.

To that end, the PCC will likely be recommending the $1 for URIs that are linked data adjacent.  This would allow users to embed references to aggregations like VIAF, while still maintaining the $0 and the URI to the actual vocabulary — and I very much prefer this approach.

So, I’m updating the MarcEdit rules file to allow users to denote multiple vocabularies to query against a single MARC field, and to denote the subfield for embedding the retrieved URI data on a vocabulary by vocabulary level.  Prior, this was set as a global value within the field definition set.  This means that if a user wanted to query LCNAF for main entry (in the 100) and then VIAF to embed a link in a $1, they would just need to use:

<field type=”bibliographic”>
<tag>100</tag>
<subfields>abcdqnpt</subfields>
<uri>0</uri>
<special_instructions>personal_name</special_instructions>
<vocab subfield=”0″>naf</vocab>
<vocab subfield=”1″>viaf</vocab>
</field>

The Subfield Attribute now defines per vocabulary element, where the URI should be stored, and the uri element, continues to act as the global subfield setting, if not value is defined in the vocab element.  Practically, this means that if you had the following data in your MARC record:

=100  1\$6880-01$aHu, Zongnan,$d1896-1962,$eauthor.

The tool will now automatically (with the rules file updates), generate both a $0 and $1.

=100  1\$6880-01$aHu, Zongnan,$d1896-1962,$eauthor.$0http://id.loc.gov/authorities/names/n84029846$1http://viaf.org/viaf/70322743

But users could easily add other data sources if they have interests beyond VIAF.

These changes will be available in all versions of MarcEdit when the next update is posted in a week or so.  This update will also include an updated rules file that will embed viaf elements in the $1 for all main entry content (when available).

 

–tr

 

 

MarcEdit, Windows XP, and what the way too early log analysis says

By reeset / On / In Library, MarcEdit, Microsoft

Related post: MarcEdit and the Windows XP Sunsetting conversation

So, this has been kind of interesting.  Since Sunday, I’ve been running a script against my access logs to get a better idea of what the MarcEdit XP user community may look like.  I timed this with the update, because I’ve found that in general, a large number of users will update the program within the first couple of weeks of the update.  Equality interesting, even though MarcEdit has an automatic updating tool, there are users that stay with very old versions of the 6.x series.

Anyway, couple of interesting things of note since this active log analysis began:

  1. Since Sunday, MarcEdit’s automatic update script has been pinged north of 250,000+ times.  That means that since Sunday, users that make use of the autoupdate notifications have opened the program to do work at least a quarter of a million times.
  2. Since Sunday, MarcEdit has been updated ~7000 times.  I’ve estimated that the active user community is around 11-12k users, but that year over year, the update service will report a unique user count in the high 20,000s.  Assuming that these are the most active users, I think this gives an idea of who will be most immediately impacted by any potential change in XP support.
  3. Of those approximate 7000 users, 9 run XP.  The largest number of these users come from China and India, but surprisingly, there are still US users (at academic institutions based on the IPs reported) that still run XP…my god.
  4. Surprisingly, the mostly widely used Windows Operating system reported was Windows 8.1.  I honestly expected to see Windows 7.  But by usage, the breakdown was Windows 8.x, Windows 10, then Windows 7.  I really thought the order was going to be Windows 7, 10, then 8.x.

 

So what can I learn from this way to early analysis of the update/usage information.  First, it confirms a suspicion that I’ve had for a while that XP is very much in the minority among MarcEdit’s most active users…and that’s actually about it.  What I anticipate seeing is that the initial trends (can 7 users be a trend) that shows XP usage largely concentrated in China and India (since these are both large user communities).  I’m honestly also curious if this will extend to the Middle East.  Year over year, the Middle East represents the 3rd highest concentration of MarcEdit users.  The question for me as this picture becomes more clear is how wide spread XP use actually is — and that I just don’t know yet.  Oh, and third…I keep thinking there is a paper to be written here…if I could just find the time.  🙂

–tr

 

 

 

 

 

Can my ILS be added to MarcEdit’s ILS Integration?

By reeset / On / In Innovative Interfaces, Koha, Library, MarcEdit

This question has shown up in my email box a number of times over the past couple of days.  My guess, it’s related to the youtube videos recently posted demonstrating how to setup and use MarcEdit directly with Alma.

  1. Windows Version: https://youtu.be/8aSUnNC48Hw
  2. Mac Version: https://youtu.be/6SNYjR_WHKU

 

Folks have been curious how this work was done, and if it would be possible to do this kind of integration on their local ILS system.  As I was answering these questions, it dawned on me, others may be interested in this information as well — especially if they are planning to speak to their ILS vendor.  So, here are some common questions currently being asked, and my answers.

How are you integrating MarcEdit with the ILS?

About 3 years ago, the folks at Koha approached me.  A number of their users make use of MarcEdit, and had wondered if it would be possible to have MarcEdit work directly with their ILS system.  I love the folks over in that community — they are consistently putting out great work, and had just recently developed a REST-based API that provided read/write operations into the database.   Working with a few folks (who happen to be at ByWaters, another great group of people), I was provided with documentation, a testing system, and a few folks willing to give it a go — so I started working to see how difficult it would be.  And the whole time I was doing this, I kept thinking – it would be really nice if I could do this kind of thing with our Innovative Interfaces (III) catalog.  While III didn’t offer an API at the time (and for the record, as of 4/17/2017, they still don’t offer a viable API for their product outside of some toy API for dealing primarily with patron and circulation information), I started to think beyond Koha and realized that I had an opportunity to not just create a Koha specific plugin but use this integration as a model to develop an integration framework in MarcEdit.  And that’s what I did.  MarcEdit’s integration framework can potentially handle the following operations (assuming the system’s API provides them):

  1. Bibliographic and Holdings Records Search and Retrieval — search can be via API call, SRU or Z39.50
  2. Bibliographic and Holdings Records creation and update
  3. Item record management

 

I’ve added tooling directly into MarcEdit that supports the above functionality, allowing me to plug and play an ILS based on the API that they provide.  The benefit is that this code is available in all versions of MarcEdit, so once the integration is created, it works in the Windows version, the Linux version, and the Mac version without any additional work.  If a community was interested in building a more robust integration client, then I/they could look at developing a plugin — but this would be outside of the integration framework, and takes a significant amount of work to make cross-platform compatible (given the significant differences in UI development between Windows, the MacOS, and Linux).

This sounds great, what do you need to integrate my ILS with MarcEdit?

This has been one of the most common questions I’ve received this weekend.  Folks have watched or read about the Alma integration, and wondered if I can do it with their ILS.  My general answer, and I mean this, is that I’m willing to integrate any ILS system with MarcEdit, so long as they can provide the available API end points that make it possible to:

  1. Search for bibliographic data (holdings data is a plus)
  2. Allow for the creation and update of bibliographic data
  3. Utilize an application friendly authentication process, that hopefully allows the tool to determine user permissions

 

This is a pretty low bar.  Basically, an API just needs to be present; and if there is one, then integrating the ILS with MarcEdit is pretty straightforward.

OK, so my ILS system has an API, what else do I need to do?

This is where it gets a bit trickier.  ILS systems tend to not work well with folks that are not their customers, or who are not other corporations.  I’m generally neither, and for the purposes of this type of development, I’ll always be neither.  This means that getting this work to happen generally requires a local organization within a particular ILS community to champion the development, and by that, I mean either provide the introductions to the necessary people at the ILS, or provide access to a local sandbox so that development can occur.  This is how the Alma integration was first initiated.  There were some interested folks at the University of Maryland that spent a lot of time working with me and with ExLibris to make it possible for me to do this integration work.  Of course, after getting started and this work gained some interest, ExLibris reached out directly, which ultimately made this a much easier process.  In fact, I’m rarely impressed by our ILS community, but I’ve been impressed by the individuals at ExLibris for this specifically.  While it took a little while to get the process started, they do have open documentation, and once we got started, have been very approachable in answering questions.  I’ve never used their systems, and I’ve had other dealings with the company that have been less positive, but in this, ExLibris’s open approach to documentation is something I wish other ILS vendors would emulate.

I’ve checked, we have an API and our library would be happy to work with you…but we’ll need you to sign an NDA because the ILS API isn’t open

Ah, I neglected above to mention one of my deal-breakers and why I have not at present, worked with the APIs that I know are available in systems like Sirsi.  I won’t sign an NDA.  In fact, in most cases, I’ll likely publish the integration code for those that are interested.  But more importantly, and this I can’t stress enough, I will not build an integration into MarcEdit to an ILS system where the API is something that must be purchased as an add-on service, or requires an organization to purchase a license to “unlock” the API access.  API access is a core part of any system, and the ability to interact, update, and develop new workflows should be available to every user.  I have no problem that ILS vendors work with closed sourced systems (MarcEdit is closed source, even though I release large portions of the components into the public domain, to simplify supporting the tool), but if you are going to develop a closed source tool, you have a responsibility to open up your APIs and provide meaningful gateways into the application to enable innovation.  And let’s face it, ILS systems have sucked at this, and much to the library community’s detriment.  This really needs to change, and while the ability to integrate with a tiny, insignificant tool like MarcEdit isn’t going to make an ILS system more open, I personally get to make that same choice, and I have made the choice that I will only put development time into integration efforts on ILS systems that understand that their community needs choices and actively embraces the ability for their communities to innovate.  What this means, in practical terms, is if your ILS system requires you or I to sign an NDA to work with the API, I’m out.  If your ILS system requires you or their customers to pay for access to the API through additional license, training, or as an add-on to the system (and this one particularly annoys me), I’m out.  As an individual, you are welcome to develop the integrations yourself as a MarcEdit plugin, and I’m happy to answer questions and help individuals through that process, but I will not do the integration work in MarcEdit itself.

I’ve checked, my ILS system API meets the above requirements, how do we proceed?

Get in touch with me at reeset@gmail.com.  The actual integration work is pretty insignificant (I’m just plugging things into the integration framework), usually, the most time consuming part is getting access to a test system and documenting the process.

Hopefully, that answers some questions.

–tr

 

 

 

 

 

MarcEdit Updates Posted

By reeset / On / In MarcEdit

Change log below:

 

Mac Updates:

2.3.12
**************************************************
** 2.3.12
**************************************************
* Update: Alma Integration Updates: New Create Holdings Record Template
* Update: Integration Framework refresh: corrects issues where folks were getting undefined function errors.
* Update: the #xx field syntax will be available in the Edit field and Edit indicator functions.  This means users will be able to edit all 6xx fields using the edit field function by using 6xx in the field textbox.
* Update: SRU Library updates to provide better error checking (specific for Windows XP)
* Update: Adding support for the Export Settings command.  This will let users export and import settings when changing computers.

Windows Updates:
6.3.2
* Update: Alma Integration Updates: New Create Holdings Record Template
* Update: Integration Framework refresh: corrects issues where folks were getting undefined function errors.
* Update: the #xx field syntax will be available in the Edit field and Edit indicator functions.  This means users will be able to edit all 6xx fields using the edit field function by using 6xx in the field textbox.
* UI Updates: All comboboxes that include 0-999 field numbers in the Edit Field, Edit Subfield, Swap Field, Copy Field, etc. have been replaced with Textboxes.  Having the dropdown boxes just didn't seem like good UX design.
* Enhancement: RunAs32 bit mode on the 64 bit systems (for using Connexion) has been updated.  Also, I'll likely be adding a visual cue (like adding * 32 to the Main window title bar) so that users know that the program is running in 32 bit mode while on a 64 bit system.
* Enhancement: MarcEdit 7 Update Advisor
* Update: SRU Library updates to provide better error checking (specific for Windows XP)

–tr

MarcEdit 7 Upgrade Advisor

By reeset / On / In MarcEdit

This post is related to the: MarcEdit and the Windows XP Sunsetting conversation

I’ll be updating this periodically, but I wanted to make this available now.  One of the biggest changes related to MarcEdit 7, is that I’m interested in building against an updated version of the .NET framework.  Tentatively, I’m looking to build against the 4.6 framework, but would be open to building against the 4.5.2 framework.  To allow users to check their local systems, and provide me with feedback — I’m including an upgrade advisor.   This will be updated periodically as my plans related to MarcEdit 7 come into shape.

You can find the upgrade advisor under the Help menu item on the Main MarcEdit Window.

Upgrade Advisor Window:

 

 

 

 

As I’ve noted, my plan is to build against the 4.6 .NET Framework.  This version of the .NET framework is supported on Windows Vista-Windows 10.

–tr

 

MarcEdit and the Windows XP Sunsetting conversation

By reeset / On / In MarcEdit

I’m again thinking about the need to seriously think about Windows XP and MarcEdit’s continued support for the nearly 20 year old OS.  What is pushing this again is the integration work I’ve been doing with Alma.   None of this work will be available to XP users, in part, because ExLibris (and rightly) uses TLS 1.2 for their website security certificate.  This isn’t supported on XP (and never will be), so the connection cannot be made to the Alma service.  I have a feeling more and more of these kinds of problems are going to come up, and the way to “fix” this on my end is to migrate MarcEdit’s windows version (the Mac version already is) to the .NET 4.6 framework.  Right now, I’m using 4.0 as a base because it is supported on Windows XP SP 3, but I have to do a number of hacks to keep things working as new technology keeps coming available.  So, I think I’m ready to let Windows XP go, and say that it is time for the MarcEdit community to put this system behind us.  I’ll likely leave the last version of MarcEdit with XP support available for download, and maybe this change will be marked by a version change number (MarcEdit 7), but it really needs to happen.

At the same time, I’m sensitive to the fact that XP has lived so long because it has been the primary system used in a number of developing countries for a very long time.  This is part of the reason I wanted to let folks know that I’m planning to make this change, and give folks an opportunity to provide some feedback.  I’ll also be doing a few things between now and June.  I have a lot of log data, and I’ll be looking at these logs to identify the actual Windows XP use.  A quick glance at my website stats tell me that Windows XP is a minority operating system — but I want to dig deeper.  MarcEdit is run hundreds of thousands of times over the month (per the update logs), and I’ve tweaked the logging to preserve the users operating system (currently, I keep nothing but a general geographic location).  My hope is that libraries will have long ago let go of Windows XP, but I want to do some diligence to make sure this is the case.  If I find that there is still significant XP usage, I’d likely extend my date before dropping XP support from my development code branch, but usage will need to be pretty significant.  But this is also why I’m welcoming feedback.  I do want to be sensitive to the user community and try to make sure that no one gets left behind.

As of right now, my plan is to leave the last XP compatible version of 6.x available for download, but this would be the end of life version which would receive no further updates.  The benefits for the MarcEdit community is this will allow me to remove large sections of code that exist only because I’m dragging XP along, as well as an improved and leaned down installer.  Likewise, I’ll be able to take advantage of some new coding structures that will allow me to more easily do some semantic web integrations, as well as make it easier to support some of the 3rd party integrations that we see.  Additionally, it will bring the Windows codebase into sync with the Linux and MacOS codebases.  By default, both of those systems make use of the 4.6 framework, which would make testing much easier on my end as now I’m testing code across 10 operating systems and 4 different .NET framework versions.  Finally, since this will be a breaking change, i.e. MarcEdit 7 would be developed to work with Windows 7+ (though, I believe it would also work on Vista, but I would no-longer be formally testing for that OS given it’s historically low uptake) on the Windows-side, I would ensure that users could install the MarcEdit 6.x and MarcEdit 7.x programs-side by side.  This is the same approach that I took when moving from MarcEdit 5 to 6, and when I dropped support for Pre-XP Service Pack 3 machines (of which, there were still a handful).

In a couple of months, I’ll start detailing formal plans.  I should also have enough data (from log analysis and active logging of OS for the next 2 months) to have a good idea of what the impact might be and if the time table needs to be shifted.

I’m tentatively planning to make this change in Fall 2017, though I’ll very likely have a working build of the MarcEdit 7.x branch in early June.

–tr

How do I know I’m running in 32 bit mode (if I’m on a 64-bit system) and when (mostly never) would I want to

By reeset / On / In MarcEdit

As a rule, you shouldn’t be running in 32-bit mode when working on a 64-bit system.  In fact, MarcEdit is compiled in a way so that the program will run automatically at the appropriate bit depth for your operating system.  So, if you have a 32-bit system, MarcEdit will automatically be configured to run in a 32-bit environment, and the executable will run as a 32-bit executable.  If you are on a 64-bit system, regardless of it you used the 32-bit installation package, the program will run itself as a 64-bit application.  The program is designed, by default, to take advantage of the benefits native to each of the different processor types.

Why are their two installation programs them?

Great question….while MarcEdit’s components will automatically configure themselves to run at the operating system bit depth, problems arise if you are going to program against MarcEdit…i.e., use the COM objects or access the .NET components and build tools or scripts around the application.  On a 64-bit system. the scripting engine is a 32-bit application (by default), so in order for MarcEdit to expose it’s programming components on a 64-bit system so that they can be accessed by either a 32 or 64-bit process, you need to install using the 64-bit installer.  This installer makes sure that appropriate references are added not only to the registry, but to the windows 32-bit emulation layer, so that the underlying programming components can be utilized by 3rd-party applications.

When would I want to run MarcEdit in 32-bit mode, if I was on a 64-bit system?

Generally, never.  And in fact, there is never a reason when using MarcEdit’s normal functions, when this would be appropriate.  However, MarcEdit has been designed to work with 3rd-party tools as well.  And this is where it gets tricky.  OCLC’s Connexion is a widely used application in the library metadata space (probably, the most widely used tool since it provides primary access to WorldCat for catalogers), but it is also a 32-bit application.  A long time ago, in a galaxy far, far away (sorry, I’m also watching the live stream waiting for the new Star Wars trailer 🙂 ), I had need to be able to work with data in Connexion in a batch process.  Sure, Connexion has macros, but the way these works, Connexion essentially opens and closes individual records, over, and over again.  It’s not very efficient.  So, I wrote a plugin for MarcEdit.  And I wrote it before 64-bit windows became the norm.  Well, as that changed, the plugin stopped working, because a 64-bit version of MarcEdit could not work with a 32-bit version of Connexion.  This is a general rule of computing — like ghostbusters, you cannot cross the streams.  So, a work around was created.

The most awesome part of the .NET framework, is that since the code is byte code, I can tell it some things before a program runs.  And this is what happens here.  The “Run MarcEdit in 32-bit Mode” creates a 32-bit process around MarcEdit, allowing the program to execute within that space.  And in that space, MarcEdit can interact directly with Connexion.  I made a quick video demonstrating how this works:

After making this video, I realized something.  It’s really hard to know if MarcEdit is actually running in this compatibility mode — there really aren’t visual cues, outside of the command box that opens initially.  And, this actually is going away.  I made a couple changes to the program to update this process as the .NET framework includes some new options that I can take advantage of to make this a better process.  So, to make this clear, I’ve done a couple things.  When you run MarcEdit in the 32-bit mode (and only in this mode), the title of the main window will be updated.  You can see this here:

In order to make it easier to see that the program has been started in the compatibility mode, the program will update the program title, adding *32 to the main window.  This only shows up in the main window, but since this is visible when the program reboots, it should be a visual cue to the user that it is now possible to run the Connexion plugin and interact with Connexion, regardless of if you are using a 64-bit version of Windows.

Questions?  Let me know.

–tr

 

MarcEdit Updates

By reeset / On / In MarcEdit

I’ve been working on a few updates the past couple weeks, the most time consuming of these being updates related to Alma.  Here’s the full list:

Windows/Linux:
SourceURL:http://marcedit.reeset.net/software/update.txt

6.2.501
* Enhancement: OpenRefine Import/Export Formatting Updates [tested on 2.7 rc 1 & 2]
* Enhancement: MarcEditor -- Right-to-Left and Left-to-Right language improvements when reading in the Editor [see: http://blog.reeset.net/?p=2103 for more info]


6.2.500
* Enhancement: ILS Integrations (Alma): Alma Holdings Editing is now available.
* Enhancement: Validator Updates - added some code to tighten the duplication reporting and added better responsiveness when running [i.e., statuses, etc.])
* Enhancement/Bug Fix: MarcEngine Updates: Specifically, in the XML space, I was running into some Chinese characters that were not being recognized as UTF8.  This can happen for characters on the fringes of a characterset or have alternative characters.  I made some edits that ensured that any character checking would fall through to a secondary process.  
* Enhancement: Task Management -- I cleaned up a few odds and ends to make managing a bit easier.  This includes exposing error messages when they popup, enabling multiple task deletion, etc.
* Enhancement: Task Management Preferences -- This came up where MarcEdit was having trouble identifying a file path as valid.  I'm going to check these paths as soon as they are selected and report if they are valid right away.  This way -- if there is a problem, you know right away.

MacOS:
SourceURL:http://marcedit.reeset.net/software/mac.txt

2.3.5
**************************************************
** 2.3.5
**************************************************
* Enhancement: ILS Integrations (Alma): Alma Holdings Editing is now available.
* Enhancement: Validator Updates - added some code to tighten the duplication reporting and added better responsiveness when running [i.e., statuses, etc.])
* Enhancement/Bug Fix: MarcEngine Updates: Specifically, in the XML space, I was running into some Chinese characters that were not being recognized as UTF8.  This can happen for characters on the fringes of a characterset or have alternative characters.  I made some edits that ensured that any character checking would fall through to a secondary process.  
* Enhancement: Task Management -- I cleaned up a few odds and ends to make managing a bit easier.  This includes exposing error messages when they popup, enabling multiple task deletion, etc.
* Enhancement: Task Management Preferences -- This came up where MarcEdit was having trouble identifying a file path as valid.  I'm going to check these paths as soon as they are selected and report if they are valid right away.  This way -- if there is a problem, you know right away.
* Enhancement: OpenRefine Import/Export Formatting Updates [tested on 2.7 rc 1 & 2]
* Enhancement: MarcEditor -- Right-to-Left and Left-to-Right language improvements when reading in the Editor [see: http://blog.reeset.net/?p=2103 for more info]

I believe that there will need to be a couple additional updates around the alma work — particularly when creating new holdings, as I’m not seeing the 001/004 pairs added to the records, but this is the start of that work.   Also, I did some work around right-to-left, left-to-right rendering when working with mixed languages.  See: http://blog.reeset.net/archives/2103

Questions, let me know.

–tr

 

MarcEditor Changes and Right-to-left displays

By reeset / On / In character encodings, MarcEdit

So, this was a tough one.  MarcEdit has a right-to-left data entry mode that was created primary for users that are creating bibliographic records primarily in a right to left language.  But what happens when you are mixing data in a record from left-to-right languages like English and Right-to-left languages, like Hebrew.  Well, in the display, odd things happen.  This is because of what the operating system does when rendering the data.  The operating system assumes certain data belongs to the right-to-left string, and then moves data in a way that it think it should render.  Here’s an example:

In this example, the $a$0 are displayed side-by-side, but this is just a display issue.  Underneath, the data is really correct.  If you compiled this data or loaded into an ILS, the data would parse correctly (though, how it displayed would be up to the ILS support of the language).  But this is confusing, but unfortunately, one of the challenges of working with records in a notepad-like environment.

Now, there is a solution that can solve the display problem.  There are two Unicode characters 0x200E and 0x200F — these are Left-to-right character markers and Right-to-left character markers.  These can be embedded in the display to render characters more appropriately.  They only show up in the display (i.e. are added when reading into the display), and are not preserved in the MARC record.  They help to alleviate some of these problems.

 

The way that this works — when the program identifies that its working with UTF8 data, the program will screen the text for characters have a byte that indicate that they should be rendered RTL.  The program will then embed a RTL marker at the beginning of the string and a LTR marker at the end of the string.  This gives the operating system instructions as to how to render the data, and I believe helps to solve this issue.

–tr

 

 

MarcEdit and Alma Integration: Working with holdings data

By reeset / On / In Cataloging, MarcEdit

Ok Alma folks,

 I’ve been thinking about a way to integrate holdings editing into the Alma integration work with MarcEdit.  Alma handles holdings via MFHDs, but honestly, the process for getting to holdings data seems a little quirky to me.  Let me explain.  When working with bibliographic data, the workflow to extract records for edit and then update, looks like the following:

 Search/Edit

  1. Records are queried via Z39.50 or SRU
  2. Data can be extracted directly to MarcEdit for editing

 

Create/Update

  1. Data is saved, and then turned into MARCXML
  2. If the record has an ID, I have to query a specific API to retrieve specific data that will be part of the bib object
  3. Data is assembled in MARCXML, and then updated or created.

 

Essentially, an update or create takes 2 API calls.

For holdings, it’s a much different animal.

Search/Edit:

  1. Search via Z39.50/SRU
  2. Query the Bib API to retrieve the holdings link
  3. Query the holdings link api to retrieve a list of holding ids
  4. Query each holdings record API individually to retrieve a holdings object
  5. Convert the holdings object to MARCXML and then into a form editable in the MarcEditor
    1. As part of this process, I have to embed the bib_id and holdin_id into the record (I’m using a 999 field) so that I can do the update

 

For Update/Create

  1. Convert the data to MARCXML
  2. Extract the ids and reassemble the records
  3. Post via the update or create API

 

Extracting the data for edit is a real pain.  I’m not sure why so many calls are necessary to pull the data.

 Anyway – Let me give you an idea of the process I’m setting up.

First – you query the data:

Couple things to note – to pull holdings, you have to click on the download all holdings link, or right click on the item you want to download.  Or, select the items you want to download, and then select CTRL+H.

When you select the option, the program will prompt you to ask if you want it to create a new holdings record if one doesn’t exist. 

 

The program will then either download all the associated holdings records or create a new one.

Couple things I want you to notice about these records.  There is a 999 field added, and you’ll notice that I’ve created this in MarcEdit.  Here’s the problem…I need to retain the BIB number to attach the holdings record to (it’s not in the holdings object), and I need the holdings record number (again, not in the holdings object).  This is a required field in MarcEdit’s process.  I can tell if a holdings item is new or updated by the presence or lack of the $d. 

 

Anyway – this is the process that I’ve come up with…it seems to work.  I’ve got a lot of debugging code to remove because I was having some trouble with the Alma API responses and needed to see what was happening underneath.  Anyway, if you are an Alma user, I’d be curious if this process looks like it will work.  Anyway, as I say – I have some cleanup left to do before anyone can use this, but I think that I’m getting close.

 

–tr