Tijdens het gebruik van de zoekfunctie loop ik al een tijdje tegen de volgende problemen aan, waarvan ik denk dat het fouten zijn in het zoekmechanisme:

1. Bij grotere zoekvrijheid, worden sommige resultaten niet getoond.

Voorbeeld: 

als ik zoek op "Roef*" vind ik 34526 resultaten, waarvan 321 in Aarle-Rixtel

als ik zoek op "Roe*" vind ik 1939554 resultaten, en verwacht ik dus minstens 321 resultaten in Aarle-Rixtel.

In het laaste geval kan ik echter helemaal niet filteren op Aarle-Rixtel

Er lijken 0 resultaten in Aarle-Rixtel gevonden te worden?

2. Sommige plaatsnamen zijn leeg, maar kan daar niet op filteren

In beide gevallen hierboven zijn er resultaten (einde filterlijst) waarbij de plaatsnaam leeg is.

Echter, daar kan ik niet op filteren!

3. Zoeken met meer dan 1 "*" wildcard in combinatie met & werkt niet goed

a. "J* d* W* 5-1-1823" geeft 3 resultaten

b. "J* & d* W* 5-1-1823" geeft 2 resultaten

Toch voldoen alle resultaten van a. ook aan b.

Ik probeer nog met betere voorbeelden te komen.

4. Zoeken met meer dan 1 "~" wildcards werkt niet 

Bijvoorbeeld "~Beatrix ~Wouters"  levert 1 resultaat, "~Beatrix Wouters" levert 68 resultaten

Dit is interessant: 

bij mij geeft zowel "J* d* W*" 5-1-1823 als "J* & d* W*" 5-1-1823 geen resultaten. Als ik de " " weglaat, geeft J* d* W* 5-1-1823 13 resultaten en J* & d* W* 5-1-1823 49 resultaten. 

Ik had al eerder gemerkt dat " " in combinatie met wildcards niet werkt (tenminste bij mij niet, ik krijg dan altijd Uw zoekopdracht heeft geen resultaten opgeleverd!) en dacht dan ook dat dat in dit zoekprogramma niet was ingebouwd.

Probleem 3 lijkt nu te zijn opgelost.

a. "J* d* W* 5-1-1823" geeft nu 13 resultaten

b. "J* & d* W* 5-1-1823" geeft nu 49 resultaten

Overigens vind ik het gebruik van de wildcards niet heel erg transparant.

Ik zou willen pleiten voor een modus waarin normale reguliere expressies (bv. volgens de Unix regex standaard) mogelijk zijn.

Iets wat past bij de onderliggende implementatie van de zoekfunctionaliteit.

Helaas werkt dit voorbeeld nog niet:

~Anna Fran* 1715-1725 in Breugel geeft 6 resultaten.

In 4 van de resultaten komt Martinus Jansse voor. 

maar als ik zoek op 

~Anna Fran* & Martinus 1715-1725 in Breugel geeft geen resultaten

Ik verwacht er 4

Wat gaat hier mis?

Probeer 'ns: Martinus Jansse & ~Anna Fran* 1715-1725

Of: Anna Frans* & Martinus Jansse 1715-1725

De tilde ~ ken ik wel van zoeken in Pro-Gen, betekent dan "bevat", zie

De tilde komt niet voor op de Reguliere expressietaal - Snelzoekgids op

https://docs.microsoft.com/nl-nl/dotnet/standard/base-types/regular-expression-language-quick-reference

^{- hautaine uitlating in post hierboven is verwijderd, dus reactie niet meer relevant -}

Dank voor je reactie en het meedenken Pauline Berens EBBI

Mijn analyse:

Het is inderdaad interessant dat "Martinus & ~Anna Fran* 1715-1725" 4 resultaten geeft,

maar "~Anna Fran* & Martinus 1715-1725" niet.

Mijn aanname is dat het voor de resultaten niet uit moet maken of ik a & b of b & a zoek, tenzij ik een rol selecteer omdat die (denk ik?) alleen op het eerste deel van toepassing is.

Het ligt blijkbaar aan de combinatie van tilde (~) en asterisk (*), want  "Anna Fran* & Martinus 1715-1725" geeft wel 4 resultaten, en "~Anna Fransse & Martinus 1715-1725" geeft de verwachtte 2 resultaten.

Dat is vreemd.  

Ik lees ~Anna Fran* als "een naamdeel dat klinkt als Anna" en "een naamdeel dat begint met Fran"

(volgens de gebruiksaanwijzing van Open Archieven)

Tijd voor een reactie van de IT-ers achter Open Archieven ;-) 

Het lijkt een vrij onbeduidend topic, maar als het onduidelijk is wat de uitkomst van een zoekopdracht zou moeten zijn, zullen veel mensen hierdoor onbedoeld de mist in gaan...

P.S. In Pro-Gen heeft de tilde bij het zoeken blijkbaar een andere betekenis. Dat is voor deze discussie verder niet relevant. 

Dag Rian, graag gedaan, inmiddels heb ik de handleiding gevonden op https://www.openarch.nl/video/

De tilde wordt idd gebruikt voor fonetisch zoeken, ik vroeg me al af waar je die vandaan haalde:-)

~Anna ~Fransse & Martinus 1715-1725 =0 hits

~Fransse & Martinus 1715-1725 = 117 hits

Martinus & ~Fransse  1715-1725 = 7 hits

Martinus & Anna ~Fransse 1715-1725 = 2 hits

Anna ~Fransse & Martinus 1715-1725 = 11 hits

Anna ~Fransce & Martinus 1715-1725 = 11 hits

Anna ~Frans & Martinus 1715-1725 = 11 hits

Anna ~Frans?e & Martinus 1715-1725 = 7 hits

Anna ~Frans* & Martinus 1715-1725 = 9 hits, waaronder de 4 uit Breugel. "U heeft fonetisch gezocht naar personen in akten uit de periode 1715-1725 met Anna Frans* in de naam waarin ook de naam Martinus voorkomt, dit geeft 9 zoekresultaten."

De tilde moet dus volgens mij voor Frans* staan, want je wilt varianten die klinken als France, Fransse etc., niet voor Anna.

De beschrijving staat op de startpagina van openarch ;-) https://www.openarch.nl/

Even voor de duidelijkheid: het gaat mij er niet om dat ik niet kan vinden wat ik zoek.

Het gaat mij erom dat ik in sommige gevallen niet vind wat ik zou moeten vinden omdat er fouten in het zoekmechanisme zitten, of de beschrijving van hoe het zou moeten werken niet duidelijk is.

Merk op dat ik in Breugel zoek, dat maakt uw resultaten iets anders

~Anna ~Fransse & Martinus 1715-1725 =0 hits

 -> ik verwacht er minstens 2 of 4 omdat er dus minstens 4 resultaten zijn  waarvan we weten dat ze hieraan voldoen.

~Fransse & Martinus 1715-1725 = 12 hits

Martinus & ~Fransse  1715-1725 = 6 hits

-> ik verwacht er dus minsten 12 omdat het geen verschil zou moeten maken met de vorige

Martinus & Anna ~Fransse 1715-1725 = 2 hits

Anna ~Fransse & Martinus 1715-1725 = 11 hits

-> bij deze 2 zou ik ook hetzelfde resultaat verwachten

Anna ~Fransce & Martinus 1715-1725 = 11 hits

Anna ~Frans & Martinus 1715-1725 = 11 hits

Anna ~Frans?e & Martinus 1715-1725 = 7 hits

Anna ~Frans* & Martinus 1715-1725 = 9 hits, waaronder de 4 uit Breugel. "U heeft fonetisch gezocht naar personen in akten uit de periode 1715-1725 met Anna Frans* in de naam waarin ook de naam Martinus voorkomt, dit geeft 9 zoekresultaten."

> De tilde moet dus volgens mij voor Frans* staan, want je wilt varianten die klinken als France, Fransse etc., niet voor > Anna.

Jawel hoor. Ik wil natuurlijk ook Joanna, Johanna, Johanna Maria, etc.

Maar eigenlijk maakt het niet zoveel uit, het is maar een voorbeeldje. 

Nogmaals, waar het om gaat is dat het zoekmechanisme niet doet wat we denken dat het zou moeten doen.

Dag Rian, voordat ik kan bevestigen dat "het zoekmechanisme niet doet wat we denken dat het zou moeten doen" moet ik eerst meer puzzelen op probleem 1,2 en 4 om te weten of het probleem in de samenstelling van de zoekvraag zit (en dus bijv. de handleiding beter zou kunnen), of in het zoekmechanisme zelf, de onderliggende techniek. Ik meld me wel weer als ik iets zinnigs heb ontdekt.

Probleem 1: Aarle-Rixtel wordt niet getoond in de keuzelijst omdat er in de keuzelijst gekozen is voor 'n maximum van 500 plaatsen die het vaakst voorkomen in het zoekresultaat. 321 Hits is vaak genoeg binnen 34526 hits op zoekvraag Roef* om in die top 500 te staan, maar niet bij 1.939.554 hits op Roe*. Om wel in de keuzelijst te staan zou Aarle-Rixtel 519x voor moeten komen. Die grens van 500 is willekeurig, het zal gedaan zijn om de pagina snel genoeg te laten laden. Wel handig om in de handleiding te zetten, om verwachtingen te temperen en aan te raden de zoekvraag in te perken.

Probleem 2: De onderste optie in de keuzelijst is niet bedoeld om te filteren, ik begrijp er uit dat van de 1.939.554 hits op Roe* 18.471x 'n plaats voorkomt die niet hoort bij de top 500. Welke plaatsen het betreft weten we niet, maar wel dat het tijd wordt de zoekvraag in te perken. Misschien handig om dit in de handleiding te zetten, als 't tenminste klopt wat ik beweer en in de keuzelijst bij deze optie standaard te tonen "overige plaatsen" o.i.d. De zoekvraag filteren op alle plaatsen behalve de top 500 levert misschien n timeout op en is daarom niet mogelijk gemaakt.

Probleem 4: Om te weten welke operatoren gecombineerd kunnen worden is het uitgebreide zoekformulier handig. Vul je in Naam 1ste Persoon=Maria Jansen en kies je zoekmethode Klinkt Als dan wordt de zoekvraag in het zoekresultaat: ~Maria Jansen, 2x 'n tilde werkt idd niet, ~Maria Janssen levert niet hetzelfde aantal hits op als ~Maria Jansen, dus de tilde wordt niet toegepast op de achternaam begrijp ik hieruit. Maria ~Jansen levert wel Jansen, Janssen  etc. op. Verschillende operatoren kun je wel combineren, ~Aaltje >Bert & Neeltje werkt, maar ~>Aal* levert 'n timeout op: "Het is even te druk, daarom konden er geen zoekresultaten opgehaald worden (timeout). Probeer het later nog eens." In het uitgebreide zoekformulier zijn zoekmethodes Bevat en Klinkt Als te combineren als je het sterretje in het zoekveld invult en Klinkt Als kiest. De zoekvraag in het zoekresultaat wordt ~aal* "U heeft fonetisch gezocht naar personen in akten met aal* in de naam, dit geeft 1.408 zoekresultaten." Twee tildes in de zoekvraag levert misschien n timeout op en is daarom niet mogelijk gemaakt. Toch mogelijk maken van zoekvragen die 'n timeout opleveren, bijv. door ophoging van de timeout-grens, zou weleens ten koste kunnen gaan van de zoeksnelheid van derden.

Kortom, volgens mij is het te vroeg om van "bugs" te spreken. Om te weten hoe 't werkt mag de handleiding wel iets uitgebreider, of gebruik Stamboomforum als zodanig😉

Benieuwd naar je reactie.

Bedankt voor het uitgebreide antwoord Pauline Berens EBBI

Probleem 1 en 2

Ik begrijp de overweging en goed om te weten. Ik realiseer me nu plotseling dat dat natuurlijk wel kan in het uitgebreide zoekscherm. 

Het rare is dat ik wel Aarle-Rixtel in de search box kan invullen, maar ik kan er toch niet op filteren.

Dat zou natuurlijk ook een oplossing zijn: maak het mogelijk om te filteren op plaatsen die niet in de lijst staan.

Probleem 4

Dank voor de testjes. Het levert helaas nog geen consistent beeld op van welke operatoren nu wel en niet gecombineerd kunnen worden en hoe. Overigens het voor reguliere expressies zeer ongebruikelijk om combinaties uit te sluiten. In ieder geval zou ik een eenduidige specificatie of handleiding willen hebben. 

Het uitgebreide zoekscherm is handig, maar uiteindelijk is het geen bewijs voor wat er wel of niet kan. Dat wordt bepaald door de onderliggende API. Ik ben een beetje aan het experimenteren met api.openarch.nl daarvoor, maar ik denk dat ik daar op hetzelfde probleem ga stuiten.

Toch tijd voor de inzichten voor 1 van de mensen die verstand hebben van het backend ben ik bang.

Voor de volledigheid: 'https://api.openarch.nl/1.0/records/search.json'

geeft precies hetzelfde resultaat.

Voorlopig is mijn conclusie dat de combinatie van ~ met wildcards (jokertekens) en &,  onvoorspelbare resultaten geeft. Op zijn minst zou ik verwachten dat & een commutatieve operator is. Dat is blijkbaar niet zo.

Het maken van een goede, snelle, krachtige en begrijpelijke zoekmachine maken is een kunst. Op dit vlak is er nog niet veel gestandaardiseerd. Reguliere expressie zijn krachtig, maar meer dan 99% van de gebruikers heeft denk ik geen idee wat dat zijn laat staan dat ze dit kunnen inzetten. Daar komt bij dat het vooral op de samengestelde zoekvragen "Coret & Brizee" of "~Coret", gekoppeld aan een filter op bron, periode en plaats, juist geen baat hebben bij regexp's.

Naast het zoeken is ook de presentatie van de resultaten een uitdaging. Het feit dat er in de filter maar max. 500 "dingen" worden getoond - uit performance overweging - is net zo'n ding die je niet opneemt bij de zoekresultaten om het geheel "rustig en clean" te houden. Maar dat is een balans zoeken, want om het onderste uit de kan te halen van een zoekmachine wil je dat gebruikers snappen hoe het werkt (en het ook consistent werkt). Ook is het afwachten of gebruikers de operatoren gebruiken zo bedoeld en getest. Zo weet ik niet was "~Anna ~Fransse" technisch doet, en of dit hetzelfde is al "~Anna Fransse" en of "~Anna Fran?e" door de achterliggende techniek werkt zoals we dat zouden willen of verwachten.

Ik ga, mede mbv bovenstaande voorbeelden, wat meer van deze complexere zoekopdrachten testen en documenteren (en werkend maken waar nodig).

Met het risico dat ik niet bij het juiste draadje aanhaak (moderator gaarne actie in dat geval) wil ik toch een zoekprobleem melden:

Ik zoek de nakomelingen van Antonie van Wijk en Pieternella Boer. Bij Open Archieven (zoekterm: van wijk & Boer en Papendrecht) krijg ik hun huwelijk te zien (en 2 weken geleden ook enkele geboorten).
Bij WWW (zoekterm: wijk, ant* en Papendrecht) krijg ik ook het huwelijk te zien met daarbij extra geboorten en de desbetreffende overlijdens.

Beide zoekmachines geven als bron het Regionaal archief Dordrecht op. Open Archieven haalt daar dus niet (altijd) de beschikbare bronnen op? Ik vind dit verwarrend, het is niet duidelijk welke data wel en niet getoond worden. Of zorg dat de data die beschikbaar zijn ook worden getoond of laat zien wat wel en niet getoond wordt. Nu loop ik het risico te concluderen dat bepaalde dat niet bestaat terwijl dat onjuist is.

@Reinoud

Open Archieven zoekt op basis van de gegevens op de akte door naar andere akten, bij het zelfde archief en andere archiefinstellingnen of verenigingen, en ook bij andere bronnen zoals het Biografisch Portaal, Graftombe en Genealogie Online.

Specifiek voor uw zoekvraag, op https://www.openarch.nl/rad:a698d291-02f5-865c-f177-4eb68301d50f ziet u onder de bronvermelding wat Open Archieven u nog meer kan bieden:

Beste Bob,

Je schrijft "Open Archieven zoekt op basis van de gegevens op de akte door naar andere akten, bij het zelfde archief..." Dat had ik begrepen en vertrouwde ik ook op. Daarom verbaasde het mij zo dat ik bij WWW met die zoekvraag veel meer akten krijg:

En op de 2e pagina staan nog een paar resultaten.
Ik ben heel blij met Open Archieven maar begrijp niet waarom niet alle resultaten die aan de zoekcriteria voldoen worden getoond. En dan bedoel ik hier natuurlijk de akten. Open Archieven laat dan wel weer zien in welke andere online stambomen een persoon voor komt en dat heeft WWW niet.

Ik wil niet het gevoel hebben dat ik bij een zoekopdracht naast Open Archieven ook WWW moet raadplegen omdat Open Archieven niet alle resultaten toont.

Beste Reinoud,

OpenArchieven heeft van de plaats Papendrecht vooral huwelijksakten in de database opgenomen:

https://www.openarch.nl/overview/level3.php?slice1=archives&value1=Regionaal+Archief+Dordrecht&slice2=places&value2=Papendrecht&slice3=sources

WieWasWie heeft dus meer akten van Papendrecht in de database opgenomen dan Open Archieven. Bij een andere zoekopdracht kan dat weer anders zijn.

Ik denk ook niet dat je je moet beperken tot de ene of de andere genealogische zoekdienst. Beide diensten vullen elkaar aan. Bij WieWasWie vind je soms gegevens die je niet op Open Archieven vindt en andersom. Hoewel er veel overlap zit in gegevens die je bij beiden kunt vinden, zijn ze niet identiek. Open Archieven heeft een aantal voordelen boven WieWasWie, die je zelf ook al hebt benoemd. Maar WieWasWie geeft bijvoorbeeld resultaten van familieadvertenties van het CBG, dat doet Open Archieven dan weer niet. 

Dus ik zou vooral beide diensten blijven gebruiken bij je onderzoek.

Beste Carmen,

Je hebt natuurlijk gelijk dat je je niet moet beperken tot een enkele zoekdienst, dat is helder. Het gaat mij om de voorspelbaarheid wat ik bij een zoekdienst wel en niet kan vinden (ik beperk mij even tot akten)
Open Archieven geeft op veel plaatsnamen uitstekende resultaten waarbij ik geen verschil met WWW kan ontdekken. Dat wekt de indruk dat de API die gebruikt wordt om de databases te ondervragen min of meer hetzelfde is. Met dat in mijn achterhoofd begrijp ik niet waarom in Papendrecht voornamelijk (maar niet alleen) huwelijksakten gevonden worden. Dit is mij, maar niet in die mate, ook bij andere plaatsen opgevallen. Als Open Archieven toegang heeft tot de database van een plaats, door wat wordt dan bepaald welke gegevns van die plaats worden getoond?