Tekst doorzoeken in Adobe Acrobat Sign

• Overzicht
• Tekst zoeken
  • HET TITELVELD VAN DE OVEREENKOMST
• Zoeken met speciale querysyntaxis
  • GERESERVEERDE TEKENS EN WOORDEN
  • ZINSOVEREENKOMST
  • PREFIX VELDNAAM
  • JOKERTEKENS
  • BOOLEAANSE UITDRUKKINGEN

Overzicht

Acrobat Sign maakt complexe zoekacties mogelijk om content in de gebruikersovereenkomsten te vinden. De zoekbalk op de pagina Beheren retourneert alle transacties die overeenkomen met een tekenreeks die is opgegeven voor de geselecteerde inhoudsbron.

• Als u ‘Uw overeenkomsten’ weergeeft, zoekt u in uw eigen inhoud. Als u een gedeeld account weergeeft, zoekt u in de inhoud van dat gedeelde account

De inhoud in de onderstaande velden wordt geïndexeerd wanneer een transactie wordt gemaakt of bijgewerkt:

• Titel: titel van de overeenkomst.
• Notitie: een door de deelnemer gemaakte notitie over een privéovereenkomst, die voor niemand anders zichtbaar is.
• Bericht: een lijst met berichten die zichtbaar zijn voor deze deelnemer (inclusief openbare en privéberichten.
• Oorspronkelijke bestandsnaam: oorspronkelijke naam van een geüpload bestand dat bij de overeenkomst hoort.
• E-mail: e-mailadres van de ontvanger (inclusief CC's) of van de afzender.
• Volledige naam: voor- en achternaam van de ontvanger (inclusief CC's) of afzender.
• Functie: functie van de ontvanger (inclusief CC's) of verzender binnen hun bedrijf.
• Bedrijfsnaam: bedrijfs- of organisatienaam van de ontvanger (inclusief CC's) of verzender.
• Naam ontvangersgroep: naam van de ad-hocovereenkomstgroep waartoe ontvangers kunnen behoren.
• Tekstveldinhoud: door de gebruiker verstrekte tekstveldinhoud in het formulier.
• Volledige naam van de deler: volledige naam van de deler van de overeenkomst. In het geval van niet delen is dit de naam van de gebruiker.
• Naam van de ontvangersgroep van de deler: naam van de ontvangersgroep van de deler van de overeenkomst. In het geval van niet delen is dit de naam van de ontvangersgroep van de gebruiker.
• Externe ID: ID toegekend aan de overeenkomst door de afzender. Kan elke vorm aannemen, maar heeft gewoonlijk de vorm '<groupID>:<ID>'. Externe ID wordt doorgegeven in de oproep naar de API voor het maken van overeenkomsten.
• Externe groeps-ID: de afzender heeft een groeps-ID toegewezen aan de overeenkomst die elke vorm kan hebben, meestal gebruikt als voorvoegsel voor de externe ID. De externe groeps-ID wordt in de aanroep doorgegeven aan de API voor het maken van overeenkomsten. U moet een externe ID instellen als u een externe groeps-ID-parameter instelt.
• Transactie-ID: ID die is toegewezen aan de overeenkomst door Acrobat Sign bij het maken.

Tekst zoeken

Stel dat u naar de volgende tekenreeks zoekt: "Een eenvoudige vis"

• Acrobat Sign "tokeniseert" de tekenreeks en gebruikt spaties als scheidingstekens. De tekenreeks in het bovenstaande voorbeeld wordt opgedeeld in drie tokens: Een, eenvoudige en vis
  • Tekens in tekenreeksquery's behoren tot een van de drie verschillende typen: letter, cijfer of scheidingsteken.
  • Tekens die worden behandeld als scheidingstekens (behalve spaties) zijn: ~ ` ! @ # $ % ^ & * ( ) - + = { } [ ] | \ . , : ; " ' < > ? /
    • Punten, dubbele punten en apostrofs blijven onderdeel van een token als tekens voor en na dat symbool van hetzelfde type zijn.
    • Aanhalingstekens die de hele queryreeks omringen, zijn geen scheidingstekens en specificeren een letterlijke tekenreekswaarde (frase)
    • Aanhalingstekens in een queryreeks zijn scheidingstekens en specificeren geen letterlijke tekenreekswaarde.
• Onderscheid tussen hoofdletters is verwijderd. bijv. een, eenvoudige, en vis
• De functie Zoeken probeert vervolgens de volledige tekst van elke token te matchen met een geïndexeerde waarde
  • Complexere tokenisatie vindt plaats voor de Overeenkomsttitel (zie hieronder)
• Er wordt een inclusieve zoekopdracht gebruikt, wat betekent dat elke match die overeenkomt met ten minste één token uit ten minste één doorzoekbaar veld, wordt opgenomen in de geretourneerde dataset
  • De geretourneerde dataset is gesorteerd op relevantiescore waarbij het meest relevante zoekresultaat bovenaan staat.

HET TITELVELD VAN DE OVEREENKOMST

Zoals hierboven vermeld is er een geavanceerde tokenisatie voor het veld Overeenkomsttitel. Dit vanwege een extra 'aangepaste' tokeniser die voornamelijk tokeniseert op contextscheidingstekens (vs. expliciete tekens). Deze aangepaste tokeniser verschilt van de standaardtokeniser op de volgende punten:

• Er worden prefixtokens (tot tien tekens) gegenereerd. Een prefixtoken is de oplopende tekenreeks van een standaardtoken. Als bijvoorbeeld de standaardtoken fish is, zijn de oplopende tokens: f, fi, fis en fish
  • Hierdoor kunt u zoeken naar gedeeltelijke tekenreeksen als u begint met het eerste teken van de token
  • Overeenkomsten halverwege een tekenreeks worden genegeerd. Zoeken naar rent matcht bijvoorbeeld niet met het woord apparently
• Tokens worden gesplitst bij niet-alfanumerieke tekens. Bijvoorbeeld: de tekenreeks Super_Duper levert de volgende tokens op: Super en Duper
  • Onderstrepingstekens (_) zijn geen scheidingstekens in de standaardtokeniser
• Tokens worden gesplitst bij overgangen tussen hoofdletters en kleine letters. Bijvoorbeeld: de tekenreeks PowerShot levert de volgende tokens op: Power en Shot
• Tokens worden gesplitst bij overgangen van letters naar cijfers. Bijvoorbeeld: de tekenreeks XL500 levert de volgende tokens op: XL en 500
• Voorloop- of volgscheidingen van elk token worden verwijderd. Bijvoorbeeld: de tekenreeks XL---42+'Autocoder' levert de volgende tokens op: XL, 42 en Autocoder
• Een genitief (s) aan het eind van elke token wordt verwijderd. Bijvoorbeeld: de tekenreeks: Dave's levert het volgende token op: Dave

Merk op dat u met de combinatie van de standaard en aangepaste tokenisers kunt zoeken naar de volledige tokentekenreeks (met de standaard tokeniser) en het prefixtokens (met de aangepaste tokeniser). Toch komt het niet overeen met een prefixtoken dat een scheidingsteken omspant. 

Voorbeeld: u hebt een overeenkomst Mijn_NDA genoemd

• De standaardtokeniser produceert een token die er als volgt uitziet: mijn_nda
• De aangepaste tokeniser produceert een reeks tokens: m, mijn, n, nd, nda, mijn_, mijn_n, mijn_nd, mijn_nda

Voorbeeld 2: u hebt een overeenkomst met de naam XL500

• De standaard tokeniser produceert een token die er als volgt uitziet: xl500
• De aangepaste tokeniser produceert een reeks tokens: xl500, x, xl, 5, 50, 500, xl5, xl50

Zoeken met speciale querysyntaxis

Zoals hierboven beschreven wordt bij de zoekbewerking in de overeenkomst gezocht naar een match in alle doorzoekbare velden van een overeenkomst. De content van doorzoekbare velden wordt getokeniseerd en die tokens worden vervolgens gematcht met de queryreeks op het moment van de query. Bij een zoekbewerking in een overeenkomst wordt ook een prefixmatch uitgevoerd van maximaal tien tekens voor die tokens. Als er ten minste één tokenmatch wordt gevonden in een overeenkomst, wordt die overeenkomst weergegeven in de zoekresultaten.  Zoekresultaten worden gesorteerd op relevantiescore, waarbij het meest relevante zoekresultaat bovenaan staat.

Overeenkomsten met een volledige veldwaarde, overeenkomsten met van een woordgroep uit een veldwaarde, zoeken naar overeenkomsten die geen bepaalde token bevatten, zoekacties naar overeenkomsten die meerdere tokens tegelijk bevatten (geen woordgroep) kunnen echter alleen worden bereikt met een speciale syntaxis. Sign Generic Query Language (SGQL) is ontwikkeld om tegemoet te komen aan de behoefte van klanten aan deze functies die een speciale syntaxis vereisen.

GERESERVEERDE TEKENS EN WOORDEN

SGQL heeft zeven gereserveerde tekens:

Deze gereserveerde tekens worden gebruikt als operatoren en definiëren taalkenmerken in een zoekopdracht. Als een gereserveerd teken onjuist wordt gebruikt, wordt een syntaxisfout geretourneerd.  

Als u gereserveerde tekens als normale tekens in een zoekopdracht wilt gebruiken, moeten ze worden verwijderd. Bijvoorbeeld de zoekopdracht

alle gereserveerde tekens zijn verwijderd en worden behandeld als normale tekens.

SGQL heeft ook drie gereserveerde woorden voor operatoren:

De operatoren moeten met hoofdletters worden geschreven. Als u operatoren als reguliere tokens in een zoekopdracht wilt gebruiken, moeten ze tussen dubbele aanhalingstekens staan. Bijvoorbeeld:

ZINSOVEREENKOMST

Een reguliere approximatieve query zal overeenkomen als EEN van de tokens in een veld voorkomt (maar niet noodzakelijkerwijs allemaal), en de tokenvolgorde is irrelevant omdat tokens niet samen hoeven voor te komen.

Een query op zinsdeel moet worden gebruikt wanneer een hoofdlettergevoelige exacte zoekactie op zinsdeel in een of meerdere doorzoekbare velden vereist is. Dit geeft de mogelijkheid om te zoeken waar meerdere tokens in hetzelfde veld voorkomen, en die tokens een voor een verschijnen in de volgorde die is gespecificeerd tussen de aanhalingstekens.

Syntaxis voor query op zinsdeel:

  of 

Als de syntaxis van de query niet voldoet aan de regels voor de syntaxis van een zinsdeel query, zal de zoekopdracht een query naar een reguliere match bij benadering uitvoeren in alle doorzoekbare velden.

Bijvoorbeeld, query

komt overeen met overeenkomsten die het zinsdeel "studiegroep" in een van de doorzoekbare velden bevatten. Houd er rekening mee dat het zinsdeel "studiegroep" niet overeenkomt met deze query, omdat het geen hoofdlettergevoelige exact zinsdeel is in vergelijking met "Studiegroep".

Een zinsdeel kan overal in een zoekopdracht worden weergegeven. Bijvoorbeeld:

komt overeen met de titel "Cursusmateriaal voor WISKUNDE 101 Studiegroep" aangezien deze titel de zoekterm "WISKUNDE" en het zinsdeel "Cursusmateriaal" en "Studiegroep" bevat.

PREFIX VELDNAAM

Een veldnaamprefix-query moet worden gebruikt om te zoeken naar slechts één bepaald veld van gebruikersovereenkomsten.

De prefixquery voor de veldnaam moet een veldnaamprefix bevatten, gevolgd door een zoekquery. Notatie querysyntaxis voor veldnaamovereenkomst:

Het veldnaamprefix kan verschijnen vóór een token of vóór een tussen haakjes geplaatst deel van een query. Bijvoorbeeld in de zoekopdracht

worden alle tokens gematcht met het titelveld van de overeenkomst.

In de zoekopdracht hieronder,

heeft alleen het woord "Hallo" een veldnaamprefix en dit woord komt alleen overeen met het titelveld van de overeenkomst. De rest van de woorden en zinnen komen overeen met alle doorzoekbare velden.

Als <field_name> niet is opgegeven, wordt gezocht in alle velden die voor het zinsdeel worden ondersteund. Anders wordt alleen gezocht in het veld <field_name>. 

Als de querysyntaxis niet voldoet aan de regels voor de querysyntaxis van de veldnaamvoorvoegsel, gebruikt Agreement Search de hele query als zoekopdracht en voert een zoekopdracht uit tussen alle doorzoekbare velden. 

De prefixquery van de veldnaam bijvoorbeeld:

zoekt alleen in het veld dat de titel van de overeenkomst bevat.

Hieronder staat een lijst met prefixen die worden ondersteund voor de query naar een veldnaamprefix. De prefixen van veldnamen zijn hoofdletterongevoelig. 

Voor achterwaartse compatibiliteit hebben sommige prefixen voor veldnamen aliassen die qua functionaliteit gelijkwaardig zijn aan de oorspronkelijke prefixen voor veldnamen. Deze aliassen zijn verouderd en zullen eventueel worden verwijderd:

  *  Het voorvoegsel voor de veldnaam 'name' kan worden gebruikt in plaats van 'title'.

 ** Het voorvoegsel voor de veldnaam 'participantEmail' kan worden gebruikt in plaats van 'email'.  

*** Het voorvoegsel voor de veldnaam 'participantName' kan gebruikt worden in plaats van 'fullName'.

JOKERTEKENS

Een jokerteken (sterretje *) kan worden gebruikt om een prefixmatch te doen, gevolgd door een onbeperkt aantal tekens in een token. Uitbreiding met jokertekens is een dure bewerking die tijdens runtime plaatsvindt, dus de volgende syntaxisregels moeten worden gevolgd om deze functie te kunnen gebruiken:

• Voorloopjokertekens zijn niet toegestaan.
• Jokers in het midden van een token zijn niet toegestaan.
• Een veldnaamprefix is vereist voor een token met een operator voor uitbreiding met jokertekens.
• Een jokertekenoperator kan niet meerdere keren in een zoekopdracht worden gebruikt.
• Zoekopdrachten die een jokertekenuitbreiding bevatten, geven een time-outfout als de uitvoeringstijd langer is dan vijf seconden.

Bijvoorbeeld, query

komt overeen met de tokens voor titelvelden

en

Uitbreiding met jokertekens is een dure operatie. Als deze niet verstandig wordt gebruikt, worden veel systeembronnen gebruikt en moet u mogelijk lang wachten op zoekresultaten. Om deze problemen te voorkomen heeft SGQL beperkingen op het gebruik van jokertekens, waardoor de duurste en meest resourceverslindende gebruiksscenario's worden geëlimineerd. Hoe specifieker de tokens zijn, hoe efficiënter de zoekopdracht is. Zoeken naar een specifiek woord of zin is altijd efficiënter dan zoeken met een jokerteken.

BOOLEAANSE UITDRUKKINGEN

SGQL ondersteunt zowel de Booleaanse operators AND, OR, en NOT als het groeperen van deze operators met behulp van haakjes. De operatoren moeten met hoofdletters worden geschreven.

De operator OR wordt altijd geïmpliceerd tussen tokens. Bijvoorbeeld:

is hetzelfde als

Tenzij u ter wille van de duidelijkheid de operator OR wilt opnemen, hoeft u deze niet op te geven.

De operator NOT is alleen van toepassing op de token die onmiddellijk op NOT volgt. Als u de operator NOT wilt toepassen op meerdere tokens, moet u deze tokens tussen haakjes plaatsen.

In de volgende tabel wordt de volgorde beschreven waarin booleaanse expressies worden geëvalueerd.

In de onderstaande tabel vindt u voorbeelden van semantisch equivalente query 's die de operatorprioriteit uitleggen wanneer er geen groepsoperatoren (haakjes) zijn opgegeven.