PDF Analysis Tools: Part 2 of the PDF Experiment

A while back I posted about the PDF experiment I’m doing to explore some character encoding anomalies in our PDF e-theses. The project is complete now, but I wanted to outline some of the steps we went through before I jump right to what we found. Step one was analyzing the PDFs to figure out what, exactly, was going on underneath the hood. But in order to do that we actually needed a preliminary step, which was finding a tool that would help us do that analysis effectively.

This actually turned out to be more difficult than it seemed at first. The errors we were looking for aren’t related to the common issues digital preservationists are most often concerned with, such as format identification and validation. Tools like JHOVE weren’t quite right for our purposes, because the errors we encountered were all deep within the content stream. We had plenty of perfectly valid PDFs (checked against JHOVE just to be sure) that would render fine in a PDF reader, but the text came out with unusual characters if copied and pasted into another document (any other document, we tried all the text editors we could find).

So our challenge was to find a tool that would help us analyze the text encoding within the content stream. It turned out Adobe Acrobat Pro was the most useful tool for manually inspecting the errors, since its preflight function allowed us to view the actual content stream encoding at the point in the document where we had a known error, such as a ligature that wouldn’t convert to its correct ASCII characters on copy-and-paste. However, this required that we already know the PDF had said error, and what we really wanted was a tool that would help us identify PDFs with those errors from a larger collection of PDF e-theses.

We tested 16 tools to see if any would solve this problem for us. Questions we asked as we tested each tool included:

  • Can the tool accurately and reliably diagnose the problems we are working on?
  • Does it have repair capabilities, or is it diagnostic-only?
  • Can it be run as a batch process (from the command line) or does it require a GUI?
  • Does it run on Linux, Windows, Mac?
  • Can it report on whether the document meets archival standards like PDF/X, PDF/A etc.?
  • Who creates and maintains the tool?
  • Is there good documentation/support?
  • Is there a cost?
  • Is it open source?

We were hoping to not only find a tool to suit our needs, but one that was free and open source if possible. For each tool, we went through the following steps for initial testing:

  1. Install the tool on local machine or server.
  2. Run the tool on each of 32 sample PDF theses that represent the different types of problems we had encountered.
  3. Record results/output and comments about the tool’s functions in a shared spreadsheet.
  4. After testing the tool and getting a feel for how it works, record general observations and answers to the questions above on a wiki page for the project.

After going through this process for all 16 tools, we hadn’t found a tool that did exactly what we needed. But we found that there were two tools whose text extraction features could be used to serve our purposes. One, PDFBox, was able to work with the ligature issue for most of the PDFs, providing cleanly extracted text that resolved to its correct ASCII characters. This was helpful in two ways: one, it led us to believe that the issue we were dealing with was also one of rendering rather than strictly encoding (whatever the encoding is for those ligatures, it can be converted correctly by at least one program); and two, it gave us an option for extracting readable text for both cataloging and indexing in our repository.

The other tool, PDFMiner, helped us by, in a sense, not working: on extracting the text, every single PDF that we had identified as one with ligature issues showed those ligature issues in the extracted text. Therefore, we decided that whatever the encoding is that’s causing the problem, PDFMiner is not able to resolve it to the correct ASCII characters. While this might sound like a deficiency in the tool, for our needs it actually allowed us to create the exact tool we were looking for!

My colleague Rich Wenger wrote a series of scripts that will extract text from a PDF using PDFMiner and then search for the anomalous characters that appear when there are known text encoding issues present. This allowed us to run his scripts over the entire collection of e-thesis PDFs to see how many have underlying text encoding issues. After running these scripts, we determined that about 30% of the collection presents the ligature encoding error, and a much smaller percentage presented other errors such as excessive line breaks and extra characters inserted in the encoded text. In my next post, I’ll discuss possible implications of these results and some of the steps we’re taking to mitigate these issues in the future. Stay tuned!

Advertisements

LaTeX and Theses and Glyphs, Oh My! Part 1 of the PDF Experiment

One of these days I’m going to write some more detailed posts about other projects I’ve mentioned in the past…but not today. Today I’m going to introduce yet another project I’m working on, although one that is about to wrap up. The project is an analysis of text encoding errors in PDF theses submitted to the Libraries for deposit into our DSpace@MIT repository. It’s just one component of a larger set of life cycle experiments currently going on as part of the Digital Content Management Initiative. There will be much more to share about the life cycle experiments over the next year, so more posts to come on that.

In the meantime, a little background on the PDF theses: graduating students here submit paper theses as the official copy of record for the Institute, which are accessioned into the Institute Archives for preservation. We scan the theses and provide electronic access to them via DSpace@MIT. However, if students wish to provide an electronic version of their theses in PDF format, in addition to the required paper copy, they may do so. After some checking to make sure the electronic version matches the official print copy, we can use the e-submission as the online access copy, thus saving us the trouble of scanning it from print.

All well and good, however our meticulous catalogers have noticed some interesting problems appearing in a few of the electronically-submitted PDF theses (locally known as e-theses) over time. Often, these problems were encountered when attempting to copy and paste the text of a thesis abstract from the PDF document into another program, such as the library catalog. Certain character combinations tended not to copy over so well; they would paste into the new program as symbols or blank spaces instead of the expected letters.

Many of the catalogers observed that these characters were often ligatures in the original text, including such common letter combinations as “ff”, “fi”, and “th”. It was unclear what, exactly, was causing this to happen, but there was a suspicion that this problem stemmed from PDFs created by LaTeX applications. For those not familiar with LaTeX (I wasn’t, when I started this project) it’s a suite of typesetting tools built on the TeX typesetting system. This system is often used to write academic papers in the scientific and mathematical disciplines because it can handle typesetting of complex math formulas more easily than word processing programs. Consequently, it is very popular here at MIT.

My job on this project, in coordination with my colleague Rich Wenger, is to identify and characterize the types of problems encountered in our PDF theses, identify the source of these problems when possible, and recommend solutions for avoiding such problems in future e-thesis submissions. We’ve been working on the analysis for several months now, and while we aren’t quite done yet, we have learned a lot about PDF documents, TeX/LaTeX, and the challenges of representing text in a visual format. In part 2, I’ll discuss the process we went through to analyze the PDF documents and develop methods for characterize the text issues we encountered. Stay tuned!

Building an Ontology, or: Don’t Put the Cart Before the Horse

I got so excited about creating a linked data set that I tried to jump right into populating a triple store…whoops! As I was reading about the various triple store systems and serializations of RDF, it became clear that, even though this is intended to be an iterative process, the data was not yet up to snuff for even an initial conversion to RDF. I had basically just copied all the information straight from our bucket diagrams into an Excel spreadsheet without really thinking about how the data should be modeled. Here’s a sample from the first pass at data-gathering:

Initial Data from Bucket Diagrams as a Spreadsheet

Initial Data from Bucket Diagrams as a Spreadsheet

You can see how I tried to go about creating columns for each attribute of a given bucket (What content type does it belong in? Does it included born-digital content? How about digitized?). There are many, many more columns not shown in this picture, each representing some aspect of the conventions in our diagrams (there’s a sample diagram here if you missed that post or forgot what they look like). The diagrams, which are inherently simple visual representations, couldn’t be too detailed or they would have quickly gotten very cluttered. In the data, however, we’re free to be much more specific and, most importantly, flexible. For example, rather than listing born-digital and digitized as two separate properties with yes/no statements, we can have a field for “creation method” that may include born-digital, digitized, and/or some additional yet-to-be-determined method.

Realizing that I needed a better way to approach this process, I backtracked a few steps to the data modeling phase, which led me to some Google searching for ontologies and ontology creation. The results were not pretty, but through a lot of twists and turns I ended up at Stanford’s Protégé website, which not only develops and hosts the fantastic Protégé software (and web service!) for ontology development, but also provides excellent tutorials on creating and working with ontologies. Jackpot!

So without further ado, I started reading through their Ontology Development 101 tutorial, which is written as though the reader has no prior ontology-creation experience. Just my speed. By following the process they outlined, I’m well on my way to creating a class hierarchy for a digital content management ontology, to be shared in future posts. I also found several existing ontologies that I can pull from…no need to reinvent the wheel. It looks like there are definitely terms for a lot of the classes, entities, and properties we need, but there is also information we’re modeling that doesn’t seem to exist in a current ontology. At least not that I could find. Here are the most useful related ontologies I’ve found so far. If you know of others I should look at, please share in the comments!

Following the Protégé tutorial’s step-by-step process has been incredibly useful. It very clearly describes how to break down the information in terms of entities with properties and relationships to each other, as opposed to a flat table. In my next couple of posts I’ll talk about the classes that have emerged to describe our digital content, and some of the initial properties we’re interested in recording.

Digital Content Management Initiative: It’s All About the Data

One of the major projects I’m working on in the fellowship is the Libraries’ Digital Content Management initiative, or DCM for short. This project started as a library-wide initiative in fiscal year 2013, focused on reviewing the MIT Libraries’ digital content to ensure that we are able and ready to manage it over time. The digital content review process we followed was developed and led by Nancy McGovern, Head of Curation and Preservation Services, and coordinated by a Life Cycle Group representing several departments across the Libraries. There’s more information about the DCM initiative on our Life Cycle Management libguide, and we’ll be posting updates on the process and results of year one soon. In the meantime, I wanted to share some work I’m doing as part of the next phase of the project now that FY13 is over.

The first part of the digital content review involved completing overviews of nine different content types managed by the Libraries: architectural and design documentation, digital audio, digital video, e-books, faculty archives, geospatial information, research data, theses, and web content. We also identified three additional content types to review in the coming year: institute records, scholarly record, and visual resources. In the process of creating these overviews, we gathered a lot of information about each content type. For the first phase of the project, that information was compiled into written overview documents and visualized as diagrams showing each of the buckets, or categories of items, within a content type. Here’s an example for our Architectural and Design Documentation content type:

Architecture and Design Bucket Diagram

Architectural and Design Documentation Bucket Diagram

These diagrams and overview reports have been very helpful for us to get a birds-eye view of all the digital content the Libraries manage (or may manage in the future). For the next phase of the project, we want to take all this information and turn it into a data set that can be queried, visualized, and added to as it changes over time. As you can see, there’s a lot of data already there; for example we have information on who currently manages the content, how much content we have,  whether it’s born-digital or digitized, and much more in the corresponding overview document.

Before we can create a data set from all this information, however, we have to decide how we want to model the data. I’ve been reading a lot about linked data and RDF (short for Resource Description Framework) over the past few years, and this data seems like it might be a good fit for the graph model for a few reasons:

  1. we need flexibility, as we don’t know yet how much more data we’ll gather or what shape it will take as we go
  2. it will allow us to easily link to existing digital preservation standards and services such as the PREMIS Preservation Metadata Ontology and the Unified Digital Format Registry (UDFR)
  3. one of our primary interests is exploring the relationships between the content types, a task for which linked data is well-suited
  4. using a web-based method for managing this information could simplify future sharing and data exchange

So the next steps in the DCM initiative present an opportunity for me to kill two birds with one stone: convert the qualitative visual and textual information we’ve compiled into a data set, and learn the process of creating and working with a triple store. This is definitely an exploratory undertaking. It may turn out that a simpler model, even a very basic relational database, will be better suited to this particular set of data. And I will definitely have to stretch my technology skills to learn how to create and query a triple store using whatever documentation I can find. But this is part of the joy of being a fellow: exploration and learning new skills are all part of the deal!

I’m going to share all the details of the process as I go, so feel free to follow along on the blog, make suggestions when I get stuck, and/or laugh (in a friendly way, I hope) when I make silly newbie mistakes. It’s going to be a very interesting project.