RDF Item Description
If you were to select a set of RDF ontologies intended to be used in the
linked data of archival descriptions, then what ontologies would you
select?
And in response Ben Companjen <ben.companjen@dans.knaw.nl> wrote the following post, which I think is absolutely wonderful. So wonderful in fact, that I am reposting it with only the tiniest bit of copy editing. I think it is worth a re-read. Thank you, Ben!
While I'm no archivist by training (information systems engineer I am), I've learned a thing or two from having to work with EAD and its basis for use, ISAD(G) (all citations below are from ISAD(G), 2nd edition). As with all information modelling, either inside or outside the Linked Data domain, you should take a step back to look at the goal of the description. When you have a list of what you want to describe, you can start looking for ontologies.
You probably know this, but I was triggered by "Because many archival descriptions are rooted in MARC records, and MODS is easily mapped from MARC." to respond. IMO archival descriptions are rooted in rules for description, not a specific file format.
So, when I think of (some of) the essences of archival description, I think of:
- "The purpose of archival description is to identify and explain the context and content of archival material in order to promote its accessibility. This is achieved by creating accurate and appropriate representations and by organizing them in accordance with predetermined models."
- Seven areas of descriptive information:
- Identity Statement Area (where essential information is conveyed to identify the unit of description)
- Context Area (where information is conveyed about the origin and custody of the unit of description)
- Content and Structure Area (where information is conveyed about the subject matter and arrangement of the unit of description)
- Condition of Access and Use Area (where information is conveyed about the availability of the unit of description)
- Allied Materials Area (where information is conveyed about materials having an important relationship to the unit of description)
- Note Area (where specialized information and information that cannot be accommodated in any of the other areas may be conveyed).
- Description Control Area (where information is conveyed on how, when and by whom the archival description was prepared)."
There is a distinction between the thing being described, and the description itself, and both have an important role within the archival description. (If anything so far causes confusion with anyone here, I misunderstood and accept to be corrected :)) NB: this is one way of thinking of descriptions. Incorporating the PROV-ontology would make sense for expressing more/other aspects of the provenance of archival entities, but I haven't got round to becoming an expert of PROV yet ;)
ISAD(G) lists 26 "elements that may be combined to constitute the description of an archival entity".
Trying to translate these 'elements', I'd end up with possible a lot more than 26 RDFS/OWL properties. Depending on the type of archival entity you can/should of course use more specific ontologies.
Let me list some properties and related ontologies.
Identifiers
The URI, naturally, and other IDs. Could be linked using dc(terms):identifier, or mods:identifier, or other ontologies. Ideally there is some way of linking the domain of the ID to the ID itself, because "box 101" is likely not unique in the universe. Perhaps you want to publish a URI strategy separately to explain how the URI was assembled/derived.
Title
Again DC(terms), MODS, RDA
Date(s)
You want properties that have a clear meaning. For example, dcterms:created and mods:dateCreated assume it is clear what "when the resource was created" means. DC terms are vague, I mean general, on purpose. You could create some properties owl:subPropertyOf dcterms date properties for this. I'd look into EDTF for encoding uncertain dates and ranges and BCE dates (MODS doesn't support BCE dates).
Level of description
What kind of 'documentary unit' does the description describe? A whole building's content or one piece of paper? I don't know of any ontology with terms "fonds", "file", "item", but you could say <http URI> rdf:type <fonds class URI>.
Extent and medium
Saying anything about extent and medium should possible only happen on the lowest level of description. Any higher level extent and medium should be calculated by aggregating lower level descriptions. On the lowest level, refer to class URIs. A combination of dimensions and material {c|sh}ould be a class, e.g. A4 paper 80 grams/square meter.
Creator(s) and administrative/biographical history
As ISAD(G) refers to ISAAR(CPF) for description of corporate bodies, people, and families, this is a perfect example of using existing people- and organisation-describing ontologies like FOAF, BIO, ORG, and others are useful for separate descriptions of the people and organisations involved. You want specific properties to describe the roles of these 'agents' in the history of the archival entity.
Archival history and Immediate source of acquisition or transfer
and you would want them 'here' (of course there is no particular order in which these properties are used). PREMIS and PROV come to mind first for recording who did what to what, (where and?) when and with what result. There are probably some ontologies describing possible "events" as RDFS/OWL classes, so you could link to those. The immediate source of acquisition or transfer may be just another event.
Scope and content
Descriptions, keywords, terms from authority files about "scope (such as, time periods, geography) and content, (such as documentary forms, subject matter, administrative processes) appropriate to the level of description.": pretty natural fit for links to SKOS thesauri and other ontologies of real-world 'things'. One might think of dcterms:subject, dcterms:description, dcterms:temporalCoverage etc., but describing how exactly such terms relate to the archival entity needs more specific properties than "subject" et al.
Appraisal, destruction and scheduling information
Reasons for including things and (possibly) removal of archival entities should go very well in rules, and some types of rules go very well in ontologies. Making this up as I type: <class of letters written by the head of state> rdfs:subClassOf <class of 'things to be kept'>. The actual selection and destruction actions could be modelled in the same way as other actions are described for provenance.
Accruals
Whether more content can be expected probably depends on other properties of the archival entity, like its type(s) and creator(s). I don't know about specific properties to record this, but <class of living heads of state archival entities> rdfs:subClassOf <class of 'living' archival entities>? There are ways of modelling rules for this, like the Rules Interchange Format, but the rules may be defined by the archives and archivists.
System of arrangement
Thinking about this, I tend to think of a collection of keywords to describe the arrangement of a low-level archival entity like a folder or box: alphabetical, as found on deceased's desk. But there is more, of course. Perhaps using the Collection Ontology for low levels could help generate higher level 'systems of arrangement'.
Conditions governing access and Conditions governing reproduction
You can describe rights with the Creative Commons Rights Expression Language.
Language of material
mods:language maybe? Preferably used on sub-document level and generated for higher-level descriptions.
Physical characteristics / technical requirements
Conditions should follow from their respective properties: <class of PDF/A-1b files> :requiresForReading <class of PDF/A-1b readers> and rules that say documents in <class A> are embargoed for 20 years after creation + a creation date can present enough information to the agent to determine dcterms:dateAvailable.
Finding aids
As a non-archivist I had some trouble understanding the difference between descriptions and finding aids and what the exact use of a finding aid was. Also, having grown up with search engines, indexes, I think the concept may eventually become extinct. I guess you could use foaf:page to link a document-like finding aid to the archival entity and rdfs:seeAlso to point to machine-actionable related things.
Existence and location of originals/copies
PROV can be used to link a copy to an original (and how the copy was created etc.). <X> prov:wasDerivedFrom <Y>. <Y> :isAt <AnotherArchive>.
Related units of description / Publication note
Use properties that describe the specific relations among archival entities. DC Terms has some useful ones, like for citations. Related items can be derived from all or selected properties automatically too.
Notes
dcterms:description? Unlike a document containing rules that needs to be finished at some time, Linked Data has no such rule. You can always create a property with a well-defined meaning to use for specific information.
Archivist's note / dates of description
Who did what when, where, why and how to the description itself. Same as for the unit of description itself. This may be a good time to draw a bit more attention to the question: what is a description? I don't have a (/ there is no) final answer, but as The One True Written Paper Description from long ago is becoming a set of triples, you want to think about it. You could link versions of RDF documents using PROV to record this information.
Rules and conventions
A link to the rules and conventions for description. Could also fit with the PROV provenance.
No, this is not a list of ontologies to use/explore right away, but I hope you (and others) find it helpful, or perhaps even food for discussion. Also, have a look at CIDOC-CRM. It has lots of properties.
Regards,
Ben
Eric Morgan