Describing the “things”: the RDF terms used (part 1)

In previous posts, I described:

  • the model of the “world” on which we’re basing the Archives Hub RDF data: the types of “thing” being described, and (some of) the relationships between them (1, 2, 3); and
  • the patterns for URIs to be assigned to the individual “things”

In this post and the next one, I’ll outline the RDF vocabularies we’re using to describe those “things”. This post covers some of the considerations in choosing the vocabularies and some of the “patterns” we’ve used in deploying them; the next lists the properties and classes you can expect to find in the LOCAH data.

Using existing RDF vocabularies

As far as possible, we’ve tried to make use of existing, deployed RDF vocabularies. These include:

Those distinctions between which vocabulary “describes” what are somewhat rough, particularly taking into account that the “directionality” of properties in RDF is somewhat arbitrary: a triple using the dcterms:creator property to link a created work to an agent is as much “about” the agent as it is “about” the thing created.

However, where we’ve seen a need to express a notion that is not well addressed by an existing vocabulary, we have defined the additional classes and properties required and provided URIs for them as a small “local” LOCAH RDF vocabulary. At this point in time, I consider most of these terms something of a “work in progress”, and likely to be revised (or even dropped completely) before the end of the project. But I suspect some will remain – which, given the bounded timescale of the project, leaves questions about the longer term management of such vocabularies.

Discovering Appropriate Vocabularies

Most of my knowledge of existing RDF vocabularies has come from lurking on good old-fashioned mailing lists, particularly the W3C Semantic Web Interest Group list and the Linked Open Data list. I don’t read every posting by any means, and the signal-to-noise ratio can be variable, but for me they remain an excellent source of information with a knowledgeable and active contributing community (and the archives are a great repository.)

In similar territory, Semantic Stackoverflow provides a “question-and-answer”-style service, though it tends to have a fairly technical focus.

Another useful source is to look at actual linked data datasets, particularly those which are in a similar “domain” to the one you’re working in and cover similar resource types, and check out what vocabularies they are using (and how they are using them). In the library/bibliographic domain in particular, there has been a fairly steady stream of linked data datasets appearing over the last couple of years, so there’s quite a bit to go on, rather less so for the archives case. For a few pointers, see e.g. this review post by Ed Summers (itself already nearly a year old).

There are some services which aim to provide disclosure/discovery services based on aggregations of information about vocabularies and their constituent terms, sometimes called “metadata registries” or “metadata schema registries”. I’ve had mixed experiences of using these services: in some cases the content is not current; in others the coverage is intentionally tailored to the requirements of a particular community, so the challenge becomes one of finding a registry whose coverage matches the task at hand. One service (with quite general coverage) which I have occasionally found useful is Schemapedia, a project by Ian Davis of Talis; it provides “vocabulary”-level descriptions, rather than descriptions of individual “terms” but it includes some examples of actual terms: see, e.g. the entry for the Biographical Vocabulary.

There are a number of services which provide search functions across aggregations of data gathered from the linked data Web/Semantic Web. Sindice crawls and aggregates a huge range of RDF data and provides a “Google”-like search across that aggregation. (I’ve also found navigating such an aggregation helpful in thinking about various aspects of linked data: the sig.ma browser highlights the consequences of merging data from multiple sources, and related issues of provenance, attribution and trust, for example).

Finally, at the risk of stating the obvious, plain old Web search engines can still be a useful entry point.

Having said all this, I admit that the discovery of RDF vocabularies is still something of a challenge, and I continue to come across useful things I’d missed. And having found something potentially useful often raises further questions: Is the vocabulary stable or still being developed? Is it described following “modern” good practice for RDF vocabularies? Is it being managed/curated? By an individual/institution/community? Does it have the support of a community of users? Particularly if the intention is for a dataset to have some longevity, these may be significant considerations.

Patterns for using RDF Vocabularies

While discovering RDF vocabularies capable of expressing the information you want to represent is a first step, it often raises issues of exactly how those vocabularies might best be deployed, or of choosing between several possible alternative solutions.

Leigh Dodds and Ian Davis of Talis have authored a booklet Linked Data Patterns which tries to address some of these challenges, by gathering together some common “patterns” of use, based on existing practice by linked data implementers – though perhaps inevitably at this stage, some aspects of that practice are something of a “moving target” as new challenges are identified and practice evolves to address them. (See, for example, a recent debate on the Linked Open Data mailing list covering the question of expectations for what the object of an rdfs:seeAlso triple might/should dereference to.)

I continue to find the reflections of linked data practitioners an excellent source, particularly those working in domains close to those I’m interested in. I regularly find myself referring to the series of posts by Jeni Tennison on creating linked data. In this context, the fifth post on “Finishing Touches” is particularly relevant, and in large part prompts my next couple of points.

Labelling

One of the principles I’ve tried to adhere to, following the guidance by Jeni is that each resource we expose should have a human-readable label, provided using the rdfs:label property, and as far as possible that label should function as a useful “stand-alone” name for the thing.

In some cases this is a straightforward matter of using some text content node in the EAD XML document as an RDF literal. In other cases, a single element in the EAD document is mapped to a number of distinct resources in our model. In these cases, the transformation process typically prefixes or suffixes the source text to generate labels for the various different things. Perhaps unsurprisingly, this sometimes leads to some slightly “artificial” or “stilted” results, so it’s something we may need to refine.

Also, and perhaps more problematically, as I’ve noted in a previous post, the practice of archival description has traditionally relied heavily on a “multi-level description” approach which results in the presentation of resource descriptions “in the context of” the descriptions of other related resources. So it is common to find individual items within a collection labelled simply as something like “Letter”, on the basis that the reader of the finding aid will glean further information from the fact that the description of the item is presented within a context provided by a list of other “sibling” items, all “children” of a “parent” aggregation of some form. Currently our mapping generates the rdfs:label of an item using only the label (EAD unititle element) of that item in the EAD document, with the result that we may indeed end up with many individual resources labelled “Letter” (though of course the description will also include other properties derived from other EAD data and links to “parent” resources). An alternative might be to try to generate a label by “qualifying” the item unittitle, say, by prefixing it with the label of a “parent” resource – though I suspect in practice this would generate some somewhat unwieldy results.

Where the source data makes it seem reasonable to express it, I’ve also indicated the use of a “preferred label”, using the skos:prefLabel property. I’m conscious here of the need to be careful: the SKOS specification includes a number of “integrity conditions”, rules which data using the SKOS vocabulary should follow. Amongst them is the requirement that

A resource has no more than one value of skos:prefLabel per language tag.

The important thing to remember is that this is intended to apply in an “open world” context, not simply as a condition scoped to a particular “document”. The EAD to RDF transform process is performed on a document-by-document basis. Within the Hub dataset, it is quite common that for a single resource, labels for that resource are generated from the content of multiple EAD documents. While in theory naming within the set of EAD documents should be consistent, in practice, the use of variants of names is widespread in our data – the names of archival repositories is one example. Generating an skos:prefLabel triple for each variant would result in a conflict with the integrity condition once the data was merged in the triple store.

Bearing in mind that the “open world” extends beyond the boundaries of our own dataset, the same considerations apply in the case where we are exposing URIs for resources for which other parties already expose descriptions, including an skos:prefLabel triple, and we can’t guarantee that the names in our data correspond to those provided by that source.

Inferencing

Another issue to consider is that referred to by Leigh and Ian in their “Materialize Inferences” pattern, and by Jeni Tennison in her discussion of “Derivable Data”. One of the strengths of using the RDF model is that it is supported by a formal semantics, a framework for reasoning with data, i.e. given some set of data, it is often possible to apply some formalised set of rules to infer or derive additional triples. However, it should not be assumed that all consumers of the data will have access to the tools which support such reasoning, so it may be more appropriate for a data provider like LOCAH to explicitly include at least some of those “derivable” triples in the data we provide.

For a simple example of what I mean, the Friend of a Friend (FOAF) vocabulary provides a property called foaf:name (“A name for some thing.”). As part of their description of that property, the FOAF vocabulary owners provide the triple:

foaf:name rdfs:subPropertyOf rdfs:label .

The RDFS property rdfs:subPropertyOf is one of those properties which is associated with a set of rules. What those rules say is that, for any two properties linked by an rdfs:subPropertyOf relation, two resources related by the first property are also related by the second. So each time I find a triple using foaf:name as a predicate, I can infer (deduce, derive) a second triple using the rdfs:label predicate, e.g. if I find

<http://example.org/id/person/p123> foaf:name “Ernest Henry Shackleton” .

then I can conclude

<http://example.org/id/person/p123> rdfs:label “Ernest Henry Shackleton” .

However, to reach that conclusion, my application needs (a) knowledge of the general rdfs:subPropertyOf inference rule, and (b) knowledge that foaf:name is a subproperty of rdfs:label – and (c) the processing capability to apply that rule!

By providing – “materializing” – both those triples in our source data, we relieve the consuming application of that responsibility – though that benefit comes at the cost of increasing the size of the descriptions we provide.

This tactic can be particularly useful, I think, for properties which are subproperties of “generic” vocabularies like the RDF Schema vocabulary or the Dublin Core vocabularies. Sometimes generic linked data tools have some “built-in knowledge” of, and/or specific behaviour associated with, some of these vocabularies (e.g. to obtain literal names/labels/titles for display to human readers). It may be perfectly reasonable to use a triple with some more specialised subproperty in our data to indicate some specific relationship, but where appropriate it is also helpful to “materialize” the triple using the more generic property as well, so that an application looking for RDF Schema or DC properties can easily access that data.

Extending that slightly, Jeni suggests a “rule of thumb” that “if the result of the reasoning involves a resource from another vocabulary, then we should include it”.

The subproperty case is just one example: the inference of resource type based on rdfs:range and rdfs:domain is another case in point. In the LOCAH data, we’ve tried to provide fairly “generous” type data (e.g. including “super-classes”) where possible – again, on the grounds that such information is a commonly used “hook” in user queries (“Select resources of type T where [some other criteria]”).

The “cost” of this approach is that the dataset and the individual “bounded descriptions” served are larger – so there is a “trade-off” here which we may want to monitor and reconsider once we see how the data is being used.

Events

As I mentioned earlier, we extended our very initial draft model to include a notion of “event”. Currently, the application of this approach in our data is quite limited: it is applied to the “creation”/”origination” of the archival resources, and to the birth, death and “periods of activity” (floruit) of individuals. What we do is similar to the approach sketched by Ben O’Steen in his processing of the British Library’s British National Bibliography data – though with a little more complexity as we make use of event ontologies which model time periods as resources, rather than as literals.

This is probably best illustrated by means of an example. Given a person with birth date of 1901 and death date of 1985, we generate an RDF graph like the following:

RDF Graph of Life Events Data

RDF Graph of Life Events Data

(The image links through to a larger version)

The time interval nodes at the right-hand side are reference.data.gov.uk URIs for years, like http://reference.data.gov.uk/id/year/1901

What I haven’t illustrated on that diagram is that I’ve also included some data using the CIDOC CRM ontology – actually using the Erlangen CRM vocabulary. I’m feeling my way a bit with this, so it is somewhat partial/experimental at the moment, but I hope to refine/extend it in the future.

The point I wanted to highlight is that we’ve made use of multiple “overlapping” vocabularies here – again on the grounds that it may be useful to provide that flexibility to consumers of the data querying using a specific vocabulary. As above, this is a “trade-off” which we may want to monitor and reconsider in the future.

Summary

I’ve tried to cover here some of the issues around our choices of RDF vocabularies and how we’ve deployed them. The next post will summarise the actual terms used.

LOD-LAM: International Linked Open Data in Libraries, Archives, and Museums Summit

LOD LAMI’m really pleased to announce that I was asked to join the organising committee for the International Linked Open Data in Libraries, Archives, and Museums Summit that will take place this June 2-3, 2011 in San Francisco, California, USA. There’s still time to apply until February 28th, and funding is available to help cover travel costs.

The International Linked Open Data in Libraries, Archives, and Museums Summit (“LOD-LAM”) will convene leaders in their respective areas of expertise from the humanities and sciences to catalyze practical, actionable approaches to publishing Linked Open Data, specifically:

  • Identify the tools and techniques for publishing and working with Linked Open Data.
  • Draft precedents and policy for licensing and copyright considerations regarding the publishing of library, archive, and museum metadata.
  • Publish definitions and promote use cases that will give LAM staff the tools they need to advocate for Linked Open Data in their institutions.

For more information see http://lod-lam.net/summit/about/.

The principal organiser/facilitator is Jon Voss (@LookBackMaps), Founder of LookBackMaps, along with Kris Carpenter Negulescu, Director of Web Group, Internet Archive, who is project managing.

I’m very chuffed to be part of the illustrious Organising Committee:

Lisa Goddard (@lisagoddard), Acting Associate University Librarian for Information Technology, Memorial University Libraries.
Martin Kalfatovic (@UDCMRK), Assistant Director, Digital Services Division at Smithsonian Institution Libraries and the Deputy Project Director of the Biodiversity Heritage Library.
Mark Matienzo (@anarchivist), Digital Archivist in Manuscripts and Archives at the Yale University Library.
Mia Ridge (@mia_out), Lead Web Developer & Technical Architect, Science Museum/NMSI (UK)
Tim Sherratt (@wragge), National Museum of Australia & University of Canberra
MacKenzie Smith, Research Director, MIT Libraries.
Adrian Stevenson (@adrianstevenson), UKOLN; Project Manager, LOCAH Linked Data Project.
John Wilbanks (@wilbanks), VP of Science, Director of Science Commons, Creative Commons.

It’ll be a great event I’m sure, so get your application in ASAP.

Identifying the “things”: URI Patterns for the Hub Linked Data

In my previous couple of posts, I outlined the model of the “world” on which we’re basing the RDF data we’re generating from the Archives Hub‘s EAD XML documents.

At the heart of the Linked Data approach is the principle that all the “things” we want to “say anything about” should be named using a URI, and that those URIs should use the http URI scheme, so that they can be easily “looked up” or “dereferenced” using Web technologies in order to obtain some information provided by the URI owner about the thing. So, having specified the types or classes of thing we want to refer to and describe, the next step is to decide on the structure of the http URIs that we’ll use to name the “instances” of those classes – the individual “things” – archival resources, repositories, concepts, persons, places, and so on. In this post, I’ll try to describe the patterns we’re using, and outline how we construct individual URIs using those patterns from the EAD input data. As I hope will become clearer, the nature of the input data conditions the form of the patterns we’ve chosen. This has turned into a rather long post (again!) but I hope the detail is useful – I think it’s important for us to try to document our processes and some of the issues we’ve grappled with as well as to present the conclusions.

In some (most) cases, these will be newly created URIs, under a domain that we (well, MIMAS and the Archives Hub service) own. For these URIs, the project is responsible for choosing the URIs and putting in place the mechanisms to ensure that their dereferencing results in the provision of some “useful information”. In other cases, we will simply be citing existing URIs, defined by other agencies who (hopefully!) provide for their dereferencing.

The UK Cabinet Office has recently published some general guidelines on URI patterns for government Linked Data, Designing URI Sets for the UK Public Sector, and within the JISC programme strand under which LOCAH is funded, projects are encouraged to follow the recommendations of those guidelines. Following these guidelines, the general URI pattern recommended to identify “things” is:

http://{domain}/id/{concept}/{reference}

where:

  • concept is a name for a class (resource type), like “person”
  • reference is a name for an individual instance of that class or type

Our RDF data is being generated, at least in the first instance, by processing EAD XML documents, so we want to construct our URIs for our “things” from content within those XML documents. And we want to do so in a way that, as far as possible, ensures that each of those URIs is an unambiguous name/referrer, i.e. it identifies a single “thing”, and we don’t end up with a single URI being used for what are in fact two different things. On the other hand, we can live with the case where we end up with multiple URIs, all of which identify a single thing, because information can be added at a later stage to indicate that they are synonyms.

The other point to note is that the initial transformation step is being performed on a “document-by-document basis”, i.e. taking a single EAD document as input and outputting RDF/XML. So for any given resource, the information we generate – including the URI of the resource – is based only on the content of that document (and any generally applicable information we can embed in the transform itself). There may be other data “about” that “thing” in another EAD document but we don’t have access to it at the time of transformation.

Also, it’s desirable that we construct our URIs in such a way that if we need to re-run the transform, we generate the same URIs from the same input data (unless we explicitly decide to change the patterns for some reason).

Finally, although the patterns below often make use of human-readable strings from the EAD document content, I haven’t treated human-readability as a major consideration. Having said that, I’ve tended to make use of (slightly normalised forms of) human-readable strings where possible, rather than, say, creating opaque “hashes”.

As with other aspects of the work, at this stage, this is a first cut at tackling the issue, and we may revise our approaches based on the experience of applying them over the dataset. Having gone through and constructed patterns for the various resource types, looking back over them now, I think I can see a small number of distinct methods that we’ve used:

  1. Identifiers: For some of these “things”, the EAD documents contain some sort of formally assigned identification code or number, which unambiguously – at least within the scope of the Hub collection – identifies that instance within the set of resources of that type (i.e. it serves as a “reference” in the terms of the Designing URI Sets… document). This is the case, for example, with the languages of the materials, using the did/langmaterial/language/@langcode attribute value. A variant of this is the case where such an identifier can be constructed from a combination of multiple pieces of content. Repositories, for example, can be identified by the pair of country code (ead/eadheader/eadid/@countrycode) and maintenance agency code (ead/eadheader/eadid/@mainagencycode). For these cases a combination of the name of the resource type and that identification code provides the basis for the “reference” part of the URI.
  2. “Authority-Controlled” Names: For many of the “things”, however, the EAD documents do not contain such a code; rather, they refer to things only by name. In some cases, the form of the name is drawn from an “authority file” – indicated in the EAD document – and the name includes sufficient information (e.g. birth/death dates, titles etc for a person) to make the resulting string an unambiguous referrer within the set of names from that source. For these cases, a combination of a name for the authority file and the name provides the basis for the “reference”. However, this does depend on the creator of the EAD document having accurately transcribed the “authoritative” form of the name, at least sufficiently to maintain unambiguity of reference.
  3. “Rule-Based” Names: In other cases, the “thing” is named, not using a name from a controlled list, but rather a name constructed according to some codified set of rules, where the rules used are indicated in the EAD document. The intent behind such rules is to try to ensure consistency of form and unambiguity of reference. The National Council of Archives’ Rules for the Construction of Personal, Place and Corporate Names (one of the rule sets recommended to Hub data creators) states “A personal name is constructed by combining mandatory and optional components of the name so that the person concerned can be identified with certainty and distinguished from others bearing similar names. An individual should have only one authorised form of name and each name should apply to only one individual.”Typically, as for the “authority file” case, this is achieved through the inclusion of dates, titles etc for persons. For these cases, a combination of a name for the rules and the name itself should provide the basis for the “reference”. However, in practice, the picture with the Hub data is somewhat more complex. First, in some cases where it is claimed that rules are followed, the content itself indicates that this is not the case. For example, the NCA Rules mandate that a personal name should include “the year in which a person was born or died, the span of years of his/her lifetime or the approximate period covered by his/her activities”, even if those dates are estimated. But there are cases in the data marked up as following the NCA Rules which do not meet this requirement – e.g. personal names providing only surname and forename with no dates – , which I suspect may result in ambiguous references. Second, even where the rule is followed and the mandatory components are present, the distributed nature of Hub data creation means that I suspect there is still some possibility that a single personal name may be used in two different sources to refer to what in fact are two different people (Consider e.g. the case of two data providers using the name “Smith, John, fl 1920-1950”).
  4. “Locally-Scoped” Names: In other cases, the form of the name is neither authority-controlled nor rule-based, but nevertheless there is some expectation that the form of the name used is sufficient to make it an unambiguous referrer within some context. This is the case, for example, with the content of the did/origination element. The difficulty, however, is in establishing reliably what that context is. What is that “local scope”? We’ve tentatively taken the approach that such names have been constructed in such a way as at least to be unambiguous within the collection of submissions to the Hub by a single repository. So by combining the repository identifier and the name, hopefully, we can arrive at a “reference” which avoids ambiguity. Again, it may turn out that this assumption is unreliable, and results in ambiguous references, so we may need to revisit this approach.
  5. “Identifier Inheritance”: (I’m sure there must be a formal term for this but I’m not sure what it is!) In these cases the EAD document does not provide an unambiguous name for the “thing” itself; however the “thing” has a simple relationship with some other “thing” for which identification fits into one of the other categories. Where the relationship is one-to-one, a URI can be constructed by adopting the pattern for that other “thing” and substituting the name of the resource type. An example of this is the case of the “biographical history” associated with a “unit of description”. The unit of description has an identifier (based on a pattern described below) and since – in data constructed using the Hub template – each unit has at most one biographical history, replacing the “unit” resource type name with a “bioghist” resource type name gives us a suitable URI path, e.g. for a unit of description for which the URI path contains “/unit/gb15abc”, the URI for the biographical history would contain “/bioghist/gb15abc”.A variant of this is the case where the relationship is many-to-one, rather than one-to-one. Here the approach needs to be extended to include e.g. a sequence number to distinguish the multiple “things”. This is the approach taken for the Unit of Description, where a “child” (“part”) unit of description uses the URI of the “parent” (“whole”) unit suffixed with a sequence number, e.g. for a unit of description for which the URI path contains “/unit/gb15abc”, the URIs for the “child” units would contain “/unit/gb15abc-1”, “/unit/gb15abc-2” and so on. In theory, this should not be necessary as the unitid for a unit should be unique within an EAD document, but in practice we’ve found that this is not the case in the actual data. (In this case, the identifier would be “reproducable” only if any new units are inserted at the end of a sequence rather than in the middle).
  6. So, with the caveat above that this is all somewhat tentative at this stage, I summarise below the approaches taken to generating URIs for instances of each of the classes in the Hub model. Note that sometimes, an instance of the same class is generated in different “contexts” within the EAD document, and in these cases different rules for URI construction may be applied in those different contexts, depending on the information available within the EAD document.

    We haven’t yet finalised the domain name we’ll be using, so for the purposes of the following, {root} represents the domain and the first part of the path. Italicised text is used for the URI patterns (or parts of them); bold text is used for XPath(-ish!) representations of the source of data within the EAD XML document.

    Finding Aid

    Pattern(s)

    {root}/id/findingaid/{eadid}

    eadid
    normalised form of ead/eadheader/eadid

    Example:

    {root}/id/findingaid/gb15sirernesthenryshackleton

    EAD document

    Pattern(s)

    {root}/id/EAD/{eadid}

    eadid
    normalised form of ead/eadheader/eadid

    Example(s)

    {root}/id/ead/gb15sirernesthenryshackleton

    Repository (Agent)

    Pattern(s)

    {root}/id/repository/{repositoryid}

    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode

    Example(s)

    {root}/id/repository/gb15

    Repository (Place)

    Pattern(s)

    {root}/id/place/{repositoryid}

    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode

    Example(s)

    {root}/id/place/gb15

    Unit of Description

    Pattern(s)

    {root}/id/unit/{unitid}

    unitid
    normalised form of archdesc/did/unitid and position within archdesc/dsc/c tree

    Note: In principle, it should be possible to use c/unitid content rather than position in tree, but in practice, there are cases where unitid content is not unique within the EAD document.

    Example(s)

    {root}/id/unit/gb15sirernesthenryshackleton

    {root}/id/unit/gb15sirernesthenryshackleton-1

    Level

    Pattern(s)

    {root}/id/level/{level-name}

    level-name
    archdesc/@level or archdesc/@otherlevel or c{n}/@level or c{n}/@otherlevel

    Example(s)

    {root}/id/level/fonds

    Language

    Pattern(s)

    http://lexvo.org/id/iso639-3/{langcode}

    Note: use existing lexvo.org URIs for languages.

    langcode
    did/langmaterial/language/@langcode

    Example(s)

    http://lexvo.org/id/iso639-3/eng

    Creation (Event)

    Pattern(s)

    {root}/id/creation/{unitid}

    unitid
    normalised form of archdesc/did/unitid and position within archdesc/dsc/c tree

    Example(s)

    {root}/id/creation/gb15sirernesthenryshackleton

    Creation (Time)

    Pattern(s)

    {root}/id/creationtime/{unitid}

    unitid
    normalised form of archdesc/did/unitid and position within archdesc/dsc/c tree

    Example(s)

    {root}/id/creationtime/gb15sirernesthenryshackleton

    Extent

    Pattern(s)

    {root}/id/extent/{unitid}

    unitid
    normalised form of archdesc/did/unitid and position within archdesc/dsc/c tree

    Example(s)

    {root}/id/extent/gb15sirernesthenryshackleton

    Biographical History

    Pattern(s)

    {root}/id/bioghist/{unitid}

    unitid
    normalised form of archdesc/did/unitid and position within archdesc/dsc/c tree

    Example(s)

    {root}/id/bioghist/gb15sirernesthenryshackleton

    Concept (Origination)

    Pattern(s)

    {root}/id/concept/agent/{repositoryid}/{origination-name}

    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode

    Example(s)

    {root}/id/concept/agent/gb15/sirernesthenryshackleton

    Agent (Origination)

    Pattern(s)

    {root}/id/agent/{repositoryid}/{origination-name}

    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode

    Example(s)

    {root}/id/agent/gb15/sirernesthenryshackleton

    Concept (ControlAccess – Subject)

    Pattern(s)

    {root}/id/concept/{source}/{subject-name}

    {root}/id/concept/{repositoryid}/{subject-name}

    source
    controlaccess/subject/@source
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    subject-name
    normalised form of controlaccess/subject

    Example(s)

    {root}/id/concept/lcsh/antiquities

    Concept (ControlAccess – Persname)

    Pattern(s)

    {root}/id/concept/person/{source}/{person-name}

    {root}/id/concept/person/{rules}/{person-name}

    {root}/id/concept/person/{repositoryid}/{person-name}

    source
    controlaccess/persname/@source
    rules
    controlaccess/persname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    person-name
    normalised form of controlaccess/persname/

    Example(s)

    {root}/id/concept/person/nra/shackletonernesthenry1874-1922sirknightexplorer

    {root}/id/concept/person/ncarules/holdenwendyfl1990cartoonist

    {root}/id/concept/person/gb1832/berlinisaiah1909-1997sirknighthistorian

    Person (ControlAccess – Persname)

    Pattern(s)

    {root}/id/person/{source}/{person-name}

    {root}/id/person/{rules}/{person-name}

    {root}/id/person/{repositoryid}/{person-name}

    source
    controlaccess/persname/@source
    rules
    controlaccess/persname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    person-name
    normalised form of controlaccess/persname/

    Example(s)

    {root}/id/person/nra/shackletonernesthenry1874-1922sirknightexplorer

    {root}/id/person/ncarules/holdenwendyfl1990cartoonist

    {root}/id/person/gb1832/berlinisaiah1909-1997sirknighthistorian

    Concept (ControlAccess – Famname)

    Pattern(s)

    {root}/id/concept/family/{source}/{family-name}

    {root}/id/concept/family/{rules}/{family-name}

    {root}/id/concept/family/{repositoryid}/{family-name}

    source
    controlaccess/famname/@source
    rules
    controlaccess/famname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    family-name
    normalised form of controlaccess/famname/

    Example(s)

    {root}/id/concept/family/nra/dundasviscountsmelvilledunira

    {root}/id/concept/family/ncarules/boucicault

    Family (ControlAccess – Famname)

    Pattern(s)

    {root}/id/family/{source}/{family-name}

    {root}/id/family/{rules}/{family-name}

    {root}/id/family/{repositoryid}/{family-name}

    source
    controlaccess/famname/@source
    rules
    controlaccess/famname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    family-name
    normalised form of controlaccess/famname/

    Example(s)

    {root}/id/family/nra/dundasviscountsmelvilledunira

    {root}/id/family/ncarules/boucicault

    Concept (ControlAccess – Corpname)

    Pattern(s)

    {root}/id/concept/organisation/{source}/{org-name}

    {root}/id/concept/organisation/{rules}/{org-name}

    {root}/id/concept/organisation/{repositoryid}/{org-name}

    source
    controlaccess/corpname/@source
    rules
    controlaccess/corpname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    org-name
    normalised form of controlaccess/corpname/

    Example(s)

    {root}/id/concept/organisation/nra/britishbroadcastingcorporation

    {root}/id/concept/organisation/aacr2/dailymail%28london%2Cengland%29

    {root}/id/concept/organisation/gb1578/vizards%2Csolicitors%2Cmonmouth

    Organisation (ControlAccess – Corpname)

    Pattern(s)

    {root}/id/organisation/{source}/{org-name}

    {root}/id/organisation/{rules}/{org-name}

    {root}/id/organisation/{repositoryid}/{org-name}

    source
    controlaccess/corpname/@source
    rules
    controlaccess/corpname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    org-name
    normalised form of controlaccess/corpname/

    Example(s)

    {root}/id/organisation/nra/britishbroadcastingcorporation

    {root}/id/organisation/aacr2/dailymail%28london%2Cengland%29

    {root}/id/organisation/gb1578/vizards%2Csolicitors%2Cmonmouth

    Concept (ControlAccess – Geogname)

    Pattern(s)

    {root}/id/concept/place/{source}/{place-name}

    {root}/id/concept/place/{rules}/{place-name}

    {root}/id/concept/place/{repositoryid}/{place-name}

    source
    controlaccess/geogname/@source
    rules
    controlaccess/geogname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    place-name
    normalised form of controlaccess/geogname/

    Example(s)

    {root}/id/concept/place/lcsh/mcmurdosound%28antarctica%29

    {root}/id/concept/place/ncarules/canada

    {root}/id/concept/place/gb982/meirionethshire%28wales%29

    Place (ControlAccess – Geogname)

    Pattern(s)

    {root}/id/place/{source}/{place-name}

    {root}/id/place/{rules}/{place-name}

    {root}/id/place/{repositoryid}/{place-name}

    source
    controlaccess/geogname/@source
    rules
    controlaccess/geogname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    place-name
    normalised form of controlaccess/geogname/

    Example(s)

    {root}/id/place/lcsh/mcmurdosound%28antarctica%29

    {root}/id/place/ncarules/canada

    {root}/id/place/gb982/meirionethshire%28wales%29

    Concept (ControlAccess – GenreForm)

    Pattern(s)

    {root}/id/concept/{source}/{genreform-name}

    {root}/id/concept/{rules}/{genreform-name}

    {root}/id/concept/{repositoryid}/{genreform-name}

    source
    controlaccess/genreform/@source
    rules
    controlaccess/genreform/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    genreform-name
    normalised form of controlaccess/genreform

    Example(s)

    {root}/id/concept/aat/buildingplans

    Concept (ControlAccess – Function)

    Pattern(s)

    {root}/id/concept/{source}/{function-name}

    {root}/id/concept/{rules}/{function-name}

    {root}/id/concept/{repositoryid}/{function-name}

    source
    controlaccess/function/@source
    rules
    controlaccess/function/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    function-name
    normalised form of controlaccess/function

    Example(s)

    {root}/id/concept/agift/miningregulations

    Book

    Pattern(s)

    {root}/id/document/{title}

    source
    controlaccess/title/@source
    rules
    controlaccess/title/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    title
    normalised form of controlaccess/title

    Example(s)

    {root}/id/document/aacr2/thecastlediaries1974-761980

    Birth (Event)

    Pattern(s)

    {root}/id/birth/{source}/{person-name}

    {root}/id/birth/{rules}/{person-name}

    {root}/id/birth/{repositoryid}/{person-name}

    source
    controlaccess/persname/@source
    rules
    controlaccess/persname/@rules
    repositoryid
    normalised form of concatentation of ead/eadheader/eadid/@countrycode and ead/eadheader/eadid/@mainagencycode
    person-name
    normalised form of controlaccess/persname/

    Example(s)

    {root}/id/birth/nra/shackletonernesthenry1874-1922sirknightexplorer

    {root}/id/birth/ncarules/allenjim1926-1999playwright

    {root}/id/birth/gb1832/berlinisaiah1909-1997sirknighthistorian

    Object

    Pattern(s)

    {object-uri}

    object-uri
    dao/@href or daogrp/daoloc/@href

    Example(s)

    http://library.kent.ac.uk/library/special/html/specoll/jack.gif

    Object Group

    Pattern(s)

    {root}/id/group/{unitid}-{groupno}

    unitid
    normalised form of archdesc/did/unitid and position within archdesc/dsc/c tree
    groupno
    position within daogrp sequence for archdesc or c{n}

    Example(s)

    {root}/id/group/gb0254ms274-1

    Time Interval (Year, Month, Day)

    i.e. specific intervals of time.

    Pattern(s)

    http://reference.data.gov.uk/id/year/{yyyy}

    http://reference.data.gov.uk/id/month/{yyyy}-{mm}

    http://reference.data.gov.uk/id/day/{yyyy}-{mm}-{dd}

    Note: use existing reference.data.gov.uk URIs for intervals.

    langcode
    did/langmaterial/language/@langcode

    Example(s)

    http://reference.data.gov.uk/id/year/1921

    http://reference.data.gov.uk/id/month/1921-06

    http://reference.data.gov.uk/id/day/1921-06-03

Some more “things”: some extensions to the Hub model

Having had a little more time to experiment with the Archives Hub EAD data, and to think about what sort of operations on the RDF data we might wish to perform or enable others to perform, I’ve introduced a few small extensions to the model I described a couple a few weeks ago.

Extents

At our last project meeting, we talked about some of the possibilities for visualisations of the data. One of the ideas (suggested by Jane) is to explore representing relative sizes of collections, perhaps on a map, so that, for example, a researcher could provide a geographic location and a subject area and get a visual representation of the relative sizes of collections within that area.

The EAD XML format provides an element called <extent> for “information about the quantity of the materials being described or an expression of the physical space they occupy”. Although the EAD Tag Library provides guidelines to try to encourage some uniformity of the content, the data in the Hub EAD documents is quite variable. Examples of the content in the samples I’ve looked at include:

  • 6.5 linear metres
  • 2.04 metres
  • 0.48m
  • 190 archive boxes
  • 13 boxes
  • One sheet of paper
  • 13 lever arch files, 48 sound tape reels, 490 audio cassette tapes (1 filing cabinet)

In the initial model, this was just treated in RDF as a single triple with subject the URI of the unit of description (an archival collection or some part of it) and this string a literal object. I’m suggesting changing this to treat the “extent” as a resource with its own URI, rather than simply as a literal. Doing that enables us – for at least some of these cases – to make explicit that it is a value measured in some “unit” (linear metres, archival boxes), to “normalise” the way those units are represented (so e.g. “linear metres”, “metres” and “m” can be mapped to a single form in the RDF data), and possibly to make comparisons, albeit approximate ones, between extents measured in different units (for example, “archival boxes” and “linear metres”).

So we end up with patterns in the RDF graph like:

unit:123 dcterms:extent extent:123 .

extent:123 ex:metres “2.04”^^xsd:decimal .

Having said that, I recognise that the nature of the input data is such that such techniques are usefully applicable only to a subset of the data; I’m not sure there’s a great deal we can do with “composite” strings like the last one in the list above, other than present them to a human reader.

Events and Times

One of the other ideas for presenting data we’ve chewed around is that of some sort of “timeline” view. It’s something I’ve been quite keen to explore – though I’m conscious that the much of the most useful information is, in the EAD documents, in the form only of prose in the “biographical/administrative histories” provided for the originators of the archives.

As a first tentative step in this direction, I’ve introduced a notion of “event” into the model, where, in the first instance:

  • the Creation of a unit of description is modelled as an event taking place during a period of time
  • (where birth/death dates are provided in the input) the Birth and Death of a person are modelled as events taking place during a period of time

It’s possible to generate this just from simple processing of the input data. It may be possible to go further and generate a richer range of “events” through the use of some flavour of intelligent text analysis/”entity extraction” tools on the biographical/administrative history text, but that’s something for us to consider in the future.

Postcodes

Finally – and as I noted in the previous post this is something which goes beyond the content of the EAD documents themselves – prompted mainly by the recent announcement by John Goodwin that the Ordnance Survey had extended their linked data dataset to include “post code units”, I’ve added in a notion of “Postcode Unit” so that we can make links to resources from that dataset (and also to the UK Postcodes dataset).

So the revised model looks something like the figure below:

Diagram showing data model for EAD data

Figure 1

So, I’m hoping that – bug fixes aside – I can stop tinkering with this for a while 🙂 and that we can work with this version of the model, and test out what is possible and where any “pain points” are, and then think about where further changes might be useful.