Lifting the Lid on Linked Data at ELAG 2011

Myself and Jane have just given our ‘Lifting the Lid on Linked Data‘ presentation at the ELAG European Library Automation Group Conference 2011 in Prague today. It seemed to go pretty well. There were a few comments about the licensing situation for the Copac data on the #elag2011 twitter stream, which is something we’re still working on.

[slideshare id=8082967&doc=elag2011-locah-110524105057-phpapp02]

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

In the previous post, I described some of the considerations in choosing RDF vocabularies to use for the LOCAH archival metadata. In the tables below, I’ve tried to summarise the properties used to “describe” an instance of each of the classes in our model, i.e. for a particular thing URI, in our dataset, one might expect to find triples with that URI as subject and these property URIs as predicates, and when our data is served as linked data, and a thing URI is dereferenced the “bounded description” provided will include those triples (and others) – though some may be optional, so not necessarily present for all instances (and some may not be present at all until we add some more data…!)

This is really more of a “reference document” than a blog post, but I provide it in part as documentation of the data creation/transformation process, and in part as a guide for potential users of the actual data. Having said that, the data is liable (even likely) to change so consumers should always refer to the actual data for an up-to-date picture of the terms used. I’ve tried to highlight (dark grey background) below terms which I consider to be particularly “at risk” and liable to be removed/replaced, mostly terms from the “locah” vocabulary.

Most of this data is generated from the transformation of the EAD XML documents; a small proportion is added separately. Again, I’ve tried to indicate that in the tables below (light grey background).

Finding Aid

Type rdf:type Class URI locah:FindingAid
foaf:Document
bibo:Document
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Title dcterms:title plain literal
Identifier dcterms:identifier plain literal
Description dcterms:description plain literal
Conforms to dcterms:conformsTo Standard URI standard:isadg
Publisher dcterms:publisher Repository (Agent) URI
Encoded As locah:encodedAs EAD URI
Topic foaf:topic Archival Resource URI
Subject dcterms:subject Archival Resource URI
Has Part dcterms:hasPart Biographical History URI

The following should probably be an owl:sameAs relationship (or we should just cite the Hub URI?)

See also rdfs:seeAlso Hub Page URI e.g.
http://archiveshub.ac.uk/data/
gb15sirernesthenryshackleton

EAD

Type rdf:type Class URI locah:EAD
foaf:Document
bibo:Document
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Title dcterms:title plain literal
Identifier dcterms:identifier plain literal
Description dcterms:description plain literal
Date Created dcterms:created plain literal
Conforms to dcterms:conformsTo Standard URI dbpedia:
Encoded_Archival_Description

standard:ead2002
Encoding Of locah:encodingOf Finding Aid URI

The Hub does not currently provide a URI for the EAD document, but it is planned to do so, at which point we should add an owl:sameAs relationship (or just cite the Hub URI?)

Repository (Agent)

Type rdf:type Class URI locah:Repository
foaf:Agent
dcterms:Agent
Label rdfs:label plain literal
Name foaf:name plain literal
Identifier dcterms:identifier plain literal
Country Code locah:
countryCode
plain literal
Maintenance Agency Code locah:
maintenance
AgencyCode
plain literal
Is Publisher Of locah:isPublisherOf Finding Aid URI
Provides Access To locah:
providesAccessTo
Archival Resource URI
Administers locah:administers Place URI
See also rdfs:seeAlso Archon Page URI e.g.
http://www.nationalarchives.gov.uk/
archon/searches/
locresult_details.asp?LR=15

Repository (Place)

Type rdf:type Class URI wg84_pos:
SpatialThing
Label rdfs:label plain literal
Title dcterms:title plain literal
Is Administered By locah:
isAdministeredBy
Repository URI
See also rdfs:seeAlso Archon Page URI e.g.
http://www.nationalarchives.gov.uk/
archon/searches/
locresult_details.asp?LR=15

The following data is not generated from the EAD documents, but added in from a separate source:

Postal Code gn:postalCode plain literal
Located In gn:locatedIn Postcode Unit URI e.g.
http://data.ordnancesurvey.co.uk/id/postcodeunit/CB21ER
Within ossr:within Postcode Unit URI e.g.
http://data.ordnancesurvey.co.uk/id/postcodeunit/CB21ER
Postcode postcode:postcode Postcode Unit URI e.g.
http://data.ordnancesurvey.co.uk/id/postcodeunit/CB21ER

Archival Resource

Type rdf:type Class URI locah:ArchivalResource
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Title dcterms:title plain literal
Level locah:level Level URI
Page foaf:page Finding Aid URI
Access Provided By locah:
accessProvidedBy
Repository (Agent) URI
Identifier dcterms:identifier plain literal
Date dcterms:date plain literal
Date Created or Accumulated locah:
dateCreated
AccumulatedString
plain literal

The following properties were introduced to distinguish different date cases (date range v single date).

Date Created or Accumulated locah:
dateCreated
Accumulated
typed literal
Date Created or Accumulated (Start) locah:
dateCreated
AccumulatedStart
typed literal
Date Created or Accumulated (End) locah:
dateCreated
AccumulatedEnd
typed literal
Produced In event:produced_in Creation Event URI
Extent (String) locah:extent plain literal
Extent dcterms:extent Extent URI
Language dcterms:language Language URI e.g.
http://lexvo.org/id/iso639-3/eng
Is Represented By locah:
isRepresentedBy
Document URI or Aggregation URI
Origination locah:origination Agent URI
Has Biographical History locah:
hasBiographicalHistory
Bioghist URI
Associated With locah:
asssociatedWith
Concept URI
Has Part dcterms:hasPart Archival Resource URI
Aggregates ore:aggregates Archival Resource URI
Is Part Of dcterms:isPartOf Archival Resource URI
Is Aggregated By ore:isAggregatedBy Archival Resource URI
Members locah:members (RDF Collection)
See also rdfs:seeAlso Hub Page URI e.g.
http://archiveshub.ac.uk/data/
gb15sirernesthenryshackleton-
gb15sirernesthenryshackleton-
imperialtrans-antarcticexpedition

For all of the following, the object is simply a copy of the XML element content from the EAD document as an XML Literal. This is a rather “dumb” and probably not terribly useful “translation” from the EAD; in a future iteration of the transform, we hope to extract further useful triples from this part of the EAD data, and we will probably remove some of these triples.

Custodial History locah:
custodialHistory
XML literal
Acquisitions locah:acquisitions XML literal
Scope and Content locah:
scopecontent
XML literal
Appraisal locah:appraisal XML literal
Accruals locah:accruals XML literal
Access Restrictions locah:
accessRestrictions
XML literal
Use Restrictions locah:
useRestrictions
XML literal
Physical or Technical Requirements locah:
physicalTechnical
Requirements
XML literal
Other Finding Aids locah:
otherFindingAids
XML literal
Location Of Originals locah:
locationOfOriginals
XML literal
Alternate Forms Available locah:
alternateForms
Available
XML literal
Related Material locah:
relatedMaterial
XML literal
Bibliography locah:bibliography XML literal
Note locah:note XML literal
Processing locah:processing XML literal

Level

Type rdf:type Class URI locah:Level
skos:Concept
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Comment rdfs:comment plain literal
Note skos:note plain literal
Definition skos:definition plain literal
Description dcterms:description plain literal

Language

Type rdf:type Class URI lvont:Language

Creation (Event)

Type rdf:type Class URI locah:Creation
lode:Event
event:Event
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Product event:product Archival Resource URI
Involved lode:involved Archival Resource URI
Time event:time Temporal Entity URI
At Time lode:atTime Temporal Entity URI

Time Interval

Type rdf:type Class URI time:Interval
time:TemporalEntity
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Timeline timeline:timeline Timeline URI timeline:universaltimeline
Start timeline:start typed literal
Interval Starts time:intervalStarts Time Interval URI e.g.
http://reference.data.gov.uk/id/
year/1874
End timeline:end typed literal
Interval Ends time:intervalEnds Time Interval URI e.g.
http://reference.data.gov.uk/id/
year/1874
Contains crm:
P86i_contains
Time Interval URI e.g.
http://reference.data.gov.uk/id/
year/1874
At timeline:at typed literal
Interval During time:intervalDuring Time Interval URI e.g.
http://reference.data.gov.uk/id/
year/1874
Falls Within crm:
P86_falls_within
Time Interval URI e.g.
http://reference.data.gov.uk/id/
year/1874

Extent

Type rdf:type Class URI locah:Extent
Label rdfs:label plain literal

In the EAD XML doc, extent is expressed simply as a literal. Where possible we’ve tried to parse out a “unit of measurement” and a quantity, reflected in RDF as a triple where the predicate reflects the unit and the object the quantity, as a typed literal, to try to make comparisons easier. I need to catch up with what current “best practice” is for representing quantities/units of measurement so this may well change. Also, currently, “units” include things like “file”, “paper” and “envelope”, which may not be terribly useful.

Archival Box locah:archbox typed literal (xsd:decimal)
Metre (Linear) locah:metre typed literal (xsd:decimal)
Cubic Metre locah:cubicmetre typed literal (xsd:decimal)
Folder locah:folder typed literal (xsd:decimal)
Envelope locah:envelope typed literal (xsd:decimal)
Volume locah:volume typed literal (xsd:decimal)
File locah:file typed literal (xsd:decimal)
Item locah:archbox typed literal (xsd:decimal)
Page locah:page typed literal (xsd:decimal)
Paper locah:paper typed literal (xsd:decimal)

Origination (Agent)

Type rdf:type Class URI foaf:Agent
dcterms:Agent
Label rdfs:label plain literal
Name foaf:name plain literal
Page foaf:page Biographical History URI
Is Origination Of locah:
isOriginationOf
Archival Resource URI

For links to other agents (external or internal):

Same As owl:sameAs Agent URI
Is Like umbel:isLike Agent URI

Biographical History

Type rdf:type Class URI locah:
BiographicalHistory
bibo:DocumentPart
bibo:Document
foaf:Document
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Title dcterms:title plain literal
Body locah:body XML literal, plain literal
Topic foaf:topic Agent URI
Subject dcterms:subject Agent URI
Is Biographical History For locah:
isBiographicalHistoryFor
Archival Resource URI
Is Part Of dcterms:isPartOf Finding Aid URI

Concept Scheme

Type rdf:type Class URI skos:ConceptScheme
Label rdfs:label plain literal

Concept (ControlAccess – Subject)

Type rdf:type Class URI skos:Concept
Label rdfs:label plain literal
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

The following properties represent the structure that is captured for controlaccess elements using the Hub EAD profile.

Name locah:name plain literal
Dates locah:dates plain literal
Location locah:location plain literal
Other locah:other plain literal

Concept (ControlAccess – Persname)

Type rdf:type Class URI skos:Concept
Label rdfs:label plain literal
Focus foaf:focus Person URI
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

The following properties represent the structure that is captured for controlaccess elements using the Hub EAD profile. Currently, there are properties associated with both the concept and the person who is the foaf:focus of the concept. I’m not sure this is necessary/useful, and we may remove some of these triples.

Surname locah:surname plain literal
Forename locah:forename plain literal
Dates locah:dates plain literal
Title locah:title plain literal
Epithet locah:epithet plain literal
Other locah:other plain literal

Person (ControlAccess – Persname)

Type rdf:type Class URI foaf:Person
foaf:Agent
dcterms:Agent
crm:
E21_Person
Label rdfs:label plain literal
Name foaf:name plain literal
Family Name foaf:familyName plain literal
Given Name foaf:givenName plain literal
Dates locah:dates plain literal
Title locah:title plain literal
Epithet locah:epithet plain literal
Other locah:other plain literal

For links to other persons (internal or external). Not generated from the EAD documents, but added in via separate process.

Same As owl:sameAs Person URI
Is Like umbel:isLike Person URI

Concept (ControlAccess – Famname)

Type rdf:type Class URI skos:Concept
Label rdfs:label plain literal
Focus foaf:focus Family URI
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

The following properties represent the structure that is captured for controlaccess elements using the Hub EAD profile. Currently, there are properties associated with both the concept and the family that is the foaf:focus of the concept. I’m not sure this is necessary/useful, and we may remove some of these triples.

Name locah:name plain literal
Dates locah:dates plain literal
Location locah:location plain literal
Other locah:other plain literal

Family (ControlAccess – Famname)

Type rdf:type Class URI locah:Family
foaf:Group
foaf:Agent
dcterms:Agent
Label rdfs:label plain literal
Name foaf:name plain literal
Dates locah:dates plain literal
Location locah:location plain literal
Other locah:other plain literal

For links to other families (internal or external). Not generated from the EAD documents, but added in via separate process.

Same As owl:sameAs Family URI
Is Like umbel:isLike Family URI

Concept (ControlAccess – Corpname)

Type rdf:type Class URI skos:Concept
Label rdfs:label plain literal
Focus foaf:focus Family URI
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

The following properties represent the structure that is captured for controlaccess elements using the Hub EAD profile. Currently, there are properties associated with both the concept and the organisation that is the foaf:focus of the concept. I’m not sure this is necessary/useful, and we may remove some of these triples.

Name locah:name plain literal
Dates locah:dates plain literal
Location locah:location plain literal
Other locah:other plain literal

Organisation (ControlAccess – Corpname)

Type rdf:type Class URI foaf:Organization
foaf:Agent
dcterms:Agent
Label rdfs:label plain literal
Name foaf:name plain literal
Dates locah:dates plain literal
Location locah:location plain literal
Other locah:other plain literal

For links to other organisations (internal or external). Not generated from the EAD documents, but added in via separate process.

Same As owl:sameAs Organisation URI
Is Like umbel:isLike Organisation URI

Concept (ControlAccess – Geogname)

Type rdf:type Class URI skos:Concept
Label rdfs:label plain literal
Focus foaf:focus Place URI
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

The following properties represent the structure that is captured for controlaccess elements using the Hub EAD profile. Currently, there are properties associated with both the concept and the place that is the foaf:focus of the concept. I’m not sure this is necessary/useful, and we may remove some of these triples.

Name locah:name plain literal
Dates locah:dates plain literal
Location locah:location plain literal
Other locah:other plain literal

Place (ControlAccess – Geogname)

Type rdf:type Class URI wg84_pos:
SpatialThing
Label rdfs:label plain literal
Name locah:name plain literal
Location locah:location plain literal
Other locah:other plain literal

For links to other places (internal or external). Not generated from the EAD documents, but added in via separate process.

Same As owl:sameAs Place URI
Is Like umbel:isLike Place URI

Concept (ControlAccess – GenreForm)

Type rdf:type Class URI locah:GenreForm
skos:Concept
Label rdfs:label plain literal
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

Concept (ControlAccess – Function)

Type rdf:type Class URI skos:Concept
Label rdfs:label plain literal
In Scheme skos:inScheme Concept Scheme URI

For links to other concepts (internal or external). Not generated from the EAD documents, but added in via separate process.

Exact Match skos:exactMatch Concept URI
Close Match skos:closeMatch Concept URI

Book/Document (ControlAccess – Title)

Type rdf:type Class URI foaf:Document
bibo:Document
Label rdfs:label plain literal
Title dcterms:title plain literal

Birth (Event)

Type rdf:type Class URI bio:Birth
bio:IndividualEvent
bio:Event
lode:Event
event:Event
crm:E67_Birth
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Date bio:date typed literal
Date dcterms:date typed literal
Time event:time Temporal Entity URI
At Time lode:atTime Temporal Entity URI
Has Time-Span crm:
P4_has_time-span
Time Interval URI
Agent bio:agent Person URI
Principal bio:principal Person URI
Agent event:agent Person URI
Involved Agent lode:involvedAgent Person URI
Brought Into Life crm:
P98_brought_into_life
Person URI

Death (Event)

Type rdf:type Class URI bio:Death
bio:IndividualEvent
bio:Event
lode:Event
event:Event
crm:E69_Death
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Date bio:date typed literal
Date dcterms:date typed literal
Time event:time Temporal Entity URI
At Time lode:atTime Temporal Entity URI
Has Time-Span crm:
P4_has_time-span
Time Interval URI
Agent bio:agent Person URI
Principal bio:principal Person URI
Agent event:agent Person URI
Involved Agent lode:involvedAgent Person URI
Was Death Of crm:
P100_was_death_of
Person URI

Floruit (Event)

Type rdf:type Class URI locah:Floruit
bio:IndividualEvent
bio:Event
lode:Event
event:Event
Label rdfs:label plain literal
Preferred Label skos:prefLabel plain literal
Date bio:date typed literal
Date dcterms:date typed literal
Time event:time Temporal Entity URI
At Time lode:atTime Temporal Entity URI
Agent bio:agent Person URI
Principal bio:principal Person URI
Agent event:agent Person URI
Involved Agent lode:involvedAgent Person URI
Was Death Of crm:
P100_was_death_of
Person URI

Object

Type rdf:type Class URI foaf:Document
bibo:Document
Is Aggregated By ore:isAggregatedBy Object Group URI

Object Group

Type rdf:type Class URI ore:Aggregation
dcmitype:Collection
bibo:Collection
Aggregates ore:aggregates Object URI

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.