Referat fra møde i
danZIG 28. januar 2002 – 34. møde
Tid og
sted: Mandag 28. januar 2002 kl. 9.30 i Biblioteksstyrelsen
Deltagere:
Poul Henrik Jørgensen, Dansk BiblioteksCenter (formand)
Hans Erik Büscher, MikroMARC
Henrik Dahl, Dantek
Hans-Henrik Felby, ICL Invia
Per M. Hansen (isf.
Ole Hultén, DC Informatik
Niels Jensen, Københavns Kommunes Biblioteker
Flemming Pedersen, CSC Consulting Group
Samt:
Bodil Dalgaard-Møller, Dansk BiblioteksCenter
Afbud
fra:
Carsten H. Andersen, DBC Medier
Peder Lærke, Handelshøjskolens Bibliotek, København
Hans Meulengracht-Madsen, DTV
Heike Schmid, Dynix
FORSLAG
TIL DAGSORDEN:
1.
Godkendelse af
dagsorden
2.
Godkendelse af
referat fra 33. møde
# Referatet udsendt på listen 20. januar 2002.
3.
Meddelelser og
konferencerapporter m.v.
# Ny version af DEFkat gateway
(kort præsentation)
# Z39.50 Holdings Schema - Version 1.2, December 2001
4.
Opsamling på
emnerne på sidste møde
# Ikke dækket af denne dagsordens øvrige punkter:
# - ZIG-meeting og Bath-meeting
October 2001
# - LDAP projekt (DEF)
5.
Implementeringspørgsmål
6.
Version 2 af danZIG-profilen
# Bilag: Oplæg udsendes på listen 21. januar 2002
# danZIG Z39.50 Profile v2002, Afsnit om
Attribut-kombinationer
# (version 2 udkast) - Oplæg ved Leif
7.
Beholdning og
bestilling
# Status for bestillingsspecifikation og implementering
# Oplæg ved Poul Henrik om opdatering af
# Tilføjelse til danZIG-profilen: Beholdning og
bestilling,
# August 2000
8.
Mødeplan
# 35. møde: 4. marts 2002 kl. 9.30
# 36. møde: fastlægges
9.
Evt.
ad.
1. Godkendelse af dagsorden
Godkendt.
ad.
2. Godkendelse af referat fra 33. møde
Referatet
udsendt på listen 20. januar 2002 blev godkendt.
ad.
3. Meddelelser og konferencerapporter m.v.
Poul Henrik summerede hvordan Z39.50 Holdings Schema - Version 1.2 kom på plads december 2001. Forslaget
kom på plads som vi ønskede.
Poul
Henrik orienterede om etablering af en NISO-komite
med henblik på at lave en national US-profil, hvor vi
er blevet kontaktet om Holdings Schema. De troede at
det var vores Schema, men det stammer faktisk fra
deres side af Atlanten.
De
ønsker i schemaet at bruge XML-elementer
i stedet for XML-attributter. Vil forventelig lave
deres eget element set, hvor vil tage udgangspunkt i Copies
i stedet for Bibliografic Item, som vi har valgt i
danZIG.
Poul
Henrik orienterede om ELAG (http://www.ifnet.it/elag2002//). Af emnerne på
årets møde nævnte han RDF og RFID fra Singapore.
ZIG-møde
4+5. april 2002 i Dublin, Ohio. Det forventet indhold
er SRW og den opdaterede version af Z39.50 standarden. Efterfølgende Bath-profile møde sammesteds. Nærmere omtale af SRW, se: http://www.loc.gov/z3950/agency/zing/srw.html
Om ZIG-møde 4+5. april 2002, se: http://www.loc.gov/z3950/agency/zig/meetings/oclc2002/oclc2002.html
Om Bath-profil møde, se: http://www.nlc-bnc.ca/bath/bathag-apr02.htm
Leif
meddelte at en ny version af DEFkat gateway er på beddingen, men en præsentation af denne faldt
ud p.g.a. tidsnød.
ad.
4. Opsamling på emnerne på sidste møde
ZIG-meeting October 2001:
Med udgangspunkt i diskussionerne om ZNG mente Henrik at der ude i den store
verden var tegn på en udviklings baseret på SOAP.
Poul Henrik tror også at fremtidige udvikling kommer
til at være baseret på web-baserede services, men at man ikke kan basere
applikationsudvikling alene på forventninger om en kommende standard. Men det
er baggrunden for at udviklingen i danZIG-regi er så
vidt muligt baseret på XML og ikke BER. På denne måde har vi fremtidssikret
vores arbejde, idet dataformatet ikke skal ændres hvis transportprotokollen
måtte blive ændret.
Leif stillede forslag om et tema på et danZIG-møde
efter næste ZIG-møde. Niels mente at der var to
aktuelle temaer: SOAP og lånerautentificering - det sidste bliver mere og mere
relevant.
Konklusion på denne drøftelse: der laves et temamøde efter næste ZIG-møde om elementerne i ZING, se: http://www.loc.gov/z3950/agency/zing/
ad.
5. Implementeringspørgsmål
Hans Henrik rejste et spørgsmål i relation til
Praksisreglerne for søgeveje: Søgning på faust-nummer
ikke længere del af defaultsøgning i DanBib.
Niels kommenterede med at man i KKB følger praksisreglerne netop bortset fra
Faust-nummer, som man fortsat har som del i defaultsøgning.
Flemming kunne fortælle at DDE-libra i
standard-opsætningen følger praksisreglerne, men mange har justeret deres
anvendelse til at medtage BIB-12 i default-register.
Bodil nævnte af DBC Hotline har fået mange henvendelser om dette spørgsmål.
Leif lovede at Biblioteksstyrelsen ville overveje spørgsmålet nærmere.
Hans
Erik rejste spørgsmålet om blanktegn i faust-nummer i
DBC?s dataleverance (d.v.s. i BIB-12). Det er en
gammel synd at faust-nummer ligger nogle steder med
blanktegn som selve data - og ikke blot som
præsentationsform. Det indgår f.eks. i dataleverancer fra DBC. Spørgsmålet også
rejst m.h.t. ISBN hvad angår med og uden bindestreger.
Det blev aftalt at vi på næste møde diskuterer om det kan være muligt at fjerne
blanktegn.
ad.
6. Version 2 af danZIG-profilen
Som bilag var udsendt på listen 21. januar 2002: danZIG
Z39.50 Profile v2002, Afsnit om
Attribut-kombinationer (version 2 udkast).
Poul
Henrik introducerede Bodil Dalgaard-Møller, som arbejder på DBC med bl.a.
opsætning af Z39.50 server - og dermed med implementering i forhold til DanBib
af danZIG-profilen. Bodil var inviteret til at
deltage i drøftelsen af dette punkt.
Generel
model
Leif forelagde først modellen for opbygningen af tabellen. Der er valgt en
horisontal fremfor en vertikal opstilling. D.v.s. i
stedet for Bath-profilens skema for hver attribut et
samlet skema med de seks attribut-værdier vandret incl.
en note om relation til Bath-profilen.
Udkastet
blev gennemgået og der var en række spørgsmål og forslag til justeringer. Disse
fremgår af en gennemskrevet version (J.nr. 331-3), som er vedlagt referatet.
Den
eneste egentlig beslutning var en beslutning om at Bath 5.A.2.9 (søgning efter materiale publiceret mellem to
tidspunkter) ikke skal understøttes i danZIG. Der var ikke nogen forventning om
at denne kombinatoriske søgning i én ville blive understøttet i praksis i
større omfang. Gert havde på forhånd oplyst at SIRSIs
system Unicorn understøtter. Den kan endvidere
understøttes af kombineret brug af andre kombinationer med USE 31.
Et
forslag om at udvide DAN-1 med USE 27 for Tekniske oplysninger blev godkendt.
Dækker over søgekoderne ts og lts,
som peger på felt 300, delfelt e, som indeholder tekniske oplysninger til en
specifik materialebetegnelse. Det kan f.eks. være VHS.
Poul
Henrik omtalte en uformel henvendelse fra en SIRSI-medarbejder
til ham og Leif, som havde spurgt om vi danskere ikke kunne vælge at lægge
DAN-1 attributterne ind i BIB-1. Derfor foreslog Poul Henrik at vi tog en
principiel drøftelse af dette punkt. En runde mellem systemlevandører
viser følgende:
Hans
Henrik: Aleph500 vil kunne understøtte flere attributsæt
i en senere version (men gør det ikke i dag). Ville foretrække at flytte DAN-1
op i BIB-1, men det er ikke afgørende.
Flemming: DDELibra har haft problemer med kombination
af flere attributsæt, men de understøtter principielt
og finder det endvidere datalogisk mere logisk med flere attribut sæt.
Hans Erik: Mikromarc understøtter flere attribut sæt,
men er ligeglad.
Henrik: Dantek finder det datalogisk mere logisk med
flere attribut sæt.
Poul Henrik: DBC er af den opfattelse at vi i danZIG bør følge Z39.50 version 3
og dermed understøtte flere attribut sæt.
Niels
tilsluttede sig at der understøttes multiple attribut sæt.
Som repræsentant for Index Data, der bl.a. leverer toolkit tilsluttede
Der
var således konsensus om at der bør understøttes multiple attribut sæt. Ideen
om at lægge DAN-1 over i BIB-1 blev således afvist.
ad.
7. Beholdning og bestilling
Dagordenspunktet var tænkt som en diskussion om hvordan
indholdet i ?Tilføjelse til danZIG-profilen:
Beholdning og bestilling, August 2000? kunne integreres i den kommende version
af danZIG-profilen.
Poul
Henrik fremlagde en præsentation, som viste sig at gå videre end Beholdning og
bestilling og udover disse emner berøre en række andre forhold som er af
betydning for udformning af en ny version af danZIG-profilen.
ARBEJDSGANG:
* Init (Z39.50-1995 v3)
* Bibliografisk søgning (bib-1, dan-1)
* Bibliografisk present (MARC, SUTRS)
* Beholdnings present (Holdings XML B2, B3)
* Bestilling (ILL-Request / ILL-Answer)
* Bestillings-status ( ILL Status-Query
/ Status-Or-Error-Report)
Endvidere
nævnte Poul Henrik to andre transaktioner, som falder lidt udenfor, men som kan
forventes at få betydning i samspil mellem bibliotek.dk og lokalsystemer:
* Brugervalidering (NCIP AuthenticateUser)
* Bestillings-kvittering (NCIP ItemRequested)
INITIALISERING:
* Z39.50-1995v3
* http://lcweb.loc.gov/z3950/agency/document.html
* ID/authentication: UserId
& Password
* Character Set Negotiation
* ISO 8859-1:1988 Latin-1& ISO 10646 BMP (UTF-8,
UTF-16)
* Bib-1 Diagnostics
* http://lcweb.loc.gov/z3950/agency/defns/bib1diag.html
* ExplainLite
I version 1 af danZIG-profilen er peget på Explain. Spørgsmålet er om vi ikke skal satse på ExplainLite.
BIBLIOGRAFISK
SEARCH & PRESENT:
* Type-1 Query med bib-1 & dan-1 attributter
* http://lcweb.loc.gov/z3950/agency/defns/bib1.html
*
http://www.bs.dk/index.ihtml?side=http://www.bs.dk/vis_pub.ihtml?id=364__fil=http://www.bs.dk/danzig/dan-1.htm&pid=0
* Lokaliseringer søges med bib-1 attribute 1044 Possessing-Institution
* Present
* Record-syntax: danMARC2, SUTRS
* ESN: "F" (Full), "B" (Brief),
"R" (Reduced)
* http://lcweb.loc.gov/z3950/agency/defns/oids.html#5
Forslaget om at bruge Use 1044 til at søge i
lokaliseringer (i Danmark vil det være biblioteksnumre) var der positiv
stemning overfor. Der var ingen som aktuelt ønskede at vi skulle inddrage det særlige ?Holdings Attribute Set? i
danZIG-profilen.
Present af bibliografiske poster blev drøftet. Et problem er felter (såkaldte
bogstavfelter lokalt) udenfor danMARC2 formatet og dernæst hvordan at felt 096
bør udleveres fra DanBib. Emnet drøftes videre ved næste møde.
BEHOLDNINGS
PRESENT
* Gamle ONE-2 Holdings Present Request:
* Record-syntax: XML OID
* ESN: "B2" eller "B3"
* ZIG Ammendment Z39.50MA-AM0007
* Record-syntax: XML OID
* Schema: Holdings XML Schema
URI
* ESN: "B2" eller "B3"
* http://lcweb.loc.gov/z3950/agency/amend/am0007.html
* http://lcweb.loc.gov/z3950/agency/defns/holdings.html
Der var stemning for at bruge mulighederne i ZIG Ammendment
Z39.50MA-AM0007 og angive ønsket Schema som en URI.
Det blev aftalt at Poul Henrik anmoder Z39.50 Maintenance
Agency om optionbitten i AM0007 bliver specificeret
[Reaktion: se bilag efter referatet]. Spørgsmålet skal drøftes igen på næste
møde med henblik på endelig beslutning.
Hans Erik nævnte at når Mikromarc bruger MARC21, så
kan der vises beholding allerede nu og han foreslog
at det blev brugt som en midlertidig løsning. Forslaget blev noteret.
BESTILING:
* Z39.50/ILL Profile 1
* www.nlc-bnc.ca/iso/ill/document/standard/z-ill-1a.pdf
* ISO ILL-APDUs i ItemRequest
ES External Octet-Aligned
* Transfer-syntax: XML (1.2.840.10003.5.109.10)
* ILL-Request APDUs i OriginPartNotToKeep
* ILL-Answer APDUs i TargetPart
* XML Schema specificeres i selve XML dok.
* www.portia.dk/pubs/ill/schema/illv2/illv2.xml
Der var tilslutning til de beskrevne løsninger. Poul Henrik uddybede i den
forbindelse et par tekniske spørgsmål, som danZIG medlemmer bl.a. har rejst i
andre sammenhænge:
-
Identifikation af XML Skema for ILL APDUer
(transaktionsposter)
- Brug af Z39.50 ItemOrder Extended
Service som transportmekanisme for ILL APDUer
OM:
Identifikation af XML Skema for ILL APDUer:
Når vi anvender Z39.50 ItemOrder Extended
Service som transportmekanisme for XML-formaterede
ILL transaktioner, er det nødvendigt at identificere det anvendte XML skema i
selve ILL/XML dokumentet. Dette er normal praksis i XML Verdenen, hvor et XML
Dokument kan indeholde en reference til sit XML Skema.
I øvrigt indeholder selve de oprindelige ISO ILL APDUer
ikke nogle felter, hvor man evt. kunne anbringe en reference til XML Skemaet.
Ved præsentation af Holdnings informationer som XML-formaterede
dokumenter sender man først et Present Request, der
bl.a. kan indeholder en angivelse af det XML Skema, som svaret skal anvende.
Men udveksling af ILL-transaktioner indebærer ikke
nogen tilsvarende Present Requests.
Man kan derfor ikke på forhånd angive det ønskede XML-skema
for ILL transaktioner. Hverken i et Present Request
eller i en foregående ILL-Request APDU.
OM:
Z39.50 ItemOrder Extended
Service som transportmekanisme for ILL APDUer:
ISO ILL protokollen er generelt defineret som en såkaldt "Symmetrisk Message-Passing" protokol. Dvs. at begge parter
spontant kan sende en ILL transaktion til modparten. Begge parter skal således
være forberedt på at modtage en ILL transaktion uden forudgående advarsel.
Dette ses i modsætning til Z39.50, som primært er defineret som en såkaldt
asymmetrisk Request-Response protokol. Dvs. at den
ene part (Klienten) sender en forespørgsel til modparten (Serveren) - og
afventer evt. fra Serveren.
En Z39.50 Client kan således normalt ikke spontant
modtage en uventet meddelelse fra en Z39.50 Server.
Derfor kan man ikke umiddelbart anvende Z39.50 til at håndtere vilkårlige typer
af ILL transaktioner, som jo netop kan optræde spontant fra begge parter.
Imidlertid begrænser danZIG sig til at anvende nogle få ILL transaktioner, som
netop afspejler en Request-Response protokol.
Eksempelvis sender en Z39.50 Client en ILL-Request APDU til Serveren, hvorefter Serveren svarer
med en tilsvarende ILL-Answer APDU.
Det er derfor både muligt og hensigtsmæssigt at anvende Z39.50 til udveksling
af de ILL Transaktioner, som er relevante for danZIG.
BESTILINGSSTATUS
* Z30.50/ILL Profile 1
* ILL Status-Query fra ILL Requester
(Z-Origin Request)
* ILL Status-Or-Error-Report fra ILL Responder (Z-Target Response)
Ingen yderligere bemærkninger.
BRUGERVALIDERING
* Baseres på ANSI/NISO Z39.83-200x NCIP
* www.niso.org/committees/at/ProtocolDraft-14.doc
* AuthenticateUser Service
* AuthenticationInput indhold skal aftales
* Request/Response udveksles som Z39.50/ILL Profile 1
Fra DBC?s blev peget på NCIP UserValidation
fremfor NCIP LookupUser,
som blev drøftet på det 31. danZIG-møde. Faciliteten
er primært tænkt ved opslag fra bibliotek.dk til lokale bibliotekssystemer.
BESTILINGSKVITTERING
* Baseres på NCIP ItemRequested Service
* Request transaktion skal aftales
Her er tale om en mulig standardbaseret afløsning for den nuværende DanBib-postkassekvittering, der som bekendt er et ?hjemmelavet? format omend byggende på ISO 8459-1.
Der
var enighed om at dette oplæg skal bruges som grundlag for
nyskrivning af danZIG-profilen. Der var endvidere
enighed om at
spørgsmål, som der har været diskussion om, skal markeres i det næste oplæg.
ad.
8. Mødeplan
35. møde: 4. marts 2002 kl. 9.30 [siden ændret til 11.
marts 2002]
36. møde: 13. maj 2002 kl. 9.30
ad.
9. Evt.
Leif svarede at bibliotek.dk er et slutbrugerprodukt - DanBib er det
professionelle værktøj.
Bodil
supplerede med at bibliotek.dk er skræddersyet som target
til klient-funktion i bibliotek.dk.
Referat:
BILAG
1
***************
Gennemskrevet version, jf. - pkt. 6. Version 2 af danZIG-profilen danZIG Z39.50 Profile v2002
Afsnit om Attribut-kombinationer
(version 2 udkast) J.nr. 331-3
BILAG
2
***************
Optionbitten i AM0007 - opfølgning pkt. 7 (under
BEHOLDNINGS PRESENT)
Poul
Henrik har som aftalt har spurgt
In the Z39.50-2001 revision:
3.2.1.1.3 Options
in the table,
Option bit 21: Use of string values for schema in compSpec
"See Note 12"
Note 12 says:
"If this option is negotiated, then Schema within Specification (in the
ASN.1 APDU definitions) is defined as in this version of the standard, that is
it may take on the additional choice of a string. Otherwise
it must be an object identifier."