Koha podaci o primjercima: Revision 1 / Wiki Knjižnice Filozofskog Fakulteta u Zagrebu

Wiki Knjižnice Filozofskog Fakulteta u Zagrebu

Koha podaci o primjercima: Revision 1

{toc: }

^^ Tablica s podacima o primjecima

Podaci o primjercima u Kohi zapisani su u tablici `items`.

.pre
mysql> describe items ;
+----------------------+--------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------+--------------+------+-----+-------------------+----------------+
| itemnumber | int(11) | NO | PRI | NULL | auto_increment |
| biblionumber | int(11) | NO | MUL | 0 | |
| biblioitemnumber | int(11) | NO | MUL | 0 | |
| barcode | varchar(20) | YES | UNI | NULL | |
| dateaccessioned | date | YES | | NULL | |
| booksellerid | mediumtext | YES | | NULL | |
| homebranch | varchar(10) | YES | MUL | NULL | |
| price | decimal(8,2) | YES | | NULL | |
| replacementprice | decimal(8,2) | YES | | NULL | |
| replacementpricedate | date | YES | | NULL | |
| datelastborrowed | date | YES | | NULL | |
| datelastseen | date | YES | | NULL | |
| stack | tinyint(1) | YES | | NULL | |
| notforloan | tinyint(1) | NO | | 0 | |
| damaged | tinyint(1) | NO | | 0 | |
| itemlost | tinyint(1) | NO | | 0 | |
| wthdrawn | tinyint(1) | NO | | 0 | |
| itemcallnumber | varchar(30) | YES | | NULL | |
| issues | smallint(6) | YES | | NULL | |
| renewals | smallint(6) | YES | | NULL | |
| reserves | smallint(6) | YES | | NULL | |
| restricted | tinyint(1) | YES | | NULL | |
| itemnotes | mediumtext | YES | | NULL | |
| holdingbranch | varchar(10) | YES | MUL | NULL | |
| paidfor | mediumtext | YES | | NULL | |
| timestamp | timestamp | NO | | CURRENT_TIMESTAMP | |
| location | varchar(80) | YES | | NULL | |
| onloan | date | YES | | NULL | |
| cn_source | varchar(10) | YES | | NULL | |
| cn_sort | varchar(30) | YES | | NULL | |
| ccode | varchar(10) | YES | | NULL | |
| materials | varchar(10) | YES | | NULL | |
| uri | varchar(255) | YES | | NULL | |
| itype | varchar(10) | YES | | NULL | |
| more_subfields_xml | longtext | YES | | NULL | |
| enumchron | varchar(80) | YES | | NULL | |
| copynumber | varchar(32) | YES | | NULL | |
+----------------------+--------------+------+-----+-------------------+----------------+
.pre

_napomena_:

* dužina polja `itemcallnumber` ne odgovara potrebama, potrebno je proširiti polje u bazi -> "Promjene u Koha bazi"{link: [Prilagodba Koha softvera] promjena u koha bazi}

^^ Import konvertiranih podataka

*scenarij 1:*
Koha prilikom importa (`bulmarcimport.pl`) čita podatke o primjercima iz polja *952* u MARC zapisu. Polje 952 dobiva se u konverziji, na temelju inventarnog broja zapisanog u ponovljivom polju. Inventarnom broju dodaje se prefix - kratica knjižnice, kako bi bio jedinstven za cijeli FF.

U sljedećoj tablici navedena su MARC polja koja postoje u konvertiranim zapisima. Navedeno je i polje u Koha bazi u koje se zapisuje pojedini podatak.

| *MARC code* | *naziv polja* | *authorized value* | *ime polja u Koha bazi* | *napomena* |
| 952$8 | Koha Collection Code | CCODE | items.ccode | oznaka knjižnice iz koje potiče primjerak |
| 952$a | Location (home branch) | branches | items.homebranch | svi dobivaju vrijednost FFZG |
| 952$b | Sublocation or collection (holding branch) | branches | items.holdingbranch | svi dobivaju vrijednost FFZG |
| 952$c | Shelving location | LOC | items.location | podatak za prikaz i OPACU. ova informacija je za knjige u OP kodirana u signaturi. primjer: 1. kat, psihologija, to je u signaturi prefix BC |
| 952$i | Inventarni broj | | items.itemnotes | inventarni broj. to je broj iz papirnate inventarne knjige. uz njega se veže stara posudba. dodaje mu se prefix s oznakom knjižnice
ovo nije najbolji odabir polja u koje se zapsuje inventarni broj, no trenutno je najjednostavnije zato što se polje automatski prikazuje tamo gdje je poželjno |

Osim ovih podataka Koha će prilikom importa popuniti i ova polja u `items` tablici:

| itemnumber | jedinstveni broj za primjerak |
| biblionumber | broj bibliografskog zapisa (tablica biblio) |
| biblioitemnumber | broj bibliografskog zapisa (tablica biblioitems) |
| dateaccessioned | trenutno vrijeme |
| replacementpricedate | trenutno vrijeme |
| datelastseen | trenutno vrijeme |

a ostalim poljima pridijelit će default vrijednosti.

*scenarij 2:*
Importaju se samo bibliografski podaci, a podaci o primjecima se stvaraju "na licu mjesta".
(prijedlog Viva-info, raspraviti i razmotriti)

^^^ U prilog scenariju 1

Želimo da se mogu rezervirati knjige iz zatvorenog spremišta, a ako nema podatka o primjerku, knjiga se ne može rezervirati. Isti je slučaj za knjige koje su trenutno posuđene.
Sve knjige koje idu u zatvoreno spremište još dugo vremena neće dobiti ćip, tj. dobit će ga u trenutku kad ih netko zatraži iz zatvorenog spremišta (tako da rezervira tu knjigu?)
Manje je zlo imati višak primjeraka u bazi, nego manjak.
Podatak o inventarnom broju treba sačuvati. Sada je u nekim knjižnicama važan za posudbu,

Potpolje 952i je dodano u Koha _MARC famework_ (to je definicija MARC zapisa u Koha bazi) i služi za zapisati taj inv. broj. Mapirano je u Koha bazu u items.itemnotes.

Inventarni broj prestaje se upotrebljavati kad se knjižnica preseli - to tek treba dogovoriti.

Svi zapisi nastali su u posljednjih 5 godina, što zanči da broj izgubljenih primjeraka ne bi smio biti jako velik.

Planirano je da se nakon migracije knjižnicarima ispinataju popisi knjiga (zapravo inventarne knjige) soritrani po staroj signaturi. Na tom isprintu knjižničari će moći zabilježiti potreban podatak (da li knjiga ide u OP? da li joj je pridjeljena ispravna signatura). Nakon toga, podatak s papira prepisao bi se u bazu. Zbog prirode posla, papirnati medij je puno prikladniji jer predstavlja puno bolju reprezentaciju fizičkog smještaja knjiga na polici, nego što se to može prikazati na sučelju elekroničkoh kataloga.

^^ Signature i čipovi

Nakon importa, u bazu je potrebno nadopisati:

| items.itemcallnumber | podatak o novoj signaturi |
| items.barcode | podatak s chipa |

te podatke potrebno je sinhronizirati s MARC zapisom.

^^^ Stara signatura i predložena nova signatura

U konvertiranim podacima signature (stara i predložena nova) su zapisane u ovim poljima:

| 942$d | stara signatura |
| 942$h | predloženi 1. element signature |
| 942$i | predloženi 2. element signature |

1. element: oznaka stručne skupine - dva slova za zbirku, dva broja za područje unutar zbirke - pr. BG10
2. element: služi za redanje unutar skupine

Prilikom importa, ti podaci ostaju na razini bibliografskog zapisa.

Na razini primjerka, podatak nije zapisan u bazu, sve dok knjižničar to ne potvrdi.
U editoru se za odgovarajući primjerak ispisuje predložena signatura (iz polja 942hi), a knjižničar ju može po potrebi ispraviti i tek onda zapisati u bazu.
U polje signature na razini primjerka (`items.imtemcallnumber` - 952$o) upisuje se cijela signatura.

Knjigama koje idu u zatvoreno spremište ne bilježi se nova signatura. One su složene po staroj signaturi.

^^^ RFID i barcode

^^^^ Programiranje čipova

opcija 1:
čipovi su predprogramirani
na naljepnici mora biti isprintano: Filozofski fakultet u Zagrebu i barkod

opcija 2:
čip se ne predprogramira nego se programira na licu mjesta prema podacima iz Koha baze.

Zaobilaženje postupka predprogramiranja bi značajno ubrzalo početak inventarizacije.
da li to znacajno produzuje vrijeme potrebno za evidentiranje svakog primjerka?

zelimo da na naljepnici nesto i pise otisnuto - programiranje se moze obaviti i 'kroz knjigu', bez potrebe da se knjiga otvara itd., ali printanje na rfid naljepnicu se ne moze obaviti nego tako da se naljepnica provuce kroz printer

naljepnice MORAJU biti predprintane nekim grafickim rjesenjem (rekli smo da bi se to svelo na SVEUCILISTE U ZAGREBU, FILOZOFSKI FAKULTET, KNJIZNICA ili tako nesto) - to se moze dobiti i od firme koja proizvodi naljepnice, no barkod koji smo zeljeli imati isprintan na naljepnicama nece ici tako, osim ako ne dostavimo popis vrijednosti (barkodova) koje zelimo isprintane na naljepnicama

zasto bismo unaprijed morali imati popis vrijednosti za ispis barkodova na naljepnice a ne imati te iste vrijednosti za ispis u cipove (odnosno, zasto bismo te iste vrijednosti ispisivali naknado u cipove, ili neke druge vrijednosti u cipove - to je pitanje na koje treba odgovoriti na sastanku

^^^^ Što sadrži oznaka?

ćip moramo moći lako zamijeniti, ako se izgubi ili ošteti - na knjigu se stavlja druga naljepnica s drugim brojem.

varijanta 1:
siglu knjiznice (KFFZG) ?? i broj od 1 do 10.000.000
Broji se od milijun do 9999999, tako da nema brojeva s nulama, odnosno da su svi brojevi iste duzine

varijanta 2:
samo serijski broj koji je istovjetan barkodu

varijanta 2 se čini razumnija jer:
(obrazložiti)

^^ Generiranje barkoda

Možemo li barkode izgenerirati nekoj posebnoj tablici? tako bismo osigurali da dobivamo jedinstvene barkode.
Znači:
1. softver za pad pročita barkod iz te tablice (možda da si povuče neki raspon, koliko knjižničar odredi, da ne napada svaki čas bazu)
2. podatak se kodira na čip
3. podatak s čipa upisuje se Kohu
4. zapisuje se datum kad se to obavilo

Na čip treba biti zapisan samo serijski broj.

Savjet u vezi generiranja barkoda - razmotriti!
http://www.nabble.com/forum/ViewPost.jtp?post=19272468&framed=y

^^ Funkcionalnost Koha modula za obradu primjeraka

U "Koha date last seen" polje upisuje se datum kad je knjiga:

* zadužena
* razdužena
* inventarizirana (Inventory/stocktaking tool)

Potrebno je negdje zapisati i datum kad je na knjigu naljepljena RFID oznaka. Da li upisivati direktno u polje `last seen` ili u drugu tablicu? (ako imamo posebnu tablicu u kojoj se generiraju barkodi, onda se datum može pisati tamo?)

"Last seen" datum se, logično, neće upisati svaki put kad kliknemo `Save` u formi za uređivanje primjeraka, jer te gumbe možemo kliknuti i bez da nam je primjerak u ruci.
Datum se automatski upisuje kod migracije (`bulkmarcimport.pl`) i pri dodavanju novog item (Add Item).

`bulkmarcimport.pl` za naše potrebe ne bi trebao zapisivati taj datum.

^^ Seljenje podataka iz 952 u 949

Polje 952 za primjerke se u Kohi koristi iz povijesnih razloga. Razmatra se prelazak na 'de facto' standard za podatke o primjercima - 949. Polje 952 koristi OCLC za interne kodove.
Konverzacija na tu temu:
http://lists.katipo.co.nz/pipermail/koha/2008-June/014340.html