Detta inlägg är gammalt och kan innehålla inaktuell information.
Kommentaren du söker har flyttats till en ny diskussion, eller är borttagen.

Felaktigt konstruerat 035

Förra veckan upptäckte vi att vi fått ett felaktigt konverterat 035 vid manuell import från XL. Det har blivit en sammanslagning av OCLC och XL:s alfanumeriska id i 035 antagligen därför att posten innehåller ett 003 med OCLC. Posten inporterade till XL via remote.

Det gäller bibid: w4qx4d40thlk3c7x
Konstruktion ser ut enligt nedan.
035
_a(OCoLC)w4qx4d40thlk3c7x



Isabel Folkesson, GUB Rapportera olämpligt innehåll

Kommentarer

  • Hej Isabel och tack för att du påpekade detta. Felet är anmält och taget vidare till utvecklarna.

    Vänliga hälsningar
    Katalogsupport
  • Detta är ett  allvarligt fel som behöver åtgärdas omgående. Vi undersöker nu hur många av de poster som vi tagit över från XL som har samma fel. Återkom gärna till oss med besked snarast.
    Isabel Folkesson, GUB
  • Hej!

    Vi kommer att behöver ytterligare uppgifter från dig för att kunna verifiera var felet uppstår. Vi kontaktar dig direkt för vidare detaljer.

    Hälsar,

    Maia Dexander Införandeaktiviteter
  • Vad är det för uppgifter ni behöver? Vi har hittat 10 likadana hittills i vår lokala katalog och det finns säkert fler! Det som kännetecknar dem är ett de har OCLC i 003 i XL. Det borde vara lätt för er att söka fram?
    Isabel Folkesson, GUB
  • Felet uppstår för att LibrisXL felaktigt lägger in två 003-fält i posten.

    När de olika systemen (i vårt fall Koha) vid import skapar ett 035a utifrån 003 + 001 så används första påträffade 003, eftersom man inte förväntat sej att det ska finnas fler än ett sådant fält.

    Så om man gör sin dubblettkontroll mot 035a
    och man redan har en post med 035 a (SE-LIBR)12345
    och inkommande post felaktigt har 035 a (OCLC)12345
    Då blir resultatet att dubblettkontrollen inte fungerar och man får in denna post som en ny post.

    Leif Andersson, SUB

    Leif Andersson
  • Hej!

    Vi har försökt att återskapa buggen genom att undersöka Download Compiled MARC, Förhandsgranska MARC samt JSON/Turtle i gränssnittet. Vi reflekterar över att ni har båda Koha som lokalt system.

    Vi tolkar arbetsflödet som att ni har importerat poster via andra källor, och sedan berikat och uppdaterat dem. Efter det har ni hämtat hem posten med Download Compiled MARC.

    Vi fortsätter undersöka problemet.

    Hälsar,
    Maia Dexander Införandeaktiviteter
  • Du kan t ex ta fram posten
    https://libris.kb.se/katalogisering/w4q5clljtjfcmr67#it

    Förhandsgranska MARC21,
    då ser du ett 003 OCoLC

    Download Compiled MARC21
    Titta på den nedladdade filen med lämpligt redskap
    Då ser du två 003-fält
    003 OCoLC
    003 SE-LIBR

    Det är det som är problemet
    003 är inte upprepningsbart, eftersom det fältet ska ange källan till systemnumret i 001
    Leif Andersson, SUB
  • Vi har nu testat vidare och kan identifiera samma problem.
    Tack för förtydligandet!

    Hälsar,

    Maia Dexander Införandeaktiviteter
  • Tack Leif för att du hjälper till att förklara vad problemet är!:-)

    Nu provade jag att hämta ner en post från GBV och samma fel uppstår! Ett 003 med DE-601  ligger i posten och vid övertaget får vi en post med ett felaktigt konstruerat 035 enligt nedan.

    035_a(DE-601)w4r06svzt84ddqxf

    NI verkar inte rikttigt förstå hur allvarligt felet är. Borde inte ni informera om detta så att inte fler korrupta poster skapas?
    Vad kommer ni att göra med de poster som tagits över till XL hittills? Alla poster som fått felaktiga systemid måste ju åtgärdas och det är knappast bara Kohabibliotek som kommer att drabbas av det.
    Isabel Folkesson, GUB
  • Hej Isabel,

    Jag hade precis samma fel för en stund sedan. Det gällde http://libris.kb.se/bib/22364059

    Denna post hade dubblerad information (i vissa fall fyrfaldig) och när jag hade fixat till posten och importerat den till Koha fanns det två SE-LIBR  i 003. Jag gick tillbaka till XL och tog bort fältet "Systemnamn", som ligger under "Adminmetadata". När jag importerade posten på nytt efter detta fanns bara ett 003-fält i Koha.
    Anna Björnberg
  • Hej,
    så bra Anna för att du fann ett sätt att jobba runt!

    Det stämmer att problemet gäller även andra källor än OCLC/Worldcat. Vi hanterar frågan som en högprioriterad bugg, men kommer inte att lägga ut någon rättning före midsommar.

    med vänlig hälsning

    Bodil Wennerlund Projektledare nya Libris
  • Men ni förstår att alla de poster som redan tagits över till våra lokala system kommer att generera dubbletter när ni korrigerar felet i 003 om posterna uppdateras eller tas över på nytt? Ni tycker inte att ni borde informera andra bibliotek om problemet så att de kan begränsa skadorna i den egna katalogen?
    Isabel Folkesson, GUB
  • Hej,
    ja vi har full förståelse för att dubbletter skapar problem för er.

    Vi har lagt information om detta som ett känt fel på driftinformationssidan http://kb.se/libris/Om-Libris/Driftinformation/ och jobbar vidare på en rättning av buggen.

    mvh

    Bodil Wennerlund Projektledare nya Libris
  • Bra! Vi behöver en lista från er, med bibid över de poster som fått felaktiga 003 för alla våra sigler så att vi kan åtgärda dessa lokalt. När ni skriver att ni kommer att rätta buggen, kommer ni både att åtgärda att felet uppstår vid övertaget från annan källa och åtgärda de poster som redan fått felaktiga 003?
    Isabel Folkesson, GUB
  • Hej,
    buggen som skapade defekta data vid konvertering till Marc 035 #a är nu rättad. Den uppstår inte längre vid import från Andra källor, till exempel OCLC/Worldcat.

    Prova gärna!

    mvh

    Bodil Wennerlund Projektledare nya Libris
  • Jag har nu testat med två poster, en från GBV och en från OCLC. Det ser rätt ut i konverteringen men systemnamn(003) ligger kvar i XL, skall det verkligen göra det? Borde inte annat systemnamn tas bort redan i XL?

    Som jag skrev i förra inlägget behöver vi också en lista med bibid över alla poster med våra sigler och med annat systemnamn än LIBRIS för perioden XL varit igång. De poster som redan tagits över kommer att orsaka dubbletter så snart de uppdateras.

    När jag testade tog jag över en post som jag varken kan redigera, lägga bestånd på eller radera i XL. Vad beror detta på? Det är en testpost så den skall inte sparas.Kontrollnummer  7g31mqgd5zvxvb4l


    Isabel Folkesson, GUB
  • Hej,
    vi undersöker och återkommer om detta.

    mvh
    Bodil Wennerlund Projektledare nya Libris
  • Hej Isabel,

    vi har försökt att återskapa problemet med att det inte går att redigera eller spara förändringar i posten, utan att lyckas. Posten är däremot väldigt stor och tar en stund att ladda upp, kan det vara så att uppladdningen inte var helt färdig innan du försökte göra förändringar?

    Vänliga hälsningar,
    Anna Berggren Produktägare och Libris-koordinator
  • Isabel,

    Jag vet inte om det är bästa sättet, men det är ett sätt iallafall, att ta fram poster som kan behöva åtgärdas pga den här buggen. Ett sätt - om man kör Koha vill säga.

    Be din systembibliotekarie eller motsvarande att köra följande SQL:

    SELECT biblionumber,
           ExtractValue(marcxml, '//datafield[@tag="035"]/subfield[@code="a"]') AS f035a
      FROM biblioitems
     where ExtractValue(marcxml, 'count(//controlfield[@tag="003"])') > 1
       and DATE(timestamp) >= '2018-06-11'

    Det tar fram biblionumber  med samtliga postens fält 035 delfält a i poster som skapats/redigeras (i Koha) på eller efter 2018-06-11 och där det förekommer fler än ett 003-fält.
    Biblionumber kan du använda för att söka fram posten i Kohas personalgränssnitt för redigering.
    Frågan tar några minuter att köra, så lämpligt är att köra den när systemet inte är belastat.

    Här är en handfull av dom första raderna som frågan returnerade när jag körde den här på SUB
       
       biblionumber    f035a
    1065100    (Uk)7g28hv215f3hxbrh (Uk)017861875
    1065110    (LIBRIS)x5rzpcl6vhmhvh45 (OCoLC)ocn983697873
    1065113    (OCoLC)5d09m78s3vfl5dvz (OCoLC)on1016771449
    1065119    (OCoLC)v3p0pkvhs576l33j (OCoLC)on1038240286
    1065122    (OCoLC)ltfqgs7sj3l5169r (OCoLC)ocn834125390
    1065124    (OCoLC)z6s40j52wwsj41hb (OCoLC)on1022075436
    1065127    (OCoLC)9j4gf8qd7rr9cg33 (OCoLC)ocn167770721
    1065131    (OCoLC)07t58jgkxhkw27sv (OCoLC)ocn987796391
    1065132    (OCoLC)5d0bf01q3s50m587 (OCoLC)ocn986816638
    1065135    (OCoLC)hqbnwrbvfk40z0pb (OCoLC)ocn991298907
    1065137    (OCoLC)w4q2dx0stmbjtxzw (OCoLC)ocn182736118
    1065138    (OCoLC)9j4kmx6b7vvtpm3l (OCoLC)ocn928407462
    1065140    (OCoLC)w4q5clljtjfcmr67 (OCoLC)ocn757805118
    1065146    (OCoLC)8h30hzn763fhnlzd (OCoLC)on1037275264
    1065148    (OCoLC)ltfbw7p0jlj2t8zt (OCoLC)ocn802322484
    1065160    (OCoLC)cl632kpv9rhc8nbr (OCoLC)on1023801031
    1065162    (OCoLC)x5rnmjsbvq8lgrb4 (OCoLC)ocn766386274
    1065163    (LIBRIS)21811377 (BOKR)9789173895781

    Dom rader där LIBRIS förekommer först är korrekta.
    Dom andra måste justeras.
    Det faktum att det också förekommer mer än ett 035a kan behöva åtgärdas så att man har endast ett 035 a och resten 035 9


    Leif Andersson, SUB
  • Jag har nu hittat en post i den lokala katalogen som inte finns kvar i Libris, och det verkar vara just den typ av post som den här tråden handlar om, alltså en OCLC-import som har 035 #a (OCoLC)ksfjtfbthszrss5b.



    Posten skapades 180620, alltså mellan driftstoppet 14-15/6 och den tidpunkt då problemet uppgavs vara fixat, 26/6. Vad hände med dessa felkonstruerade poster? Togs de bort? Och hur ska vi åtgärda dessa?

    Jag kan givetvis importera eller konstruera en ny post och länka om vår lokala post till den nyskapade posten i Libris. Men det vore bra att informeras om vad som har hänt, vad som ska och behöver göras och vilka poster det är som har tagits bort.

    Mårten Bohman, GUB
  • Hej!

    Information om vad som har hänt och åtgärder kring detta kommer inom kort.

    Mvh
    Libris kundservice

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.