I’m glad I found your site. I’m a mac user, and was on the verge of buying a PC laptop to help my mom with some cataloging, since I didn’t think MarcEdit was available for my mac.

I’m running 10.6.8 and found your Youtube video for installing MarcEdit. I followed it step by step while also following the INSTALL.txt from the MarcEdit download (version 5.5?). It was somewhat easy to follow, but it definitely took some time since I never go into the Terminal. I did notice that the INSTALL.txt didn’t match the one in your video, so I followed the INSTALL.txt instructions more closely.

In the end, I got MarcEdit installed and was able to open it, but no records show when I tried doing a search for “map of oregon” the same way you did it on your tutorial video. I’m not sure where I went wrong. Terminal procedures/commands are a completely foreign language to me and I don’t want to get myself into any deeper trouble by trying to guess fixes.

I would appreciate your help because I need to get MarcEdit up and running ASAP in order to complete the work which will be given to me. Thanks so much for your time and consideration.

Yours,
GN

Instead of Macports, I’d suggest taking a look at Homebrew – you may find it more convenient for this. For example, in Homebrew yaz has minimal package dependencies and builds in about a minute.

One of the things that I’d like to work on is how to provide better automated updating of these components as well. It looks like Ohio State has some testing machines (one a mac) that I might be able to take advantage of to look at doing some of that kind of work as well. I’ve actually gone back and forth on investing more time in this because I’ve not been sure the direction the Mono team was going to go (since they seemed to be primarily concerned with Linux compatibility) — but there’s been a lot of work lately done cleaning up Mac issues, so I’m feeling better about taking another look at this.

–tr

You’re absolutely right! This is especially a problem with MARC records encoded in the elusive MARC8 character set, but our only option is to export or process that data in another characters set, usually UTF-8. Plus, not all MARC data is in MARC formatting – it’s just data. I’m dealing with this problem now. Your MARCEdit tool has been absolutely a godsend with the ability to convert characters in the clipboard! Thanks for your continued development of it.

Mark

In practical terms — yes — mixing the two character encoding streams isn’t optimal. This is why I have always enforced, for practical term, this notion that if you were working with UTF8 encoded data — you are not allowed to encode data into MARC records using either NRC notations or ALA mnemonics. The reason is that these values often exist to support MARC8 character sets, so the data transposes into MARC8 entities. Unfortunately, this is how data comes to librarians (how the data is generated, I’m not sure) and, yes, some folks have become accustomed to referring to data using the MARC8 mnemonics — so for their workflows — even when dealing with UTF8 data — they would rather use the MARC8 entities because it doesn’t require hunting down the UTF8 key in a key map.

Since the data exists (more than I’d like — especially when you start looking at data outside of MARC21 and look at the larger bibliographic universe) and those workflows exist — I’ve been looking for a way to ensure that MarcEdit can accommodate this particular use case, and protect the integrity of the records so that folks that are doing this, are not creating data that cannot be read by other systems since another system will pick a character set and either flatten or mangle the data appropriately.

I will disagree that there isn’t a reliable way to determine character sets of the data as long as you make some assumptions. MarcEdit uses a heuristic approach to character set analysis that allows it to make some better guessing than most to determine if a character is in MARC8 or UTF8. This is part of the reason it can correct this data on the fly.

But your point is taken. This wasn’t an endorsement of any particular workflow or way of encoding data. Nor was it an endorsement that people should be mixing character encodings within records. It was more of a missive that I’ve come up with what I believe will be an adequate solution for dealing with a problem that already exists within the bibliographic community.

–tr

(even if i’m misunderstanding what’s going on, the fact that some cataloging/metadata librarians still don’t understand the basic fact that mixing utf8 and marc8 in a record is by definition corrupt… makes it dangerous to title your post “dealing with data in mixed character sets” as if mixing character encodings is an okay thing!)