Cataloguing removable media

 Up at the Athenaeum, people are increasingly donating USB sticks containing family history information. Usually as well as family trees, they contained scanned photographs and documents including birth death and marriage certificates as well as immigration records and picture pages from old passports.

All valuable stuff.

And it's not a rare ocurrence today we had two in the space of half an hour.

In some cases they come with some quite detailed documentation, with the best following all the guidelines as regards human readable filenames for directories and files and providing some descriptive information.

Others, perhaps less so, and we need to think about how we document them.

For the moment we need a little procedure to ensure that we catalogue and record the items in a standard way, so that we can keep the USB sticks safely, and make sure that the connection between any printed documentation and the USB is preserved.

After all, people have entrusted us to look after their family history research and it is the very least we can do is look after it for them in as professional a way as possible.

It has also revealed that we didn't actually have a procedure for managing donated electronic material, so I made one up.

As a procedure it owes something to the procedure we developed some years ago for ingesting field research data when I was at ANU, and people would bring us data that they wanted to archive, examples include species abundance data and digitised historical documents.

The difference here is that at the Athenaeum we have no content management solution - while the data may eventually end up in Victorian Collections or Trove at the moment our focus is simply on the safe storage of the donated data.

 When I wrote the procedure I had in mind the differing skill levels of our volunteers, so I tried to make it as mechanical as possible and not too different from the way we ingest data about aretfacts - the draft is available to download as a pdf.

The document is very much a work in progress, and may be subject to revision. In the meantime, please feel free to take a look, and reuse the content if it seems appropriate.

Ipads versus Android tablets

 Just under a year ago, I bought myself a refurbished iPad as some applications had stopped working on my pandemic era Huawei MediaPad, basically due to it being stuck on an old version of Android.

I expected that over the course of this year I'd gradually change over to using the iPad exclusively, and the MediaPad would go to the ewaste centre.

A great pity, as it is an excellent device, but facts have to be faced, and Apple own the tablet space in Australia and Android devices are not even a minority sport.

However, due to my being a total gonk and failing to realise that if you buy a subscription to a news website through Google, in most cases you only get access to the Android app, I've kept on using the Huawei to read the news in the morning and check the weather.

This has given me an opportunity to compare both devices over the longer term.

Tablets don't really have to do much other than run an application, download and display content, so things like memory and processor power are not important - as long as they have enough to do the job in a timely manner it doesn't matter if one has a higher performance benchmark than the other.

In fact both are roughly the same age and roughly the same specification - the Huawei has a bit more memory - certainly you don't feel any significant difference in performance when using YouTube or Spotify.

Where you do see a difference is in switching between applications or indeed cutting and pasting content between the two.

The iPad is simply clunkier. It does the job, but it's clunkier, and I put this down to the fact that Android is inherently multi tasking, while older versions of iPadOs are not.

This isn't a showstopper by any means - if all you want is a device to review documents on or watch videos, you probably don't care that much.

Strangely, the one real differentiator is long term operating system support - Apple are still pushing out updates for a five year old device while the MediaPad has dropped off Huawei's update list.

So, if I was to go out and buy a replacement device today, which would it be?

A current model iPad brought from Apple in Australia is A$600, meanwhile the current Honor Pad is around A$550 bought from Amazon in Australia. (Since I bought my MediaPad, Huawei have both rebranded their phone and tablet business unit as Honor and sold it to another Chinese electronics manufacturer to avoid US sanctions on the Huawei parent company) 

Amazon also sell grey market imports of the previous Honor Pad, the 8a, for around A$250. The 8a is based around Android 14,  which is still supported.

Given the price advantage of the grey market import of the previous model, I think that's the one I would go for, if I wanted a new and competent device and didn't want to spend six hundred bucks on a tablet.

Refurbished Huawei and Honor devices are not really an option - you're unlikely to get any operating system updates. Refurbished iPads are competent, but more recent models attract a price premium meaning there's little advantage over buying new.

So, there we have it. As always your mileage may vary, especially depending exactly how you intend to use the device. What I would steer clear of are some of the remaindered Huawei branded mediapads floating around various online marketplaces - the supported operating systems are simply too old, even though the hardware is still good and performs well.

Guerilla cataloguing - part 0

 I've mentioned before that we planned to recatalogue the heritage book collection using LibraryThing, the heritage book collection being the contents of the Athenaeum when it functioned as the town library in Stanley.

As far as we can tell, they hardly ever deaccessioned anything giving us a picture of changing reading tastes from sometime around 1862 to 1971 when it ceased to function as a library.

Actually, I suspect tastes haven't changed much, given the number of early copies we have of novels by Louisa M Alcott, Mary Elizabeth Braddon, Wilkie Collins and the rest - clearly the nineteenth century subscribers to the library had same liking for mysteries and sensation novels as we do today.

Until we try it, we've no real idea how well recataloguing with LibraryThing and our proposed methdology is going to work.

To refine and document our procedures we are going to run a pilot project on a few shelves to see how well it works and if it works well, we'll turn it into a guerilla project where we basically just do it, and don't worry overmuch about deadlines or formal project plans.

There is an intention to try and get other people involved so we can turn the project round fairly quickly, so we do need a simple and robust set of procedures so we can bring people on board and get them up to speed - quite different from the documentation of Dow's and Lake View where there was only me and the main reason for documenting procedures was to avoid drift and capture any changes to the methdology.

So today it was part 0 of the exercise - creating an account on LibraryThing for the Athenaeum, and as part of what we want out of it is a set of MARC records to allow us to port the catalogued data to another library system, identify some tools for verifying and manipulating MARC records, especially as instead of class marks or any standard cataloguing scheme, the original spreadsheet used shelf position.

This is worse than it sounds - for the thirdmost book from the left on the front row of shelf C the shelfmark is C3F, and the thirdmost book from the left on the rear row the shelfmark is C3B. Unfortunately there's no guarantee that there are the same number of books in the front and back rows - as a scheme it's almost as eccentric as the Cotton Collection classification scheme.

So basically, we need to be able to validate the MARC output.

MARC is a binary format dating from the early days of library computing and, like BibTeX, is essentially a lowest common denominator format, ie one most other systems can read and process.

So, what we need is a utility that can read the binary MARC file and display the file in a human readable form - something that with MARC is a bit of an exaggeration.

Now, the last time I did any serious work with MARC was twenty years ago when I wrote a simple parser in Perl to take a set of MARC records and format them so that the records looked like old fashioned card catalogue images.

I forget why I was asked to do this, but I remember looking out at the rain coming down on the museum car park while I fiddled with regular expressions.

So we needed something to let us examine the contents of MARC files, and given that we have a budget of zero dollars and zero cents for this exercise it had to be both free and public domain.

Well, there's not a lot of choice - basically it seems to come down to Terry Reese's MarcEdit, which has the merit of being endorsed by the Library of Congress, FastMRCView, produced by the Russian State Library (formerly the Lenin Library) in Moscow, and the online only MRV MARC Record viewer.

Otherwise there don't seem to be a lot of options out there, but it's quite possible that I've missed a couple of other public domain applications, but playing with MARC seems to be very much a minority sport. 

I've decided, quite unilaterally to go with both MarcEdit and FastMRCView in the pilot and compare the output, while both seem to do what it says on the tin, there's always a risk that one application interprets the data slightly differently from another.

FastMRCView is a windows only application, while MarcEdit comes in Windows, Linux and OS X flavours. As most of the prior work on the catalogue has been done on windows there's no pressing need to change operating systems.

So, we have our account and some software that looks as if it might help with the gnarly stuff, all that remains is try and see is how well our proposed methodology works in practice ...

Changes to blogger.com

 Google appears to have decided that the way to improve the blogger experience is to add some AI generated stuff to it - see the following couple of screenshots

I'm doubtful about this, especially the latter option given that Google's AI enabled search often gets things wrong if it's an obscure topic (like the ones I post on).

As to what a 'Google experience' constitutes, I'm not sure.

For this reason I'm going to ignore these new options for the moment ...

 

Plant remains in heritage books

 Up at the Athenaeum today we had a little conundrum.

We had been donated a book dating from the early 1870s, which had been given as a Sunday School prize to a member of a local family still resident in the area.

The book's exact provenance is unknown - there are some markings in pencil that suggest that at some time it had been resold in a second hand book store, but there's no doubt about its origins - the original dedication is intact which gives the name of the recipient, the date, and the location - in this case Three Mile, a now vanished mining settlement on the outside of Beechworth.

Unfortunately, the book is a wreck. The spine's is broken, there are loose pages, possible insect damage, and foxing, and is probably not worth conserving, but might be worth retaining as is because of its local connection, especially as the family still live in the area.

But when I was leafing through it to check for damage I found this

someone had at some point put a small plant inside, possibly as a keepsake or a bookmark.

Now, if we decided to preserve the book because of its connection to a local family, rather than simply photographing the dedication on the fly leaf, what do we do about the plant remains?

Well I didn't know. Google was singularly useless, so I appealed to mastodon.

No one replied, but I had a brainwave.

When I was a much younger man, I had a girlfriend who was a field botanist.

When we went for a bushwalk, if she found an interesting plant she hadn't seen before she would take a sample, wrap it in a bit of newsprint and put it inside a field guide for later identification.

Putting it inside a field guide kept the sample flat and the newsprint absorbed the moisture (more or less).

Proper herbaria - reference collections of dried plants - are a little more elaborate, but not by much, with the plants being pressed flat on absorbent acid free paper and then transferred to a fresh sheet of archival paper and attached with archive quality paper tape and then stored in a sleeve or folder.

And this gave me an answer to my own question

1) transfer item to sheet of archival paper
2) secure in place with archival tape
3) photograph, document etc
4) fold paper to make a packet without damaging the item
5) place in archival storage box in labelled acid free or tyvek envelope

Given that the book is so damaged if we decided to retain it would probably make sense to tie it up with cotton tape and place in an archive box, in which case we would simply put the plant packet in the box along with the book, that way we keep the association between the two objects ...

 

Of internet speeds past

 This morning I tooted that our internet speed had jumped to about half a gig, something that is quite amazing in terms of infrastructure for rural Victoria. Admittedly it's only that fast on download, upload speeds are still comparatively slow

but basically fast enough that you really don't need to worry about speed and latency when moving data about. In fact, compared to my first year documenting Dow's when I would upload my days work, typically 70 or 80 jpegs and and a few spreadsheets, at home, I would flood our ADSL connection, it seems pretty magical.

Then, I couldn't actually upload the data at Dow's, the internet was simply too slow down there, so I ended up resorting to sneakernet and saving my work to a USB drive before uploading it at home.

At the time that our fast ADSL connection seemed fairly zippy, especially compared to our house in Canberra where our ADSL connection was incredibly slow and I ended up investing in a 3G router that was plugged into the ISP's modem.

The 3G router used a USB stick modem to connect to the internet, but could be configured to use the ethernet connection to the ISP's modem by default and only fail over to the 3G connection if our rather flaky connection over the old copper wire phone system went away - which it did every time in rained

The fact the phone cable went via our neighbour's apple tree probably didn't help much either..

Before then we had dialup over a 56k modem.

But that wasn't our first dialup internet.

Around 1990 or 1991 I bought a Global Village Teleport Bronze 2400 baud modem which I plugged into the back of my Mac Classic.

There was something quite magical then about being able to open a terminal session and log into the dialup gateway of the university where I then worked and check the health of servers, send emails, and upload and download documents to work on at home.

This was at a time before the worldwide web and text based systems such as gopher were as sophisticated as it got, and there were no real ISPs (in fact we had to shoot down a thought bubble from marketing about starting an ISP in the mid nineties, instead we used to suggest that people use the British Library's service which was a rebadged version of one of the big commercial ISPs.)

It was of course a simpler time.

Letters still came in the mail, and if you needed to order something you either sent the order in the mail, or if it was urgent, by fax, and the internet was really still just an academic plaything.

Contrast that to today, where the internet is essential to just about everything we do, as was shown in the case of Tonga when a volcanic eruption not only cut off the connection to the rest of the planet, but between the main island and outlying islands.

The loss of the internet was crippling, all the more so because the previous satellite based service had been abandoned because the new service was just so much better, and everything, and I mean everything went via the now broken undersea cable ...