Sunday, 29 of November of 2015

Publishing linked data by way of EAD files

[This blog posting comes from a draft of the Linked Archival Metadata: A Guidebook –ELM ]

If you have used EAD to describe your collections, then you can easily make your descriptions available as valid linked data, but the result will be less than optimal. This is true not for a lack of technology but rather from the inherent purpose and structure of EAD files.

A few years ago an organisation in the United Kingdom called the Archive’s Hub was funded by a granting agency called JISC to explore the publishing of archival descriptions as linked data. One of the outcomes of this effort was the creation of an XSL stylesheet transforming EAD into RDF/XML. The terms used in the stylesheet originate from quite a number of standardized, widely accepted ontologies, and with only the tiniest bit configuration / customization the stylesheet can transform a generic EAD file into valid RDF/XML. The resulting XML files can then be made available on a Web server or incorporated into a triple store. This goes a long way to publishing archival descriptions as linked data. The only additional things needed are a transformation of EAD into HTML and the configuration of a Web server to do content-negotiation between the XML and HTML.

For the smaller archive with only a few hundred EAD files whose content does not change very quickly, this is a simple, feasible, and practical solution to publishing archival descriptions as linked data. With the exception of doing some content-negotiation, this solution does not require any computer technology that is not already being used in archives, and it only requires a few small tweaks to a given workflow:

  1. implement a content-negotiation solution
  2. edit EAD file
  3. transform EAD into RDF/XML
  4. transform EAD into HTML
  5. save the resulting XML and HTML files on a Web server
  6. go to step #2

On the other hand an EAD file is the combination of a narrative description with a hierarchal inventory list, and this data structure does not lend itself very well to the triples of linked data. For example, EAD headers are full of controlled vocabularies terms but there is no way to link these terms with specific inventory items. This is because the vocabulary terms are expected to describe the collection as a whole, not individual things. This problem could be overcome if each individual component of the EAD were associated with controlled vocabulary terms, but this would significantly increase the amount of work needed to create the EAD files in the first place.

The common practice of using literals (“strings”) to denote the names of people, places, and things in EAD files would also need to be changed in order to fully realize the vision of linked data. Specifically, it would be necessary for archivists to supplement their EAD files with commonly used URIs denoting subject headings and named authorities. These URIs could be inserted into id attributes throughout an EAD file, and the resulting RDF would be more linkable, but the labor to do so would increase, especially since many of the named authorities will not exist in standardized authority lists.

Despite these short comings, transforming EAD files into some sort of serialized RDF goes a long way towards publishing archival descriptions as linked data. This particular process is a good beginning and outputs valid information, just information that is not as accurate as possible. This process lends itself to iterative improvements, and outputting something is better than outputting nothing. But this particular process is not for everybody. The archive whose content changes quickly, the archive with copious numbers of collections, or the archive wishing to publish the most accurate linked data possible will probably not want to use EAD files as the root of their publishing system. Instead some sort of database application is probably the best solution.


Leave a comment
http://sites.tufts.edu/liam/2014/01/05/linked-data-via-ead/
sites.tufts.edu
crawl=CC-MAIN-2015-48
25771
application/http; msgtype=response
sha1:HIDXBM7NU7AZ6PVE3MYR5FNHBNTKL656
<urn:uuid:7698d5f6-bbf8-47c0-b53a-3a480f03ad95>
2015-11-29T23:08:16Z
130.64.212.136
sha1:WJWIPKOD2L2PTV22LG222WZE2KTNY5EQ
<urn:uuid:6f3cc353-9fd1-4d55-91c1-71f80adae320>
http://sites.tufts.edu/liam/2014/01/05/linked-data-via-ead/
response
<urn:uuid:864116d6-f888-4394-8340-1ff0c101bbe3>
robots: classic
hostname: ip-10-71-132-137.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2015-48
operator: CommonCrawl Admin
description: Wide crawl of the web for Nov 2015
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf