Zum Inhalt
Sprache:DeutschEnglish Last updated: 2026-10-25

RDF-Export (CIDOC CRM, RiC-O, Memobase)

Anton exportiert Bestände als RDF in drei Profilen — Anton ist das einzige Archivdatenbank-System in der Schweiz, das alle drei standard­ konform liefert:

  • A+-Profil — CIDOC CRM 7.1.x als Leitmodell, RiC-O 1.1 selektiv mit-annotiert (für die breite Linked-Data-Welt, Wikidata, Europeana etc.)
  • Pure-RiC-O-Profil — reines RiC-O 1.1, standardkonform, ohne CRM (für RiC-O-only-Konsumenten wie SPA / Swiss Archival Portal, künftige ICA-Portale)
  • Memobase-Profil — JSON-LD-Form gemäss https://api.memobase.ch/context/* (für die Lieferung an Memobase via Memoriav-Konvention §9)

Drei Profile im Überblick

Profil Leitmodell Format Zweck
A+ (Standard) CIDOC CRM 7.1.x + RiC-O 1.1 selektiv Turtle (Default), JSON-LD, RDF/XML, N-Triples LOD-Veröffentlichung, breite Konsumenten (Wikidata, Europeana, GND-Aggregatoren)
RiC-O (pur) Reines RiC-O 1.1, Standard-Namespace JSON-LD (Default), Turtle, RDF/XML, N-Triples RiC-O-only-Konsumenten (SPA, ICA-Portale, RDA-konforme Archive)
Memobase RiC-O 1.1 mit Memobase-@context JSON-LD (Default), Turtle (Debug) Lieferung an Memobase / Memoriav

Alle drei Profile sprechen über dieselben Anton-Daten und dieselbe Bestands­hierarchie; sie unterscheiden sich nur in der Wahl der RDF-Properties, im IRI-Schema und im JSON-LD-Context.

Zugriff

1. UI — /export/rdf

Im Menü Daten-Export → RDF. Drei Spalten nebeneinander (reduziert sich responsive auf eine Spalte unter dem md-Breakpoint):

  • A+ (CIDOC CRM + RiC-O) — Drop-down mit Wurzel-Objekt (Collection / Recordgroup / Fonds), Knopf Erstelle RDF produziert asynchron eine Turtle-Datei in storage/rdf/<identifier>-cidoc.ttl.
  • RiC-O (pur) — gleiches Drop-down, Knopf Erstelle RiC-O RDF produziert JSON-LD in storage/rdf/<identifier>-ric.jsonld.
  • Memobase — gleiches Drop-down, Knopf Erstelle Memobase RDF produziert JSON-LD in storage/rdf/<identifier>-memobase.jsonld.

Die generierten Dateien erscheinen in der FileTable darunter und lassen sich direkt herunterladen oder löschen.

2. API — /api/v1/objects/{id}?format=…

On-demand, ohne Datei-Caching. Authentifizierung mit dem API-Token im Header wie bei allen anderen Anton-API-Calls (siehe API-Authentifizierung).

# A+ (default Turtle)
curl -H "Authorization: Bearer TOKEN" "https://archiv.example/api/objects/42?format=cidoc-crm"

# A+ als JSON-LD
curl -H "Authorization: Bearer TOKEN" "https://archiv.example/api/objects/42?format=cidoc-crm&serialization=jsonld"

# A+ als RDF/XML oder N-Triples
curl "...&format=cidoc-crm&serialization=rdfxml"
curl "...&format=cidoc-crm&serialization=ntriples"

# Memobase (default JSON-LD)
curl "...&format=memobase"

# Memobase als Turtle (Debug)
curl "...&format=memobase&serialization=turtle"

# Pure RiC-O (default JSON-LD)
curl "...&format=ric"

# Pure RiC-O als Turtle / RDF-XML / N-Triples
curl "...&format=ric&serialization=turtle"
curl "...&format=ric&serialization=rdfxml"
curl "...&format=ric&serialization=ntriples"

Akzeptierte format-Werte für das A+-Profil: cidoc-crm, cidoc, rdf (Aliase). Für das RiC-O-Profil: ric, rico (Aliase). Akzeptierte serialization-Werte pro Profil:

Profil turtle jsonld rdfxml ntriples
cidoc-crm ✓ (Default) ✓ ✓ ✓
ric ✓ ✓ (Default) ✓ ✓
memobase ✓ (Debug) ✓ (Default) ✗ HTTP 400 ✗ HTTP 400

3. CLI — anton:export-rdf

# Ganzer Tenant, A+, Turtle, auf stdout
php artisan anton:export-rdf --env=kr > kr.ttl

# Ein Teilbaum (z.B. Fonds mit id 42)
php artisan anton:export-rdf --env=kr --root=42 > fonds_42.ttl

# Memobase-Profil
php artisan anton:export-rdf --env=gf --root=1 --profile=memobase --format=jsonld > gf.jsonld

# Pure RiC-O
php artisan anton:export-rdf --env=kr --root=1 --profile=ric --format=jsonld > kr-ric.jsonld

# JSON-LD vom A+-Profil
php artisan anton:export-rdf --env=kr --format=jsonld > kr.jsonld

Optionen:

Option Default Bedeutung
--root=<id> leer Beschränkt den Export auf den Closure-Table-Teilbaum unter dem AntonObject mit dieser ID. Ohne --root= werden alle Root-Objekte exportiert.
--format=<wert> turtle (a-plus), jsonld (memobase + ric + bundle) Serialisierung
--profile=<wert> a-plus a-plus, memobase, ric (alias rico) oder a-plus-bundle
--include-protected aus Umgeht den Datenschutzfilter: gesperrte Datensätze, nur interne Medien und interne Textfelder kommen mit. Für Migration und Backup, nicht für Publikation. Wirkt bei a-plus, ric und a-plus-bundle — nicht bei memobase
--include-originals aus Nur a-plus-bundle: packt zusätzlich zu den web/thumb-Ableitungen die Original-Master ins ZIP
--media-layout=<wert> flat Nur a-plus-bundle: flat (anton-static) oder native (spiegelt die Medienablage, mit Konversions-Unterordner je Medium)

Migrations-Export

Die beiden Schalter zusammen machen aus dem Bundle ein vollständiges Migrationspaket statt einer Publikationsansicht:

php artisan anton:export-rdf --env=<slug> --root=<id> \
    --profile=a-plus-bundle --include-protected --include-originals

Das ZIP enthält dann den CIDOC-CRM/RiC-O-Graphen inklusive der gesperrten Datensätze und die Originaldateien. Damit lässt sich ein Bestand standardkonform in ein anderes System überführen.

Drei Einschränkungen

  • Es gibt kein fertiges Werkzeug, das das Paket wieder nach Anton einliest. Machbar wäre ein Rückweg mit einigem Aufwand, gebaut ist er nicht — für Backup und Wiederherstellung ist der native Round-Trip der vorgesehene Weg.
  • Schutzfristen stehen im Graphen und sind maschinell auswertbar, durchgesetzt werden müssen sie im Zielsystem.
  • Ein so erzeugtes Paket enthält personenbezogene und gesperrte Daten und darf nicht öffentlich gehostet werden.

Nur auf der CLI

Die UI (/export/rdf) und die API reichen --include-protected und --include-originals nicht durch — dort entsteht immer die gefilterte Publikationsvariante mit Derivaten. Bei Anton as a Service erzeugt k & r das Migrationspaket auf Anfrage; on premises läuft das Kommando die betreibende Institution selbst.

Was im A+-Profil drinsteht

CRM trägt das volle Detail, RiC-O die wichtigsten Klassen + Skelett. Stichworte:

  • AntonObject → crm:E73_Information_Object (E22 für physische Objekte, E33/E36/E31 je nach object_type) + rico:RecordSet/Record je nach Verzeichnungsstufe.
  • Hierarchie → crm:P46/P46i + rico:isOrWasIncludedIn.
  • AntonEvent → 17 verifizierte Eventtypen (creation, acquisition, reception, digitisation, …) auf die passenden CRM-Klassen (E12_Production, E8_Acquisition, E10_Transfer_of_Custody, …) plus Anton-Term redundant als crm:P2_has_type.
  • Notes typisiert als crm:E33_Linguistic_Object UND zusätzlich als matching rico:scopeAndContent/rico:history/rico:conditionsOfAccess etc. auf der Entität (A+-„Loss-#2-Fix").
  • Authority-Links (GND/VIAF/Wikidata/GeoNames) → owl:sameAs / skos:exactMatch auf die externe URI.
  • Standort → crm:P55_has_current_location + rico:hasOrHadPhysicalLocation auf einen eigenen <location/…>-Knoten (crm:E53_Place / rico:PhysicalLocation). Die locations-Tabelle ist nicht dieselbe wie places, entsprechend eigener IRI-Raum.
  • Schutzfrist → crm:P104_is_subject_to + rico:isOrWasRegulatedBy auf einen crm:E30_Right / rico:Rule-Knoten mit Fristtyp (crm:P2_has_type / rico:hasOrHadRuleType), Dauer als crm:E54_Dimension und Freigabejahr als crm:E52_Time-Span. Dazu eine klartextliche Aussage in rico:conditionsOfAccess («Closed until 2099»), damit der Status ohne Rechnen lesbar ist. Fehlt das Entstehungsdatum, wird die Frist ohne Jahr ausgewiesen — siehe Schutzfristen.
  • Gesperrtes und Internes wird gefiltert: objects.private, media.private_media, actors.private plus interne Note-Types (internal_note, archivists_notes, comment).

Der Export bildet Fristen ab, wendet sie aber nicht an

Mit --include-protected (Migration/Backup) enthält das Paket auch gesperrte Datensätze. Die Fristen stehen dann zwar im Graphen und sind maschinell auswertbar, durchgesetzt werden müssen sie aber im Zielsystem.

Vollständige Spec: https://github.com/kraenzle-ritter/anton-cidoc.

Was im RiC-O-(pur)-Profil drinsteht

Reines RiC-O 1.1, kein CIDOC CRM, keine Memobase-Aliase. Standard rico:-Namespace, Multilinguale Literale als @language-getagte Werte (de/fr/it/en/rm — alle Locales bleiben erhalten).

  • AntonObject → rico:Record (Items) bzw. rico:RecordSet (alle anderen Stufen).
  • Title als eigenes Node via rico:hasOrHadTitle → rico:Title mit rico:title (multilingual).
  • Identifier als eigenes Node via rico:hasOrHadIdentifier → rico:Identifier (zwei Nodes wenn identifier_old gesetzt).
  • Hierarchie via rico:isOrWasIncludedIn.
  • AntonEvent → eigenständiges rico:Activity-Node mit rico:hasActivityType (Term-URI), rico:hasParticipant (Record), rico:hasOrHadAgent (Person), rico:hasOrHadLocation (Place), rico:hasBeginningDate/hasEndDate → eigene rico:Date-Nodes mit rico:expressedDate (Text) + rico:normalizedDateValue (typed xsd:date/gYear).
  • Actor → rico:Person/Family/CorporateBody mit rico:hasOrHadName → eigene rico:Name-Nodes für Hauptname + Varianten + Alternativnamen.
  • Place → rico:Place mit rico:hasOrHadName und rico:hasOrHadLocation → Blank-Node mit geo:asWKT (lon/lat- korrigiert).
  • Keywords als rico:Concept + skos:Concept, referenziert via rico:hasOrHadSubject.
  • Media als rico:Instantiation mit ebucore:hasMimeType/ hasHash/size immer, plus AV-EBUcore-Properties aus den technischen Merkmalen des Masters (siehe unten).
  • IRI-Schema: https://<tenant>.anton.ch/id/<entity-type>/<tenant-slug>-<id> (überschreibbar via setting('ric_base_iri') pro Mandant oder config('exporter_rdf.ric.base_iri') global).
  • Authority-Links als schema:sameAs auf GND/VIAF/Wikidata/GeoNames.

Der Hauptunterschied zum A+-Profil: A+ schreibt die "RiC-O-Skelett"- Beziehungen (isOrWasIncludedIn, hasCreator) zusätzlich neben dem CRM-Detail; pure RiC-O liefert echte rico:Activity-Nodes mit allen Rollen — ein RiC-O-only-Konsument sieht damit die Events vollständig.

Was im Memobase-Profil drinsteht

Schlanker und Memobase-spezifisch:

  • Klassen-Trio Institution / RecordSet / Record (Anton-Tenant ↦ Institution, Anton-Objekt-Level item ↦ Record, alles andere ↦ RecordSet).
  • IRI-Schema https://memobase.ch/(institution|recordSet|record|digital)/<inst-slug>-<id> (konfigurierbar via memobase_slug-Setting; Fallback ist der Tenant-Slug).
  • Sprach-suffigierte Property-Aliase statt @language-Tags: titleDe/titleFr/titleIt, scopeAndContentDe, conditionsOfAccessFr etc. Nur Deutsch/Französisch/Italienisch — Englisch und Rätoromanisch werden gedroppt (englisch-only-Werte landen als Fallback unter dem nackten Alias-Namen).
  • Memoriav-Sponsoring-Hinweis rdau:P60451 → https://www.memoriav.ch/ auf jedem RecordSet und Record, sobald setting('memobase_sponsoring_memoriav') auf 1 gesetzt ist (Memoriav-Konvention §9).
  • EBUcore für AV-Material: ebucore:hasMimeType, ebucore:hasHash, ebucore:size immer. Bei Ton und Video aus den technischen Merkmalen (siehe unten) zusätzlich ebucore:duration, ebucore:hasCodec, ebucore:bitRate, ebucore:videoTrack, ebucore:samplingRate, ebucore:aspectRatio.

Der JSON-LD-Context ist als Snapshot eingefroren — Memobase könnte ihn serverseitig ändern; wir bemerken das durch ein gezieltes Audit, nicht automatisch zur Export-Laufzeit.

Per-Tenant-Settings für Memobase

Setting Pflicht? Bedeutung
repository_name ✓ Institutionsname (wird zu nameDe)
repository_isil empfohlen ISIL-Code (wdt:P791 am Institution-Node)
repository_email empfohlen Kontakt-Email (wdt:P968)
repository_url empfohlen Offizielle Website (wdt:P856)
memobase_slug optional Memobase-Slug im IRI (Default: Tenant-Slug)
memobase_sponsoring_memoriav für Memoriav-Kund:innen 1 aktiviert den Sponsor-Hinweis auf jedem Record

Alle Settings werden über /settings oder per Tinker (setting('key', 'value')) gepflegt.

AV-Metadaten

Dauer, Codec, Bitrate, Bildgrösse, Abtastrate und Seitenverhältnis kommen aus den technischen Merkmalen des Masters. Diese misst die Formatprüfung mit ffprobe bei der Übernahme, und der nächtliche Lauf media:validate-formats trägt sie für ältere Medien nach. Die Medienseite zeigt sie unter «Technische Merkmale». Der Codec ist der des Bildes, bei reinem Ton der des Tons; die Bitrate ist die der ganzen Datei.

Bei Bildern zählt nur die Grösse: aus den Merkmalen, wo es welche gibt (TIFF), sonst aus dem Kopf des Masters. Damit schreibt der RiC-O- und der A+-Export Breite und Höhe auch für Fotos.

Bis v0.111 standen diese Werte ein zweites Mal in sechs Spalten av_* der Tabelle media, gefüllt von media:extract-av-metadata. Spalten und Befehl sind seit v0.112 entfernt (#720).

Per-Objekt-Buttons in der Detail-Ansicht

Zusätzlich zum /export/rdf-Tab (Job-basiert, asynchron) kann jedes Objekt in der Detail-Ansicht synchron-downloadbar gemacht werden über das Download-Modul (Antonfield id 1105, früher word_download). Das Modul rendert bis zu acht Buttons in der internen Detail-Ansicht — welche erscheinen, steuert pro Format ein eigenes Setting:

Button Setting Inhalt
WORD level_of_description_ids_for_word_download Word-Findbuch via WordController
DIP level_of_description_ids_for_dip_download OAIS-DIP-Paket (BagIt-ZIP)
OCFL level_of_description_ids_for_ocfl_download OCFL-Objekt (ZIP)
OCFL (Bestand) level_of_description_ids_for_ocfl_subtree_download OCFL-Storage-Root
EAD level_of_description_ids_for_ead_download EAD-XML für dieses Objekt
CIDOC CRM level_of_description_ids_for_cidoc_download A+ Turtle für diesen Subtree
RiC-O level_of_description_ids_for_ric_download Pure RiC-O JSON-LD
Memobase level_of_description_ids_for_memobase_download Memobase-JSON-LD

Jedes Setting ist eine Liste von level_of_description_id-Werten. Default ist überall [] — bei einer frischen Installation sieht der User keinen neuen Button bis ein Admin via /settings (oder Tinker) die LoDs einträgt.

Beispiel: alle vier neuen Buttons auf Fonds/Series/File/Item aktivieren:

ddev artisan tinker --env=<slug> --execute='
use Ottosmops\Settings\Setting;
foreach (["ead", "cidoc", "ric", "memobase"] as $k) {
    Setting::setValue("level_of_description_ids_for_".$k."_download", [3, 4, 5, 6]);
}
'

Die Buttons hängen alle an synchrone Inline-Download-Routes (/objects/{id}/download/{format} mit Format ead|cidoc-crm|ric|memobase) und respektieren die mayBeShown()-Privacy-Logik der bestehenden Detail-Ansicht (gesperrte Datensätze sehen nur interne Rollen).

Grosse Teilbäume

Ab einer Grösse entstehen die Downloads des Moduls nicht mehr im Request, sondern im Hintergrund (Job BuildUserExport), mit den Rechten der Person, die sie auslöst. Die Datei erscheint dann unter Daten-Export → Meine Exporte (/export/mine), siehe Meine Exporte. Dasselbe gilt für den Excel-Export einer Trefferliste.

.env zählt Vorgabe
EXPORT_SYNC_RECORDS Datensätze im Teilbaum (Word, EAD, CIDOC CRM, RiC, Memobase), Zeilen beim Excel-Export 1000
EXPORT_SYNC_MEDIA Medien bei DIP (BagIt) und OCFL 500
EXPORT_KEEP_DAYS Tage, die eine Datei unter «Meine Exporte» bleibt 7

Das E-ARK DIP hat seine eigene Grenze, siehe DIP Download.

Hinweis zum Rename: Eine Backwards-Compat-Klasse WordDownload extends Download besteht weiterhin, damit kundenspezifische Form-Konfigurationen, die noch word_download referenzieren, rendern. Der Alias wird irgendwann entfernt — Tenants mit customer-spezifischen Forms sollten auf download umstellen.

Was nicht im Export landet

Gilt für den Standardfall — also ohne --include-protected:

  • Volltext (objects.full_text) — gehört nicht zu den ISAD-Feldern
  • Interne Textfelder (Notetypes internal_note, archivists_notes, comment) — werden im A+ und im Memobase-Profil gleich gefiltert
  • Gesperrte Datensätze (private = 1) — mit ihnen der ganze Teilbaum, weil sich die Sperre vererbt

Mit --include-protected entfallen die beiden letzten Punkte: gesperrte Datensätze, nur interne Medien und die internen Textfelder sind dann enthalten. Der Volltext bleibt in jedem Fall draussen.

Bezugspunkte