An interesting question brought up by David Seaman here at the Readex Digital Institute.  David provided the opening keynote for the conference and in it, discussed a process that Dartmouth College went through this year to consider how the library can become more nimble within our networked world.  How the library can be given a license, if you will, to allow the library to release services that aren't perfect and are iterative in their development cycle.  And while I can certainly get where David is coming from, I don't think that the logical outcome is a service model that lives within perpetual beta.

I think that part my objection to this phrase comes from my development background.  As a developer, I'm a firm believer in a very iterative approach to development.  Those that use MarcEdit can probably attest (sometimes to their dismay) that updates can come with varying frequency as the program adapts to changes within the metadata community.  Since MarcEdit doesn't follow a point release cycle in the traditional sense, could it be a beta application?  I guess that might depend on your definition of beta -- as it certainly would seem to meet the criteria that Google applies to many of it's services.  However, there is a difference I think.  While I take an iterative approach to development, I also want to convey to users that I will support this resource into the future and as beta, that's not the case.  My personal opinion is that services that languish in beta are doing two things:

1. telling users that these services are potentially not long-term, so they could be gone tomorrow
2. giving users a weak apology for the problems that might exist in the software (and deflecting blame for those issues, because hey, it's beta).

So, I don't see this as the road to nimble development.  Instead, when I heard David's talk, I heard something else.  I believe libraries fail to innovate because as a group we are insecure that our users will leave us if we fail.  And when I hear talks like David's, that's what I'm hearing his organization say.  They are asking the library administrators for permission to fail, because what is technological research but a string of failures in search for a solution.  We learn through our failures, but I think that as a community, our fear of failing before our users can paralysis us.  The fear of failing before an administration that does not support this type of research and discover can paralysis innovation by smart, energetic people within an organization.  A lot of people, I think, look at Google, their labs, their beta services and say, yes, that is a model that we should emulate.  But they don't fully understand I think that within this model, Google builds failure as an acceptable outcome into their development plan.  If libraries want to emulate anything from the Googles or the Microsofts of the world, they should emulate that and engender that type of discovery and research within their libraries. 

I am actually very fortunate at Oregon State University in that I have a director and an administration that understands that for our library to meet the needs of our users now and in the future, we cannot be standing still.  And while the path we might take might not always be the correct one, the point is that we are always moving and always learning and refining our understanding of what our users want today and tomorrow.  What I'd like to see for David's library is that kind of environment -- and I wish him luck in it.

--TR

I don't usually post information about pending updates, but I want to prep users for an upcoming change.  In all versions of MarcEdit, the application installs all application and configuration files by default to the Program Files/MarcEdit 5.0/ directory.  To help make MarcEdit friendlier for Vista/Group managed XP systems, the next build is going to separate the program files from the configuration files.  Why do this?  Well, in Vista and Group managed XP based systems, the Program Files directory is set as read-only for all users but workstation administrators and for the first time, I'm seeing a tipping point where more users are not doing everyday tasks logged in as administrators. 

Unfortunately, making this work in MarcEdit is tricky only because of the large established user-base and some other application needs so I've been taking my time trying to work out a process that will be pretty much transparent to the user.  In the coming update, the MarcEdit application will be doing three things:

1) On install, it will migrate your current configurations to the Roaming User application program (XP: c:\documents and settings\[user]\application settings\MarcEdit

2) On Install, MarcEdit will keep a shadow copy of your configuration files in the MarcEdit program directory/shadow.  These file essentially will be used for back-up purposes.

3) Remove the current directories at the program files/marcedit 5.0/ level (since they will be migrated and backed-up).

At present, I have a number of users that are trying out the new migration process and providing feedback so by the time this makes it out as an update, the process shouldn't be noticeable.  When I post this update (soon), I'll include an update on the migration process as well as a few shortcuts and diagnostic links that will be included to help get users to these user files quicker when needed (for example, if there's a need to modify xslt files).

--TR

While I'll have to admit that much of my time over the past two months has been sucked up by other commitments (like preparing my dosier for my six year review), I have had some time to make some significant changes to MarcEdit -- at least -- some significant changes to parts of the MarcEdit application.  For this update, here's what's changed:

1. Plug-ins:
1. The OCLC Connexion helper plug-in has been expanded to include more information from the Connexion menu screens.  So, for example, the old plug-in use to just pull title and control numbers.  Now, the plug-in includes addition data like other language titles, date, holdings, holdings count, My status, material format and Workflow value.  I've also added a simple search function that will allow users to select items for edit using simple in string matching and regular expression matching.  I think that the search functionality will be a big improvement for users working with integrated save files, but I'm a little worried that it might not be granular enough.  If that's the case, let me know.   As with the previous updates, to install the new version, uninstall the old plug-in, restart MarcEdit, install the new plug-in and then restart MarcEdit.  I've still got to make this process easier. :)
2. I've also been working on a second plug-in.  This is the CONTENTdm Helper Plug-in.  For those of you at the Eastern CONTENTdm Usergroup -- you seen this plug-in in action.  Essentially, the plug-in is designed to allow users the ability to perform changes against the CONTENTdm desc.all file.  For those of you that don't use CONTENTdm, this is the file where CDM stores all it's metadata.  For the most part, editing this file is a big no-no since CDM uses an inverse file index (I would guess) to create pointers to physical locations in this metadata file.  Change the size of this file by a byte, and all the CDM indexes are invalidated.  This is unfortunate, because many times, what you want to do is edit this file directly and that's what this plug-in allows you to do.  Essentially, users can run simple find and replaces or more complicated Regular Expressions against this metadata file.  The plug-in manages the changes and uploads the modified data back to CDM in a method that CONTENTdm can handle.  This is a new plug-in.  I've used it at OSU, but I would certainly make a backup of the data in your index/description directory (particularly the desc.all and *.ind files before running the index.  I've yet to have it ruin one of my collections, but obviously, that's in my own controlled environment.  We'll see what happens once I get it into the wild.  My guess is that this should be completed by the end of the week.
2. Script Wizard:
• I've updated the script wizard correcting a few cases where scripts could generate syntax errors so that they won't run.  Fixing the scripts was easy enough (all you had to do was essentially delete a character), but this will fix that problem.
3. Z39.50:
• Not yet completed, but I'm updating the Z39.50 client so that you can now query up to 3 databases at one time.  This has required a change in the UI for the Z39.50 client.  Should be updated by the end of the week -- and once finished, I'd be curious to see what folks think of the new UI (and maybe suggestions for making it more intuitive)
4. URL Checker:

Lastly, if you have any big ideas for the next version of MarcEdit, let me know.  I'm starting to compile a list of big ideas for the next major release of MarcEdit.

--TR

I've made a few updates that fix a few things with the MARCEngine COM object as well as the Tab Delimited wizard.  The big changes are to the MarcEngine.  I'm slowly starting to roll a few changes into the application that will eventually be used for UniMARC conversions.  Also, I've made some changes to the default XSLT files to accommodate some of those changes as well.

You can download from: http://oregonstate.edu/~reeset/marcedit/software/development/MarcEdit51_Setup.exe

--TR

I've been doing a little bit of MarcEdit work, refining a few of the function to try to make the program a little smarter when it comes to doing what users are actually wanting to do, rather than what they are asking to do.  One case in point -- if a user has a set of MARC record that they want to work with in UTF8, the preferred workflow is to do the following:
* If the file is in MARC8, then running the file through the MarcBreaker, selecting the UTF8 option.  This translates the data into UTF8.  At this point, users can edit the records in the MarcEditor and then simply compile the data (once translated to UTF8, you never have to tell it to do that again.  MarcEdit actually deals with all data in UTF8, MARC8 is only supported as a legacy format) back to MARC.  This can be done from the MarcEditor, or by selecting the MarcMaker and simply compiling the data file (which out checking either the MARC8 or UTF8 options).

What I've run into lately is some questions by folks that have been running into problems with UTF8 encoded data due to the way that they are remaking the records.  A handful of users have been Breaking the records (using the UTF8 switch) and then remaking the records (using the UTF8 switch).  This is problematic in MarcEdit, because the assumption made when you check the UTF8 switch from the MarcMaker is that data is *not* in UTF8 so it treats the data as non-UTF8 data.  This flattens UTF8 data (if it is present).  However, that's obviously not the user's intent.  So, I've added some code that will essentially checks filestreams to see if what the user has asked the program to do is actually what they want to do.  In this case, if a user has a UTF8 encoded file and then checks UTF8 during the Making process -- the program will do a cursory check of the data before making assumptions about the data being processed. 

One additional note on this -- as noted above, MarcEdit does not assume MARC8.  So, if your data is in UTF8, there is no need to select the UTF8 switch.  These conversion switches really should only be selected if you have data in one format and you want to convert it to another.  For example, if you have data in MARC8 and you want to convert it to UTF8, then select the UTF8 switch.  If you have data in UTF8, but would like to have it converted to MARC8 -- then select the MARC8 switch.  If you have data in another format (like Big 5, etc.) then you want to use the MarcEdit Character Conversion tool to translate the data to UTF8, MARC8 or another character encoding.

Other updates...One biggy was some modifications to the Z39.50 client.  I'd made some changes previously that allowed you to edit records directly using Z39.50's extended services.  I've done a bit more work here so now you realistically could use MarcEdit as a cataloging client for something like Koha, a Zebra Server, etc.  Any server that supports the Extended Services should be able to utilize MarcEdit as a cataloging client for direct record maintenance.

OAI Harvesting  -- I've added some failback processing to help work with OAI servers that are may break their connections during harvest.

Obviously, other changes have been made (a few related to the installer when dealing with 64 bit versions of Vista). 

Download Files:

• MarcEdit Client: http://oregonstate.edu/~reeset/marcedit/software/development/MarcEdit51_Setup.exe
• MarcEdit Runtimes (primarily for developers): http://oregonstate.edu/~reeset/marcedit/software/development/MarcEdit51_Runtimes.exe

--TR

For those using this -- I've figured out how to get the Access connection to behave better, so now if you will be able to extract as many records as you need to edit and expect all updates to occur.  Prior, the plug-in would occasionally error out and an handful of records wouldn't get changed in the Connexion file.  This is fixed.  To update the Plugin -- open the plugin manager, delete the old Connexion plugin, then close MarcEdit.  Next, open MarcEdit, go to the plugin manager and download the updated version of the library.  Restart MarcEdit -- you are now using the current version of the plugin.

Source files for those interested: http://oregonstate.edu/~reeset/marcedit/software/development/plugins/source/oclc_helper.zip

--TR

Sorry I haven't gotten this up -- I'll post it tonight.

--TR