The project I worked on at MITH is up, MITH’s Vintage Computers. It’s a catalog and archive of the vintage computer systems and equipment at the center.
The goal is to demonstrate an intuitive and useful way to browse vintage systems. These are complex artifacts with numerous component pieces and software, each of various versions and iterations, with a wealth of important properties and functions, and all from many manufacturers and designers. No model yet exists for conveying this complexity in metadata records. Hopefully the site suggests the utility of such an endeavor, and is at least a little fun to browse.
I had an immense amount of help and support from all the folks at MITH, who shepherded the project start to finish. I can’t thank them enough for their support and expertise. But still: thanks everyone!
Work with Omeka soldiers on. As I write more PHP to handle the relational metadata on display for the site, I continue to notice some of constraints of my present setup:
The code specifying the functionality for recognition and categorization of relationship metadata (‘Is Part Of’, ‘Has Part’, ‘Connections’ and now ‘Sister Part’) is inside the custom theme. This is breaking the principle of content and display as separate operations that can mix and match. Thus if you take away the custom theme, none of the relationship functionality is present. This was not a strict division in the first place, but that’s even less so now.
Omeka does not provide a way to formally link objects together beyond grouping them into collections. While the Extended Dublin Core plugin provides useful dcterms like ‘hasPart’ and ‘isPartOf’, and while they can be expressed in RDF/XML, the Omeka system itself does not provide a way to hinge functionality upon such relationships. In fact the only way an item’s associated components are displayed is through some string manipulation of the item’s ‘isPartOf’ or ‘hasPart’ values. I cannot just ask Omeka for the related items.
Despite these constraints, I am not disappointed with the setup. I think Omeka’s presentation strength is perfectly suited to this work and to my timeframe. This particular project is about presenting a model that can be critiqued and shared. To that effect, the Turing test can (more or less) work here: if it operates now as fully functional, and appears semantic and scalable, then it has achieved the purpose. We don’t ask, “Is it extensible, interoperable, and semantic?” We just ask, “Does it work that way? Would such a system be worthwhile?” There is nothing on display now (on the local machine, that is) which could not be easily done elsewhere in a more robust, scalable way if it were deemed important enough to do it. I am thinking particularly of the Fedora repository, which I have worked with at the Goodwill Computer Museum, as well-suited to the sort of lateral, semantic relationships this model would provide.
Matt noted this sort of modeling as potentially useful for platform studies, and I imagine an entire linked database of such modeling, where one could index any number of machines by any number of properties and components, would help digital humanists examine machines or platforms across an array of creators and timespans, and would facilitate some easier groupings and associations.
In any case – going back, the first constraint is a matter of abstracting the code enough so that it can function as a plugin. Such an effort is considerable because the plugin would need to achieve the logical linking of items that the present implementation does not. My first instinct would be to directly manipulate the MySQL Omeka database, and insert foreign keys and such. And while doing this, one would want to keep the configurations flexible enough so that the plugin is of use to other Omeka users who need to define relationships in an entirely different way. It’s an interesting project, but also beyond the scope of this one I think.
Moving on, this week I’ve added a ‘Sister Parts’ display which shows components that are part of the current item’s container. The upside is more information on display, and faster browsing. The downside is more information on display (read: clutter!).
Beyond this, we are presently working on getting an instance on a live server for some broader access and viewing. Keep your fingers crossed.
This week I’ve been working with Omeka a good deal, experimenting with an approach to modeling and documenting a computer system through it.
I see two “issues” presently. The first is what metadata and what documentation needs to be provided for MITH’s purposes, the second is how to present and organize all this information.
It seems desirable to try and model hardware and computing systems through component pieces and parts. This allows one to describe the specific locations of a certain types of firmware and software, and it allows parcelling out documentation to a flexible level of granularity or generality depending upon the item being described (e.g. a motherboard, a ROM chip, a connector, a floppy, or a computer system).
For example Apple IIe systems either have Apple DOS or ProDOS on them. Specifically, that software is located on the PROM chip of the Disk II controller card, and it operates with Applesoft II BASIC, located on a ROM chip on the motherboard. What appears as a fluid interface on the screen is really two pieces of software in two different places, and each has a distinct history and properties. Articulating this distinction seems especially appropriate for organizations that will be using their systems for research and media access, and would like to assess the details of a machine or of media at a glance.
There isn’t an organization I’m aware of that is doing this for its audience or users at this point. It seems typical to document extensively at the level of the computer system. That is intuitive, especially in the timeframe that saw so many vertically-integrated personal computers (Commodores, Apples, IBMs) but the march of PC clones complicates that approach.
In another light one can see this as the popular ideal of the computer. For example, the iMac: it looks like it doesn’t have any parts, like it sprung from the forehead of Jobs, fully formed and completely capable. And it is pleasing to the eye.
Anyways, it’s been really edifying to do this research. Omeka’s API has been pretty capable for this sort of task too.
As an exploration in creating a limit case for computing equipment metadata, I have been documented Matt’s Apple IIe system to the fullest extent possible. The idea is to observe how much metadata can be reasonably gathered. From this body of data we may better understand what kind of metadata an institute would want on hand about the systems they curate or archive. It’s been fun.
By the way, the Wikipedia article on the Apple IIe erroneously lists ProDOS as the only OS for the system. Later versions shipped with that OS, but the unit originally shipped with Apple DOS 3.3, and the unit here is one such system. So I’ve changed that. Always good to remind myself that Wikipedia is not authoritative (and a little scary, given how much I use it).
This week I’ve also been examining Omeka. I think Omeka will be well-suited to the task of conveying MITH’s vintage computing resources in a compelling way for the general public, while also accommodating more technical or administrative metadata for use in-house. Omeka as a CMS has some very well developed strengths, and most are geared toward the presentation of museum objects as opposed to archival management of objects. I hope future development on the platform will look into easier data portability and interoperability with systems besides other Omeka instances.
For example, the Dublin Core Extended plugin is great, and as a bonus adds the ability to output an item’s Dublin Core record in RDF/XML. I have put in some trial PHP code to link to a display of this output, along with DCMES/XML and Omeka/XML. This is with the idea that a user may want to take this data and plug it in somewhere else.
A few impediments to this proposition exist right now. One is that other element sets which may be in use on the Omeka instance (such as CDWA Lite, upcoming VRA Core, etc.) will not show up in those DC outputs, though they will be present in Omeka/XML. It would be useful to export an item’s metadata, across all its element sets, to RDF/XML, since RDF is the functioning backbone of the Semantic Web and of Linked Data.
Second, HTML is allowed to fill a DC value. The developers have covered this feature/bug before, and it’s stated that the decision stems from the project’s emphasis on presentation. One could strip these tags with PHP’s strip_tags(), but you wouldn’t be left with a URI suitable for use in the Semantic Web necessarily. I’m keeping my eye on Patrick Murray-John’s Linked Open Omeka plugin in development, which tries to address these sorts of issues.
In any case, this is just an initial exploration of what Omeka does and doesn’t do, to understand the limits of the system. It’s a bit fine-grained for this point in the project.
Opened Apple IIe
So to pull it back a little, the real consideration at this point is development of relevant metadata for computing equipment. To my knowledge, no element set exists for this. There are certainly a number of ontologies describing a computer. On that note, one ontology finds computers under “Office Equipment.” Interestingly, the label at the bottom of the Apple IIe also states “Office Equipment.” Perhaps this is an industry scheme then? First guess is an FCC categorization, since I can’t imagine Apple self-applying the term.
In any case, these ontologies aren’t really geared toward either archival institutes which may use these computers for data recovery and access (and research), or museums which may want to describe them as cultural artifacts. So while the DC element set is suitable as a base, we’re open to other element sets with hierarchies (e.g. MODS) or a freeform exploratory generation of a new set. I really don’t think the need for such a set is going to go away soon for archives, as more and more find themselves taking in computing equipment as part of a fonds or as office equipment (ha) for the archive’s legacy media materials.
Here’s an update on the flippy disk problem for this week. In retrospect, that the reed switch was operating correctly was obvious: since wiring to the photo sensor was cut and rerouted to the reed switch and the regular side of the disks were being imaged, clearly the switch is operating correctly. Otherwise, the drive would error out for lack of a pulse for the index hole. (Slapping forehead.)
Instead the problem likely lays in the second, user-created write-unprotect notch. For the set of C64 disks at hand, these are circular and probably dealt with a hole punch. Using a disk with a larger unprotect notch (a straight-edged cut more similar to the manufacturer’s) did allow the FC5025 to read the flip side.
Manufacturer's write-unprotect notch
It seems then that the drive must detect a write-unprotect notch, or it will not be able to read any tracks. I have not located anything in the Fc5025 documentation indicating that it is unable to image write-protected disks, so it may be that rewiring the drive has introduced some logic which insists that an undetected write-unprotect notch prevent track reads.
Custom hole-punched write-unprotect notch
There is also a collection of Loadstar disks here. For the disks that have a second write-unprotect notch (all but a few out of about fifty disks), both sides have been imaged fine by the FC5025 in D64 image format. However, we are considering taking G64 images of these disks as well. This format may allow the transfer of data used in copy-protected schemes which would otherwise be overlooked by the D64 format. As I’ve been learning at the C64 Preservation Project and ShadowM’s Commodore 64 site, the Commodore 1541 drive has an I/O, ROM, RAM and CPU. Code can therefore be sent to the drive and this is the basis of very wide variety of copy-protection schemes embedded in the Group Code Recording encoding of the disks. These may range from data stored in the unused upper five tracks of C64 disks (tracks 35-40) to strange header and gap data and custom formats.
5.25" Drive Outfitted with Magnet, and Photodiode Wires Rerouted
My first week at MITH has been marked by a firsthand encounter with a tradition of 1980s personal computing and data storage: the flippy disk. Before I get into that though I thought I would briefly introduce myself.
I’m a graduate student at UT Austin’s School of Information. Although I originally set out to study book and manuscript preservation, my interests soon turned to digital media preservation and curation. Specifically, newer media that uses unique digital affordances are of interest: video games, interactive narratives, etc. Not surprisingly legacy media and vintage hardware can play into this quite a bit.
My background is in the humanities, studying literature. But like a lot of folks here, I have at least some technical aptitude when it comes to computing. I fondly remember trying to program an adventure game in QBASIC, using nothing but text prompts, if…else conditions, and GOTO. It was unashamed spaghetti code, but fun.
On to flippy disks. The majority of 5.25″ disks were design to be used on single side only, but users could produce another notch on the opposite edge of the manufacturer’s own. When the user inserted the disk (upside-down) into the drive, the new write-unprotect notch allowed the floppy disk drive to treat the side as writable, thus doubling the user’s storage capacity.
Walker Sampson 