adr: language tagging for preferred_label and alternative_labels #109

Context

ADR-0007 gave Work an optional alternative_labels list of plain strings, published as skos:altLabel. It considered language-tagged label objects ({ value: string, language?: string }[]) and rejected them — explicitly not on merit:

it is the better end state, but it leaves preferred_label a bare string, and the inconsistency means the language question should be answered for both fields at once.

It filed the follow-up:

Separate ADR: language tagging for labels, answered for preferred_label and alternative_labels together.

The problem

Both label fields are bare strings today, so the registry publishes labels in several languages with no way to say which is which.

• preferred_label holds one English string per work, even where the scholarly name is not English.
• The eight Nietzsche works are registered under German titles; the Dante, Hume and Homer works under Italian, English and English.
• alternative_labels mixes kinds and languages in one flat list: abbreviations (NE, LXX, PI), Latin and Greek titles, and translated titles.

A client cannot select the label for its reader's language, and skos:altLabel is published without the language tag SKOS expects.

What exists to build on

• LanguageTag is already implemented at standard/schema/common.ts — RFC 5646 langtag plus privateuse — and mirrored as an OpenAPI pattern. The validator does not need to be written.
• ResolverTargetEntry already uses it, so there is a precedent for the shape inside this codebase.

Constraints

• Identity is untouched. No label is a UUID seed input under ADR-0002, so any change here re-mints nothing. That was ADR-0007's central guarantee and it must survive.
• preferred_label is required and published. Changing its type is a breaking change to Work. Under the working-draft clause that is permitted before 1.0, but it is not free after v0.1.0 is tagged and citable.
• Homonymy stays legal. ADR-0007 lets two works claim the same label. Language tagging must not turn that into an error.
• Ranked search reads these fields. src/lib/find.ts ranks on a seven-tier ladder over both label fields. A shape change reaches the finder and the registry browser filter.

Related, and worth deciding together

#92 asks for ranked search over alternative labels and for a way to mark an entry as an abbreviation rather than a title. An abbreviation is language-bearing too — NE is English, EN is German for the same work. If the entry shape gains a language, it may as well gain a kind in the same change rather than in two successive breaking changes.

Links

• decisions/ADR-0007-alternative-labels-for-works.md — the rejected option 3, and open question 1
• standard/schema/common.ts — the existing LanguageTag
• adr: ranked search over alternative labels, and duplicate-hit disambiguation #92 — ranked search and abbreviation kinds