Inhoud
Sleutelwaarden in Primo VE
Sleutelwaarden in bibliografische records zijn
belangrijk: ze zijn bepalend voor de opdeling
van de records in facets, de sortering van
records, de thumbnails of icoontjes die voor
zoekresultaten worden weergegeven en dit
zowel in Alma als in Limo. Ook op
dit vlak zorgt de overstap naar Primo VE voor
een grote verandering.
In Primo zijn (binnenkort: waren) er
uitgebreide normalisatiemogelijkheden die ons
toelieten om te bepalen hoe de sleutelwaarden
in Alma-records gebruikt werden om voor het
Primo-record het resource type te bepalen. Dat liet toe om ook
op dit vlak lokale afwijkingen van de
standaarden te 'normaliseren'.
In Primo VE lukt dit niet meer: er zijn vaste
criteria bepaald waaraan een Alma-record
moet
voldoen om in een bepaald Primo
VE-resource type te
worden ingedeeld. Deze criteria zijn
afgestemd
op de internationale standaarden en meer
bepaald op MARC21. Je kan een tabel waarin de
Primo VE-resource types met bijhorende
criteria worden opgelijst raadplegen via
volgende link: Mapping to the Display,
Facets, and Search Sections in the Primo
VE Record
Die tabel maakt duidelijk dat voor een aantal
documenttypes de criteria vrij complex zijn.
Het gaat vaak om kleine verschillen, soms diep
verscholen in de tag 008.
Naast deze standaard- of out-of-the-box
(OTB) documenttypes kunnen ook nog een
beperkt aantal lokale Primo
VE-resource types geconfigureerd
worden. Voorlopig worden
dit: Rare books (voor oude drukken), Games, Schoolbooks/Didactic
material en Standards &
Norms.
Alles bij elkaar maakt dit de opdracht voor
catalografen steeds moeilijker: steeds
meer
sleutelwaarden moeten ofwel via templates,
ofwel in het record zelf in de gaten worden
gehouden en waar nodig ingevoerd of aangepast
worden. Daarom werd gezocht naar een oplossing
die deze opdracht kan vereenvoudigen.
De catalograaf bepaalt 2
hoofdsleutels, Alma doet de rest
Die eenvoudigere oplossing bestaat uit een
workflow waarbij de catalograaf bij de
redactie van een bibliografisch record 2
hoofdsleutels invoert in de specifiek
daarvoor bestemde tag 902:
- 902 $$r = documenttype : een term die het soort document weergeeft dat beschreven wordt. Voorbeelden: BOOK, ARTICLE, JOURNAL, MUSIC SCORE, OBJECT, ...
- 902 $$m = materiaaltype : een term die de materiële vorm van het document aanduidt. Voorbeelden: PHYSICAL, ELECTRONIC_DIGITAL, DISC, ...
Wanneer de catalograaf beslist om
het record op te slaan, start automatisch
een
proces dat op basis van de ingevoerde
hoofdsleutels, de sleutelwaarden in het
record
(in LDR, 008, 336-338, 340 en 655) gaat
nakijken en
invoeren/aanpassen. Op die manier
houdt de catalograaf de beslissing in handen
maar wordt de uitvoering overgelaten aan het
bibliotheeksysteem.
Een voorbeeld: een catalograaf beschrijft een
elektronische
versie van een thesis en kiest voor 902 $$r
THESIS $$m ELECTRONIC_DIGITAL. Bij het opslaan
zorgt het automatische proces waar nodig voor
volgende
controles en aanpassingen.
- LDR pos. 6 = a [voor language
material]
- LDR pos. 7 = m [voor monograph]
- 008 pos. 23 = o [voor online]
- 008 pos. 24 = m [voor thesis]
- 336 $$a text $$2 rdacontent
- 337 $$a computer $$2 rdamedia
- 338 $$a online resource $$2
rdacarrier
- 340 $$a Online
- Een genre Thesis is niet meer
nodig.
Lees daar meer over op volgende pagina: Geen
genres meer i.f.v. resource
types.
Door die tag 902 in zijn geheel maar ook de
twee subvelden verplicht te maken en
bovendien voor beide subvelden een gesloten
keuzelijst vast te leggen, wordt de
kans op fouten aanzienlijk verkleind: als de
catalograaf het veld of één van de subvelden
vergeet in te vullen of een waarde invult die
niet op de lijst voorkomt (en er dus zou voor
zorgen dat de automatische uitvoering zou
mislukken), meldt Alma een blokkerende (rode)
fout. Pas na verbetering of aanvulling van de
hoofdsleutels zal Alma het record opslaan en
de vele sleutelwaarden in het record
automatisch correct instellen.
Op afzonderlijke webpagina's is een
volledig overzicht van de beschikbare
hoofdsleutels voor documenttypes en
materiaaltypes opgemaakt, met de
nodige
duiding over het gebruik van elk van die
sleutels. Bekijk de lijsten via volgende
links:
Meer duidelijkheid over gebruik van
bestaande records binnen het netwerk
Deze nieuwe methode zorgt er niet alleen voor
dat Alma-records correct worden ingevoerd en
weergegeven in Limo. Ook in Alma zullen
sleutelwaarden correcter dan nu getoond
worden en is het voor catalografen duidelijker
of ze bepaalde records al dan niet kunnen
gebruiken.
Dat is in het bijzonder het geval voor de
scheiding tussen Alma-P (de fysieke
collecties) enerzijds en Alma-D/E (de digitale
en elektronische collecties) anderzijds.
Uitgebreide informatie vind je op: P-inventory scheiden van
D/E-inventory Aan een record
dat gemaakt is om de fysieke
versie van een document te beschrijven mogen
in het hele netwerk enkel holdings worden
gekoppeld. Aan records die een digitale of
elektronische versie beschrijven mogen enkel
representations en/of portfolios worden
gekoppeld.
Door de complexiteit werden de laatste jaren
heel wat records gecreëerd met verkeerde
sleutelwaarden: meestal gaat het om records
met elektronische inventory (portfolios) die toch de sleutelwaarden van
een
fysiek record hebben. Het screenshot hieronder
toont een voorbeeld:
- de catalograaf die een nieuw record maakt,
alle sleutelwaarden juist invoeren door in
902 $$m de hoofdsleutel te kiezen die
hij/zij nodig heeft.
- alle collega's die later het record willen
gebruiken zowel in de zoekresultaten als
in het record zelf een correcte aanduiding
krijgen van het type record: fysiek of
elektronisch.
De nieuwe methode toegepast in de
workflows
Meer uitgebreide informatie vind je op volgende
pagina's:
- Hoofdsleutels en
templates
- Hoofdsleutels en
nieuwe records creëren
- Hoofdsleutels en
bestaande records gebruiken
Colofon
Laatst gewijzigd op 9.02.2022