Dotaz #427
| Stav řešení | Schváleno |
|---|---|
| Typ dotazu | všeobecný popis (XXX) |
| Odesláno | 12. 03. 2009 |
| MARC 21 | 856, 956 |
| Citační číslo RDA | |
| Klíčová slova | obálky knih |
| Komentáře šlo přidávat do | 30. března 2009 |
Charakteristika problému
Jak máme postupovat při zápisu adresy elektronické podoby obsahu katalogizované publikace? Dotaz č.358 vyřešil tuto otázku zápisem do pole 856. V poslední době se objevují záznamy, v nichž je adresa zapsána do pole 956. Jaký je rozdíl v použití těchto dvou polí?
Rozhodnutí o řešení
Revize 29.1.2024. Platné i pro pravidla RDA.
Pro propojení na elektronické verze dokumentů nebo jejich části se použije pole 856 (platí shodně pro MARC 21 i UNIMARC). Pole 956 používá SK ČR pro ukládání odkazů na naskenované obsahy a případně i obálky vzniklé v projektu TOC.
Pokud knihovna chce přebírat ze SK záznam i s polem 956, musí mít toto pole přidané do definičních tabulek nebo jeho obsah převádět do pole 856.
Bližší informace k projektu TOC:
http://obalkyknih.cz
Podrobnější vysvětlení k technické stránce problému:
V rámci projektu TOC (=Table of Contents) probíhá v NK ČR a knihovnách přidružených v kooperativní katalogizaci (MZK a VKOL) skenování obsahů zpracovávaných knih. Výsledkem jsou jednak „obrázky“ oskenovaných obsahů (pdf) přístupné z webu přes URL, jednak zpracované OCR výstupy (ty jsou indexované pouze pro zvláštní přístupový soubor v bázi NKC). Nástrojem pro uložení a zpřístupnění výstupů je zvláštní přídavný modul systému Aleph zvaný ADAM. Linky na „objekty“ v bázi, kde proces probíhá (NKC), nejsou uloženy v záznamu, ale ve zvláštních systémových tabulkách a zobrazení se tvoří virtuálně.
Aby se linky na obsahy zpřístupnily také v souborném katalogu, spouští se periodicky program, který příslušné URL pro nově zpracované obsahy importuje do báze SKC. Protože je žádoucí zachovat možnost obdobného formátování zobrazení linků na obsahy v obou bázích (tj. trochu jinak a na jiném místě, než se formátuje standardní pole 856), zvolili jsme pro tento účel speciální pole 956. Jeho struktura je shodná s polem 856. Toto pole zůstává v záznamech báze SKC zachováno, i když je původní záznam přepsán kvalitnějším záznamem s vyšší váhou. Pole 956 mohou knihovny ze záznamů v SKC stahovat a rozhodnout se, zda tyto údaje zachovají v lokální bázi v tomto poli, nebo zda je „přemístí“ do standardního pole 856 – podle svých potřeb (kde nečiní problémy přidat pole 956 do definičních tabulek, je vhodnějším řešením pole ponechat, jak je). Pokud záznam se staženým polem 956 pošle knihovna do souborného katalogu, nebude odmítnut, ale pole záměrně nebude přijato, protože se do záznamu dostává jinou cestou.
Aby knihovny mohly stahovat link na obsahy i z katalogu NK, kde se v záznamu fyzicky nenachází, generujeme pole 956 v bázi NKC pro Z39.50 přístup jako virtuální pole.
Návrh řešení
Pro propojení na elektronické verze dokumentů nebo jejich části se použije pole 856 (platí shodně pro MARC 21 i UNIMARC).
Pole 956 používá SK ČR pro ukládání odkazů na naskenované obsahy a případně i obálky vzniklé v projektu TOC (Obohacování bibliografických záznamů o obsahy a obálky dokumentů) a generované do SK ČR z modulu Aleph Adam.
Komentáře
Jinými slovy: všichni používejte pole 856, ale SK ČR používá (a bude používat?) pole 956? Tzn. přebereme-li záznam ze SK ČR, měl by náš katalogizátor přepsat obsah 956 do 856? Rozumím tomu dobře? Pokud ano, smysl mi trochu uniká...
Není to tak, každé pole slouží k jinému účelu. Konkrétní příklad viz SK ČR, záznam č. 3649926 (ISBN 978-80-87108-07-9).
Chceme se vyhnout případným problémům s přebíranými záznamy do budoucna, proto se snažíme ujasnit si to. Chápu to tedy dobře takto?: Pole 856 slouží k zápisu zdroje nebo jeho prvků v elektronické podobě KROMĚ odkazů na naskenované obsahy a obálky vzniklé v projektu TOC - pro ty slouží pole 956. (Pozn.: záznam stejného dokumentu v aleph.vkol.cz - sysno 000880019 - obsahuje všechny odkazy v 856. Je to nesprávně?)
Rovněž si myslím, že pro odkazy na naskenované obsahy a obálky vzniklé v projektu TOC by bylo vhodné používat pole 856. A nemohlo by toto pole být i v záznamu NKP?
Když stáhnu záznam přes Z39.50 z NKP a zašlu jej s naším polem 910 do SK, vrátí se mi s poznámkou, že pole 956 není deklarováno v kontrolním souboru. Z SK stáhnu záznam bez obsahů, což neodpovídá odpovědi ve stanovisku odpovědného pracovníka. Když pole 956 smažu připravím naše čtenáře o obsahy. Řešení s ručním přesunováním z pole 956 do pole 856 mi připadá kostrbaté, řešení se smazáním pole 956 a po odeslání záznamu do SK jejich znovu přetažení je nesmyslné. Národní knihovna má jistě dobré důvody proč to řeší tímto způsobem, ale uvědomuje si problémy, které tím vznikají jiným knihovnám?
Schválený dotaz, diskuse je uzavřena