 Oh hello everyone. So a digital photo, a document typed in word, an mp3 file, all stand alone born digital objects. The sector has a pretty good understanding of how to catalog these types of objects, largely because they have analog equivalents that have varied in format for years. The daguerreotype, the album in print, the color photograph, and the JPEG are all just different formats of the same type of content, but cataloging gets confusing when you have nothing familiar to equate it to. In 2009, Canterbury Museum was approached by NASA about the donation of the first satellite tracking dish used by NASA in the Antarctic from 1984 to 1993. The accompanying exhibit, which was then on display at the Antarctica Traction in Christchurch, was also offered at the same time. From the start it was clear that the satellite and its base were of interest, and curators were convinced that there was valuable information in the exhibition, but they just weren't sure how to describe it. I'll talk you through our thought process and the conclusions we arrived at, but first I'll give you a little background on the acquisitions process at the Canterbury Museum. Any object offered to the museum goes through the acquisitions process. The objects first put on an object receipt form, which when signed transfers ownership of the object to the museum. Next, the assigned curator writes a proposal about why the object is or is not suitable for the collection. The proposals then brought force to the acquisitions team, which means monthly. This team is made up of curators, registration staff, the director, and the manager best practice. The team then votes on whether the object should become part of the collection based on the proposal. And then once that happens, it's assigned a accession number and it goes into the collection. Part of the proposal process involves selecting a collection status for the objects. The museum has three internal classifications, permanent, information, and ceremonial. Objects in the permanent collection can be used for research and display, and they're eligible for conservation treatment if required. The information collection is mainly for hands-on items used by the Education Department or books used for research. The ceremonial collection is reserved for objects that might be loaned on short-term notice for a tangy or a similar event. The museum also has a set of internal data standards that dictate how objects are described and counted on the database. The count determines whether an object has one record with multiple parts, such as a T-set, or what if the object gets multiple records, like a photo album where every image gets its own record. And it's clear that the satellite was one object with multiple parts. You've got the satellite, you've got the base. But what about all this exhibition material, which includes these interactives here and these text panels? It gets a bit tricky. So the first iteration identified 17 objects, which you'll see there. Here the software is described as digital files and the hardware is described as computer. However, the acquisitions team felt that this description didn't make it clear that the acquisition actually consisted of a satellite tracking dish and a display. So it was re-described to make that distinction clear. Whereas before the computers on their implied parts were listed together, the cables and the monitors on the towers were now listed separately. And all the digital files were listed together, no longer recognizing the fact that there had been two separate gallery cask interactives. So if you go back here, you've got one there and another one there. So they were all lumped together. At this point in time, the digital collective policy was being drafted. The policy in its draft form states that all digital material was to be renamed by its accession number and stored in up to three different places on the museum service for backup. The digital files took up a huge amount of space on the servers, prompting a re-examination of the acquisition and how it was catalogued and stored. In November 2012, an acquisition review was carried out that raised some valid questions. What was the justification for retaining the object? Was it meant to be a functional exhibit or a non functioning prop? Was it important as a research tool? What about the long term preservation of obsolete software? Should they migrate the data to new formats? What were the costs and logistical implications of keeping the software functional? How long would it take to label and catalog 2,180 digital files folders? The content of the exhibit was the main interest. With the server space being a major concern, it was recommended that all files not necessary for the operation of the cask be removed from the backup drive. Similarly, if the touchscreens were intended as non functioning props, their operating files should also be removed from the server. Any functional images, video and text files were to be cataloged individually and renamed as per the conventions in the draft digital policy. A separate drive would be established for digital collection items, a second drive would store high resolution copies, and a third would store easily accessible low resolution copies for research access. Staff were now determined with staff were now tasked with determining which files were essential. Opening the digital files revealed a complex file structure. Were these folders essential or just packing? Packaging? What about the files that don't open? Are they broken or just an obsolete formats? What about copyright? These look like images from other institutions. Can we legally collect these and reuse them? As for the hardware, which cable goes with which monitor? Enlisting the help of the museum's IT staff person curators work to reassemble the units. Our surprise, some of the cables didn't work. Myson keyboard had to be plugged in to calibrate the screen. So to use this interactive, you had to press over here to get this part to work. So that was a bit of a surprise, but we did manage to calibrate one of them. The plugging in the mouse and the keyboard to do so loaded on a new driver. Had we just changed the original object? When we tried to run the programs, we discovered one kept glitching and it was essentially non functional. After several months of discussion and debate, it was concluded that the museum wanted to preserve a functional example of an early 2000s display. This meant kiosk.jar, this one, which was essentially non functioning and its associated hardware were nowhere needed. That's reducing the amount of space on the server. Now, according to the draft digital policy, all these files which I showed you here were supposed to be renamed with their accession number and part number. But there was some concern that that might mess up all the formatting and not allow the different parts of the software to talk to each other. Communicating this concern wasn't easy. Even though we all used computers, we're not familiar with how they work. So this is what was left of the functioning hardware. We did still need to add a couple pieces. So we started to think of some analogies that might help us clarify why we shouldn't be renaming all those files. So our first analogy was it's like a book. If you rename all those files, it's like ripping out all the pages and storing them separately. But then there's the caveat and this is from our collection that this book has inserts which are numbered as parts that can be pulled out and they've been numbered in case they get separated so we can put them back in. Not a good example. Then we tried a bag of archaeology. Now at the Canterbury Museum, we treat these as one whole. So it'll just be like a bag of charts from this site and they're not separated. They're not counted separately. This seemed to go over much better. But then there's the issue of needing to add a mouse and a keyboard and speakers and functioning cables. Curators recommended that the hardware be part of the information collection so we could easily change the parts and update it. But the acquisitions team was uncomfortable with this. They emphasize that the information collection is really meant for educational hands-on items and research books. This prompted discussion about whether adding a mouse and the driver to run that mouse counted as conservation. A member of staff pointed out that several carvings, part of the permanent collection currently on display, had had new power eyes put in. This was done in consultation with Iwi and everyone had agreed it was the right step. So with concerns about altering the objects of the lab, the acquisition was classified as part of the permanent collection with the caveat that we can add parts to make it functional. So there it is, reclassified. Fortunately, it's not just the Canterbury Museum that's had trouble wrapping its head around how to describe software. Matthew Fuller identifies it as a blind spot within the broader realm of cultural studies relating to computers. In his book, Software Studies, a lexicon. While current catalog standards may record what an object is in broad terms and where it's stored, this may not be enough and this is something we've touched on today. Of course, the first and the second edition book are different, but you access them more or less the same way. That may not be the same case for version one and version two of Piece of Software. So we need to record that kind of information so that future researchers can source emulators or hardware. One reason for this blind spot may be that software is often just seen as a tool without much thought going into the intentions of its use or why it was made. Matthew Kirschenbaum at the Maryland Institute of Technology has identified 14 different types of software based on the use and the purposes they were created. So he has software as acid, package, shrink wrap, notation, object, crap, craft, so for the tongue, epigraphy, cliff crap, hardware, social media, background, paper trail, service, and big data. Now, so there's one example. This is from the Library of Congress and they cataloged it as shrink wrap, but that doesn't really suit our example because it's a one-off piece of software that lives on a PC from circa 2003. So we see it as an object at the museum, but since it's a one-off, it's an artisanal product or software as craft. So basically, in summary, we've determined that it's very important to describe any system requirements running with the software, any cultural context surrounding it, but there's one question that I'm still not sure about. What about all those folders and files in the software? Do I have to count them as parts? Are there any questions? Discussions? Is anyone confused? I find it interesting that he looked at kind of cataloging published material when I kind of see this as being kind of an unpublished terrain and from my point of view, why he didn't consider looking at archival sort of principles like for instance, we would never alter the original order and we would never rename. Sort of playing with actually you change the authenticity of the items that you're dealing with once you're ultimately doing that, it goes back to our key principles. But yeah, just wondering why you looked at books as an example. When we look at collections, like large collections of huge, harbored collections that we deal with currently, and that's the vast norms that we deal with nowadays. But yeah. I think it's partially because our draft digital policy just didn't get finished and it only talks about Word documents and standalone digital, like JPEGs and things like that. And we were also trying to draw on the expertise and familiarity of the team. So there wasn't necessarily an archival knowledge on the team, so making that analogy wasn't very helpful. So we tried to go with the books, thinking about all the horror of pages getting ripped out and thought that might have an impact. Because I deal with thousands and thousands of books with numerical like crazy file structures and you know, it goes on and on and on, like totally undisciplined as far as what we file for them to get as well and you know, in the hit sales produce that are hyperlinked in between different documents within the system. You know, they're not just one bit, it's just the huge context around it. Good to know that there are other options out there. Is the draft strategy going to be completed? And would you like some help? Yes, I would like some help. Yes, I would very much like some help. What happened is our registrar came from Canada and decided he didn't like New Zealand. So he went home before finishing it. So we have a new registrar. Because I think, you know, you're not likely to say you're not the first person to go through this and we should actually be sharing some of these ideas because I would have said exactly the same thing, but you do not rename the file. And that actually, recording as much information about every individual file, like the file size and the checksum and the format type and all those kinds of things is essential. It's a lot of work, but there are tools that have been developed to actually help automate it. That would be helpful to know too. So I guess it's, you know, we have been talking to each other a lot to talk about in the library, but we don't get into the other cities quite so much, so it's useful for us to know that. Yes, so there's definitely an interest in Canterbury. It's not just Canterbury Museum that has an interest. We'll edit that camp a couple of weeks ago, talking to similar sector people. There was definitely questions about this and presented a similar topic and everyone was just as perplexed. So we could use some expertise and some advice. And this is kind of like being such a hybrid object. Yes. This is physical and digital. Yeah. It's dealing with lots of formats of technology and that kind of thing. It is really difficult. Like the typescreen obviously isn't going to work in 20 years. So how do you replace it? What do you replace it with? And that's kind of like how we deal with artworks. So we acquire sort of hybrid artworks that have digital components, physical components. And so we've got to see the questions that we go through that help us make decisions around what to connect and what not to connect. So... That would be fantastic. We'll talk later. Great. Is there any other question? Thanks, Gerona. That's actually a question for Adrienne and Toria. Go ahead. Yeah. Just on there, with Jonas, Antarctica, and Kasia. Do you guys... How do you deal with that? I mean, if... The idea isn't to play it in a simple year's time. Do you use emulation or how do you store it? I mean, you bet. Well, I mean, we... We... At this stage, we would probably... Because we're not using emulation now. It could be, like, maybe two or three weeks and it could go on. So we'll record as much as possible. So things like actually reporting what the operating system is, the hardware that needs to run at that time. There's much information in the context that you can need to not collect them because you need to know that if you are not stimulated so that you can rebuild a virtual machine, that you retain a bit stream as much as you can so don't change it but document everything so that you at least have the original. Right now, we may not have the solution for doing it, but if we've got as much information that can later, then we might be able to do this. Still a risk of losing it. But you just, the thing about digital and the high-precision is documentation, documentation, documentation. Taking photos of a book and recording what the actual interaction is. Things like understanding that if you use the knowledge not calibrated here, she needs to know. So here, that's a non-issue so that you record there as well. It seems really daunting but then it becomes a collecting question should you collect it. If you're collecting it and you don't think you're actually going to be able to do it after the implementation given to somebody else or just predicting that the public hands are at risk of making costs for these things. Yeah, yeah, that doesn't talk much to you. Yeah, and just like you can't not use that. Like if we've done mistakes and we've probably acknowledged that you know probably certain things that we actually can deliver on provide access to like a huge issue for us currently is providing access to email clients. As we have, I don't know, everyone knows or the standard ones but we've got ones that are long since the Thunderbird but I don't know anyone's heard of that but you know and it's incredibly complex you know those are moving parts that are similar in a lot of ways because you need yeah, that there's huge and complex issues around digital logic in itself you know and the hyperventure of them as well but you just can't understand my documentation and you don't know like in how many years come how useful that documentation's going to be so you always have to take it straight away and like you were talking about you went to Sturkey damaged the files in the process so we do a process of we make right blocking things before we copy anything across to our system so we can have a verification process so we know that we haven't definitely 100% certainly haven't altered anything to do with those digital files once again. So, thank you Vint Joanna, that was good, thank you very much.