Well into the multi-month thread Tim Berners-Lee offered up a very helpful, historical recap of the “what is a resource” issue , in which he said:

I would like to see what the documents [AWWW and RFC 2616] all look like if edited to use the words Document and Thing, and eliminate Resource.

A Short History of “Resource”

Which, somewhat predictably, started a discussion of what a Document is. However this conversation seemed more tangible and earthy, and culminated in Larry Masinter recommending David M. Levy’s book Scrolling Forward:

… since much of the thought behind it informs a lot of my own thinking about the nature of “Document”, “representation”, “Resource” and the like.

www-tag email message

Now Larry is a scientist at Adobe, a company that knows a thing or two about electronic documents. He also works closely with the W3C and IETF on web architectural issues. So when he suggested reading a book to learn what he means by Document my ears perked up. The interjection of a book reference into this rapid-fire email exchange was like a magic spell, that made me pause, and consider that a working definition of Document was nuanced enough to be the subject matter of an entire book.

I’ve come to expect references to Michael Buckland’s classic What is a Document? in discussions of documents. I hadn’t run across David Levy’s name before so Larry’s recommendation was enough for me to request it from the stacks, and give it a read. I wasn’t disappointed. Scrolling Forward is an ode to documents of all shapes and sizes, from all time periods. It’s a joyful, mind expanding work, that explores the entire landscape of our documents: from cash register receipts, the multi-editioned Leaves of Grass, email messages, letters, books, photographs, papyrus scrolls, greeting cards and web pages. Since this takes place in 212 pages, it is not surprising that the analysis synthesizes rather than being exhaustive. Having received a doctorate in computer science from Stanford, obtained a diploma in calligraphy and bookbinding from the Roehampton Institute, and then worked at Xerox PARC studying the nature of documents for 15 years, Levy’s own professional career is marked by a bringing together of scientific and humanistic disciplines.

One of the key messages of the book is a working definition of the Document. Levy’s draws out his definition largely in contrast to a statement made by David Weinberger in his 1996 Wired piece What’s a Document? where he says:

The fact that we can’t even say what a document is anymore indicates the profundity of the change we are undergoing in how we interact with information and, ultimately, our world.

What is a Document?

To which Levy responds:

We can say what a document is. Doing this, however, requires a somewhat different approach from that which dictionaries take. It requires going beyond word usage. It does require looking at the relevant technologies, but in such a way that we aren’t fixated on them, that we don’t fetishize them. Most of all, it requires immersing ourselves in the social roles these technologies play.

Scrolling Forward p. 23

So Scrolling Forward is a survey of sorts; a survey of document types that are inextricably linked to the social contexts in which they were created. This approach to describing rather than positing a theory of documents dove-tailed nicely with some reading of Wittgenstein I’ve been doing recently. In Wittgenstein’s later period he eschewed positing philosophical theories, but instead attempted to resolve philosophical problems by exploring the richness of language and its use in social settings, or language games, to lay bare the problem in a therapeutic way. Levy takes a similar approach in simply laying out the complex, sometimes contradictory history of documents before us, instead of carving out a logical argument and selecting facts to support it.

Some parts of the book that were of particular interest to me (as a software developer working in the area of digital preservation) were the sections discussing document fixity:

… paper documents, and indeed all documents are static and changing, fixed and fluid. There is a reason why text and graphics editors have a Save button, after all.

Scrolling Forward p. 36

Also of interest was Levy’s analysis of why the idea of “digital libraries” is such a lightning rod of opinion (which perhaps applies to its sister concept “repositories”).

[The] ambiguity between institution and collection is carried through in the phrase “digital library”. For some groups, most notably librarians, the phase refers most directly to institutions that oversee digital collections, while for other professionals, primarily computer and information scientists, it refers to digital collections, without regard to the institutional settings (if any) in which they might be managed … Digital library, it seems to me, draws much of its power from this ambiguity: it provides a name for collections of digital materials that invokes the aura of the modern library and its social mission (library as social institution). But it does so without actually making any commitments to the public good (library as collection).

Scrolling Forward p. 135

And finally, Levy doesn’t shy away from the big questions of how our psychological and religious impulses influence our notions of what documents are.

The human search for and construction of order [...] is our response to the profound mystery, and accompanying anxiety, of existence. Emerging into an unfathomable universe and fearing we are nothing within it, we strive to create a meaningful and ultimately immortal place for ourselves [...] Culture creates the conditions for a meaningful existence, for us to play out our games of physical and symbolic survival. But it is an ongoing performance, a play we can never stop performing, lest we see the back-stage gears and levers and be reminded of the mysterious and terrifying backdrop against which we are performing it. [Documents] are death-transcending, lack-filling artifacts of major proportions. Perhaps they can’t literally prevent our physical demise or fill our deepest sense of lack. But they are the central participants in our attempts to do so. Every one of them — each cash register receipt, each greeting card, each Post-it note — makes a contribution to the collaborative edifice we call human culture. Although few carry the weight of the Bible or the Constitution, all of them inform us of “what is and what we should do”. And in concert they help us create and sustain an orderly, and meaningful human lifeworld.

Scrolling Forward pp. 187-188

Heady stuff to be sure. And now I feel like I’ve traveled far from the beginning of this blog post, and the definition of information resources and the semantic web. Scrolling Forward has given me a very personal perspective on what documents are, and have been–and as a result I’m a bit more hopeful about the future of electronic documents. Working in digital preservation, it’s sometimes pretty easy to give in to despair. I’m not sure what the the application of this perspective is towards the normalization of language in the Architecture of the World Wide Web and RFC 2616. But it seems certain that part of the answer lies in not taking our information technologies too seriously, and trying to stay focused on the roles that they play in our individual and collective lives:

We make a mistake, I believe, when we fixate on particular forms and technologies, taking them, in and of themselves, to be the carriers of what we want either to embrace or resist. Not only do we fail to see the forms and technologies in their full complexity, but we use them, in their symbolic simplicity, as blunt instruments with which to beat one another over the head.

Scrolling Forward p. 198

PS. The bibliography is a great source of new material to read too.
PSS. This blog post was also a not-so-secret experiment in using RDFa and the Bibliographic Ontology to mark up quotations. Check out the rdf assertions you can extract from it using the RDFa Distiller.

Everyone’s a critic right? Nevertheless, I’m just going to jot down a few thoughts about the API, mainly for my friend over in #code4lib Bill Dueber who works on the project. Let me just say at the outset that I think it’s awesome that HathiTrust are providing this API, especially given some of the licensing constraints around some of the content. The API is a good example of putting library data on the web using both general and special purpose standards. But there are a few minor things that could be tweaked I think, to make the API fit into the web and the repository space a bit better.

it would be nice if the OpenSearch description document referenced in the HTML at

http://catalog.hathitrust.org/Search/OpenSearch?method=describe

worked. It should be pretty easy and non-invasive to add a basic description file for the HTML response since the search is already GET driven. Ideally it would be nice to see the responses also available as Atom and/or JSON with Atom Feed Paging.

Another thing that would be nice to see is the API being merged more into the human usable webapp. The best way to explain this is with an example. Consider the HTML page for this 1914 edition of Walt Whitman’s Leaves of Grass, available with this clean URI:

http://catalog.hathitrust.org/Record/000206297

Now, you can get a few flavors of metadata for this book, and an aggregated zip file of all the page images and OCR if you are a HathiTrust member. Why not make these alternate representations discoverable right from the item display? It could be as simple as adding some <link> elements to the HTML, that use the link relations they’ve already established for their Atom:

<head>
<link rel="http://schemas.hathitrust.org/htd/2009#meta" 
    type="application/atom+xml" 
    href="http://services.hathitrust.org/api/htd/meta/mdp.39015056032132" />
<link rel="http://schemas.hathitrust.org/htd/2009#structure " 
    type="application/atom+xml" 
    href="http://services.hathitrust.org/api/htd/structure/mdp.39015056032132" />
<link rel="http://schemas.hathitrust.org/htd/2009#aggregate" 
    type="application/zip" 
    href="https://services.hathitrust.org/api/htd/aggregate/mdp.39015056032132" />
</head>

If you wanted to get fancy you could also put human readable links into the <body> and annotate them w/ RDFa. But this would just be icing on the cake. There are a few reasons for doing at least the bare minimum. The big one is to enable in browser applications (like Zotero, etc) to be able to learn more about a given resource in a relatively straightforward and commonplace way. The other big one is to let automated agents like GoogleBot and YahooSlurp and Internet Archive’s Heritrix, etc. discover the deep web data that’s held behind your API. Another nice side effect is that it helps people who might ordinarily scrape your site automatically discover the API in a straightforward way.

Lastly, I was curious to know if HathiTrust considered adjusting their Atom response to use the Atom pattern recommended by the OAI-ORE folks. They are pretty close already, and in fact seem to have modeled their own aggregation vocabulary on OAI-ORE. It would be interesting to hear why they diverged if it was intentional, and if it might be possible to use a bit of oai-ore in there so we can bootstrap an oai-ore harvesting ecosystem.

I’m not sure that I can still call this approach to integrating web2.0 APIs into web1.x applications Linked Data anymore, since it doesn’t really involve RDF directly. It does involve thinking in a RESTful way about the resources you are publishing on the web, and how they can be linked together to form a graph. My colleague Dan has been writing in Computers in Libraries recently about how perhaps thinking in terms of “building a better web” may be a more accurate way of describing this activity.

For reasons I don’t fully understand I’ve been reading a lot of Wittgenstein (well mainly books about Wittgenstein honestly) lately during the non-bike commute. The trajectory of his thought over his life is really interesting to me. He had this zen-like, controversial idea that

Philosophy simply puts everything before us, nor deduces anything. — Since everything lies open to view there is nothing to explain. For what is hidden, for example, is of no interest to us. (PI 126)

I really like this idea that our data APIs on the web could be “open to view” by checking out the HTML, following your nose, and writing scrapers, bots and browser plugins to use what you find. I think it’s unfortunate that the recent changes to the Linked Data Design Issues, and the ensuing discussion seemed to create this dividing line about the use of RDF and SPARQL. I had always hoped (and continue to hope) that the Linked Data effort is bigger than a particular brand, or reformulation of the semantic web effort … for me it’s a pattern for building a better web. I think RDF is very well suited to expressing the core nature of the web, the Giant Global Graph. I’ve served up RDF representations in applications I’ve worked on just for this reason. But I think Linked Data pattern will thrive most if it is thought of as an inclusive continuum of efforts, similar to what Dan Brickley has suggested. Us technology people strive for explicitness, it’s an occupational hazard — but there’s sometimes quite a bit of strength in ambiguity.

Anyhow, my little review of the HathiTrust API turned into a bit of a soapbox for me to stand on and shout like a lunatic. I guess I’ve been wanting to write about what I think Linked Data is for a few weeks now, and it just kinda bubbled up when I least expected it. Sorry Bill!