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.
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.
Walker Sampson 