I thought I’d take a quick moment to highlight some work that was done by one of the programmers here at The OSU, Peter Dietz. Peter is a bit of a DSpace wiz and a contributor to the project, and one of the things that he’s been interested in working on has been the development of a REST API for DSpace. You can see the notes on his work on this GitHub pull request: https://github.com/DSpace/DSpace/pull/323.
Thankfully, I’m at a point in my career where I no longer have to be the individual that has to wrestle with DSpace’s UI development, but I’ve never been a big fan of it. From the days when the interface was primarily JSP to the, it sounded like a good idea at the time, XSLT interfaces that most people use today, I’ve long pined for the ability to separate the DSpace interface development from the actual application, and move that development into a framework environment (any framework environment). However, the lack of a mature REST API has made this type of separation very difficult.
The work that Peter has done introduces a simple READ API into the DSpace environment. A good deal more work would need to be done around authentication to manage access to non-public materials as well as expansions to the API around search, etc., but I think that this work represents a good first step.
However, what’s even more exciting is the demonstration applications that Peter has written to test the API. The primary client that he’s used to test his implementation is a Google Play application, which was developed utilizing a MVC framework. While a very, very simple client, it’s a great first step I think that shows some of the benefits of separating the interface development away from the core repository functionality, as changes related to the API or development around the API no longer require recompiling the entire repository stack.
Anyway – Peter’s work and his notes can be found as part of this GitHub pull request. https://github.com/DSpace/DSpace/pull/323. Here’s hoping that either through Peter’s work, or new development, or a combination of the two; we will see the inclusion of a REST API in the next release of the DSpace application.
I’ve posted the latest MarcEdit update. This update includes the following:
- Bug Fix: UTF-8 to MARC-8 Conversion: When converting specific characters from the Extended Arabic set from UTF-8 to MARC-8, some data translations were embedding null characters between translated data characters. This has been corrected.
- Enhancement: Generate Call Numbers Tool: Generate FAST Headings has been added to this tool.
- New Feature: Generate FAST Headings: A stand alone tool for Generating FAST Headings.
- Enhancement: Generate Call Numbers Tool: Made some enhancements to improve very specific call number selections.
- Enhancement: New Preference Tab: OCLC API Settings — MarcEdit’s direct integration components will require users to obtain a developer’s key from OCLC. To facilitate this process, I’m rolling this out in two phases. Phase 1 is the integration with FAST and the preference addition (with links to how to obtain a key). Phase 2 will be the inclusion of a batch holdings tool, as well as the ability to interact directly with OCLC’s WorldCat.
Couple of notes:
- FAST Generation utilizes a handful of web services to allow MarcEdit to automatically poll OCLC about specific records and return suggested headings. Not all records will have headings suggested to it, but you should find that the same level of coverage for data found in the Call Number Tool will be found with the FAST Tool.
- Secondly, with the FAST Generation, this process does come with a cost. Using the FAST Services requires much more data to be sent from OCLC, and from what I can tell, it appears that generating the FAST headings as part of say, the Call Number service, increases execution time on OCLC’s side. So be aware that this process does include a built-in time cost.
- I’ve been spending the past few weeks working with folks from OCLC on integrating MarcEdit with the OCLC Metadata API. I have created a C# library and will be writing up some notes on that shortly as I finish getting things checked into GitHub. This API wrapper will be the bridge that enables MarcEdit to interact with the API. My intention is to provide both MarcEdit application facing integration, as well as provide access to this API wrapper through MarcEdit’s COM API for users interested in utilizing the wrapper within their own applications or as part of a scripting language.
- As noted in the Enhancement note, I”m rolling out integration in two phases. One of the things that I don’t think many catalogers will realize is that to utilize OCLC’s web services, you need to get a special key from the developer’s network. This is different than the username/password that one uses to access any of OCLC’s other cataloging services. Because I doubt many people will have these keys up front, I’ve included a new preferences section in this release that includes information on how you obtain a key from the OCLC’s Developer Network, as well as a place to store the information. In the next update, I will complete the integration, and activate the Key Validation, which will activate the new tools dedicated around interaction with the WorldCat Database. The ETA to complete this work is likely 7 days as I’ve done the work, but have not finished writing all the unit tests.
For the new update, you can pick it up through MarcEdit’s automatic updater, or by downloading the version directly at:
I got a reminder from Oregon State University that my old web space will be disabled this weekend. I’ve since moved all the content to a new location, but be aware that it will likely take the search engines some time to update these redirects since so many people linked to the older URLs.
I’ve also nearly migrated most of the other content simply to: http://reeset.net.