Metadata values¶

A value is the answer that fills in a property. dcterms:creator → Jane Smith. Simple enough, but a value can take one of three shapes, and knowing which shape you mean saves a lot of confusion later. Plenty of people, and a fair bit of cataloguing software, get it subtly wrong.

The three shapes of a value¶

Shape	What it is	Example	"Jane Smith" stored as…
Literal	plain text, the words are the value	a title, an abstract, a date	the text `"Jane Smith"`
Link out (URI)	a pointer to a thing out on the web	a Wikidata person, a Library of Congress subject	a web address, with `"Jane Smith"` as a label
Link in (resource)	a pointer to another object in this archive	the Item that is Jane Smith	a reference to that object's record

The trap is assuming a value is always the first shape (just text) or at most the first two. The third shape is the one that makes an archive relational instead of a pile of disconnected text, and it's easy to miss.

1. Literal: the words are the value¶

Most values are literals. A title, a description, a note, a date written as text. There is nothing behind the words. The string itself is the whole answer.

dcterms:title → "Letter to the Editor, March 1968"

A literal can carry a language tag but it never points anywhere. What you see is what it is.

2. Link out: point at something on the web¶

Sometimes the value isn't really text. It's a thing that already has an official identity somewhere on the web. A person in Wikidata, a subject heading at the Library of Congress, a place in GeoNames. Instead of retyping "Jane Smith" as loose text (which no computer can tell apart from any other Jane Smith), you point at the authoritative web address for that Jane Smith.

dcterms:creator → https://www.wikidata.org/wiki/Q6152786 (labelled "Jane Smith")

You still show a friendly label "Jane Smith" to readers, but underneath, the value is an unambiguous link.

3. Link in: point at another object in this archive¶

This is the shape people forget. A value can point at another object you've already catalogued in Athena. The creator of a letter can be an Item that represents Jane Smith. A photograph's subject can be the Item Set for a protest it documents.

dcterms:creator → (the Item "Jane Smith" in this archive) dcterms:isPartOf → (the Item Set "1968 Correspondence")

This is what turns a heap of records into a connected archive. Click Jane Smith on one letter and find every other object that links to her. Relationship-style properties (isPartOf, hasPart, relation, references, creator, recipient) are exactly the ones that want this "link in" shape.

Link in vs. link out (same idea, different destination)

Both shapes 2 and 3 say "this value is a thing, not text." The only difference is where the thing lives: shape 2 points out to the public web. Shape 3 points in at another object in your own archive. A value that should be a link-in but gets stored as a bare literal looks fine on screen and silently loses the connection.

In one picture¶

graph LR
    P["Item: 'Letter, 1968'"]
    P -->|title| L["“Letter to the Editor”<br/><i>literal</i>"]
    P -->|creator| W["wikidata.org/Q12345<br/><i>link out</i>"]
    P -->|isPartOf| C["Item Set: '1968 Correspondence'<br/><i>link in</i>"]

One object, "three property → value" pairs, each a different shape. Same sentence every time: [class] - [property] - [value]. All that changes is what kind of thing the value is:

dctype:Text - dcterms:title - "Letter to the Editor". The value is a literal (the words are the value).
dctype:Text - dcterms:creator - wikidata.org/Q12345. The value is a link out, a URI pointing to a thing on the web.
dctype:Text - dcterms:isPartOf - Item Set "1968 Correspondence". The value is a link in, a pointer to another object in this archive.

Same class, same sentence shape every time. The only thing that varies down the list is what kind of thing sits in the value slot.

vocabulary:class¶

property:value¶

Editing values follows the object

A value belongs to an object (an Item, Item Set, or Media). Permission to add, edit, or remove a value is the same as permission to edit its parent object. If you can edit the object, you can edit its values. See User roles.