Für Bestandsverläufe von fortlaufenden Ressourcen ("serials") wird das DAIA-Feld item
um ein optionales Unterfeld chronology
mit folgender Struktur ergänzt. Die Unterfelder sind so strukturiert, dass sie u.A. zur Anzeige, Sortierung und Filterung verwendet werden können.
Das Feld chronology
hat vier optionale Unterfelder, von denen mindestens eins gesetzt sein sollte (ansonsten kann chronology
ignoriert werden):
intervals
für Intervalle von Erscheinungszeiträumenpoints
für einzelne Erscheinungszeitpunkteembargo
für eine "moving wall"about
Bestandsverlauf und -Lücken als Freitext
Das Feld intervals
besteht aus einer nicht-leeren Liste von aufsteigenden Zeiträumen. Ein Zeitraum besteht aus folgenden optionalen Unterfeldern, wobei mindestens volume
oder year
vorhanden sein muss:
year
("Berichtsjahr"): Integer, in der Regel vierstelligyear2
("Berichtsjahr-bis"): Integer, in der Regel vielstellig. Muss, falls vorhanden größer alsyear
sein.endYear
: Integer, Endjahr des Zeitraums größer alsyear
volume
("Band"): Freitext, enthält in der Regel eine ZahlendVolume
: Freitext, enthält in der Regel eine Zahl größer alsvolume
issue
("Heft"): Freitext, enthält in der Regel eine ZahlendIssue
: Freitext, enthält in der Regel eine Zahl größer alsissue
missing
("Lücke"): boolean, ob es sich um Lücke handelt.
Band 1.1989 ff.:
[ { "volume": "1", "year": 1989 } ]
Seit Band 3, Berichtsjahr 1989/99:
[ { "volume": "3", "year": 1998, "year2": 1999 } ]
Das Unterfeld points
enthält eine Liste von Zeitpunkten analog der Elemente von feld intervals
.
Einzelne Bände 1.1970 und 3.1972; Band 7.1973 fehlt:
[ { "volume": "1", "year": 1970 },
{ "volume": "3", "year": 1972 },
{ "volume": "7", "year": 1973, "missing": true } ]
Mit dem Unterfeld embargo
kann eine "moving wall" angegeben werden. Das Feld hat immer drei Unterfelder:
period
mit einem Integer-Wert der nicht Null sein darfunit
mit einem der Werteday
,month
,year
,volume
, undissue
.
Ab vor zwei Jahren zugänglich:
{ "period": -2, "unit": "year" }
Bis auf das jeweils aktuelle Heft zugänglich:
{ "period": -1, "unit": "issue" }
Jeweils 1 Monat lang zugänglich:
{ "period": 1, "unit": "month" }
Band 1.1920 bis 19.1939, Band 21.1941, Band 36.1956 u.ff. außer Band 38.1958 und der jeweils aktuelle Jahrgang:
{
"intervals": [ { "volume": "1", "year": 1920 },
{ "volume": "19", "year": 1939 },
{ "volume": "36", "year": 1956 } ],
"points": [ { "volume": "21", "year": 1941 }
{ "volume": "38", "year": 1958, "missing": true } ],
"embargo": { "period": -1, "unit": "volume" }
]
Der Inhalt des Unterfeld chronology
ergibt sich aus den Katalogisierungsrichtlinien von GBV, BSZ und ZDB die wiederum im Wesentlichen auf RDA basieren:
- Pica3 7120 / PICA+ 231@ beim GBV
- Pica3 7120 / PICA+ 231@ beim BSZ
- Pica3 8032 bei ZDB (PDF), Pica3 8033 bei ZDB (PDF) und Pica3 8035 bei ZDB
Feld 7120 (=PICA+ 231@) enthält "bibliographische Bestandsangaben für fortlaufende Ressourcen in maschinell interpretierbarer Form." Die Struktur entspricht dem allgemeinen Bestandsverlauf der in Feld 4024 / 031N festgelegt ist:
In Feld 7120 stehen den GBV-Katalogisierungsrichtlinien entsprechend nur vollständige Jahrgänge bzw. Bände und Angabe von Heften. Heftlücken können zusätzlich im Freitextfeld 7121 erfasst werden:
Das Freitextfeld 7121 folgt einer eigenen Syntax, die sich parsen lässt um daraus Feld 7120 zu erzeugen. Im Katalogisierungsclient gibt es dazu das Skript "ZDB: Feld7120" (Feld7120.vbs
in WinIBW). Die Katalogisierungsrichtlinie empfiehlt jedoch das Ergebnis des Skript nachzuprüfen.
Außerdem wurde herangezogen:
- Entwurf der Enumeration and Chronology of Periodicals Ontology (ECPO) von Carsten Klee (ZDB)
- (ONIX for Serials)
Also was mir beim Überfliegen aufgefallen ist (nachträglich von @nichtich sortiert und kommentiert):
(2001:Jan.1-2006:June 30)=no.320-no.385
kommt dann plötzlich das DAIA-Feldnumber
(obwohl nicht oben definiert).about
wird mehrdeutig verwendet. Kommt da jetzt der Bestandsverlauf rein, oder auch eine Angabe zu Lücken?"about": "volumes v.4 and v.5 are missing",
Ist die Zahl der Zeiträume ungerade, handelt es sich um eine offene Zeitspanne.
. Aber das verstehe ich nicht. Ich kann doch ein (ungerade) Zeitraum haben, der abgeschlossen ist. Im Endeffekt müsste man doch dann den letzten Zeitraum prüfen, ob end*-Felder existieren. Vielleicht wäre ein DAIA-Feldrunning
sinnvoll, welches nicht zusammen mit end*-Feldern auftauchen darf.5/6.1999/2000 - 7/8.2001/2002
-->/v5/b1999/V8/E2002
wird. Also immer das erste Start-Statement und das letzte End-Statement. Von daher ist zu überlegen, wie in DAIA mit doppelten / mehrfachen Bänden, Jahren, Heften umgegangen werden soll und obyear2
wirklich notwendig ist.embargo
sehe ich eine Verbindung mit der MWO, die man vielleicht noch mal anpassen müsste. Für DAIA wäre hier mal ein Use-Case zu entwicklen, um zu schauen, ob die Daten für diesen Zweck gut genutzt werden könnten. Z.B. soll daraus nur ein Text geniert werden, der anzeigt, was man kriegen kann und was nicht oder kann damit eine API für eine (EZB-)Ampel angefragt werden.So etwas wie
{ "volume": "2 [i.e. 3]" }
wird es wohl auch nicht geben, wenn der Inhalt aus 7120 kommt. Jedenfalls ist das in der ZDB nicht erlaubt.Zum Beispiel
(2001:Jan.1-2006:June 30)=no.320-no.385
: In der ZDB würden die parallelen Nummern nicht nach 7120 wandern. Mal abgesehen davon, dass in 7120 in der ZDB keine Hefte vorkommen, würde unser Script Feld7120 die Nummern ignorieren. Für das Feld 4025 würden dafür die Monate/Tage genommen.Lücken werden in der ZDB im Feld 8035 verzeichnet. Ich denke aber, dass das nur in Ausnahme geschieht und die Lücken implizit aus 7210 abgeleitet werden müssten. Im GBV scheint es mir genau so zu laufen. Es werden nicht explizit Lücken in 7121 erfasst, sondern es gibt eine Syntax, wie im Bestandsverlauf Lücken gekennzeichnete werden. Von daher wird das DAIA-Feld
missing
wohl weniger gebraucht werden.Mir fällt bestimmt noch mehr ein. Aber so weit erst einmal mein Senf.