Project

General

Profile

Enhancement #3265

Afgræns søgeresultat til et interval af år som erstatning for date facetgruppen

Added by Christel Krabbenhøft about 2 years ago. Updated 4 months ago.

Status:
DBC (waiting)
Priority:
High
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Søgning - Søgeresultat - hjemmeside, Biblioteksinfo - Sidefod

Description

Scenarie: Bruger søger nyere værk af en specifik forfatter, er usikker på udgivelsesåret, og ønsker derfor at afgrænse søgeresultatet til et interval af år (lige nu er det kun muligt at vælge et enkelt udgivelsesår). Mulig løsning: Slider eller lign. der giver brugeren mulighed for at vælge flere udgivelsesår.

History

#1 Updated by Rolf Madsen about 2 years ago

  • Subject changed from Afgræns søgeresultat til et interval af år to Afgræns søgeresultat til et interval af år som erstatning for date facetgruppen

#2 Updated by Rasmus Høymann Laursen about 2 years ago

  • Assignee changed from Rasmus Høymann Laursen to Philip Birk-Jensen

#3 Updated by Gitte Barlach about 2 years ago

Jeg vil foreslå vi tager en drøftelse af flg. forslag:

at gøre det muligt for brugeren at vælge flere facetter til i første hug. Dette bør være en AND søgning. Flere valg indenfor samme facetgruppe bør være en OR søgning

#4 Updated by Rolf Madsen about 2 years ago

Jeg har forestillet mig noget ala:

#5 Updated by Philip Birk-Jensen about 2 years ago

  • Assignee changed from Philip Birk-Jensen to Steen Holten-Andersen

#6 Updated by Philip Birk-Jensen about 2 years ago

  • Status changed from Ready for development to Needs code review
  • Assignee changed from Steen Holten-Andersen to Gitte Barlach

#7 Updated by Gitte Barlach almost 2 years ago

  • Assignee changed from Gitte Barlach to Jesper Kristensen

#8 Updated by Jesper Kristensen almost 2 years ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Jesper Kristensen to Philip Birk-Jensen

Dette skal tilpasse SAL.

Det at man tigger en ekstra søgning, for at lave en range vælger forstår jeg ikke helt. Hvis vi har et søge resultat, hvor jeg antager denne dims skal vises. Så har vi alt den data vi skal bruge via ting_search_current_results() som indholder både sidste search request og resultater.

Der til kommer det at https://github.com/ding2/ding2/pull/1075 forsøger er fjerne så mange søgninger som muligt.

#9 Updated by Simon Holt almost 2 years ago

En anden ting med denne løsning: Er ikke sikker på det er kombatibelt med feltsøgning. Altså hvis man vælger at bruge facetten på en søgeprofil, viser den stadig den gamle version med checkboxe.

Vil gerne lave det, men ville være rart, hvis der er tænkt på det i PR.

#10 Updated by Philip Birk-Jensen over 1 year ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Philip Birk-Jensen to Gitte Barlach

Nyt PR: https://github.com/ding2/ding2/pull/1123

@Simon har implementeret de ti ting_field_search, og det ser ud til at virke.
Jeg er dog lidt i tvivl om der er noget jeg har misset, det ligner at ting_field_search_form_ding_facetbrowser_form_alter gør mange af de samme ting som ding_facetbrowser_form allerede gør, jeg er derfor lidt usikker på om den del der springer over ved field.date gør andet der er kritisk for resultatet?

@Jesper Det resultat vi allerede har indeholder kun data fundet inden for intervallet, derfor vil facets også kun være inden for intervallet. Dette gør vi ikke kan bygge det ydre interval op, uden at foretage en søgning, hvor der ikke filtreres på facet.date.

#11 Updated by Gitte Barlach over 1 year ago

  • Assignee changed from Gitte Barlach to Jesper Kristensen

#12 Updated by Jesper Kristensen over 1 year ago

  • Status changed from Needs code review to Need more info
  • Assignee changed from Jesper Kristensen to Gitte Barlach

Jeg vil meget gerne lige vend denne med resten af core, da den laver om i forskellige lag som vil påvirke andre projekter på ved ind.

 

Dertil kommer det at der vil blive lavet ekstra søgninger i et allerede presset system på performance fronten...

#13 Updated by Gitte Barlach over 1 year ago

  • Status changed from Need more info to Needs code review
  • Assignee changed from Gitte Barlach to Kasper Garnæs

#14 Updated by Kasper Garnæs over 1 year ago

  • Status changed from Needs code review to Ready for development
  • Assignee changed from Kasper Garnæs to Philip Birk-Jensen

Jeg er enig med Jesper i at det er uhensigtsmæssigt at der bliver foretaget en søgning til. Jeg er også enig med Philip i at vi har brug for den data, som den ekstra søgning giver os.

Jeg er kommet med et alternativt løsningsforslag i pull requestet: https://github.com/ding2/ding2/pull/1123/files#r209749602.

Bemærk også at dette ændrer i vores søgeabstraktionslag for at tillade range filters.

#15 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Kasper Garnæs

Har kommenteret på github

#16 Updated by Gitte Barlach over 1 year ago

  • Status changed from Ready for development to Needs code review

#17 Updated by Gitte Barlach over 1 year ago

  • Priority changed from Normal to High

#18 Updated by Christel Krabbenhøft over 1 year ago

  • Priority changed from High to Normal

#19 Updated by Kasper Garnæs over 1 year ago

Jeg har tænkt løsningen igennem i forhold til at undgå den ekstra søgning, som bliver foretaget i det nuværende PR.

Jeg har følgende alternative løsningsforslag:

  1. Det originale interval gemmes søgeparametrene i url'en på linie med de nuværende værdier. Hvis disse ikke er sat (fx. ved den initielle søgning) baseres intervallet udelukkende på søgeresultatet.
    Bemærk: I det nuværende PR viser intervallet også en angivelse af hvor mange resultater der kan forventes (se screenshot). Antal resultater opdateres i browseren når intervallet ændres. Data til at understøtte dette er ikke hensigtsmæssigt at opbevare som URL parametre. Derfor foreslår jeg at denne del af intervallet droppes. Det fremgår heller ikke af Rolfs forslag i kommentar 4.
  2. De originale intervaller gemmes i cachen som så kan benyttes efterfølgende til at hente ud fra. Det er dog ærgeligt at skulle benytte cache til at simulere tilstand.

Et par andre observationer til de næste der skal arbejde med dette:

  1. Intervallet ser ikke helt rigtigt ud i min browser (Firefox/OSX). Jeg havde umiddelbart forventet at den fyldte mere i bredden.
  2. Nogle årstalstermer er ikke reelle tal og passer derfor dårligt ind. Jeg har fx. set 199? (se screenshot).

#20 Updated by Rolf Madsen over 1 year ago

NB. Det lader til at det observerede "199?" er en fejl i datagrundlaget:

<facetTerm>
   <frequence>2113</frequence>
   <term>199?</term>
</facetTerm>

#21 Updated by Rolf Madsen over 1 year ago

  • Status changed from Ready for development to Reviewed - Needs info/rework
  • Assignee changed from Gitte Barlach to Philip Birk-Jensen
  • Target version changed from Release 29-2 - Bugfixes (B14) to Release 30 - Søgegrænseflade

#23 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Gitte Barlach

Jeg har prøvet at søge på krimi og på danmark, men jeg får ikke nogen årstal med "?" i. Kan dette være blevet fixet allerede?

Med hensyn til bredden ikke ser helt korrekt ud, så er det formentlig fordi scss ikke er blevet kompileret, og color efterfølgende opdateret, min ser nemlig sådan ud når css ikke er opdateret.

 

Hvis vi skal undgå det ekstra kald der kommer når man har filtretet på årstal, ville jeg foreslå cache løsningen, så vi kunne beholde antal resultater (som alle de andre filtrer også har).
Men hvis vi går med query parameter løsningen, ville jeg mene vi lige så godt kunne gemme antalet sammen med årstallet. Det ville give en del mere data i URLen, men det ville de enkelte årstal allerede.

Lad mig hører hvilken løsning vi ønsker, så giver jeg det et bud.

#24 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Gitte Barlach to Philip Birk-Jensen

Prøv bare at søge på term.date=200? også fold facet.date facetgruppen ud.

#25 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

#26 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen

Det er et spørgsmål om opsætning.

Dit miljø skal konfigureres med agency 100200 profile ting.

https://vanilla-fbs.ddbcms.dk/search/ting/term.date%3D200%3F?

#27 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

Når jeg ændrer min library code til 100200 får jeg ingen søgeresultater længere.

Kan jeg få en komplet liste over hvad mine indstillinger skal være?

#28 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen

Her er et komplet eksempel fra test servicen hvor du kan se 57 eksempler på årstal der indeholder "?".

https://oss-services.dbc.dk/opensearch/5.0/?action=search&query=%22*%22&agency=100200&facetName=facet.date&numberOfTerms=1000&profile=test&start=0&stepValue=0

#29 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

Jeg fik 100200  til at virke, og har nu fået resultater med ?
Har opdateret PR (https://github.com/ding2/ding2/pull/1123).

Det er nu lavet så den ignorere de år der indeholder ?, det har heller ikke lykkedes mig, at finde et materiale der bliver vist med et ? i deres år, så de bliver måske sorteret fra når der søges på facet.date?
Jeg føler dette er den bedste løsning på nuværende tidspunkt, men hvis der er en specifikation på hvordan disse bliver, kan vi få dem kodet ind, jeg har bare ikike kunne finde en rød tråd.

Vi mangler stadig en beslutning på hvordan det dobbeltekald skal håndteres (når der ikke ændres på facetterne).

#30 Updated by Rolf Madsen over 1 year ago

Jeg har fået et hurtigt svar fra Bodil på DBC. :-)

***

Det er helt utroligt, hvilke informationer, man kan få i danAMRC2-formatet ;-)

http://www.kat-format.dk/danMARC2/Danmarc2.9.htm#pgfId=1574258

Delfelt *a Udgivelsesår

Delfelt *a er obligatorisk i bibliografiske poster på katalogiseringsniveau '0' eller '1' i felt 008 *v. I flerpoststrukturer er delfeltet dog kun obligatorisk på ét niveau: i hovedposten eller i sektions- eller bindposterne.

I delfelt *a inddateres 4 cifre for årstal.

Hvis udgivelsesåret er ukendt, er der to inddateringsmuligheder:

  • ukendte årstalscifre kan inddateres som ?
  • årstal, der angiver det interval, inden for hvilket materialet anses for udkommet, kan inddateres i delfelt *a og *z. I dette tilfælde skal statuskoden være '?' i delfelt *u.

Delfelt *z Efterfølgende udgivelsesår

Et interval mellem to årstal kan gengives ved brug af et delfelt *a og et delfelt *z. Årstallene skal inddateres i kronologisk rækkefølge.

Delfeltet *a, henholdsvis *z, svarer til årstal i publiceringsafsnittet. Det vil være muligt at generere en simpel årstalsangivelse til publiceringen ud fra felt 008 delfelt *a og/eller *z.

Eksempler til delfelt *u, *a og *z

1 008 00 *a 1993

2 008 00 *a 1993 *z 1994
(Flerårig udgivelse)

3 008 00 *a 199?
(Udgivelsesåret ligger mellem 1990 og 1999)

4 008 00 *u ? *a 1990 *z 1994
(Udgivelsesåret ligger mellem 1990 og 1994)

5 008 00 *u r *a 1993 *z 1994
(Nyt oplag 1994 af 1. udgave fra 1993)

6 008 00 *u o *a 1994
(Uafsluttet flerbindsværk eller løsbladsværk)

7 008 00 *u f *a 1993
(1. udgave, 1. oplag af monografi)

8 008 00 *u u *a 1993
(Ny ændret udgave)

9 008 00 *u c *a 1990
(Løbende periodicum, hvis udgivelse er startet i 1990)

10 008 00 *u d *a 1980 *z 1994
(Periodicum, hvis udgivelse er startet i 1980 og afsluttet i 1994)

#31 Updated by Rolf Madsen over 1 year ago

Er der noget teknisk til hinder for at årstal med ? indgår i visningen på lige fod med de øvrige værdier?

Er det du mangler en beslutning omkring de foreslag Kasper kom med i https://platform.dandigbib.org/issues/3265#note-19 ?

Vi har et designoplæg på visningen fra de seneste drøftelser omkring UX i søgegrænsefladen der kunne bruges som inspiration.

#32 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen

#33 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

Er det du mangler en beslutning omkring de foreslag Kasper kom med i https://platform.dandigbib.org/issues/3265#note-19 ?

Ja, det skal besluttes om resultatet fra den søgning der finder spændet af årstal skal gemmes i cachen eller i siden url.

 


 

Den nuværende løsning ser således ud:

 


 

Er der noget teknisk til hinder for at årstal med ? indgår i visningen på lige fod med de øvrige værdier?

Den nuværende løsning bruger jQuery slider (som følger med Drupal), som kun understøtter tal værdier. Skal vi understøtte "?" i selve slideren skal dette hackes, eller også skal en alternativ motor findes eller bygges (jeg har ikke undersøgt hvad der er af muligheder).

 


 

Jeg kender ikke til danAMR2 formatet, men det minder ikke om de queries der bliver benyttet når der søges.

Jeg kan også se, i tidligere link til liste over facet.date værdier, at der muligvis vil være andre udfordringer med den data der modtages, et hurtigt kig over formatterne giver mindst følgende formater:

  • 2010, 1985, 2000
  • 200?, 18??, 195?, ????
  • 1995-2001, 1990-1997
  • 19901993, 19891997
  • 1987?2002, 196?1990
  • 196979, 191910
  • 198919901996
  • ukendt årstal

For at kunne håndtere disse, har vi brug for en metode der kan omdanne disse til et specifikt format vi selv definere, så en mængde (antallet af resultater på det enkelte term værdi) kan udregnes ud fra et spænd.

 


 

En anden ting, er det virker som om antallet af resultater ikke altid giver mening, jeg har følgende søge eksempler eksempler:

  1. (term.date=200?) AND (facet.date="2009") : 492455
  2. (term.date=200?) AND (facet.date>="2009" AND facet.date<="2009") : 500949
  3. (term.date=200?) AND (facet.date>="200?" AND facet.date<="2009") : 9576
  4. (term.date=200?) AND (facet.date>="2009" AND facet.date<="2010") : 500961

På disse eksempler får jeg følgende tilbage fra facet listen (listen over årstal, med et tilhørende antal resultater for det enkelte årstal):

  • 200? = 417
  • 2009 = 492455
  • 2010 = 1925

Ud fra disse tal er søgning #1 har fundet det korrekte antal.
Søgning #2 burde give samme antal som #1, men giver 8494 flere resultater.
#3 og #4 giver begge uforventede resultater, jeg ville ha forventet #4 gav 494380 (492455 + 1925).

Hvis det forventede antal resultater (givet af facets listen), og det endelige antal givet fra selve søgninge ikke stemmer overens, skal vi måske droppe det forventede antal (som Kasper har foreslået tidligere, dog af andre årsager).
Eller præsentere mængden mere upræcist. Eller præsentere mængde som en relativ værdi af den komplette mængde, evt som en graf, foreslået af Rolf i #3265-31.

 


 

Summa summarum, så tror jeg at implementere andre årstal, end simple tal vil give problemer, og være svært at vedligeholde, samt muligvis forvirre slutbrugeren, hvis vi skal håndtere nogen af de lidt vildere formater. Ligeledes ser det ud som om de ikke er understøttet fuldt ud i søgningen (se #3 søge resultat der giver et markant lavere antal resultater end forventet), med mindre jeg har misforstået noget her?

Det virker som om der ikke kan stoles på de forventede tal, når der søges i spænd (se søgning #2, som jo burde være identisk med #1), og derfor vil den nemme løsning være, at fjerne det forventede antal. Fjernes dette tal, skal slideren automatisk hoppe mellem årstal der indeholder resultater, i stedet for at indeholde alle år (som den gør nu, da det gav den bedste fornemmelse).
Eller resultaterne skal præsenteres mere som visuelle mængder, ala hvad der foreslåes i #3265-31.

#34 Updated by Rolf Madsen over 1 year ago

Jeg ville forvente at du skulle brug OR operatoren til at inkludere den range af årstal der er valgt.

Derfor ville jeg også foreslå at spændet af årstal gemmes i side URL'en ala:

https://upgrade-fbs.ddbcms.dk/search/ting/danmark%20%20and%20%28facet.date%3D2001%20or%20facet.date%3D2002%20or%20facet.date%3D2003%20or%20facet.date%3D2004%20or%20facet.date%3D2005%20or%20facet.date%3D2006%20or%20facet.date%3D2007%20or%20facet.date%3D2008%20or%20facet.date%3D2009%20or%20facet.date%3D2010%29?

Svarende til:

and facet.date=2001 or facet.date=2002 or facet.date=2003 or facet.date=2004 or facet.date=2005 or facet.date=2006 or facet.date=2007 or facet.date=2008 or facet.date=2009 or facet.date=2010

Således benytter vi and operatoren imellem facetgrupper og or operatoren imellem facetter i en facetgruppe.

#35 Updated by Philip Birk-Jensen over 1 year ago

Jeg undersøger om de forventede resultater stemmer overens med antalet af resultater når vi indsætter alle årstal i spændet ind som OR.

 

Derfor ville jeg også foreslå at spændet af årstal gemmes i side URL'en ala:

Det valgte spænd gemmes allerede i URL, spørgsmålet er om vi skal gemme alle tilgængelige år (samt deres forventede antal) som en query parameter i URL'en eller i cache.
Jeg frygter vi kan komme tæt på MSIE max url længde på ~2000 tegn, hvis vi gemmer det totale spænd i URL. Vi ville nok kunne omgå dette via gzcompress.

#36 Updated by Philip Birk-Jensen over 1 year ago

En hurtig test hvor der søges på:

  1. (term.date=200?) AND (facet.date="2009" OR facet.date="2010") : 494142
  2. danmark and facet.date=2001 or facet.date=2002 or facet.date=2003 or facet.date=2004 or facet.date=2005 or facet.date=2006 or facet.date=2007 or facet.date=2008 or facet.date=2009 or facet.date=2010 : 3566196

og de forventede tal er

  • Søgning #1
    • 2009 = 492480
    • 2010 = 1925
  • Søgning #2
    • 2008 = 610900
    • 2009 = 492488
    • 2010 = 487639
    • 2007 = 425864
    • 2006 = 330562
    • 2005 = 310029
    • 2003 = 308953
    • 2002 = 298013
    • 2004 = 297605
    • 2001 = 14990

Så de 2 tal stemmer desværre ikke overns ved brug af OR, det ser dog ud til de er lidt tættere på end ved brug af >= og <= (i disse 2 søgninger, det kan meget vel være anderledes i andre søgninger).

#37 Updated by Rolf Madsen over 1 year ago

Husk min søgestrenge indeholder "danmark".

#38 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen
  • Kategorier Biblioteksinfo - Sidefod added

#39 Updated by Philip Birk-Jensen over 1 year ago

Jeg havde danmark med i mit søgeresultat, jeg havde dog ikke fået datoerne pakket ind, men ved følgende søgning:

  1. danmark and (facet.date=2001 or facet.date=2002 or facet.date=2003 or facet.date=2004 or facet.date=2005 or facet.date=2006 or facet.date=2007 or facet.date=2008 or facet.date=2009 or facet.date=2010) : 135219

Forventede resultater:

  • 2004 = 15775
  • 2007 = 15166
  • 2005 = 13655
  • 2008 = 13607
  • 2010 = 13410
  • 2009 = 13382
  • 2001 = 12991
  • 2006 = 12929
  • 2003 = 12781
  • 2002 = 12383

Stemmer forventet og resultat stadig ikke.

#40 Updated by Rolf Madsen over 1 year ago

Det skyldes at nogle poster godt kan have flere date elementer.

Eksempel:

<dkabm:record>
<ac:identifier>26291925|870970</ac:identifier>
<dc:identifier xsi:type="dkdcplus:ISBN">87-88626-33-4</dc:identifier>
<dc:identifier xsi:type="dkdcplus:ISBN">9788788626339</dc:identifier>
<dc:identifier xsi:type="dkdcplus:ISSN">1901-7847</dc:identifier>
<ac:source>Bibliotekskatalog</ac:source>
<dc:title>Årbog</dc:title>
<dc:title xsi:type="dkdcplus:full">Årbog. Årgang 2005</dc:title>
<dc:subject xsi:type="dkdcplus:DK5">30.1626</dc:subject>
<dc:subject xsi:type="dkdcplus:DK5-Text">Arbejderklassen</dc:subject>
<dcterms:audience>voksenmaterialer</dcterms:audience>
<dkdcplus:version>1. udgave, 1. oplag</dkdcplus:version>
<dc:publisher>
Arbejdermuseet & Arbejderbevægelsens Bibliotek og Arkiv
</dc:publisher>
<dc:contributor>
Fonden Arbejdermuseet & Arbejderbevægelsens Bibliotek og Arkiv
</dc:contributor>
<dc:date>2006</dc:date>
<dc:date>2011</dc:date>

Det er meget tydeligt hvis du søger på <open:query>facet.date=2010 or facet.date=2011</open:query> og ser på de værdier der ligger i facet.date hvor du kan se at der findes værker med mange andre årstal:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://oss.dbc.dk/ns/opensearch">
<SOAP-ENV:Body>
<searchResponse>
<result>
<hitCount>1043930</hitCount>
<collectionCount>0</collectionCount>
<more>true</more>
<facetResult>
<facet>
<facetName>facet.date</facetName>
<facetTerm>
<frequence>556495</frequence>
<term>2011</term>
</facetTerm>
<facetTerm>
<frequence>487652</frequence>
<term>2010</term>
</facetTerm>
<facetTerm>
<frequence>448</frequence>
<term>2007</term>
</facetTerm>

[...]

#41 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

Okay, så vi vil aldrig kunne matche de forventede tal med det antal der kommer i det endelige resultat.

Men hvis vi går ud fra vi kan bruge tallene relativt (sådan ca), kan slideren laves om så den præsentere det som en graf, der ikke må være for præcis. Eller vi skal droppe det forventede tal på slideren?

#42 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen

Jeg hælder til at fjerne tallet!

#43 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

Jeg har fjernet tallet og opdateret PR.

Men jeg har opdaget en anden fejl, jeg (underligt nok) ikke har lagt mærke til tidligere.
Når jeg filtrere på et spænd får jeg resultater tilbage, men filtrere jeg på et spænd og en ekstra parameter får jeg en fejl tilbage.

(danmark) AND (facet.date>="1950" AND facet.date<="2018")
Giver et resultatset der bliver sendt videre i systemet og jeg får en søgeside, hvor alle materialer er mellem 1950 og 2018.

(danmark) AND (facet.date>="1950" AND facet.date<="2018" AND facet.type="bog")
Giver en fejl: "Internal problem: No answer from Solr"

Har prøvet at rykke lidt rundt på paranteserne, og rækkefølgen af facets, men jeg har ikke ramt noget der virker.

Har også prøvet, at OR datoer på i stedet (hvilket jeg helst ikke vil gøre i den endelige løsning, da det vil kræve et specifikt hack for date filteret), men følgende query giver samme fejl:
(danmark) AND (facet.date=2001 OR facet.date=2002 OR facet.date=2003) AND (facet.type="bog")

Jeg kan ikke se hvad fejlen er, er der nogen som kan se hvad jeg har gjort galt, eller mangler?

#45 Updated by Simon Holt over 1 year ago

Der er ustabile svartider i opensearch lige nu, så det er måske det Phillip er rendt ind i: https://kundeservice.dbc.dk/

#46 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

Jeg får stadig fejl på mit query. Det endelige query der sendes af sted ser således ud: ((danmark) AND (facet.date=2001 OR facet.date=2002 OR facet.date=2003) AND (facet.type="bog")) and holdingsitem.agencyid="100200".

Skal jeg ændre mit agencyid?

#47 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen

I'et i agencyId skal være med stort.

Eksempel med agencyId 725300

((danmark) AND (facet.date=2001 OR facet.date=2002 OR facet.date=2003) AND (facet.type="bog")) and holdingsitem.agencyId="725300"

https://vanilla-fbs.ddbcms.dk/search/ting/%28%28danmark%29%20AND%20%28facet.date%3D2001%20OR%20facet.date%3D2002%20OR%20facet.date%3D2003%29%20AND%20%28facet.type%3D%22bog%22%29%29%20and%20holdingsitem.agencyId%3D%22725300%22?

#48 Updated by Christel Krabbenhøft over 1 year ago

Philip, vil du kigge på sagen igen?

#49 Updated by Philip Birk-Jensen over 1 year ago

  • Assignee changed from Philip Birk-Jensen to Rolf Madsen

agencyid bliver automatisk sat på af TingClientSearchRequest, jeg har prøvet at ændre det til agencyId, men jeg får stadig samme fejl.

Hvilken profile skal jeg bruge når jeg ændre agency id til 725300?

#50 Updated by Simon Holt over 1 year ago

@Phillip du er velkommen til at bruge vores agencyid og profile hvis det er. Kan i hvert fald se det giver resultater:

agencyid: 763000

profile: opac

#51 Updated by Philip Birk-Jensen over 1 year ago

  • Status changed from Reviewed - Needs info/rework to Needs code review

Tak for info, efter jeg har ændret agency og profile virker det efter hensigten.

#52 Updated by Jesper Kristensen about 1 year ago

  • Status changed from Needs code review to Need more info

Jeg ser ikke udfra jeres snak her at performance er håndteret endnu?

Se https://platform.dandigbib.org/issues/3265#note-19

#53 Updated by Rolf Madsen about 1 year ago

  • Assignee changed from Rolf Madsen to Philip Birk-Jensen

@Philip, vil du se på Jespers kommentar?

#54 Updated by Christel Krabbenhøft about 1 year ago

  • Target version changed from Release 30 - Søgegrænseflade to Release 31 - bugfixes

#55 Updated by Philip Birk-Jensen about 1 year ago

Jeg vælger en løsning på dobbeltkald problemet, så vi undgår dobbeltkald ved sideskift.

Jeg hopper dog på barsel nu her, og er væk i lidt over en måned, så jeg vil først kunne rykke på dette i slutningen af marts.

#56 Updated by Philip Birk-Jensen 11 months ago

  • Status changed from Need more info to Needs code review
  • Assignee changed from Philip Birk-Jensen to Gitte Barlach

Jeg har implementeret en cache og opdateret PR (https://github.com/ding2/ding2/pull/1123).

Der er kommet en række scrutinzer fejl, men de ser ikke ud til at være fra dette PR, skal jeg kigge på at rette disse i dette issue?

#57 Updated by Gitte Barlach 11 months ago

  • Assignee changed from Gitte Barlach to Kasper Garnæs

#58 Updated by Kasper Garnæs 10 months ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Kasper Garnæs to Philip Birk-Jensen

Reviewed. Jeg har en række kommentarer til hvordan dette er implementeret.

Philip: Jeg er enig i at Scrutinizer kommentarerne ikke stammer fra dine ændringer, men vi sætter pris på hvis du har overskud til at rette dem.

#59 Updated by Philip Birk-Jensen 10 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Philip Birk-Jensen to Kasper Garnæs

PR er opdateret.

Jeg har lavet 2 kommentar på github.

#60 Updated by Kasper Garnæs 9 months ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Kasper Garnæs to Philip Birk-Jensen

Rereviewed. Tak for spørgsmål. Jeg har prøvet at svare på bedste vis.

#61 Updated by Philip Birk-Jensen 9 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Philip Birk-Jensen to Kasper Garnæs

Jeg lavede noget rod i en rebase der ødelagde tidligere PR. Det var nemmere at lave et nyt (selvom vi mister kommentar sporet).

Nyt PR: https://github.com/ding2/ding2/pull/1440

I det nye PR tager jeg hånd om alle git kommentar.

Er godt klar over det er lidt noget rod med skift af PR ligepludselig, jeg troede jeg kunne lave noget smart med en rebase, men det eksploderede desværre.

#62 Updated by Kasper Garnæs 9 months ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Kasper Garnæs to Philip Birk-Jensen

OK. Jeg har én enkelt kommentar og så burde vi være klar.

#63 Updated by Philip Birk-Jensen 9 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Philip Birk-Jensen to Kasper Garnæs

PR opdateret

#64 Updated by Kasper Garnæs 9 months ago

  • Status changed from Needs code review to Reviewed

Godkendt.

#65 Updated by Kasper Garnæs 9 months ago

  • Status changed from Reviewed to Technical test

Merged.

#66 Updated by Kasper Garnæs 9 months ago

  • Assignee changed from Kasper Garnæs to Gitte Barlach

#67 Updated by Tue Gaston 9 months ago

Christel Krabbenhøft wrote:

Scenarie: Bruger søger nyere værk af en specifik forfatter, er usikker på udgivelsesåret, og ønsker derfor at afgrænse søgeresultatet til et interval af år (lige nu er det kun muligt at vælge et enkelt udgivelsesår). Mulig løsning: Slider eller lign. der giver brugeren mulighed for at vælge flere udgivelsesår.

Den leverede løsning fungerer desværre ikke tilfredsstillende.

Jeg går på https://vanilla-fbs.ddbcms.dk/ og søger på ”danmark”: https://vanilla-fbs.ddbcms.dk/search/ting/danmark?
Jeg får 203.641 resultater.

Jeg scroller ned, indtil jeg ser årstals-slideren, og ser at intervallet er 2008-2018 (skønt mange resultater er langt ældre end 2008, og der også er nogle fra 2019).
Jeg trækker den venstre ende af slideren mod højre, så intervallet er 2010-2018, og udløser dermed en ny søgning.
Nu får jeg 62.849 resultater.

MEN! Nu kan jeg trække slideren meget længere til venstre (det kunne jeg ikke før), helt tilbage til 1910, og får dermed 199.294 resultater.
Lige meget hvad jeg gør, har jeg dog ikke mulighed for at trække den højre ende af slideren længere til højre, så jeg kan få 2019 med.

 

Desuden er der et problem i mobilvisningen (Chrome for android)
Jeg går på vanilla og søger på "jensen", og får 50.567 resultater.
Jeg vælger "Afgræns din søgning" og scroller ned til årstals-slideren (hvor der, i lighed med på desktop-versionen, er afgrænset til et interval af år - 2004-2018 - der er mindre end det, der er resultater fra på min søgning, men det er ikke pointen her).

Jeg vælger et nyt "nedre årstal", så intervallet er 2007-2018, og udløser en ny søgning.
Nu får jeg 16.646 resultater.

Så vælger jeg endnu en gang "Afgræns din søgning" og scroller ned til årstals-slideren.
Og så kommer problemet: Jeg kan ikke gøre intervallet større igen. Intervallet 2007-2018 er udvidet, så det fylder hele sliderens længde, der er altså ingen mulighed for at trække den venstre ende af afgrænsningen længere til venstre for at få et lavere nedre årstal eller den højre ende længere til højre.
Det var der i desktop-versionen.

#68 Updated by Tue Gaston 9 months ago

  • Assignee changed from Gitte Barlach to Philip Birk-Jensen

#69 Updated by Gitte Barlach 9 months ago

  • Status changed from Technical test to Reviewed - Needs info/rework

#70 Updated by Philip Birk-Jensen 9 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Philip Birk-Jensen to Gitte Barlach

#71 Updated by Gitte Barlach 9 months ago

  • Assignee changed from Gitte Barlach to Kasper Garnæs

#72 Updated by Kasper Garnæs 9 months ago

  • Status changed from Needs code review to Needs design decision
  • Assignee changed from Kasper Garnæs to Rolf Madsen

Tue har helt ret i sine findings og Philip har lavet et forslag, der addresser problemerne. Alligevel mener jeg at det kræver en informeret beslutning, om hvorvidt ændringen kan accepteres.

 

Opsummeret så skyldes Tues oplevelse at årstal eksisterer som et facet i OpenSearch på linie med forfatter, emne o.l. DDB CMS spørger som udgangspunkt om ~25 termer per facet. OpenSearch vil så returnere de termer med højest frekvens og dermed også kun op til ~25 årstal, som kan blive vist i intervallet. Med den allerede godkendte ændring vil DDB CMS ved efterfølgende requests (fx. hvis brugeren afgrænser sin søgning) lave et ekstra request imod OpenSearch for at få det fulde årstalsinterval med, så der er mulighed for at brede søgningen ud igen. Her fortages en ekstra søgning, hvor der udelukkende fokuseres på årstalsfacetten, men hvor der samtidig hentes langt flere termer per facet: 999. Dermed er der også mere data til at udspænde intervallet.

Philips foreslåede ændring medfører at der også ved det initielle request bliver sendt et ekstra request afsted efter 999 årstal. Derved opnår vi igen meget data til at udfolde intervallet.

 

Ud fra et performanceperspektiv er den foreslåede løsning problematisk eftersom den ekstra søgning tilføjer et væsenligt overhead på den vigtige initielle søgning og også her gør brugeroplevelsen langsommere.

 

Vi har tidligere søgt at undgå nedsat performance ved implementering af dette. Jeg kan se følgende alternativer - altså ud over at acceptere løsningen i ovenstående PR:

  1. DDB CMS henter et langt større antal termer for *alle* facetter. Dermed gøres hvert request tungere for til gængæld at spare det ekstra request.
  2. DDB CMS henter spænd for datofacetten asynkront. Dette kræver yderligere udvikling og koden gøres endnu mere kompleks.
  3. OpenSearch får bedre understøttelse af intervalfacetter således at minimum og maksimumværdier kan returneres.
  4. Funktionaliteten udelades.

#73 Updated by Rolf Madsen 9 months ago

  • Target version changed from Release 31 - bugfixes to Release 33 - Bugfixes

Tak for opsummeringen Kasper!

Denne funktion til at angive en range af udgivelsesår er på ingen måde så højt prioriteret at den må påvirke performance på søgeresultatet negativt.

Derfor mener jeg at:

  1. Dette issue skal udskydes til en senere release.
  2. DDB kontakter DBC med henblik på en mere hensigsmæssig visning af facet.date facetten til at understøtte filtrering på ranges.
  3. Løsningen implementeres når vi refaktorerer facetbrowseren ud fra de UX anbefalinger vi har udarbejdet for søgegrænsefladen.

Designoplæg til ny facetbrowser.

NB. DBC forventes at levere facetklynger, som er den horisontale visning af Ebøger, Lydbøger, Film og Spil mv., med udgangen af 2. kvartal 2019, hvilket så kan implementeres som første fase at refaktoreringen af facetbrowseren.

#74 Updated by Rolf Madsen 9 months ago

Jeg har oprettet en sag hos DBC, med følgende formål at få:

  1. udleveret ældste og nyeste udgivelsesår i facet.date.
  2. ryddet op i de data der findes i facet.date indekset så der ikke længere indeholder tekst, specialtegn etc.

Din sag har fået nummer: REQ0037714.

#75 Updated by Gitte Barlach 9 months ago

Det vil sige at https://github.com/ding2/ding2/pull/1459 skal revertes. 

#76 Updated by Gitte Barlach 9 months ago

  • Assignee changed from Rolf Madsen to Kasper Garnæs

#77 Updated by Gitte Barlach 8 months ago

  • Target version changed from Release 33 - Bugfixes to Release 31 - Adgangsplatform og LUG

Hej Kasper
Ifm næste byg skal denne revertes. 

#78 Updated by Simon Holt 6 months ago

Så vidt jeg kan læse mig til skulle denne revertes.. også de ændringer der er blevet godkendt?

Ser nemlig ud til at slideren stadig optræder i seneste release.

#79 Updated by Christel Krabbenhøft 6 months ago

  • Target version changed from Release 31 - Adgangsplatform og LUG to Release 32 - Bugfixes

#80 Updated by Gitte Barlach 5 months ago

  • Status changed from Needs design decision to Needs code review
  • Priority changed from Normal to High

Du har ret, Simon

Slideren optræder i seneste release, dvs. beta6. Det skal den ikke. Ændringerne skal revertes. Kan du hjælpe med det, Kasper ?

#81 Updated by Gitte Barlach 5 months ago

  • Target version changed from Release 32 - Bugfixes to Release 31 - Adgangsplatform og LUG

#82 Updated by Kasper Garnæs 5 months ago

  • Status changed from Needs code review to Technical test

#83 Updated by Gitte Barlach 5 months ago

Testet på upgrade-fbs med 7.x-5.0.0-beta7
Facetgruppen Årstal er nu tilbage til sit klassiske udseende, dvs. der er ingen slider. Hermed godkendt. 

#84 Updated by Gitte Barlach 5 months ago

  • Status changed from Resolved (tag version) to Needs design decision
  • Assignee changed from Gitte Barlach to Rolf Madsen

#85 Updated by Gitte Barlach 4 months ago

  • Target version changed from Release 31 - Adgangsplatform og LUG to DDB CMS - Analyse og prioritering udestår

#86 Updated by Rolf Madsen 4 months ago

Det ser umiddelbart ud som en funktion der findes i SOLR, så jeg vil foreslå at der bliver oprettet et projekt på Releaseplan 2020 til udvikling hos DBC.

https://lucene.apache.org/solr/guide/6_6/faceting.html#Faceting-RangeFaceting

#87 Updated by Rolf Madsen 4 months ago

Jeg kan faktisk meget godt lide den måde pricerunner.dk har implementeret deres horisontale facetter.

Eksempelvis: https://www.pricerunner.dk/cl/27/Baerbar#price_max=5000

#88 Updated by Rolf Madsen 4 months ago

  • Status changed from Needs design decision to DBC (waiting)

Jeg har overført dette issue til den backlog der overgives til Kombit når de overtager bestillerfunktionen overfor DBC.

Also available in: Atom PDF