Filtrering udfra transaktionsdata
I Artesis brønd skal vi til at starte op på en release som skal gøre brønden i stand til at filtrere på data fra udlånsystemet. For at kunne gøre dette skal brøndens poster beriges med lokaliseringsdata, såsom hyldeliste, filialer osv. Men også data der fortæller om der for en given post er materialer hjemme eller ej.
Data som vi samlet kalder transaktionsdata.
Transaktionsdata er kendetegnet ved at de har en eller anden grad af flygtighed over sig. Nogle biblioteker benytter sig af flydende bogbestand. Dette betyder at lokaliseringsdata for en post ændrer sig hen over en dag. Det samme er naturligvis tilfældet med om et materiale er hjemme eller ej.
Der er derfor en udfordring i at kunne holde brønden opdateret med disse data. Men det afhænger også af hvilke krav/forventninger I som bruger har til systemet.
Jeg ser derfor to mulige veje vi kan gå:
1) Såfremt at vi skal holde disse data opdateret i noget der ligner realtid, er det nødvendigt, at det er lokalsystemet, der giver brønden besked om ændringer. Dvs at ved udlån/aflevering/materialeflytninger sendes der beskeder via webservices til brønden om at der for en given post er sket de førnævnte ændringer.
2) Såfremt at det kan accepteres, at der er en forsinkelse i, at disse data bliver tilgængelig i brønden, kan vi nøjes med en løbende eksport henover en dag. Dvs at lokalsystemet med f.eks. 1-2 timers interval eksporterer transaktionsdata til brønden.
For begge løsninger har vi tænkt os at opfinde et letvægtsformat til eksportere/modtage data i. Der er altså ikke nogen af løsningerne der handler om eksport/modtagelse af marc-poster.
Jeg brug for at vide følgende:
- Hvad der er en acceptabel forsinkelse på transaktionsdata?
- Hvilken løsning er reelt muligt i lokalsystemerne?
- Findes der andre muligheder for at holde transaktionsdata opdateret end de 2 nævnte?
- Hvilke data er der egentlig tale om?
Ideer og kommentarer skal være afgivet inden 1.6.2011.
Med venlig hilsen
Kurt Poulsen,
Projektleder for Artesis Brønd,
DBC
Kommentarer
Vedr. Filtrering på transaktionsdata
Før det første synes jeg at der er en rigtig god idé at åbne op for muligheden for at filtrere på transaktionsdata. Det giver mulighed for at lave nogle rigtige gode søgemuligheder. Umiddelbart synes jeg der er to scenarier hvor man kan bruge transaktionsdata.
1. Hvor man bruger den viden som ligger i vores beholdningsoplysninger til at forfine søgningen. Det kunne f.eks være at man brugte vores opdeling i børn og voksen afdeling til at styre facetten voksen / børn i facetbrowseren. Disse oplysninger er hos os ret statiske og kræver ikke mere end en opdatering i døgnet.
2. Mulighed for at afgrænse søgningen til en filial og til bøger som er hjemme på den filial. F.eks at man kunne søge efter krimier som er hjemme lige nu på mit lokale bibliotek. Her skal systemet helst være ret nøjagtigt. Hvis brugeren oplever gang på gang at søge på noget som skulle være hjemme og det ikke er det alligevel så bliver oplevelsen med denne feature negativ og kræver tid hos personalet som skal forklare og hjælpe brugeren. Realtime ville være det perfekte men jeg har ikke kendskab til at sådan feature hos DDELibra. Mit bud ville være at 30 - 60 minuters forsinkelse er acceptabelt. Det vil ofte være de samme materialer som man søger på den måde f.eks ferielitteratur lige op til sommerferien.
PS. Hvis det ender med at man samler ind data om udlån fra rigtigt mange biblioteker så kunne man bruge dem til rankering af søgeresultater. F.eks hvis en bog bliver udlån meget på mange biblioteker så kommer den højere op i søgeresultatet. Sådan system kunne være meget tidsfølsomt så hvis der et emne som er op i tiden så rankerer det højt og når interessen er væk så rankerer det lavt igen.
vedr: filtrering på transaktionsdata
Tak for inputtet.
1) Det er helt rigtigt at den opstilling der står i lokalsystemets beholding er mere rigtig end den vi kan skønne os til ved data manipulering fra posterne
2) Nu er der jo nogle biblioteker der har flydende materialebestand og derfor skifter materialernes placering hele tiden. Er det også ok med en 30 - 60 minutters forsinkelse på denne?
Hvordan ser du mulighederne for at I selv laver en form for opdatering af brøndens data? Er det f.eks. muligt at lave et script der med et bestemt tidsinterval henter data ud fra lokalsystemet og sender dem til en webservice på DBC? Eller er det kun muligt at lave et fil-opload af data som det sker med posterne?
Rankering på antal udlån står helt klart på vores ønskeliste også, men jeg vil ikke love at vi når så langt i denne omgang. Men en spændende mulighed er det helt klart.
vedr: filtrering på transaktionsdata
Vi har flydende bestand her på Randers Bibliotek. Et materiale skifter i mellem en filial til en anden i afleveringsøjeblikket. Min tanke omkring de 30-60 minuter var at der går alligevel en lille stykke tid fra at en bog er blevet kørt ind i vores afleveringsautomat til den er kommet ud på en vogn i udlånet og derefter op på hylden. Dvs. der er alligevel en forsinkelse i forhold til at bogen er til rådighed for låneren så derfor kan 30-60 minuter accepteres. Der går så også lidt tid fra en bog bliver udlånt til den ikke optræder på søgeresultatet over materialer som burde være hjemme, men det forekommer jo også i dag hvis nogen har taget en bog ned fra hylden men ikke lånt den ud endnu.
I forhold måden en opdatering foregår så er det nok Axiell som skal komme med et bud på en løsning. Vi har selvfølgeligt muligheden for at køre vores eksport af poster oftere end tilfældet er i dag. En anden mulighed er at bruge den webservice (Alma) som vi bruger til at få fat i beholdningsdata på hjemmesiden. Der kan vi fat alle de data (opstilling, udlånt, osv) som der er behov for. Problemet er at der mangler en metode til at vide at det er de her specifike 500 poster som er blevet ændret i den sidste time så vi ikke skal igennem alle 180.000 poster hver gang.
vedr: filtrering på transaktionsdata
Så en forsinkelse på 30-60 minutter er en acceptabel forsinkelse. Det er noteret.
Vi vil ikke modtage bibliografiske poster for at kunne håndtere filtrering. Det skal leveres i et meget mindre og mere let tilgængelig format såsom et kort XML-format lavet til lejligheden
Så vi kommer ikke uden om at I/vi skal have Axiell på banen for at udvikle et script/program der løbende udtrækker hvad der er udlånt/afleveret siden sidste udtræk for at så sende det til os. Det er lidt ærgeligt. Men det må vi finde en løsning på.
Tak for dit input. Skulle du få en god ide til hvordan udtrækket kan løses så sig endelig til.
vedr: filtrering på transaktionsdata
Et uddybende spørgsmål:
Når der maks må gå 30 minutter fra bogen er afleveret/udlånt til det slår igennem på brønden, så må det betyde at biblioteket skal oploade data til os tiere end for hvert 30. minut for at vi kan sikre at data er søgbare inden de 30 minutter er gået?
Et tænkt eksempel kunne være:
Randers bibliotek sender transaktionern til DBC hver 15. minut, hvorefter DBC sørger for at de er tilgængeligt senest 15. minutter derefter?
Er det korrekt?
Et andet spørgsmål:
Hvor mange udlånstransaktioner pr. time har Randers bibliotek når det stærkest?
vedr: filtrering på transaktionsdata
Ja det er rigtigt forstået. Når jeg siger 30-60 minuter så er det den samlede forsinkelse. Frekvensen hos villes afhænge af hvor hurtigigt i kan håndtere de tilsendte data.
I normal driftsituation så er max transaktioner per time 500 udlån og 500 aflevereringer. Der kan være specialtilfælde,(første dag efter påske, Kulturhusdag og andre lignende dage) hvor det er højere måske op 1000 udlån/afleveringer per time.
vedr: filtrering på transaktionsdata
Ok. Tak for opklaringen