Hej
I forbindelse med udvikling af vores kommende ding2 side, har vi opdaget, at man ikke kan benytte CCL-søgning (som vi har været vant til), men at man skal bruge søgekoder baseret på Dublin Core formatet.
Findes der mon en liste over Dublin Core søgekoder?
Kommentarer
Søgekoder
Et sted af starte er her: http://oss.dbc.dk/plone/services/open-search. Under overskriften DKABM er der en liste over de indekser som er muligt at søge i. f.eks dc:title. I listen har indekserne følgende syntaks prefic:indeksnavn (f.eks dc:title) men når de bruges i en søgning skal syntaksen være følgende: prefix.indeksnavn=søgeord f.eks dc.title=java eller dc.date=2010. Her har vi prøvet at forklare det her til lånerne: https://www.randersbib.dk/vejledninger/soegning/avanceret-soegning . Hvis man bruger operatorerne OR eller NOT i sin søgning skal det være med stort.
Beholdning søgekode
Tak for de gode svar! Vi er vant til i CCL at kunne afgrænse til beholdning (bh=). Men det er ikke lykkedes mig at opsuse en tilsvarende DC søgekode. Findes det?
Biblioteksspecifikke
Biblioteksspecifikke beholdningsoplysninger er ikke indexeret i brønden - dermed findes der er ingen dublic core "søgekode" :)
Søgesyntax
Det er en god start, og vi har fundet tilsvarende dokumentation andre steder.
Er der en notation for rankering f.eks. mht. udgivelsesdato? Lige nu benytter vi lidt upraktisk en URL variabel istedet for DC syntax.
Og hvad gør vi med de fejlbehæftede emner i brønden som har dc.date i fremtiden eller = ??? og tilsvarende fejl?
Vi ville meget gerne kunne trække de nyeste emner ud i forskellige lister med pga fejl i brønden er vi lige nu nødsaget til dc.date = 2012, og det er jo ikke ligeså sjovt.
Fejlbehæftede emner
Jeg kan nok ikke hjælpe med rankering, men vil gerne have nogle eksempler på emner, som har fejl i dc.date ?
brønd fejl
Hvis jeg f.eks. søger dc.type = bog og rankerer efter date_descending er der materialer med fejl:
http://www.server003.b14cms.dk/users/fkb.dk/persding2/da/search/ting/dc.type%3Dbog?sort=date_descending
Det gælder også andre facetter.
Rankering på udgivelsesdato
Rankering er eget felt i Opensearch (f.eks <ns1:sort>date_descending</ns1:sort>) så man kan ikke bruge querystrengen direkte til sortering. Hvis I gerne vil hente materiale sorteret på udgivelsesdato så tilføjer I en værdi i sort feltet i forespørgslen til Opensearch. F.eks kan man bruge date_descending for at sortere på årstal med de nyeste først. Det er en meget grov sortering fordi alle materialer fra f.eks 2012 får den samme sortering dvs. at materiale som kom i januar kan komme før noget som er lige kommet i august.
Når det gælder bibliotekets egne materialer har man mulighed for at sortere precist på anskaffelsedato ved at bruge værdien "acquisitionDate_descending" i sorteringfeltet . Det kræver dog at man indberetter accessiondatoen via felt 096 i katalogposten når man indberetter sine poster til DBC via toting scriptet. Det er ikke sat som default man kan indstilles.
brug af værdien i acquisitionDate
Ved du om jeg kan trække værdien i ”acquisitionDate” ind i et Drupal site eller det kun til sorteringsbrug?
acquisitionDate
Datoen ”acquisitionDate” kan hentes fra brønden ved at bruge MarcExchange formatet men det vil nok ikke give nogen mening for ereolen. Værdien på ”acquisitionDate” hentes fra felt 096 delfelt t i danmarc2 formatet og dækker over den dato hvor biblioteket fik det første fysiske (beholdningsregistrerede) eksemplar af et materiale. Derfor har elektroniske materialer som ebøger ikke nogen accessiondato.
Der findes et felt 001 delfelt d i marc poster for katalogiseringsdato (eller delfelt c for sidste ændring af posten) og det kunne man godt bruge for digitale materialer. Dvs. at man kan lave en liste over ebøger på ereolen som er blevet katalogiseret indenfor de sidste 2 måneder dvs. er nye. For at det kan lade sig gøre skal vi have DBC til at give mulighed for at sortere på katalogiseringsdato. Så kan vi lave nyhedslister på digitalt materiale.
first published dato i 096*t
For ereolens og netlydbogs vedkommende kan jeg oplyse, at poster fra disse kilder også rummer marcXchange, og tilmed også har indhold i felt 096, delfelt t. Værdien i dette felt kommer fra Publizon, og udgør den dato, som ebogen/netlydbogen første gang er udgivet via Publizon.
Feltet er derfor også for de to kilders vedkommende søgbart via "sort.acquisitionDate", og kan til visning hentes ud fra marcXchange.
Sortering
Glimrende. Så her finder vi fkb's nyligt indkøbte bøger, hvoraf en er en gammel sag:
http://www.server003.b14cms.dk/users/fkb.dk/persding2/da/search/ting/dc.type%3Dbog?sort=acquisitionDate_descending
Ang. querystrengen, så må vi finde en workaround. På fkb arbjeder vi med landingpages for alle emneord. Og hvert emneord kan have sin egen søgestreng som trækker materialer op af brønden. Det ville være smukt om rankering også kunne indgå i denne streng.
Hvis der er planer om en kommende søgesyntax mht. rankering så tilpasser vi gerne til den. Og indtil da kunne vi forsøge med følgende løsning hvor vi laver regex match på dc.rank=* og overfører matchet til URL variablen
Eksempel på søgestreng:
dc.type=bog dc.rank=acquisitionDate_descending
Bliver parset til noget a la
search/ting/dc.type%3Dbog?sort=acquisitionDate_descending
Accessionsdato
Accessionsdatoen er den dato vi modtager et fysiskt eksemplar klar til udlån på biblioteket. Hvis vi køber en gammel bog for den første gang så kommer den også med på listen.
I forhold til parse søgestrengen så er det i hele taget en god idé. Vi burde skåne vores lånere for syntaks som dc.language=tysk og stedet give mulighed for et simpel søgesprog som f.eks sprog=tysk. Så kunne dit eksempel blive til type=bog og sortering=anskaffelsesdato.
Next step
Det er også en god idé, men det introducerer en helt ny og tredie syntax for søgning, så det tror jeg skal vendes mere overordnet om alle er interesseret i det.
dc.date er udgivelsesdato
dc.date er udgivelsesdato (fra forlag), indexeret i brønden.
dc.date
dc.date er mig bekendt kun udgivelsesår
Ja, år - det jeg mener er, at
Ja, år - det jeg mener er, at det ingenting har med bibliotekets beholdning at gøre :)
Brugervejledning på bibliotek.kk.dk
København har lavet en vejledning til avanceret søgning til brugeren.
Den ligger på http://bibliotek.kk.dk/biblioteker/blog/avanceret-soegning
Det er vel meningen at
Det er vel meningen at brugeren overhovedet ikke skal se al den slags ... tanken bag var at kombinere google's nemhed med CCL's styrke ... se fx http://zing.z3950.org/cql/intro.html ... i sidste ende er det udviklerens ansvar at give den bedst mulige oplevelse med [søge]systemet ... det skulle ikke være umuligt :)
Forskellige scenarier
Låneren på biblioteket vil selvfølgelig aldrig skulle forholde sig til CCL. De benytter et søgefelt (som tilfældigvis også forstår CCL) og indskrænker søgningen via afkrydsning af facetter i et grafisk interface.
Men der er intet simpelt grafisk interface som giver den fulde kraft af CCL. Og hvis en bibliotekar eller anden bruger af backenden (eller en låner der kender CCL) ønsker at præsentere et særligt specifikt udtræk af brønden, så kommer CLL på banen.
De fleste udtræk kan man håndtere med søgeord og et par klik i facetter.
Men eksempelvis så snart to boolske operatorer kommer i spil skal man i CLL:
(dc.type="bog" OR dc.type="avisartikel") AND (dc.subject="jazz" AND dc.subject="rock")
Meningen med at give brugere af backend mulighed for CCL er i sidste ende at præsentere lånerne for de bedst mulige relevante forslag.
Jeg antager at du mener CQL
Jeg antager at du mener CQL og ikke CCL :)
Jeg håber tanken er at vi har ét søge-felt hvor (uanset brugerens behold (simpelt eller avanceret)) man vil kunne udtrykke/søge intuitivt og det derfor i sidste ende vil der for brugeren ikke være nogen forskel i mellem de to (simpel/avanceret) :P
Jaja, der er stadig arbejde foran os :)
CQL CQL CQL
Ah ja tak. CQL var det jeg mente.
Og ja, der er bare et tekstfelt for brugeren. Som assisteres af afkrydsningsfelter i facet modulet.
Vi overvejer desuden en mere tekstbaseret beskrivelse af søgningen som forklarer brugeren hvilke filtre der evt. er aktive i den pågældende søgning.