Wij stellen vragen middels stuf-bg aan gegevensmagazijnen. In de zoekvraag stellen we exact=false als we op delen van namen/velden willen zoeken. Dit werkt bij alle gegevensmagazijnleveranciers alleen aan het einde van de zoekterm: bij 'Wander' krijg ik 'Wanders' en 'Wandersen' mee. Bij personen gaat dit goed. bij bedrijven gaat dit fout: bij 'praxis' krijg ik niet 'bouwhandel praxis' terug. Juist die eerste tekst is overbodig. Bij notariskantoor, tuincentrum voorvoegsels gaat dit steeds mis. Hoe komt dit en kan dit aangepast worden?
ma, 4-08-2014 - 15.33u
#1
Zoeken met StUF-BG op delen van woorden zoals bedrijfsnaam
Beste Rene, Ik heb geen antwoord op je vraag, maar wil je vraag m.b.t. het 'exact' en 'niet-exact' zoeken nog een stuk uitbreiden. Wat te doen met: - Hoofdletter gevoelig zoeken - Hoe om te gaan met diacrieten Naar mijn mening is de standaard niet helder over bovenstaande functionaliteit. De enige definitie die ik kan vinden betreft: "Bij een gelijk-selectie kan worden aangegeven dat alleen een gedeelte van de waarde overeen hoeft te stemmen" (wat ik interpreteer als "Bouwhandel praxis" wordt geretourneerd bij niet-exact zoeken op "praxis" en "Wanneer het attribute StUF:exact ontbreekt of de waarde true heeft, dan voldoen alleen objecten, waarbij de waarde voor het selectiecriterium exact overeenkomt met de gespecificeerde waarde" Omdat niets is aangegeven over hoofdletter gevoelig zoeken c.q. diacrieten is nu niet duidelijk of: - 'Praxis' geretourneerd wordt bij zoeken op 'praxis' - "Dröge" geretourneerd wordt bij zoeken op "Droge" Wil programmatuur werken met gegevensmagazijnen van verschillende leveranciers zal het exact en niet-exact zoeken nader gespecificeerd moeten worden.
De StUF-standaard specificeert niet helder hoe StUF:exact="false" geïmplementeerd dient te worden. Omdat bij zoeken op een willekeurige string in een waarde de performance niet gegarandeerd kan worden, was het de bedoeling om te specificeren dat de wildcard zich alleen aan het einde van het gelijk-criterium mag bevinden. Voor de partijen die deze functionaliteit hebben geïmplementeerd was dit kennelijk duidelijk, maar het moet in de standaard nog verduidelijkt worden (een erratum). Daarnaast speelt ook het door Bernard Rutgrink aangekaarte probleem. Leveranciers van gegevensmagazijnen zijn er waarschijnlijk vanuit gegaan dat een waarde in het gelijk-criterium exact moet overeenkomen en dan loop je inderdaad aan tegen de problemen die Bernard schetst. Het lijkt wenselijk dat de StUF-expertgroep zich eens buigt over deze problematiek.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0343.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Een beperking van StUF:exact="false" zoeken met alleen de mogelijkheid van de wildcard aan het einde i.v.m. performance vind ik niet logisch. Elke ontwikkelaar weet dat zoeken met wildcards langzamer zal zijn dan exact zoeken en kan daar rekening mee houden (als StUF het zou ondersteunen). Het lijkt me dat de implementatie een standaard niet mag beperken. Je kan er wel rekening mee houden. Mogelijk kan er naast (of in plaats van) 'exact=false' gedefinieerd worden of er met wildcards, voor, na, voor-en-na de zoekstring gezocht moet worden.
Zie ook de discussie 'zoeken op een gedeelte van de waarde'.
In het standaardisatietraject "RSGB-Bevragingen" komt het vraagstuk rondom het gebruik van wildcards ook aan de orde. De functionele behoefte die daar wordt gedefinieerd komt het meest overeen met het voorstel dat Bernard doet in zijn reactie van 03-09-2014.
Dus naast (of in plaats van) 'exact=false' definieren of er met wildcards, voor, na, voor-en-na de zoekstring gezocht moet worden.
Het zou zonde zijn als om hier een specifieke oplossing voor te moeten uitwerken die alleen binnen RSGB-bevragingen wordt voorgeschreven terwijl het ook generiek uitgewerkt kan worden.
Ik zou graag zien dat dit onderwerp op korte termijn op de agenda van de StUF expert-groep komt.
Aanvullend op mijn vorige reactie wil ik aangeven dat ik ook graag op korte termijn gebruik wil maken van deze functionaliteit in de standaard "RSGB-bevragingen" . Derhalve zou ik ik dus graag zien dat dit voorstel als erratum wordt behandeld.
In het bestand van de onderhoudsverzoeken heeft Henri Korver bij dit onderhoudsverzoek (ONV0343) opgemerkt dat het fijn zou zijn als we dit probleem zouden kunnen oplossen in stuf0302. Naar zijn mening ligt er echter nog geen concrete uitwerking.
Johan Boer maakt mij er op attent dat Bernard Rutgrink ons op 3-9-2014 een concrete oplossing aan de hand doet. Deze komt op de onderstaande voorbeelden neer:
<zkn:achternaam exact="false" wildcard="voor-en-na">ssen</zkn:achternaam>
het attribute 'wildcard' kan hierbij de volgende waarden aannemen 'voor', 'na' en 'voor-en-na'.
Een andere optie is:
<zkn:achternaam wildcard="voor-en-na">ssen</zkn:achternaam>
waarbij het attribute 'exact' niet meer nodig is omdat het gebruik van het attribute 'wildcard' eigenlijk al impliceert dat exact 'false' is.
Het voorstel van Bernard komt neer op het toevoegen van nieuwe functionaliteit in een bestaand sectormodel en dit lijkt me alleen toegestaan als ale partijen die de betreffende functionaliteit geïmplementeerd hebben het eens zijn met deze aanpassing. Het dient in elk geval opgenomen te worden stuf0302 en kan van daaruit worden opgenomen in bg0320.
Aangezien de meeste gegevens worden opgeslagen in relationele databasesystemen en dus met SQL-statements zullen worden opgehaald uit de opslag, stellen wij voor om de SQL-standaard voor wildcards te gebruiken, waarbij exact="false" aangeeft dat er met een like-operator moet worden gezocht en dus de wildcards volgens de SQL-standaard worden toegepast. ("%" voor een willekeurig aantal tekens, "_" voor één willekeurig teken)
Hierbij zouden we graag zien dat in sectormodellen wordt aangegeven voor welke velden deze optie is toegestaan. Dit omdat het een mogelijk zware operatie kan zijn.
We zijn het met Maarten eens dat dit als een RFC moet worden behandeld en te groot is voor een erratum.
het volgende issue dat hieruit voortvloeit, is die van hoofdletter- ongevoelig zoeken!
zonder deze meteen hierin te betrekkken, hebben we een oplossing die niet afdoende zal zijn voor gebruikers.
Zoals Sid hierboven aangaf, zou ik wel graag een beperkt aantal elementen zien waarop dit mogelijk moet zijn.
@Sid: Goed idee om de wildcards van SQL te gebruiken (%, _, etc.). In de nieuwe stijl waarin we geen attributes meer gebruiken zouden we dat bijvoorbeeld als volgt vorm kunnen geven:
<BG:gelijk>
<StUF:entiteit>
<StUF:entiteittype>NPS</StUF:entiteittype>
</StUF:entiteit>
<BG:geslachtsnaam>
<StUF:waarde>Korver</StUF:waarde>
</BG:geslachtsnaam>
<BG:voorvoegselGeslachtsnaam>
<StUF:noValue>geenWaarde</StUF:noValue>
</BG:voorvoegselGeslachtsnaam>
<BG:voornamen>
<StUF:waarde>Henri%</StUF:waarde>
<StUF:wildcards>true</StUF:wildcards>
</BG:voornamen>
</BG:gelijk>
Binnen het element "voornamen" wordt het nieuwe gereserveerde element "wildcards" gebruikt om aan te geven dat het element "waarde" wildcards kan bevatten, in dit geval het % symbool, en dus als een LIKE afgehandeld moet worden in plaats van als een '='. Wellicht is het een idee om de IN-operator van SQL ook te ondersteunen. Misschien moeten we daarvoor ook nog een syntax voor verzinnen.
Tijdens de StUF Expertgroep van 16 september 2015 is besloten dit ONV om te zetten naar een RFC en het op de lijst te plaatsen van in StUF 3.02 op te lossen RFC's.
Tijdens de StUF Expertgroep van 19 oktober 2016 is besloten dit RFC af te voeren. RFC0418 voorziet immers al een RFC voor deze behoefte.