Til NorZIG-møtet 17. mars 1999

Kommentarer til utkastet til norsk Z39.50-profil

Her følger de kommentarene til den norske profilen som er mottatt så langt. Jeg håper det kan bli flere før møtet.

1999-03-11 Ole Husby

Fra NBO:

Mht. Z39.50-profilen ser jeg ingen problemer med den spesifikt norske delen, men jeg opplever litt ubehag ved noen punkter i CENL profilen:

5.1: Hva er origin - programvaren eller det sluttbrukeren ser? Vi var vel inne på tvetydigheten i forrige møte. Snakker vi om selve programvaren er kravet for svakt: det vil være rimelig å forlange at den skal kunne konfigureres til å sende en hvilken som helst bib-1 attributt-kombinasjon, iallefall for en frittstående klient. Snakker vi derimot om det brukeren ser er kravet for sterkt. En god klient kan konfigureres per database, og bør f.eks. ikke vise ISSN-felt hvis dette ikke er søkbart i den aktuelle basen.

5.2: Her står et forbehold for ISBN og ISSN som egentlig bør gjelde alle felt bortsett fra title word og any. I allefall må det tas forbehold for forfatter-feltene. Slike finnes ikke i periodika-basene. NOSP og SAMPER inneholder heller ikke emneord!

Det kan vel diskuteres om forbeholdene skal uttrykkes i selve profilen, eller i implementatorens forhold til den.

Torstein

Fra BIBLIOFIL:

1 Vi mener det er er veldig viktig å få med informasjon om tilgjengelighet i tillegg til den rene bestandsinformasjonen i forslaget.

Vi vil derfor foreslå at det legges på enda et delfelt i *850 som angir antall ledige eksemplarer. Helst hadde vi sett at vi i tillegg angir når et eksemplar forventes å være tilgjengelig. Det siste er imidlertid vanskelig siden *850 $e inneholder antall eksemplarer. Det beste hadde etter vår mening vært at antallet *850 tagger anga antall eksemplarer. Da kunne hver tag fortelle noe om hvert sitt eksemplar.

Vi foreslår at vi legger med f.eks. $h (ledig i NORMARC) og lar denne inneholde antall ledige eksemplarer.

Eks: 

*850  $a DEICHM $b hbba $e 2 $h 1
*850  $a DEICHM $b hvut $e 3 $h 2
Det kan evt. diskuteres om man alltid antar $e til å være 1 (evt. utelater den) og heller repeterer antallet *850 etter antallet eksemplarer. Da hadde det vært ønskelig å legge dato for forventet tilgjengelighet (normalt forfallsdato) i $h. En ugyldig dato (0/0/0000) kunne da bety at eksemplaret er tilgjengelig, evt. at manglende $h betyr at eksemplaret er tilgjengelig.

Eks: 

*850  $a DEICHM $b hbba $h 00000000
*850  $a DEICHM $b hbba $h 19990412
*850  $a DEICHM $b hvut $h 00000000
*850  $a DEICHM $b hvut $h 19990517
*850  $a DEICHM $b hvut $h 00000000
2 Et problem som ofte kommer opp er informasjon om hvor ferske de dataene som det søkes i er. Særlig ved innføring av bestandsinformasjon er dette viktig. Speiling av data ut til egne servere er i bruk i flere av biblioteksystemene.

Protokollen (v. 2) har støtte for slik informasjon gjennom Explain og databaseInfo; lastUpdate og updateInterval.

Er det hensiktsmessig å oppfordre til bruk av dette, eller finnes det andre måter å formidle slik informasjon på?

Tore Morkemo

Fra HiO:

1. CENL kap. 3: jeg er enig i at Local number skal inn, men baade her, i ONE-profilen og i CENL profilen savner jeg KORPORASJON. Jeg har iallefall ofte bruk for aa soeke paa korporasjonsnavn. kan vi ikke ta det med som obligatorisk? Er det noen av systemene i Norge som ikke dekker dette?

2. CENL kap. 4.4 Enig i at UNIMARC utelates som obligatorisk.

3. CENL kap.5.1.1: Igjen savner jeg korporasjon. Her er heller ikke Local number, bør ikke det være med her også?

4. CENL kap. 5.2: samme som over, korporasjon.

5. I arbeidet med ONE profilen maatte vi ta absolutt minste felles multiplum derfor ble SERIE utelatt. men boer det utelates? Vi kan jo formulere det som for ISBN og ISSN at det er obligatorisk hvis relevant?

Jeg er klar over at vi kan gi soeking paa serie via titler, men det er ikke helt pent. Saerlig ikke ord i tittel.

Mht. Holdings data: 1. det er et par "trykkfeil" i dokumentet (USRMARC ist.f. USMARC og 852 tag der det i eksempelet er brukt 850)

Mht. 850 $g saa er det et problem. Ikke at vi kan faa innfoert et nytt delfelt, men at $g ikke er strukturert. Det er et sporsmaal om vi skal vaere kompatible med resten av verden eller sende data som kan behandles maskinelt. Eller skal vi bruke Ole Brum-metoden?

Er det bedre aa bruke 866 enn 852 i USMARC? Jeg vet ikke. Fordelen med 852 er at den er beskrevet i det "vanlige" formatet, altsaa ikke i spesialformatet for holdings, men er det andre faktorer som spiller inn?

Skal profilen inneholde 856? Eller si noe om dette feltet?

Er det ikke litt dumt å fjerne seg fra CENL profilen mht. UNIMARC? Burde det ikke være slik at vi tar CENL-profilen som den er, og i TILLEGG legger vi f.eks. NORMARC, andre Use-versier etc.?

Liv