Mark Shelstad, head of Archives and Special Collections at University of Texas at San Antonio, sent me a link to the TARO (Texas Archival Resources Online) page for UTSA’s Archives and Special Collections finding aids in XML format.

With the current scripts, these are the fun tag stats:

• 1,684 total tags extracted
• 75% (1,266 tags) are associated with only one finding aid
• 3% (51 tags) are associated with 10 or more finding aids

Collection Size

235 out of tne 253 collections ended up with a collection size of 0.

Consider the encoding of the collection size in the Guide to the Women’s Overseas Service League Records, 1910-2007:

<physdesc label="Extent:" encodinganalog="300$a">
    77 linear feet (approximately 44,000 items)
</physdesc>

Contrast this with one of the examples where the size of the collection was extracted properly by the current script:

<physdesc label="Extent:" encodinganalog="300$a">
    <extent>8.4 linear feet</extent>
    (14 boxes)
</physdesc>

Sometimes it feels like a game of Where’s Waldo. In this case we are simply missing the set of <extent> tags  from the first example. Off I went to the EAD tag descriptions to find the guidelines for use of the <physdesc> tag, where I found this overview of the tag:

A wrapper element for bundling information about the appearance or construction of the described materials, such as their dimensions, a count of their quantity or statement about the space they occupy, and terms describing their genre, form, or function, as well as any other aspects of their appearance, such as color, substance, style, and technique or method of creation. The information may be presented as plain text, or it may be divided into the <dimension>, <extent>, <genreform>, and <physfacet> subelements.

Bad news for my script logic – both versions are valid! This is a great example of how valid encoding can still present challenges. While in this example it seems just as easy to parse the version with the <extent> tags as without, it will only be through examination of a much broader sample of data that we can determine how much of a problem we have on our hands with this scenario of size data included in the <physdesc> tags without enclosing <extent> or <dimension> tags.

Inclusive Dates

Twenty of the UTSA collections came through with no years. When I examined the data, I found an assortment of <unitdate> formats that my current script could not parse properly, including the examples below:

• 1917-1980 (bulk 1920-1945)
• 1876-1903, 1914-1919, 1940-2002
• 1940s, 1970s-1990s

Another encoding approach that could not be parsed was the one used for the finding aid of the Church Women United of San Antonio Records. In this case the <unitdate> tag is within the <unittitle> tag as seen here:

<unittitle label="Title:" encodinganalog="245">
Church Women United of San Antonio Records,
<unitdate label="Dates:" encodinganalog="245$a">1961-2005</unitdate>
</unittitle>

Among the finding aids for which I did extract a range of inclusive date years, I also found issues with values like 1950s-1990s. The current script interpreted this to represent 1950 through 1990, but I believe it would be more properly translated as representing 1950 through 1999.

General Code Fixes

The University of Texas at San Antonio’s finding aids have provided additional examples of the following data and encoding issues already identified in earlier data sets:

• Inconsistent repository titles (26 different variations of “The University of Texas at San Antonio Library”)
• Titles with embedded and tagged dates
• Carriage return and tab characters that need to be removed
• Emphasis within a title or abstract added via a tag (such as <emph render=”italic”>Storyletters</emph> seen in A Guide to the Storyletters Records, 1991-2000) which interrupts extraction of text at that point

Next Steps

This is the last data set I am analyzing before tackling actual updates to the ArchivesZ data extraction script. My next step is to review and prioritize my long to do list for updates to this script. Most of what I have found in my examination of the data sets are ways in which my script was not smart enough to handle valid variations in encoding and the tabs, carriage returns, formatting tags and special characters found throughout everyone’s XML. Yes, there are some cases in which the data itself is less than optimal (such as non-standardized repository titles) or the values challenging (so many ways to describe the size of a collection!), but overall I am optimistic about how much more I can improve the extraction script before I have to resort to hand correcting records in the database.

Thanks to everyone for your patience with these data analysis posts. Onward to programming!

This post is from from: Spellbound Blog.

ArchivesZ Data Challenges: University of Texas at San Antonio

• Titles with embedded tags or punctuation. Generally the script drops anything after it hits either, so rather than a title like William E. Towell Papers, 1941 – 1988, my database ended up only with “William E Towell Papers,” based on this encoding:  <titleproper>Inventory of the William E. Towell Papers, <date normal=”1941/1988″>1941 – 1988</date></titleproper>
• Need to handle a conversion factor for  a size of  “1 folder” (as found in the Inventory of the Biltmore Forest School Images, 1890 – 1988)
• My script chokes on the Inclusive Year format “1910 and 1931 – 1937″ (as found in the Inventory of the Alfred Cunningham Papers, 1910 and 1931 – 1937)
• The presence of a <lb/> character within the <extent> tag, used to force a line break, is preventing my script from extracting any size information at all (as found in the Inventory of the DeWitt Nelson Papers, 1940 – 1976)
• Within the <abstract> tag, my script drops everything after an <emph render=”doublequote”> tag (making for a very short abstract in the case of the Inventory of the Arthur Bernard Recknagel Auxiliary Photograph Collection, 1911 – 1947).

The most dramatic issue, seen across all the finding aids in this set, is that no subject data was extracted from any of the finding aids. My working theory for the moment is that this is due to the use of <list> and <item> tags as shown here:

<controlaccess>
<head>Subject Headings</head>
<list type="simple">
<item><genreform source="lcnaf" encodinganalog="655">Audiotapes</genreform></item>
<item><persname source="lcnaf" encodinganalog="600">Ainsworth, John H., 1909-</persname></item>
<item><subject source="lcnaf" encodinganalog="650">Businessmen -- United States</subject></item>

This is in contrast with this example of encoding from Syracuse University:

<controlaccess>
<head>Subject and Genre Headings</head>
<subject encodinganalog="650" source="local">Adult education</subject>
<persname encodinganalog="600" source="lcnaf">Adolphson, L. H.</persname>
<persname encodinganalog="600" source="lcnaf">Bradford, Leland Powers, 1905-</persname>

Or this sample from Oregon State University:

<controlaccess id="a12">
	 <controlaccess>
		  <persname encodinganalog="600" source="local" rules="aacr2"
		  role="subject">Aitken, Frances Alva, 1889-1970.</persname>
	 </controlaccess>
	 <controlaccess>
		  <corpname encodinganalog="610" source="local" role="subject"
		  rules="aacr2">Oregon Agricultural College. Class of 1910.</corpname>
		  <corpname source="lcnaf" encodinganalog="610" role="subject">Oregon
				Agricultural College--Students.</corpname>
	 </controlaccess>
	 <controlaccess>
		  <geogname source="lcsh" role="subject" encodinganalog="651">Corvallis
				(Or.)</geogname>
	 </controlaccess>
	 <controlaccess>
		  <subject encodinganalog="650" source="lcsh">Student
				activities--Oregon--Corvallis.</subject>
	 </controlaccess>

Both the Syracuse and OSU examples are handled by the current state of the data extract script.

Amanda pointed me to the NCEAD Best Practice Guidelines for EAD 2002. Down in Appendex G: How Do I Encode…, the second question down is “What if I have multi-part scope notes, biographical notes or subject headings?” followed by exactly the <list> and <item> tag usage as is being done for the Forest History Society finding aids. This format clearly should be handled.

So, no fun tag stats for this run – but I hope to fix my ruby script so that the Forest History Society finding aids can be incorporated into the data set I use for testing version 2 of ArchivesZ. My ruby script to do list is getting quite long!

This post is from from: Spellbound Blog.

ArchivesZ Data Challenges: Forest History Society

These finding aids have helped me identify three types of ArchivesZ data challenges:

• strange characters
• broad composite subjects
• determination of accurate collection size

Strange and mysterious characters!

These finding aids use a special character in the place of the standard Library of Congress double dash which normally appears between subsections of the subject heading.

An example subject from the Utah Government XML looks like this:

Women—Suffrage—Utah.

Viewing the same subject in a pure text editor (such as vi):

Women&#8212;Suffrage&#8212;Utah.

By the time it gets into my database and is pulled out via a query in MySQL Query Browser it looks like this:

Women—Suffrage—Utah.

Rather than just stripping out all instances of &#8212;,  my plan is to replace them with the standard Library of Congress double dash. This will ensure that the existing code that breaks the subjects down to tags will still work.

Composite Subjects

When I say “composite subject” what I mean is a subject that includes multiple very disparate terms. Rather than the Library of Congress style subjects, all aspects of which relate to the collection in question, these composite subjects cover multiple subjects which are grouped together for convenience.

This is a list of some of the most popular subjects for the Utah Gov collections:

• Politics, Government, and Law
• Business, Industry, Labor, and Commerce
• Science, Technology, and Health
• Arts, Humanities, and Social Sciences

These subjects throw a monkey wrench into my theories about decomposing subjects based on commas. The collections to which these subjects are assigned likely fit in only one of the component themes. For example, the “Inventory of Publications from Department of Technology Services, 1993-2008″ is assigned the subject “Science, Technology, and Health”. If I divide this subject into 3 separate tags, the Science and Health tags would be quite misleading.

So that leaves me a bit trapped. If I want to divide subjects such as “Art, Cuban, 20th century”, as I discuss in my Syracuse University post, then I end up also dividing these umbrella subjects which separate such very divergent terms with commas.

This issue goes on my list of reasons to add a repository configuration file for use by the data extraction script.

Accurate Collection Size

In my quest to convert all sizes to linear feet – sizes such as these are challenging:

• 0.20 cubic foot and 1 microfilm reel
• 0.35 cubic foot and 2 microfilm reels

I also have situations of sizes be specified in multiple sections of the finding aid. The Inventory of ALERT Foundation records from Governor Bangerter, 1986-1991 has a collection level size of “0.50 cubic foot and 2 microfilm reels”, but further down in this finding aid I see this:

series: ALERT Foundation records

• box 1, folder 1: Documentary: “”Letters from our Children,”" Motion picture film reel, 16mm
• box 1, folder 2: Documentary: “”Letters from our Children,”" VHS videocassette
• box 1, folder 3: Documentary: “”Letters from our Children,”" VHS videocassette
• box 1, folder 4: Documentary: “”Letters from our Children,”" VHS videocassette

When they said 2 microfilm reels – do they really mean a 16mm motion picture film reel and a VHS videocassette? Is there 1 VHS videocassette or 3? How sizes are specified in a specific repository’s finding aids is another possible candidate for a repository level configuration script.

Tagging Statistics

Finally, here are a few tag stats:

• Only 31 tags (1.5% of all Utah Government tags) are associated with 10 or more collections
• 1404 tags (71.5%) are assigned to only a single collection
• 107 collections have been assigned only 1 tag
• 10 collections have no subjects

Of course these statistics are based on the current incarnation of the data extraction script. After I modify the script, there will be a greater number of tags and (hopefully) more overlap of tags across multiple collections. These types of statistics should help me gauge how well my data extraction logic is working.

This post is from from: Spellbound Blog.

ArchivesZ Data Challenges: Utah Government Archives & Records Service

• University Archives
  
• Public Policy Papers
• Manuscript Division
  
• Latin American Ephemera Collection
• Engineering Library
  

So onward to the data issues and what they mean for my ever growing ‘script fix to-do list’.

Repository Names

As we saw with the Oregon State University finding aids, the finding aids from Princeton University had a wide range of different values for repository names. In the list below we spot some issues. Some end in periods, some do not. One has extra space (probably a carriage return) in the middle. One does not include Princeton in the repository name. Once we have many repositories’ finding aids in ArchivesZ, a repository name of ‘Engineering Library’ does not tell the user enough about where those collections can be found.

Here is the list of repository titles my script extracted:

• Princeton University Library. Department of Rare Books and Special Collections.
• Engineering Library
• Princeton University Library
• Princeton University Library. Department of Rare                    Books and Special Collections.
• Princeton University Library.

My script can handle the extra period and the extra spaces, but the non-specific name would need to ultimately be fixed on the source side.

Collection Size

The current script assumes that there is only one extent value specified to express the size of the collection. Princeton’s finding aids showed me examples of multiple extent values. For example, the Christina Georgina Rossetti Collection has both a collection level size of 0.4 linear feet (1 archival box) as well as a 2nd extent specification corresponding to a specific folder with the value of (1 poem, 3 drawings, 1 photo, 1 incomplete article). The script must be modified to only consider the collection level size.

Complicated Titles

The current script logic apparently does not handle what I would call ‘complicated collection titles’. For example, I ended up with “Edward Livingston Papers, ” as the title for a collection with a full title of Edward Livingston Papers, 1683-1877 (bulk 1764-1836). This is the way that this title is encoded:
<unittitle encodinganalog="245$a" label="Title and dates: ">Edward Livingston Papers, <unitdate encodinganalog="245$f" normal="1683/1877" type="inclusive">1683-1877</unitdate> (bulk <unitdate encodinganalog="245$g" normal="1764/1836" type="bulk">1764-1836</unitdate>)</unittitle>

This post is from from: Spellbound Blog.

ArchivesZ Data Challenges: Princeton University

My scripts extracted 6632 unique ‘tags’ from the subjects assigned to the finding aids. As part of the data parsing and loading of data for use in the visualizations, the script divides up compound subjects into tags. For example, in the subjects we find assigned to Syracuse University finding aids we find these values (number shown is number of finding aids to which that subject is assigned):

• Art — American — 20th century (1)
• Art — Cartoonists (68)
• Art — Cartoonists. (3)
• Art — Exhibitions. (1)
• Art — Illustrators (36)
• Art — Illustrators. (1)
• Art — Painters (77)
• Art — Philosophy. (1)
• Art — Sculpture (33)

As well as subjects, where the components are separated by commas such as these (number listed indicates total finding aids assigned that subject):

• Art, American (33)
• Art, American. (46)
• Art, American, 20th century (28)
• Art, American, 20th century. (31)
• Art, Cuban, 20th century (1)
• Art, Modern (1)
• Art, French, 20th century. (1)

The goal is to capture the core ideas – to capture the overlap in subject matter among diverse collections. All of the collections with any of these subjects are about Art. With the current script, the tag Art is associated with 179 collections from Syracuse University. You can see from this tiny subset of subjects that other themes would be revealed when these subjects were decomposed more completely – and this just scratches the surface.

Out of the 6676 subjects, 5658 subjects are assigned to single collections. Out of the 6632 tags the current script extracted from those subjects, 5594 tags are assigned to single collections. Not much improvement with the current state of the script.

While currently the script does a good job with the Library of Congress double dash separation pattern, the Syracuse University data has shown me a number of other standard patterns that need to be handled which can be seen in the small sampling of art related subjects shown above. The easy one is removing periods and stripping spaces from the end of subject values. The harder change will be to implement smart separation of subjects into tags based on commas. This would need the code to only break up <subject> values while leaving <persname> and <corpname> alone. I will also need to examine <geogname> values from across various institutions to decide if it is better to break them up or leave them be.

Other than these subject issues, there are a few other script modification that I will need to make based on scenarios the data in the Syracuse finding aids have shown me:

• Syracuse University uses an entity to populate the repository values – the current script does not handle this at all.
• Ensure that single item collections are assigned a size of .25 linear feet
• Linear ft must be added as another recognized abbreviation for linear feet

All these issues are being added to my master ‘to do’ list for updating the EAD parsing script. Onward to the next data set.

Want to share your institution’s EAD finding aids in XML format with the ArchivesZ project? Please drop me a line via my contact form.

Image Credit: Syracuse University image above from Syracuse University Special Collections Research Center home page.

This post is from from: Spellbound Blog.

ArchivesZ Data Challenges: Syracuse University Special Collections Research Center

Version one of ArchivesZ only used finding aids from the University of Maryland and the Library of Congress. This was definitely a case of the path of least resistance. I attend the University of Maryland and the Library of Congress has a very convenient page providing links to all their Finding Aids source XML files. A very key aspect of creating version 2 of ArchivesZ is making sure that the scripts that pull data from EAD XML files is robust enough to handle the encoding practices of a very diverse range of institutions.

Please keep in mind that OSU is likely to bear the brunt of many basic data issues that I would have unearthed with whatever data sets I tried first!

There are 3 crucial data elements on which the visualizations of ArchivesZ depend: subject, inclusive dates, and collection size. Each element presents unique challenges. The script parsing issues I am uncovering with the OSU finding aids are currently worst for collection size. In order to make pretty charts which let people compare the quantity of materials in each collection (or record group  – please forgive that I use the term ‘collection’ to mean any set of records for which a finding aid has been created), we need to be able to assign a single number to represent the size of each collection. Based on the values used in the LOC and UMD finding aids, we chose to go with linear of feet as our standard unit of measurement. So the trick is to translate whatever archivists choose to put into the <physdesc> element of their finding aid into some number of linear feet.

These are the size conversion rules we implemented for version 1 of ArchivesZ:

• 1 microfilm reel = 1 linear foot
• Collections represented only by a number of items will be represented as .25 linear feet
• If size only specified in number of boxes, then 1 box = .5 linear feet
• When the size is given in some different types of units, they are prioritized in the following order: linear feet > boxes > microfilm reels > items

This works reasonably well when the physical description values are simple – it starts to fall apart when what is entered is more complicated. Here are some examples of the physical descriptions in the OSU finding aids:

Guide to the Phi Kappa Phi-OSU Chapter Records: The display in the ‘pretty’ version of the finding aid  online shows this: 5.5 cubic feet (9 boxes, including 2 oversize boxes) (3 microfilm reels)

The version in the XML file is this:

<physdesc>
  <extent>5.5 cubic feet</extent>
  <extent>9 boxes, including 2 oversize boxes</extent>
  <extent>3 microfilm reels</extent>
</physdesc>

With the current algorithm, this finding aid would be marked as being 3 linear feet in size. At a bare minimum, I must add ‘cubic feet’ as another unit to be converted. More difficult to discern is if I should have a value of  5.5 linear feet (assuming 1 cubic foot = 1 linear foot for the purposes of these comparisons) or a value of 8.5 linear feet (5.5 + 3 linear feet for the 3 microfilm reels). There is never going to be a perfect answer here, but clearly my logic needs to be more sophisticated than it is now.

Harvey L. McAlister Collection: The display in the pretty version of this finding aid online is this: 1 cubic foot, including 26 photographs (4 boxes, including 2 oversize boxes, and 1 map folder)

The version in the XML file is this:

<physdesc>
  <extent encodinganalog="300$a">1 cubic foot, including 26 photographs</extent>
  <extent encodinganalog="300$a">4 boxes, including 2 oversize boxes, and 1 map folder</extent>
</physdesc>

With the current algorithm, this finding aid would be marked as being 1 linear foot in size. From looking at these two examples, it would seem that this would be fine and in fact – for the purposes of calculating a comparable size – only looking at the first <extent> value might be the way to go – at least for OSU finding aids.

There are some other simpler issues relating to standardization in the way that certain values are entered. For example, after ingesting 173 finding aids from OSU (the number I got through before my script flat out choked on a size designation), I ended up with five different repositories added to my REPOSITORIES table. I had expected only one. Each of these was entered as repository name — and I have included the length of each value to show how extra spaces are causing part of the problem:

• Oregon State University                Libraries – length 36
• Oregon State University    – length 23
• Oregon State UniversityLibraries    – length 32
• Oregon State University             Libraries  – length 36
• Oregon State University Libraries    – length 33

Some of these I can handle by adding smarter trimming of trailing spaces – but in this case it is clear that typos and inconsistency are also a challenge. I checked and each of these different <corpname> values, within the <repository> element is used by at least 10 finding aids. Perhaps they have been inherited over time from a template?

I have considered creating a repository definition file that could be used when loading finding aids from one repository at a time. This would remove dependence on perfect replication of these sorts of values while still supplying the data needed to let people limit their searches by a named repository.

The last issue is the most minor. There are many /n and /t characters throughout the XML documents. These I plan to simply strip out as the script parses the XML file.

A big thank you to Elizabeth Nielsen, Senior Staff Archivist at OSU Archives. Her response to my query about OSU’s comfort with my taking apart their finding aids in public on my blog was “Bring it on – we’re tough!”.

It is fascinating to dig into new finding aids and see how the parsing script handles what it finds. I plan to test the existing script on XML from more sources to see all the things that must be fixed. Then I get to wrap my head around code that someone else wrote (another member of the original ArchivesZ team wrote the version 1 ruby script). For those of you who are not programmers, you can skim through my Book Review of Dreaming in Code to get a handle on why this can be harder than it sounds like it should be.

Want to share your institution’s EAD finding aids in XML format with the ArchivesZ project? Please drop me a line via my contact form.

Image Credit: OSU Archives image above from the OSU Archives Home Page.

This post is from from: Spellbound Blog.

ArchivesZ Data Challenges: Oregon State University Archives

Max’s prototype of Susa 2.0 is now online! He asked that I make sure you know it works best (showing all the intended mouse over text for links) with Internet Explorer version 6.0. The prototype presents the finding aid of the Susa Young Gates Papers from the Utah State Historical Society. His design tackles the major issues that plague large finding aids normally displayed in traditional single page layouts. Anyone who has looked at a large finding aid online has had the experience of being scrolled down somewhere in the middle and realizing they have no idea what they are looking at. What folder is this item in? What box is this folder in? Am I reading through a list of letters from 1950 or are these the ones from 1970?

Context is hard to communicate when you are dealing with long lists of folders that stretch longer than the length of the screen. Max’s design uses a three column approach to provide context from left to right. His design also gives users a way to look at the full list of either items or folders, independent of their originating containers – each list then sortable in three different ways: ‘as arranged’, alphabetically or by date. I love this page which shows how a scanned document might be displayed within the proper context of the collection – in this case, page 2 of document 1 of the General Correspondence from 1886-1909. All of these ideas get at the heart of giving researchers more control over how to tackle the records in a collection while making sure that they don’t loose the tools that ordered documents in a folder would provide them in the research room.

His prototype takes a step beyond just changing how the finding aid itself is presented – but also considers how the work flow of a researcher can be improved while also simplifying the record request processes. The prototype gives the patron the option to request the scanning of specific folders or items. They can also add records to their ‘research cart’ to either request the proper boxes be retrieved or to store the records in a personal research area within the archives website – both possibilities sound useful to me.

Max’s prototype is such a great example of rethinking how people are expected to work with archival records within the confines of the information we already have available in finding aids as they exist today. I highly recommend you give Susa 2.0 a look. It is a testament to Max’s incredible patience that he was able to create this prototype using over 200 separate HTML files – but it also sets the bar high for what we could be doing with our interface design!

This post is from from: Spellbound Blog.

Susa 2.0: Max Evans’ Finding Aid Prototype

As of August 22nd, 2008 it was official. There is even a blog post over on the NEH Office of Digital Humanities updates page to prove it. The University of Maryland was granted a Level I NEH Digital Humanities Startup Grant to fund work on the ‘Visualizing Archival Collections’ project. The official one liner is that the project will support “The development of visualization tools for assessing information contained in electronic archival finding aids created with Encoded Archival Description (EAD)”. Why did I wait so long to announce this on the blog? I wanted to have something fun to announce at the end of my SAA presentation out in San Francisco!

The project director is Dr. Jennifer Golbeck. I also have the support of University of Maryland’s Jennie Levine, Dr. Bruce Ambacher, and Dr. Doug Oard. This amazing set collaborators should help me stay on the right track and make sure I keep the sometimes competing issues relating to archives, information retrieval and interface design in balance.

I will be collecting EAD encoded finding aids over the next few months. My goal is to gather a broad sample of English language finding aids from a wide range of institutions and work on the script that extracts this data into a database. Once we have the data extracted I get to look at what we have, do some data cleanup and start thinking about what sorts of visualizations might work with our real world data. During the spring term we will design and build a 2nd generation prototype of ArchivesZ.

Want your data to be part of this? If you would like to contribute EAD finding aids in XML format to the project, please send me the following information:

1. Archives Name
2. Archives Parent Institution (if applicable)
3. Archives Location
4. Contact at Archives for questions about the finding aids (name, email and phone number)
5. Estimate of # of finding aids being offered
6. Controlled Vocabulary or Thesaurus used for Subject values (as many as are used)
7. Method of finding aid delivery (sending me a zip file? pointing me at a directory online? some other way?)
8. Do I have your permission to post a discussion of the data issues I may find in your finding aids here on Spellbound Blog? (Please see the OSU Archives post as an example of they types of issues I discuss)

You can either put this into the form on my Contact Page or send email directly to jeanne AT spellboundblog dot com.

Thank you to everyone for their enthusiasm about the ArchivesZ project. It is very exciting to have the opportunity to take all these shiny ideas to the next level.

This post is from from: Spellbound Blog.

NEH Digital Humanities Startup Grant News: Visualizing Archival Collections

Babel

Babel converts files from one format to another. I did a test to see if it would convert one of the Library of Congress EAD Finding Aids from XML to some other format – but it gave me an error (‘unqualified attribute ‘repositoryencoding’ not allowed’). I love the idea that I could just point this at an EAD finding aid and get something useful out the other side – but apparently that is a bit on the wishful thinking side – at least for the moment.

Exhibit 2.0

Exhibit 2.0 is described on the Exhibit homepage as follows:

Exhibit is a three-tier web application framework written in Javascript, which you can include like you would include Google Maps. If you just want to show a few hundred records of data on maps, timelines, scatter plots, interactive tables, etc., why bother learning SQL, ASP, PHP, CGI, or whatever when you can just use Exhibit? To use Exhibit, you write: a simple data file, and an HTML file in which you specify how the data should be shown. Data + Presentation. That’s all there is to publishing, as it should be.

Sounds fabulous, doesn’t it? I wish I had a week to play with this tool. They have a whole slew of examples, but I think the two I list below do a fine job of showing what you can create (not to mention being fairly thematic for those of you paying attention to the US Presidential Primaries news coverage):

• 2008 Presidential Election Candidates on the Issues
• US Presidents

Gadget

Gadget is an XML inspector designed to create useful summaries of vast pools of XML data. I didn’t download and play with this one – but it sounds like something that might be very interesting to pump a big pile of EAD XML format finding aids into to see what could be discovered from an aggregate point of view.

Longwell & RDFizers

Longwell is a faceted browser for RDF formatted data, while RDFizers is actually a directory of tools which convert other data formats into the RDF format. It doesn’t exist now, but if there was an RDFizer that went from EAD to RDF then Longwell would become more interesting to archivists.

That said, they already do have both a MARC/MODS RDFizer and an OAI-PMH RDFizer. I suspect that many archivists could put their hands on archival data in one of these two formats – which makes experimenting with Longwell more plausible in the near term.

Final Thoughts

There are lots other tools that are part of the SIMILE project (screen scrapers and timeplotters and more), but the ones listed above most ignited my imagination. Surely there are geek archivists even now rolling up their sleeves to figuring out how to leverage free open source tools like these, both to improve access to records and increase understanding of what we have and how well it is (or isn’t) documented.

I hope to find time to play with each of these over the next few months – but I would love to know if anyone else out there has already tried any of these tools. Have suggestions for likely datasets? Have knowledge of existing archive related applications using these tools? Please post your comments below or drop me a line via my contact form!

Image Credit: The Simile Project logo displayed above is from MIT’s Simile Project website.

This post is from from: Spellbound Blog.

MIT’s SIMILE Project: Innovations in Metadata Interaction and Analysis

My co-presenters are Max Evans (currently of the NHPRC, soon to be of the LDS Church Historical Department) and Elizabeth Yakel (of University of Michigan, School of Information). Jodi Allison-Bunnell from Northwest Digital Archives, Orbis Cascade Alliance is our panel Chair.

This is the description of our panel that we submitted with our proposal:

Encoded Archival Description (EAD) was created in 1995 to increase uniformity and interoperability of data about archival collections to facilitate discovery. It has yet to realize that goal: most online finding aids merely recreate paper documents. Speakers will demonstrate how the structured, standardized nature of EAD can form the basis of user-friendly interfaces and finding aids that can accommodate multiple perspectives and utilize graphical and visual interfaces–while faithfully recording and presenting the context, structure, and content of the collection. Panelists will also address the challenges of unleashing the power of EAD, including normalizing XML, the lack of standard values for cross-institutional aggregation of data, and different approaches to subject terms, with a discussion of the technological and practical issues that surround them. The session relates to the SAA strategic priorities of technology and public awareness and engages elemental questions of revolutionary and evolutionary change.

My portion of the panel will focus on my ArchivesZ information visualization project. I will be discussing both the power of this type of graphical interface to archival collections as well as addressing the roadblocks to their practical implementation. My plan is to continue the work I started last Spring over the course of this Spring and Summer – and show off a new version of ArchivesZ in San Francisco (as well as online here of course!).

Here are the descriptions of Max, Elizabeth and Jodi’s planned contributions (cribbed from our proposal submission):

• Max Evans will explore the fundamental purposes of finding aids and explore what can be done to leverage EAD’s structure to render graphical, informative, and elegant finding aids online.
• Elizabeth Yakel will discuss usability test findings and how these were incorporated into the EAD-based Polar Bear Expedition Digital Collections to allow communities to engage with collections in new ways.
• Jodi Allison-Bunnell brings a lively interest in user-centered presentations of finding aids that emerge from her work as manager of a five-state EAD consortium.

I am so pleased and excited. So – who is planning on going to San Fransisco in August? I hope to see you there.

Image Credit: Society of American Archivists, ARCHIVES 2008: Archival R/Evolution & Identities web page.

This post is from from: Spellbound Blog.

SAA2008 Here I Come! After the Revolution: Unleashing the Power of EAD