Pdf datoteka - Narodna in univerzitetna knjižnica

1
11-JN-6-29/02-BA-as
11.3.2002
Naročnik: NARODNA IN UNIVERZITETNA KNJIŽNICA
POVABILO K ODDAJI PONUDBE
Predmet javnega naročila: Izdelava računalniške programske opreme za poizvedovanje po
Slovenski bibliografiji (CD-ROM in Internet)
* * *
Vabimo vas, da nam podate svojo ponudbo za navedeni predmet javnega naročila v skladu s
pogoji, navedenimi v dokumentaciji javnega naročila.
Hvala za sodelovanje in lepo pozdravljeni!.
Narodna in univerzitetna knjižnica
Priloga. dokumentacija javnega naročila
mag. Lenart Šetinc
ravnatelj

2
NARODNA IN UNIVERZITETNA KNJIŽNICA,
Ljubljana, Turjaška 1
J A V N O N A R O Č I L O M A L E V R E D N O S T I
DOKUMENTACIJA JAVNEGA NAROČILA
za izbiro izvajalca za izdelavo računalniške programske opreme
za poizvedovanje po Slovenski bibliografiji (CD-ROM in Internet)
VSEBINA:
1. NAVODILO PONUDNIKOM ZA IZDELAVO PONUDBE
2. PONUDBA (obr. JN-5)
3. IZJAVA O SPREJEMANJU IN IZPOLNJEVANJU POGOJEV JAVNEGA NAROČILA
(obr. JN-7)
4. REFERENCE (obr. JN-8)
5. PROGRAM DEL - METODOLOŠKI PRISTOP (obr. JN-9)
6. VZOREC POGODBE (obr. JN-10)
7. PRILOGA A (opis programa)

3
NAVODILO PONUDNIKOM ZA
IZDELAVO PONUDBE
I.
Predmet tega javnega naročila je izdelava računalniške programske opreme za poizvedovanje
po Slovenski bibliografiji (CD-ROM in Internet).
Struktura, specifikacije, opisi in druge zahteve naročnika v zvezi s programsko opremo so
navedeni v prilogi A.
Priročniki standardov (UNIMARC, Slovenska bibliografija na CD-ROMu s priročnikom itd.)
so ponudnikom na voljo v Informacijskem centru za bibliotekarstvo (INDOK) naročnika vsak
delavnik od 9. - 13. ure.
II.
Predmet javnega naročila ni razdeljen na samostojne sklope in zato ponudniki lahko oddajo
veljavno ponudbo le za izdelavo celotne programske opreme (POGOJ).
III.
Programska oprema mora upoštevati uveljavljene standardne rešitve in izpolnjevati naslednje
pogoje:
• okolje Windows 2000
• Microsoft SQL
• podpora standarda UNIMARC
• podpora standarda XML
• možnost dograjevanja, spreminjanja in dodatnega razvoja
• izvorna koda in dokumentacija morata biti pripravljeni na način, ki bo omogočal
nadgradnjo in vzdrževanje programske opreme tudi tretjim osebam, čeprav bo pod
enakimi pogoji pri tem imel prednost izbrani ponudnik.

4
IV.
Ponudnik lahko dobi vse informacije v zvezi s predmetom javnega naročila na podlagi
pisnega zaprosila do izteka roka za oddajo ponudbe.
Odgovore na vprašanja in pojasnila bo naročnik posredoval tudi vsem drugim ponudnikom
brez navedbe ponudnika, ki je zaprosil za pojasnilo.
Kontaktna oseba naročnika je dr. Maja Žumer (e-pošta maja.zumer@nuk.uni-lj.si), (telefon
2001-161).
V.
Ponudba mora biti izdelana v slovenskem jeziku, vsi obrazci morajo biti popolno in pravilno
izpolnjeni, žigosani in podpisani s strani pooblaščene osebe ponudnika (POGOJ).
VI.
Vsak ponudnik lahko predloži samo eno ponudbo (POGOJ), lahko pa v ponudbi nakaže več
rešitev.
Ponudnik ne more sodelovati pri izvedbi tega javnega naročila s podizvajalci (POGOJ).
Rok za predložitev ponudb je 2. april 2002.
VII.
VIII.
Ponudnik lahko ponudbo pošlje po pošti na naslov naročnika ali jo odda neposredno
naročniku na Turjaško 1 v Ljubljani.
Ponudba je pravočasna, če jo naročnik prejme do izteka roka za predložitev ponudb.
Prepoznih ponudb naročnik ne bo obravnaval in jih bo neodprte vrnil pošiljatelju.
Odpiranje ponudb ne bo javno.
IX.
Ponudbena dokumentacija mora biti na papirju formata A4 in predložena naročniku v zaprti
kuverti temu ustreznega formata. Na kuverti mora biti navedeno ime in naslov naročnika
(Narodna in univerzitetna knjižnica, Turjaška 1, Ljubljana), oznaka: "PONUDBA ZA
IZDELAVO PROGRAMSKE OPREME - NE ODPIRAJ!" ter popolno ime in naslov
ponudnika oziroma pošiljatelja.
Nepravilno ali nepopolno označene pošiljke bo naročnik neodprte vrnil pošiljatelju.
Če na kuverti ne bo naslova pošiljatelja, jo bo naročnik odprl samo zato, da ugotovi
pošiljatelja in mu jo bo vrnil, ne da bi jo obravnaval.

5
X.
Naročnik bo obravnaval in ocenjeval samo pravočasne in popolne ponudbe, ki bodo
izpolnjevale vse pogoje, določene v teh navodilih in ki ne vsebujejo neresničnih podatkov.
Ponudba je popolna, če je izdelana po teh navodilih in vsebuje vse pravilno izpolnjene
zahtevane dokumente po naslednjem vrstnem redu:
1. obrazec - PONUDBA (obr. JN - 5)
2. obrazec - IZJAVA (obr. JN - 7)
3. obrazec - REFERENCE (obr. JN - 8)
4. obrazec - PROGRAM DEL - METODOLOŠKI PRISTOP (obr. JN - 9)
5. izpolnjen, podpisan in parafiran (vsaka stran) ter žigosan VZOREC POGODBE (0br. JN-
100).
XI.
V obrazcu PROGRAM - METODOLOŠKI PRISTOP (opisni del) ponudnik predstavi
metodološki pristop k izdelavi programske opreme in navede okvirni terminski plan izvedbe
posameznih faz.
Opisni del naj zajema opis rešitev za vse zahteve, ki so navedene v prilogi A. V opisu rešitev
naj bodo navedene vse zahteve in pogoji, ki jih za izvedbo postavlja naročnik. Predstavljen
naj bo način izpolnjevanja zahtev z opisom načina rešitve. Opis naj bo tekstualen in kjer je
primerno tudi grafičen. V opisu naj bodo podane tudi zahteve glede zmogljivosti strojne
opreme, zmogljivosti komunikacij in morebitne uporabe licenčne programske opreme.
Drugi pogoji:
XII.
1. Rok izvedbe: najpozneje 90 dni od sklenitve pogodbe.
2. Rok plačila: najmanj 30 dni od prejema računa na podlagi predhodne potrditve in
pozitivne ocene programa s strani naročnika.
3. Cena izdelave programske opreme je fiksna ves čas trajanja pogodbe.
4. Rok veljavnosti ponudbe: najmanj do 30. junija 2002.
5. Ostali pogoji so navedeni v vzorcu pogodbe.
XIII.
V obrazcu PONUDBA ponudnik vpiše tudi vse tarife, ki izhajajo iz obrazca.
Cena izdelave programske opreme mora vsebovati vse stroške izdelave vključno z
dokumentacijo in inštalacijo ter uvajanjem naročnikovih delavcev in ostalimi zahtevami
naročnika.
XIV.
V obrazcu REFERENCE ponudnik navede primerljivo programsko opremo, ki jo je ponudnik
v zadnjih 3 letih pred datumom te dokumentacije izdelal za druge naročnike. Za vsako

6
programsko opremo izpolni en obrazec (JN-8). Naročnik lahko podatke preveri pri naročnikih
teh baz.
Za primerljivo šteje:
- podatkovna zbirka na CD-ROMu
- zbirka na spletu, XML kot izhodni format
- distribuirano iskanje.
XV.
Naročnik bo ocenjeval ponudbe po naslednjih merilih:
1. cena izdelave programske opreme : 50 % ocene
2. rok izvedbe: 10 % ocene
3. referenca ponudnika: 40 % ocene.
Ad 1/ Cena izdelave programske opreme
Naročnik bo točkoval ponudbe in sicer tako, da bo najcenejši ponudnik dobil 5 točk, najdražji
pa 1. Ostali bodo dobili ustrezno vmesno oceno. Število točk se množi s 5.
Ad 2/ Rok izvedbe naročila
Naročnik bo točkoval ponudbe in sicer tako, da bo ponudnik z najkrajšim rokom dobil oceno
5, z najdaljšim pa 1. Ostali bodo dobili ustrezno vmesno oceno.
Ad 3/ Reference
Naročnik bo točkoval ponudbe in sicer tako, da bo ponudnik z največ referencami dobil 5
točk, z najmanj pa 1. Ostali bodo dobili ustrezno vmesno oceno. Število točk se množi s 4.
XVI.
Posamezna merila so ovrednotena v točkah oziroma v odstotkih. Seštevek vseh točk iz vseh
meril je največ 50.
Izbran bo tisti ponudnik, ki bo v skupnem seštevku ocen po vseh merilih dobil največje
število točk.
Če bo po vseh navedenih merilih več ponudnikov dobilo enako število točk, ima prednost
tisti, ki je ponudil nižjo ceno.
Vsi ponudniki bodo pisno obveščeni o izboru.
XVII.

7
XVIII.
Izbrani ponudnik mora z naročnikom podpisati pogodbo in jo podpisano vrniti naročniku v
roku 8 dni od prejema v podpis. V nasprotnem primeru se bo štelo, da izbrani ponudnik ne
želi skleniti pogodbe in bo naročnik lahko izbral ponudnika, katerega ponudba je bila
ocenjena kot druga najugodnejša, lahko bo postopek ponovil ali pa naročilo oddal tretji osebi.
Če izbrani ponudnik iz razlogov, ki so na njegovi strani v navedenem roku ne sklene pogodbe,
je naročniku odškodninsko odgovoren.
XIX.
Ocenjena vrednost tega javnega naročila je brez DDV 3,000.000 SIT.
Ponudbe, ki bodo za več kot 10 % presegle ocenjeno vrednost bodo izločene.
XX.
Naročnik si pridržuje pravico, da brez kakršnekoli obrazložitve in brez kakršnekoli
odškodninske ali druge obveznosti do ponudnikov ne sprejme nobene ponudbe ali da prekliče
postopek javnega naročila.
XXI.
Šteje se, da ponudnik s tem, ko odda svojo ponudbo, v celoti in brez pogojev ali pridržkov
sprejema vse pogoje tega javnega naročila.
XXII.
Vse stroške priprave in izdelave ponudbe nosi izključno ponudnik sam.
Narodna in univerzitetna knjižnica

8
NAROČNIK:
NARODNA IN UNIVERZITETNA KNJIŽNICA
obr. JN-5
P O N U D B A
I. PODATKI O PONUDNIKU
- firma( ime )__________________________________________________________
- sedež_______________________________________________________________
- zakoniti zastopnik ____________________________________________________
- štev. reg. vložka______________ Okrožno sodišče v ________________________
- matična številka___________________
- davčna številka_____________________, davčni zavezanec: DA - NE
- žiro račun ___________________________pri______________________________
- kontaktna oseba_______________________________________________________
- telefon/fax/ e.mail______________________________________________________
II. PREDMET PONUDBE
IZDELAVA RAČUNALNIŠKE PROGRAMSKE OPREME
ZA POIZVEDOVANJE PO SLOVENSKI BIBLIOGRAFIJI
(CD-ROM IN INTERNET)

9
III. VSEBINA PONUDBE:
1. Cena izdelave programske opreme:
- brez DDV ______________________________________ SIT
- z DDV _________________________________________ SIT
2. Cena letnega vzdrževanja:
- brez DDV ______________________________________ SIT
- z DDV _________________________________________ SIT
3. Cena svetovalne ure pri nadgradnjah
- brez DDV ______________________________________ SIT
- z DDV _________________________________________ SIT
4. Cena programerske ure pri nadgradnjah
- brez DDV ______________________________________ SIT
- z DDV _________________________________________ SIT
5. Rok izvedbe naročila ___________ dni od podpisa pogodbe
6. Rok plačila __________ dni
IV. VELJAVNOST PONUDBE DO: _________________________________________
Številka:
Kraj in datum:
Žig in podpis
pooblaščene osebe ponudnika

10
NAROČNIK:
NARODNA IN UNIVERZITETNA KNJIŽNICA
obr. JN-7
I Z J A V A
O SPREJEMANJU IN IZPOLNJEVANJU POGOJEV
PONUDNIK:
___________________________________________________________________________
V zvezi z našo ponudbo štev. ________________ z dne _______________________- za
izdelavo programske opreme za poizvedovanje po Slovenski bibliografiji
i z j a v l j a m o ,
da se strinjamo in sprejemamo vse pogoje, ki so navedeni in zahtevani v dokumentaciji tega
javnega naročila
Prav tako pod materialno in kazensko odgovornostjo izjavljamo in jamčimo, da:
− vse kopije dokumentov, ki so priložene ponudbi, ustrezajo originalom,
− vse navedbe, ki so podane v tej ponudbi, ustrezajo dejanskemu stanju,
− izpolnjujemo pogoje, ki jih določa 41. člen ZJN-1 (Uradni list RS št. 39/00, 102/00 in
30/01).
Vsi navedeni podatki in izjave so resnični in jih bomo na zahtevo naročnika dokazali z
verodostojnimi listinami
Kraj in datum
Žig in podpis
pooblaščene osebe ponudnika

11
NAROČNIK:
NARODNA IN UNIVERZITETNA KNJIŽNICA
obr. JN-8
PONUDNIK: ________________________________________________
REFERENCE
Podatki o primerljivih projektih (XIV. točka navodil)
___________________________________________________________________________
NAZIV PROJEKTA:
DATUM IZDELAVE:
NAROČNIK:
ŠTEVILO ZAPISOV:
KRATEK OPIS:
Kraj in datum:
Žig in podpis pooblaščene osebe

12
NAROČNIK:
NARODNA IN UNIVERZITETNA KNJIŽNICA
obr. JN-9
PONUDNIK: ____________________________________________________________
PROGRAM DEL - METODOLOŠKI PRISTOP
Kraj in datum:
Žig in podpis
pooblaščene osebe ponudnika

13
VZOREC POGODBE (obr. JN-10)
Na podlagi sklepa naročnika štev. _________________ z dne _____________ o izbiri
najugodnejšega ponudnika v postopku javnega naročila male vrednosti - izdelave
računalniške programske opreme za poizvedovanje po Slovenski bibliografiji,
s k l e n e t a
NAROČNIK: NARODNA IN UNIVERZITETNA KNJIŽNICA Ljubljana, Turjaška 1, ki ga
zastopa ravnatelj mag. Lenart Šetinc
in
IZVAJALEC:
___________________________________________________________________________
___________________________________________________________________________
(naziv, naslov, zastopnik)
(v nadaljevanju: izvajalec)
naslednjo
P O G O D B O
O IZDELAVI RAČUNALNIŠKE PROGRAMSKE OPREME
ZA POIZVEDOVANJE PO SLOVENSKI BIBLIOGRAFIJI
(CD-ROM IN INTERNET)
1. člen
Predmet pogodbe je izdelava računalniške programske opreme za poizvedovanje po Slovenski
bibliografiji po zahtevah iz dokumentacije javnega naročila.
Delo po tej pogodbi obsega analizo oziroma povzetek obstoječega stanja, programiranje
aplikativnih rešitev, kreiranje in nameščanje programske opreme na lokaciji naročnika,
izdelavo dokumentacije, uvajanje oziroma usposobitev delavcev naročnika ter izročitev
programske opreme naročniku.
Dokumentacija javnega naročila je sestavni del te pogodbe.
2. člen
Vrednost pogodbe je določena s fiksno ceno za izdelavo programske opreme iz 1.člena po
izvajalčevi ponudbi in znaša ___________________ SIT (z besedo: ___________________),
od tega znaša DDV ____________ SIT.

14
3. člen
Podlaga za izplačilo pogodbene vrednosti je naročnikova pozitivna ocena izdelka, na podlagi
katere izvajalec izstavi naročniku račun.
Naročnik bo izdelek oceni v roku 10 delovnih dni od prejema. Ob prevzemu se sestavi
primopredajni zapisnik.
Če naročnik izdelek pozitivno oceni, je dolžan račun za opravljeno delo izvajalcu plačati v
roku ______ dni od prejema računa.
V primeru zamude s plačilom je naročnik dolžan plačati izvajalcu zakonske zamudne obresti.
4. člen
Rok za izročitev brezhibno delujočega in funkcionalno ustreznega računalniškega programa s
pripadajočo dokumentacijo in izvorno kodo naročniku je ______ dni od sklenitve pogodbe.
Izvajalec bo naročniku ob izročitvi izdelka izročil tudi celotno izvorno kodo programa. Vsako
naknadno spremembo izvorne kode mora izvajalec dokumentirati in izročiti naročniku.
V primeru zamude pri izvedbi del po tej pogodbi, se lahko izvajalcu določi naknadni rok za
izpolnitev, če krivda za zamudo ni na strani izvajalca, vendar le v primeru višje sile, ki
nastane neodvisno od volje ene ali druge stranke.
5. člen
Če izvajalec po svoji krivdi naročniku ne izroči brezhibno delujočega in funkcionalno
ustreznega računalniškega programa v pogodbenem roku iz 4. člena te pogodbe, ima naročnik
pravico zaračunati pogodbeno kazen v višini 5 %o (promilov) od pogodbene cene za vsak
koledarski dan zamude in jo bo ob plačilu odštel od zneska računa, ima pa tudi pravico
zahtevati povrnitev škode, ki jo je zaradi zamude utrpel.
Če je zamuda taka. da bi imel naročnik večjo škodo, izdelava programa pa je postala
brezpredmetna in ni več v interesu naročnika, lahko naročnik odstopi od pogodbe ob
uveljavljanju nastale škode.
6. člen
Naročnik se obvezuje, da bo izvajalcu zagotovil razpoložljivost človeških, informacijskih in
drugih virov ter mu dal na razpolago vse potrebne informacije za izvedbo dela.
Naročnik bo sproti spremljal delo izvajalca.

15
7. člen
Izvajalec se obvezuje:
- prevzeto delo opraviti strokovno in kvalitetno, v skladu z dokumentacijo javnega naročila
in ponudbeno dokumentacijo in navodili naročnika ter v stalnem sodelovanju z
naročnikom oziroma od njega pooblaščeno osebo,
- izvajati vse pogodbene obveznosti v dogovorjenih rokih,
- pri izvajanju dela bo izvajalec uporabljal napredne informacijske tehnologije ter izvrševal
storitve gospodarno in v korist naročnika,
- po predaji oziroma prevzemu dela s strani naročnika bo izvajalec na zahtevo naročnika
programsko opremo redno vzdrževal, za kar bosta stranki sklenili posebno pogodbo.
8. člen
Izvajalec jamči naročniku, da bo računalniški program brezhibno deloval in izvajal vse
funkcije, določene v dokumentaciji javnega naročila ter po zahtevah naročnika.
Odgovornost izvajalca za kakovost in solidnost izvedbe pogodbenih del se presoja in izvaja v
skladu z zakonom o obligacijskih razmerjih.
9. člen
Izvajalec je dolžan na svoje stroške v najkrajšem možnem času odpraviti vse napake in
pomanjkljivosti na računalniškem programu, ki se pokažejo v roku 2 let od izročitve
programa naročniku. V nasprotnem primeru lahko to stori naročnik sam oziroma po njegovem
naročilu kdo drug na stroške izvajalca. Ta rok se podaljša za čas odpravljanja napak in
pomanjkljivosti. V vsakem primeru pa ima naročnik tudi pravico zahtevati povrnitev škode.
Odzivni čas izvajalca za odpravo napak na računalniškem programu je ob delavnikih 24 ur, ob
nedelavnikih pa 48 ur.
10. člen
Izvajalec jamči naročniku, da je računalniški program prost kakršnihkoli lastninskih,
avtorskopravnih, licenčnih ali drugih omejitev v korist tretjih oseb.
11. člen
Naročnik je izključni lastnik računalniškega programa in ima na njem v celoti, izključno ter
časovno in prostorsko neomejeno vse materialne avtorske pravice po Zakonu o avtorski in
sorodnih pravicah (Uradni list RS št. 21/95 in 9/01), ki jih lahko brez posebnega dovoljenja in
plačila izvajalcu neomejeno prenaša na tretje osebe.
Izvajalec brez predhodnega pisnega dovoljenja naročnika ne sme računalniškega programa ali
izvorne kode izročiti, prodati, posoditi ali kakorkoli drugače dati na razpolago tretjim osebam.

16
12. člen
Pogodbeni stranki bosta vse medsebojne dogovore ter podatke in dokumentacijo v zvezi s
predmetom te pogodbe in bodo označeni kot zaupni, ali bo iz vsebine možno sklepati, da so
zaupne narave, varovale kot poslovno skrivnost in jih ne bosta neupravičeno uporabljali v
svojo korist oziroma komercialno izkoriščali ali posredovali tretjim osebam.
13. člen
O vseh dogovorih in dejanjih pogodbenih strank v zvezi z izvajanjem pogodbe se sproti vodi
pisno evidenco.
14. člen
Pooblaščeni zastopnik naročnika je dr. Maja Žumer, ki opravlja tudi strokovni nadzor nad
izvajanjem del.
Pooblaščeni zastopnik izvajalca za izvajanje te pogodbe je ___________________________.
15. člen
Vse spremembe in dopolnitve te pogodbe so veljavne le v pisni obliki in ko jih podpišeta
pooblaščena predstavnika obeh pogodbenih strank.
16. člen
Spore rešuje stvarno pristojno sodišče v Ljubljani.
17. člen
Pogodba začne veljati z dnem, ko jo podpišeta pooblaščena predstavnika obeh pogodbenih
strank.
Pogodba je sestavljena in podpisana v 4 enakih izvodih, od katerih prejme vsaka pogodbena
stranka po 2 izvoda.
Številka: ___________________
V Ljubljani, dne ______________
Številka: ___________________
V ____________, dne _________
NAROČNIK:
Narodna in univerzitetna knjižnica
IZVAJALEC:
mag. Lenart Šetinc
ravnatelj

17
PRILOGA A
Slovenska bibliografija na CD-ROMu
Specifikacija
Program za poizvedovanje po Slovenski bibliografiji na CD-ROMu naj po funkcionalnosti in
izgledu v celoti sledi dosedanji programski opremi. CD-ROM in priročnik sta na voljo v
Informacijskem centru za bibliotekarstvo.
CD-ROM izhaja dvakrat letno. V prihodnosti je možna tudi drugačna frekvenca.
Vsakokrat se iz vzajemnega kataloga pripravijo (celotni) podatki v UNIMARC formatu, ki jih
mora ponudnik obdelati in CD-ROM pripraviti za tisk.

18
Slovenska bibliografija na internetu
Specifikacija
S stališča uporabnika mora biti ta verzija popolna kopija programa na CD-ROMu.
Ta verzija se bo ažurirala pogosteje (predvidoma enkrat mesečno). Pripravljena morajo biti
orodja, ki brez sodelovanja ponudnika omogočajo dodajanje novih zapisov ali tvorbo celotne
zbirke.
Dodatna zahteva pri tej verziji je tudi vključevanje v distribuirano iskanje, zaradi česar mora
ponudnik upoštevati tudi dodatne funkcionalne zahteve, opisane v prilogi Functional
specifications for testbeds.

19
FUNCTIONAL SPECIFICATION FOR TESTBEDS
In this chapter the functionality, which should be obtained in the two testbeds, is
defined. These specifications are the basis for implementation in the Z39.50 and the
XML testbed.
The most important agreements relate to the requests to one or more targets and the
responses from these targets. Other features like merging or sorting results and a
multilingual access to subjects are not functions for the testbeds. They will be treated
in connection with the portal software.
Search Functionality
Search Requests
To obtain consistent search results by searching in different databases it is necessary to
define common search terms and options. According to the Bath Profile Functional
Area C: Level 1 Cross-Domain Search and Retrieval the following search
specifications are defined as basis for the testbeds.
Search terms
• Author:
Person or entity responsible for a resource
• Title:
Name given to a resource
• Subject:
Topic of the content of the resource
• Standard identifier:
Such as ISBN, ISSN, Music Standard numbers, CODEN, Superintendent of
Documents Item Number, etc., but does not identify a specific standard number
scheme
• Any:
Data elements that are commonly used as access points (as defined by the server)
Search limiter
Additionally some search limitations are desirable. They can be used only as a search
limiter in conjunction with another operand.
• Date of Publication:
Date (year) associated with the creation or availability of the resource. For this
term not only the exact match of the access point and the search term is necessary
but also relations like: less than, less than or equal, greater than or equal, and
greater than.
• Language of Publication:
A code that indicates the language of the item. The proposed code is ISO 639.2
with 3-character alphabetic symbols. The usage depends on the possibility of the
partners.
• Material-type:
A free-form string that describes the material type of the item, e.g. book, journal,
cassette, computer file. It is very doubtful whether for this term a common code

20
can be used. There is no standard available and each system has its own view and
marking of the material.
Boolean operators
Several single search criteria can be combined with the operators ‘and’, ‘or’, ‘and-not’.
Standard is a keyword search. Alternatively in the query for ‘title’, ‘subject’ and ‘any’
the parameter phrase (one or more words in the exact order) can be used.
Truncation
For each search term right truncation is an additional option.
Record transfer
A further request parameter for search and retrieval concerns the format of the
response (e.g. full, brief). A parameter for the preferred record syntax is probably not
required because there is a general agreement to support XML.
The search request includes also a parameter for the maximal number of records to be
returned.
Result sets
For the retrieval functionality the server must store query results, which can be
referenced in subsequently wishes by a result set name. The retrieval request may
specify a starting position within the set and the number of records to be returned. In
this way navigation in the results and the aimed request for an individual record is
possible.
Scan / Browse
Remark:
Not yet decided
Search responses
The response from the server includes a result counter with the number of records
identified by the search request and stored in the result set
For the XML and the Z39.50 testbed the server must support a result set name.
Because the XML server does not maintain sessions the server names the result set and
send it to the client.
If there are any hits available the records are delivered in the response. The number
and the format correspond to the request parameters.
If the search request cannot be processed, the target submits a diagnostic record with
the reason (e.g. timeout for availability of the result set).

21
Presentation of Retrieved Records
Short List
The first result of a search request is the number of hits and one or more short records.
If more databases are selected, each system sends a response. The standard
presentation generate for each database a presentation block with the name of the
database and the number of hits as header, a list of the retrieved short records and
some buttons for navigation. The short list is numbered serially and includes for each
entry a link to the full record. Brief records may only contain Author, Title,
Publication Date. To see further hits from the result set of a single database in a short
list, navigation buttons are available.
Full Presentation
The display of all fields of a retrieved record can be reached by a click on a short
entry. Additionally the name of the database, the number of hits, the ordinal number of
the full record and buttons for e.g. next and previous full record are presented on this
screen. The returned records can contain clickable links to other documents and digital
objects.
A further important link for the full presentation is a URL that leads to the record in
the original system. As possible each partner should generate and provide a URL as
access to the own services e.g. document ordering. So the user has the possibility to
order a document if it is not available in electronic form or to access licensed
documents. The aim is to integrate such functionality in the Tel Portal, not in the
testbeds.

22
TECHNICAL SPECIFICATIONS AND IMPLEMENTATION OF XML TESTBED
General requirements
The KB databases will be made available by the KB according to the specifications in
chapter 8.3. Participants of the http/XML testbed have to support record fetching by
the KB system according to the specifications in chapter 8.4. The participants database
records will then be fetched on regular basis for indexing.
When a partners http/XML database supports access according to the specifications in
chapter 8.3, such a database may be considered as standalone http/XML target and
there is no need for central indexing and record fetching.
The functional specifications will as close as possible resemble the Bath profile,
functional Area C. For the http/XML there is no standard interface like Z39.50
available. For the interface specifications it is therefore intended to anticipate on the
ZNG-initiative. As the interface definitions for ZNG are not yet available some aspects
may be subject to change in the near future. As far as information is available from
ZNG, this information is incorporated in these specifications.
Future extensions of the interface should be possible.
Interface description
Below the input and output for the XML testbed is specified. Although the
terminology used in Z39.50 does not apply to the http/XML environment we try to be
in line with this terminology as much as possible.
General target features
- Services Search/retrieve (one service does all)
- Character Set: UTF-8
- Attributes Set: See list
- Record Syntaxes: XML (see output specification)
- Diagnostic Set: -
There is no init or close service defined. Authentication, that is part of the Z39.50 init
service, will be handled on a per-request basis but will not be specified here for search
and retrieval of metadata. All the metadata presented within the TEL context are
considered to be available without restriction.
Input specification
All requests to the http/XML targets are done by a conventional URL GET-query.
There is a one kilobyte limit on the length of URL’s but this is not considered as a
severe limitation.
The requesting “TEL-URL” will be defined as follows:
TEL-URL := ?

23
The request is defined as:
:= = {&=}
Valid parameters are:
query:
the actual search query to be performed
resultsetid: the name of the query result as given by the target
responseSchema: identification of the type of the desired response
recordSchema: identification of the desired record schema
startRecord: rank number of record to be retrieved in result set
maximumRecords maximum number of records to be retrieved from result set
collection: the name of the collection to be searched in. In the current KB
system this field may also be part of the query because all
collections are in a single index.
SortField:
the sort field for the result set (the choice of sort fields will be
limited)
A simple query is defined as:
[field:][term [ AND|OR|NOT [field:]term]
Queries can be combined recursively in boolean expressions by putting the query
between parenthesis.
Search attributes
Index types:
Title (word/phrase) : supported
Subject (word/phrase)
how to deal with different subject types is not yet
specified
Author:
supported
standard identifier (isbn, issn): supported
any (word/phrase):
supported
Date of publication as relation: supported (>, < and =)
Language:
supported
Material type:
supported
Named-result-sets:
Query type:
Operator types:
Result set id as operator:
Term-types:
Element set names:
named (no default) sets are supported
boolean combinations with brackets, indicating
order of operands, truncation indicated by “*”
(matches one or many characters) and “?”
(matches any character)
AND, OR and NOT
not supported at target level
general and value (e.g. year)
see response schema
Remarks.
The index types (Z39.50 use attributes) as mentioned above are the minimum set
required for TEL. In Z39.50 these names correspond to numbers. It would be
advisable to use the names of the Dublin Core fields as index types.
There are no restrictions on the use of local index types.

24
Output specification (response schema)
The response for each request will be in XML format. There will be a global, basic
schema defined for the response. The response consists of bibliographic data and data
that concerns navigation. There may be different schemas for bibliographic data
possible although in this specification Dublin Core is considered to be the default
record schema for TEL. A final decision on the exact DTD will be made in WP3.
A TEL-DTD, based on the ZNG Prototype 1 WSDL Definition (
http://www.lib.ox.ac.uk/jafer/zng/zng-p1.wsdl.html with some minor changes) is
shown below.

25
]
A response consist of contextual information and one or more records. The distinction
between full and short records is made though the record schema.
When a request is invoked without arguments the result will be an explain message.
This is an XML-message that will contain some information on the target. Details are
not specified here.
The recordData contains the metadata and the schema of these metadata is part of the
record tag. The default schema will be Dublin Core.
There are some points where the above DTD does not match the ZNG Prototype 1
WSDL Definition. As ZNG is still under development, there is a chance that ZNG will
accept recommendations from TEL. The differences are extra tags in the TEL-DTD
that are not defined in ZNG. These are:
the maximum size of a result set for a target
the actual query
The number of a record within the result set
The URL variables that are unknown to the target
The response is considered to be evolving in time and this specification describes the
starting point for TEL. The number of record schemas may grow as well as the
number of response schemas. An additional response that is likely to be part of the
output in future implementations is the result of browsing in an index (Z39.50 scan).
The default record schema and response schema are undefined and depend on local
implementations. For TEL the defined schemas are:
ResponseSchema=TELResponse
RecordSchema=TELshortRecord
RecordSchema= TELfullRecord
Interaction between input and output
All the parameters in the requesting URL, like search terms, format specification and
record range, will have a meaning in specifying the search request and the response for
that request. It is intended to keep the names of the XML output tags as much as
possible identical to the names of corresponding parameters in the requesting URL.
The origin as well as the target are expected to be tolerant with respect to their input.
For missing parameters a reasonable default should, when necessary, be substituted
and parameters, that in a certain context have no meaning, will be neglected.

26
Having said this, ambiguity should be avoided by specifying some limitations. A valid
request is considered to have at least one and not more than one of the following
parameters as input: a query, a resultsetid or a recordid. These parameters may be
accompanied by other parameters but these extra parameters will be neglected if not
meaningful or not supported.
Meaningful combinations for input parameters are:
1) Query [,responseSchema] [,startRecord] [,maximumRecords] [,recordSchema]
[,collection] [sortField]
2) Resultsetid [,responseSchema] [,startRecord] [,maximumRecords] [,sortField]
3) Recordid [,recordSchema]
4) Resultsetid [,recordSchema][startRecord]
5) – (no parameters)
The response will always be a searchRetrieveResponse message unless a request is
invoked without parameters. In that case the result will be an “explain” message with
the full database name and the searchable fields. The searchRetrieveResponse is
controlled by the URL parameters.
In case the requesting URL contains parameters that are not specified or unknown to
the target, these parameters will be returned in the tag with subtags with
the names of these parameters. This allows the gateway or client to provide context
information to each request.
Fetching and indexing XML records from remote targets
For targets that will not conform to the input and output specifications in 8.3., this part
will specify how XML records from remote databases will be fetched. Fetching is
done by the KB central system for indexing purposes. After the indexing process the
XML-records are not stored in the KB storage infrastructure: fetching is done
separately but in the same way for retrieval by the portal service as a result of a user
request.
The remote database is requested for the list of new records since a certain timestamp
This timestamp will generally be the time of the previous request. The remote database
returns a list with record identifiers in XML format. Each record then is requested
individually and stored in the KB XML-repository and indexed as is described in 8.5.
The records will be sent by the remote target in the format as described in 8.3.
The URL for requesting the list of records, updated since a certain timestamp, will be:
base-url?query=*&timestamp=&responseSchema=id-only
The response will be the tel-record-list as specified in 8.3.3 with id’s only and no
actual tel-records. To avoid too much load the amount of returned record id’s will be
limited to 10000. When this limit is reached, a new timestamp, that corresponds to the
last record in the list and that is to be used in the next request, is added to the response.
The individual tel-records will be requested by the following URL:

27
Base-url?record-Id=&responseSchema=tel-record
The default record schema for TEL is the tel-record schema as specified in 8.3.3.
How the records are processed internally by the system of the KB is considered out of
the scope of these specifications.
XML indexing
The specification of the indexing of XML records will be a description of how the
XML records are currently indexed by the search and retrieval system of the KB. The
product used now is AltaVista Developers Toolkit but this may be subject to change in
the future.
All end-nodes in the xml records will be indexed twice: once as a keyword and once
with the tag name as field name being a prefix. This field name can be used in search
queries as prefix also. As soon as a tag with a certain name exists in an XML-record
and this XML-record is presented to the indexing mechanism, this name becomes a
valid field and can be used as prefix in searching. There is only one index and field
names do not have to be defined before. Searching is done on basis of single words.
Searching phrases is done by putting the phrase within quotes.
Proximity and fuzzy searching are not supported. Boolean combinations are supported
by using AND,OR and NOT and the order of operation may be set by using
parentheses.
Technical requirements of the testbed
The http/XML testbed is supposed to test the result of searching in one or more
http/XML databases. The test passes if a remote client is capable of submitting a
search (conform these specifications) and interpreting the output correctly (conform
these specifications). It is sufficient therefor to do the test with a browser and an html
form that will transform the presented results by means of an XSL stylesheet.
The technical requirements on the client side are therefor minimal: a workstation with
Internet Explorer and a stylesheet that will transform the output records to a readable
format.
The requirements on the server side are that the search and retrieval service running at
the KB accepts queries as defined in this specification and delivers output as defined
in this specification. There are no additional requirements.
Realisation of the testbed
The http/XML testbed requires the following work to be done:
1) Development of the search and retrieval functionality to support these
specifications.

28
2) Development of an http search form and an xsl stylesheet for simple testing by
means of Internet Explorer
3) Development of software for fetching remote records
Test scenarios
The purpose of the test is to prove that the server side functionality is suitable for
building the integrated TEL portal service. The test scenario should therefor resemble
the test scenario for the Z39.50 testbed with respect to user’s input and the server’s
output.
For both the Z39.50 targets as the http/XML targets the user query is entered in a
HTML form which will result in a http search request. This input form may be such
that the resulting http request meets the specifications of 8.3. The request can in that
case be sent to the http/XML server without any translation.
The same search request should be used for the Z39.50 testbed. This might require a
translation of the search request for existing gateways.
The response will of course contain different records but the conceptually the result
should be the same.