Ratkaisuksi on Z39.50 Implementor's Groupissa (ZIG) kehitetty ohjeita, joita kutsutaan profiileiksi sekä ohjelmistokehittäjien sopimuksiksi (Implementor's agreements). Näiden ohjeiden laatimisesta on viimeisen parin vuoden aikana tullut oleellinen osa ZIG-ryhmän työskentelyä, koska niiden on havaittu helpottavan Z39.50-ohjelmistojen kehittämistä merkittävästi.
Tämä artikkeli on tarkoitettu johdannoksi Z39.50-profiileihin ja -sopimuksiin perehtyville. Asia on Suomessa ajankohtainen, muun muassa koska LINNEA-2 Request for Proposal nojautuu eräiden verkkotoimintojen osalta kansalliseen Z39.50-profiiliin sekä yhteisluetteloprofiiliin (Union Catalogue Profile).
Profiilien ja sopimusten välinen ero ei ole järin suuri. ZIG-ryhmässä on tapana luonnehtia eroa toteamalla että profiili on joukko samaa asiaa koskevia sopimuksia. Selkeyden vuoksi käsittelen sopimukset ja profiilit kuitenkin erikseen omissa luvuissaan.
Sopimukset
Sopimukset ja ohjeet (tai linkit niihin) on koottu Kongressin kirjaston Z39.50-sivuille. Elokuuhun 1998 mennessä on hyväksytty seitsemän sopimusta (http://lcweb.loc.gov/z3950/agency/agree/agree.html), ja kahdeksas läpäissee seulan lokakuussa 1998 ZIG-ryhmän kokouksessa Madridissa.
Sopimuksen virallinen määritelmä on seuraava:
agreements address cases where the Z39.50 protocol does not provide a single, unambiguous solution for a particular function (or provides, or appears to provide, multiple solutions)
Jossakin määrin sopimusten kaltaisia ilmiöitä ovat selvennykset (Clarification) ja kommentit (Commentaries). Sopimuksiin verrattuna ne ovat kapea-alaisempia; niitä onkin hyväksytty tätä kirjoitettaessa jo yli 60 (http://lcweb.loc.gov/z3950/agency/clarify/clarify.html ja http://lcweb.loc.gov/z3950/agency/wisdom/wisdom.html).
Selvennyksiä ja kommentteja kuvataan seuraavasti:
A Commentary differs from a Clarification (though they are processed in a similar manner), whose intent is to clarify, in cases where the text of the standard is ambiguous or requires interpretation. A commentary addresses aspects of the standard where the related prose may be terse but not necessarily ambiguous. The text of a commentary may be much less formal than the corresponding text of the standard.
Sopimuksista kenties tärkein määrittelee sen, miten Z39.50:n hakutermit vertautuvat USMARC-formaattiin (ftp://ftp.loc.gov/pub/z3950/defs/bib1.txt). Tämän dokumentin pohjalta Arne Hedman ja allekirjoittanut laativat FINMARCin vastaavan määrityksen (http://www.lib.helsinki.fi/z3950/bib1semf.html). Ainoa kehitteillä oleva sopimus koskee sekin tiedonhakua; Kanadan kansalliskirjasto käynnistämän prosessin tarkoituksena on sopia periaatteet Z39.50-sanahaun (keyword searching) toteutukselle (http://www.nlc-bnc.ca/iso/z3950/keyword2.htm). Syy tämän suosituksen laadinnalle on, että eri palvelimien oletusarvot esimerkiksi katkaisun käytössä vaihtelevat. Tämä tekee sovellusten käyttäytymisen vaikeasti ennustettavaksi. Yhteinen toimintamalli helpottaa hakujen tekoa oleellisesti.
Profiilit
Sopimukset ovat Z39.50-ohjelmien rakentajien ja käyttäjien kannalta katsottuna kapea-alaisia ohjetekstejä, joilla voidaan hoitaa yksittäisiä ongelmia kuntoon. Profiileilla sen sijaan on strategista merkitystä, koska ne ohjaavat voimakkaasti sitä, miten sovelluksia rakennetaan. Z39.50 on tavattoman monipuolinen standardi, ja siksi profilointi on välttämätöntä, toisin kuin esimerkiksi pääteprotokolla Telnetin tapauksessa.
Verkon koordinoinnin kannalta profiloinnin ongelma on, että Z39.50:een perehtyvälle ei riitä itse standardin tuntemus; on tutustuttava myös profiileihin. Profiileja voidaan ja tulee käyttää Z39.50 -ohjelmistokehityksen ohjaamiseen, ja siksi Helsingin yliopiston kirjasto on osallistunut profilointityöhön aktiivisesti.
Ensimmäinen Z39.50-profiili oli amerikkalainen ATS-1, joka määrittelee tekijä-, nimeke- ja aiheenmukaisen haun toteutuksen Z39.50-sovelluksissa (http://lcweb.loc.gov/z3950/agency/profiles/ats.html). Yhdysvalloissa tämän tekstin noudattaminen auttaa jo paljon, koska kirjastojen tietokannat ovat hyvin homogeenisia - muun muassa formaatti ja merkkivalikoima ovat samat.
CENL-profiili
EU:n ONE-projektissa havaittiin, että Euroopassa tarvitaan ATS-1:stä laajempi Z39.50-profiili. Täällä on otettava huomioon myös merkki- ja formaattikonversiot sekä se, että eri maissa käytetään erilaisia sisällönkuvailujärjestelmiä ja auktorisoituja nimenmuotoja. ONE:ssa kehitettiinkin oma profiili (http://www.bibsys.no/one-wg/bib-1.profile.html), josta muokattiin edelleen eurooppalainen sovellusohje (http://www.lib.helsinki.fi/z3950/cenl_profile.html).
CENL-profiili on ATS-1:een verrattuna vaativa: se edellyttää muun muassa USA:ssa harvinaisen Scan-palvelun (indeksien selaus) toteuttamista, perusteena ONE-hankkeen testeissä ilmitullut Z-hakujen nollatulosjoukkojen yleisyys. Lisäksi CENL-profiilia noudattavien palvelimien on kyettävä toimittamaan tietueet USMARC- ja UNIMARC-muodossa. Vaatimuksien kovuus verrattuna ATS-1:een perustuu osittain siihen, että eurooppalaiset Z39.50-sovellukset ovat keskimäärin amerikkalaisia edistyneempiä. Lisäksi, emme halunneet vain määritellä sitä, mitä on jo olemassa, vaan kertoa minkä uusien ominaisuuksien rakentaminen on meidän mielestämme oleellista.
Prioriteettilistan kärjessä ovat kansainvälisen yhteistyön näkökulmasta piirteet, jotka sallivat tehokkaan tiedonhaun ja tietueiden kopioinnin kansallisten rajojen yli. Merkki- ja formaattikonversioiden vaatiminen voi hätkähdyttää amerikkalaisia ohjelmistotaloja, joiden kotimarkkinoilla näitä piirteitä ei tarvita. Näiden ohjelmistojen rakentaminen on onneksi oleellisesti helpottunut sen takia, että ohjelmien kehittäjät voivat käyttää hyväkseen ONE- ja CHASE-projekteissa rakennettuja maksuttomia työkaluja.
CENL-profiili tarjoaa hyvän pohjan myös kansallisille Z39.50-profiileille. Ainakin Suomi ja Tanska ovat laatineet sellaisen. Suomen profiilin (http://www.lib.helsinki.fi/z3950/fin_profile.html) erot CENL-profiilista ovat kansallisen verkkomme kannalta merkittäviä laajennuksia:
- Z39.50:n yhteisluetteloprofiilin tuki
- FINMARC-tuki
- Suomessa käytettävien bibliografisen tiedon hakutermien kattava tuki
- Access control -toiminnon tuki (yhteisluettelon suojaaminen k-tunnuksella ja salasanalla)
Kansallinen Z39.50-profiilimme tarjoaa erinomaisen pohjan Suomen kirjastoverkon kehittämiselle. Tekstissä on kuitenkin sivuutettu lyhyin viittauksin oleellisia asioita. Esimerkki tästä on vaatimus yhteisluetteloprofiilin noudattamisesta. Koska harva lienee tutustunut tähän profiiliin, tarkastelen seuraavaksi sen sisältöä ja pohdin sen soveltamista Suomessa. Lopuksi luon silmäyksen toiseen merkittävään kehitteillä olevaan määritykseen, OPAC/Holdings -profiiliin.
Union Catalogue Profile
Z39.50-profiili määrittelee yleensä toteutettavaksi vain osan standardin sisältämistä piirteistä. Yhteisluetteloprofiili (http://www.nla.gov.au/ucp) on tässä suhteessa poikkeus - se spesifioi myös koko joukon uusia ominaisuuksia, joista Z39.50-perusteksti ei tiedä mitään. Välitön johtopäätös - Z39.50 on tältä osin puutteellinen - on oikea. Standardissa muun muassa todetaan, että tietueiden lukitseminen on hoidettava "itse". Profiilissa tämäkin piirre on mukana. Profiilin ja standardin vertailu kertoo sekin jo jotakin: kun Z39.50:n 150 sivusta Extended Services Update vie vajaan sivun, yhteisluetteloprofiilissa on sivuja 54.
Yhteisluetteloprofiilin tavoite on seuraava:
This Profile is intended for use with the ISO 23950 (Z39.50 Information Retrieval Protocol) standard to allow a data creator to update a database in a distributed environment using the Database Update Extended Service of the standard.
Tietokanta voi olla joko oma näyttöluettelo, yhteisluettelo tai molemmat. Yhteisluetteloprofiilin toteuttavien ohjelmien avulla voidaan siis luoda verkko, jossa luetteloija päivittää samanaikaisesti sekä omaa tietokantaa että yhteisluetteloa. Luettelointiohjelma ja yhteisluettelosovellus voivat olla eri valmistajan tuotteita, koska ne kommunikoivat keskenään Z39.50:n välityksellä. Luetteloijien tarvitsee opetella vain yksi sovellus, vaikka oma näyttöluettelo ja yhteisluettelo olisivatkin eri valmistajan tuotteita. Paljon työtä vaativista yhteisluetteloiden eräpäivityksistä voidaan päästä eroon sitten kun kaikki sovellukset tukevat yhteisluetteloprofiilin keskeisiä piirteitä.
Yhteisluetteloprofiilin kehitystyöstä valtaosa on tehty Australian kansalliskirjastossa pitäen silmällä kansallisen verkon tarpeita. Ei siis ole yllätys, että profiili on erittäin kattava; se sisältää seuraavat toiminnot:
- Tietueen lisäys (Record insert)
- Tietueen muokkaus (Record replace); esimerkiksi kentän poisto tai lisäys
- Kentän muokkaus (Element update); yksittäisen kentän sisällön muuttaminen, osakentän lisäys tai poisto, indikaattoreiden muokkaus
- Tietueen poisto
- Erikoispäivitys (Special update); tuplien yhdistäminen tai "batch edit/replace", palvelu jolla suurta joukkoa tietueita muokataan samalla tavalla
- Tietueen lukitseminen
Toimintojen määrityksen ohella profiili kuvaa kuhunkiin toimintoon liittyvät sanomat ja (virhe)ilmoitukset. Oheisena malliksi asiakasohjelman lähettämä tietueen lisäyspyyntö:
|
Element Name |
Contents |
|
referenceId |
Optional - supplied by origin |
|
function |
Create |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted (optional) |
|
description |
Omitted (optional) |
|
taskSpecificParameters |
{Z39-50-extendedServices5} esRequest |
|
action |
recordInsert |
|
databaseName |
ex: UC-B (bibliographic record)
UC-H (holdings record)
UC-A (authority record) |
|
schema |
Omitted or record insert schema |
|
elementSetName |
set containing record ID, version identifier (date / time stamp) and title - default for successful update |
|
actionQualifier |
used for record review notes or "does not duplicate" lists |
|
suppliedRecords |
|
|
record |
|
|
recordId |
optional, i.e. not required for a MARC record insert because within the record itself |
|
supplementalId |
optional, i.e. not required for a MARC record insert because within the record itself |
|
correlationInfo |
not used |
|
waitAction |
wait if possible ( 1-10 records)
do not wait |
|
elements |
full - requesting that the target should return all task package elements in the update response where applicable |
|
otherInfo |
|
Ja tässä palvelimen lähettämä vastaus edellä olleeseen pyyntöön:
|
Element Name |
Contents |
|
ReferenceId |
optional - supplied by origin |
|
OperationStatus |
Done
Accepted
Failure |
|
Diagnostics |
only if failure |
|
TaskPackage consisting of: |
{Z39-50-recordSyntax (106)} taskPackage
(always supplied with update, so that the record ids can be conveyed to the origin) |
|
packageType |
Update |
|
packageName |
ex: 199607031045 |
|
userId |
ex: NU:46 |
|
retentionTime |
ex: 7 days |
|
permissions |
Omitted |
|
description |
Omitted |
|
targetReference |
ex: NU46:23 |
|
creationDateTime |
ex: 19960703104734 |
|
taskStatus |
0 (pending) 1 (active)
2 (complete) 3 (aborted) |
|
packageDiagnosis |
ex: Diagnostic record, format extServices, permission 1 (id not authorised) |
|
taskSpecificParameters |
update taskPackage |
|
action |
recordInsert |
|
databaseName |
ex: UC-B (bibliographic record)
UC-H (holdings record)
UC-A (authority record) |
|
schema |
Omitted |
|
elementSetName |
as per request |
|
actionQualifier |
Omitted |
|
updateStatus |
success
partial
failure |
|
globalDiagnostics |
if applicable |
|
taskPackageRecords |
|
|
recordOrSurDiag |
see table under Error Message Handling |
|
correlationInfo |
as supplied by target |
|
recordStatus |
success
queued
in process
failure |
|
supplementalDiagnostics |
see table under Error Message Handling |
|
OtherInfo |
Omitted - This data element is returned with the update response which may be given before the update has actually occurred. When this happens, the origin will later use search to access records in the task package. For this reason, information relating to records in the task package must be contained within the task package parameters and hence this data element is of limited value in an update response. |
LINNEAn kannalta katsottuna yhteisluetteloprofiili sisältää arvioni mukaan kaiken oleellisen ja vielä vähän päälle. Tästä oli paljon etua RFP:n laadinnassa, koska pystyimme viittaamaan olemassa olevaan ohjeeseen, josta on tulossa ISO-standardi. Yhteisluetteloprofiilia vastaavan oman määrityksen laatiminen olisi vaatinut useita viikkoja, ellei kuukausia. Toisaalta ohjelmistovalmistajat on paljon helpompi saada toteuttamaan standardiin perustuvia ominaisuuksia kuin omia spesifikaatiota.
Yhteisluetteloprofiilin toteutuksia ei tätä kirjoitettaessa tietääkseni vielä ole. Tämä on ymmärrettävää, koska profiili valmistui vasta kuluvan vuoden maaliskuussa, ja lopullinen siunaus asialle saataneen vasta ZIG-ryhmän Madridin kokouksessa lokakuussa 1998. Kun sovelluksia ryhdytään rakentamaan, ne eivät toteuttane koko profiilia vaan vain pakolliset toiminnot, jotka on määritelty profiilin luvussa 11 (Conformance). Minimitason sovelluksesta jäävät pois muun muassa Element update ja Special update -palvelut; käytännössä tämä merkitsisi muun muassa sitä, että tuplien poisto yhteisluettelosta pitäisi hoitaa järjestelmän sisäisin konstein.
Järjestelmissä joissa asiakas- ja palvelinohjelma kommunikoivat Z39.50:n välityksellä tietokannan ylläpito on järkevää rakentaa profiilin varaan. Niinpä VTLS:n Virtua on yksi ensimmäisistä profiilin hyödyntäjistä. Muissa kirjastosovelluksissa tämäntyyppisen palvelun rakentamisen tarve riippuu ensi sijassa siitä, onko ohjelman (maksukykyisillä) käyttäjillä yhteisluetteloita vai ei. Vastaavia palveluita on monissa järjestelmissä toteutettu sovelluksen omin ratkaisuin, ja näiden piirteiden muuntaminen Z39.50-pohjaiseksi ei liene kovin hankalaa. Jos taas tarvittava toiminnallisuus on luotava tyhjästä, urakka voi olla melkoinen.
OPAC/Holdings profile
Yhteisluetteloprofiilia tarvitaan ensisijaisesti yhteisluetteloiden ylläpitoon, jos järjestelmän sisäinen kommunikointiprotokolla ei ole Z39.50. OPAC/Holdings-profiili sen sijaan on hyödyksi kaikissa Z39.50-järjestelmissä. Profiilin laadinta käynnistyi vuoden 1997 kesällä, ja elokuussa 1998 työ on lähes valmis. On todennäköistä, että profiili hyväksytään yhteisluetteloprofiilin tavoin ZIG:in seuraavassa kokouksessa Madridissa lokakuussa 1998. Jos kiistoja jää, ne koskevat yksityiskohtia, ei enää niin sanottuja suuria linjoja.
Kaikki OPAC/Holdings -profiiliin liittyvä dokumentaatio löytyy Kanadan kansalliskirjaston WWW-palvelimelta osoitteesta http://www.nlc-bnc.ca/iso/z3950/, otsikon Holdings alta. Sijoituspaikka johtuu siitä, että Fay Turner NLC:stä sekä kirjaston ohjelmatoimittaja Amicus ovat olleet profiilin aloitteentekijöitä ja kehittäjiä, DRA:n ohella.
OPAC/Holdings -profiilin alaotsikko kertoo mistä on kyse: Profile for retrieving detailed library holdings in a bibliographic environment. Z39.50-palvelin voi lähettää bibliografiset tietueet asiakasohjelmalle monessa eri muodossa. Tavallisin ratkaisu on jokin MARC-formaatti, ja tämä valinta on myös OPAC/Holdings -profiilin lähtökohta:
This profile does not preclude, and in fact encourages, the delivery of location and holdings information within MARC record fields specifically designated for this purpose. For instance, the US MARC bibliographic record may legitimately carry holdings data in the 850-873 fields in some circumstances. This profile is thus directed initially toward the delivery of detailed holdings information which cannot be carried in MARC biliographic records, as well as the delivery of circulation information if available.
Moni kansallinen MARC-formaatti kompastuu jo yhdistelmätason varastotietojen siirrossa siihen, ettei sen kumppaniksi ole määritelty varastotietojen MARC-formaattia. Suomessa tätä ongelmaa ei onneksi formaattitasolla ole. Valitettavasti tällä hetkellä käytössämme oleva VTLS-94:n Z39.50-palvelin ei osaa yhdistää MARC-tietuetta ja siihen linkattua varastotietojen tietuetta (-tietueita) toisiinsa.
Yksityiskohtaisten varastotietojen liittäminen MARC-tietueeseen on huono ajatus ennen muuta varasto- ja saatavuustietojen suuren määrän vuoksi. Niinpä profiilin mukaan, jos järjestelmän käyttäjä haluaa yksityiskohtaiset varastotiedot tai saatavuustiedot, hänen on erikseen pyydettävä ne palvelimelta. Oletusarvoisesti tiedon hakija saa vain bibliografiset tiedot, jotka voivat sisältää esimerkiksi kirjastotunnukset.
Varasto- ja saatavuustiedot "paketoidaan" GRS-1 (Generic Record Syntax 1) -muotoon. GRS-1 on yksi Z39.50-standardissa määritellyistä tietuemuodoista. Nimensä mukaisesti se on hyvin yleinen määritys, jonka avulla voidaan määritellä erilaisia tietuerakenteita. OPAC/Holdings -profiilin täydennykseksi on luotu OPAC/Holdings -skeema, jossa määritellään siirrettävä tietosisältö (http://www.nlc-bnc.ca/iso/z3950/holds7.htm). Sen tietoelementit on poimittu seuraavista standardeista:
1. ISO 10324: Information and documentation -- Holdings statements -- Summary level (1997)
2. ANSI/NISO Z39.71: Holdings Statements for Bibliographic Items
3. US-MARC Format for Holdings Data
4. ISO 8459-4 : Information and documentation -- Bibliographic data
element directory -- Part 4: Circulation applications
Tulokseksi on saatu varsin kattavan näköinen lista, jota palvelimen ei tarvitse kokonaisuudessaan lähettää. Palvelin voi lähettää käyttäjän toiveiden mukaan seuraavia valikoimia:
1. BibAndLocations
2. LocationsOnly
3. BibAndSummaryHoldings
4. BibAndDetailedHoldings
5. SummaryHoldingsOnly
6. DetailedHoldingsOnly
7. BibAndSummaryHoldingsAndCirc
8. BibAndDetailedHoldingsAndCirc
9. SummaryHoldingsAndCirc
10. DetailedHoldingsAndCirc
Jos LINDA:n Z-palvelin tukisi OPAC/Holdings -profiilia, se voisi toimittaa vaihtoehdot 1-3 ja 5. LINNEA-kirjastojen näyttöluettelot puolestaan tukisivat vaihtoehtoja 4, 6, 8 ja 10 tai 3, 5, 7 ja 9 riippuen siitä, millä tasolla kausijulkaisun varastotiedot on koodattu. Profiilia tukeva asiakasohjelma osaa avata saapuvan GRS-tietueen, ja tiedot esitetään käyttäjälle "ihmisystävällisessä muodossa". Tämän jälkeen pitäisi sitten olla mahdollista edetä esimerkiksi kaukopalvelutilausten tekoon.
ONE-projektissa havaittiin, että pelkkä bibliografisen datan siirto ei tyydytä käyttäjiä. Myös varasto- ja saatavuustietoja tarvitaan, ja OPAC/Holdings -profiili luo tämäntyyppisten tietojen siirrolle toimivan perustan. Toistaiseksi käytännön sovelluksia on vähän; ensimmäisiä implementoijia ovat Virtuan kaltaiset järjestelmät, joissa Z39.50 on sovelluksen sisäinen kommunikointiprotokolla. Mutta on varmaa, että muitakin hyödyntäjiä tulee, kunhan ZIG saa työnsä lopullisesti valmiiksi.
Lopuksi
Z39.50-standardin kehitys on näennäisesti pysähdyksissä, koska Z39.50 versio 4:n rakentamista ei ole edes kunnolla aloitettu, siitä huolimatta että versio 3 valmistui jo 1995. Yksi selitys hiljaiselolle on se, että useimmat Z39.50-ohjelmistot etenkin USA:ssa eivät ole vielä lähelläkään Z39.50 versio 3:n tasoa. Töitä on tehtävä rapakon takana lujasti, ennen kuin standardiin pitää määritellä uutta kehitettävää. Toinen usein esitettävä ja minusta varsin vakuuttava selitys on, että Z39.50 on nykymuodossaan jo varsin kattava, eikä siitä puutu enää mitään bibliografisen tiedonhaun kannalta oleellista.
Sitä mukaa kun uusia palveluita on ryhdytty toteuttamaan, on käynyt ilmeiseksi että yhteensopivia ohjelmia saadaan aikaan vain antamalla tarkempia ohjeita Z39.50:n implementoimisesta. Tätä tarkoitusta palvelevat sopimukset ja profiilit. Varsinkin jälkimmäisten rooli on kansallisen kirjastoverkon koordinoinnin kannalta hyvin tärkeä, koska niiden avulla voidaan ohjata ohjelmistokehitystä ja luoda edellytykset sille, että eri ohjelmistotalojen tuotteet ovat yhteismitallisia. Linnea-verkon kannalta keskeisimmät profiilit ovat kansallinen Z39.50-yleisprofiilimme sekä yhteisluettelo- ja OPAC/Holdings-profiili.
Juha Hakala, kehittämisjohtaja
Helsingin yliopiston kirjasto
Email:
Juha.Hakala@helsinki.fi
Tietolinja 2/1998
|
