Pesquisa de texto no Adobe Acrobat Sign

• Visão geral
• Como funciona a pesquisa de texto
  • O CAMPO TÍTULO DO CONTRATO
• Pesquisar com sintaxe de consulta especial
  • CARACTERES E PALAVRAS RESERVADOS
  • CORRESPONDÊNCIA DE FRASE
  • PREFIXO DO NOME DO CAMPO
  • CURINGAS
  • EXPRESSÕES BOOLEANAS

Visão geral

O Acrobat Sign permite uma pesquisa complexa para localizar conteúdo nos contratos do usuário. A barra de pesquisa, localizada na página Gerenciar, retorna todas as transações que correspondem a qualquer sequência de caracteres fornecida para a fonte de conteúdo selecionada.

• Se estiver visualizando "seus contratos", a pesquisa tem por base seu conteúdo. Se estiver visualizando uma conta compartilhada, você pesquisa o conteúdo de contas compartilhadas

O conteúdo nos campos abaixo é indexado à medida que uma transação é criada/atualizada:

• Título - título do contrato.
• Observação - uma observação de contrato particular feita pelo participante que não é visível para mais ninguém.
• Mensagem - uma lista de mensagens visíveis a este participante (inclui mensagens públicas e privadas).
• Nome original do arquivo - nome original de um arquivo carregado associado ao contrato.
• Email - endereço de email do destinatário (incluindo CCs) ou do remetente.
• Nome completo - nome e sobrenome do destinatário (incluindo CCs) ou remetente.
• Cargo - cargo do destinatário (incluindo CCs) ou remetente dentro da empresa.
• Nome da empresa - nome da empresa ou organização do destinatário (incluindo CCs) ou remetente.
• Nome do grupo de destinatários - nome do grupo de contratos ad-hoc ao qual os destinatários podem pertencer.
• Conteúdo do campo de texto - conteúdo do campo de texto fornecido pelo usuário no formulário.
• Nome completo do compartilhador - nome completo do compartilhador do contrato. Em caso de não compartilhamento, esse é o nome do usuário.
• Nome do grupo de recipients do compartilhador - nome do grupo de recipients do compartilhador do contrato. No caso de não compartilhamento, esse é o nome do grupo de recipients do usuário.
• ID externa - a ID atribuída ao contrato pelo remetente que pode ser de qualquer formato, mas geralmente no formato de "<groupID>:<ID>". A ID externa é transmitida na chamada para a API de criação de contrato.
• ID do grupo externo - a ID do grupo atribuído ao contrato pelo remetente que pode ser de qualquer formato, geralmente usada como um prefixo para a ID externa. A ID do grupo externo é transmitida na chamada para a API de criação de contrato. É necessário definir a ID externa se estiver definindo o parâmetro de ID do grupo externo.
• ID da transação - ID atribuída ao contrato pelo Acrobat Sign na criação.

Como funciona a pesquisa de texto

Se você estava procurando pela sequência de caracteres: "Um peixe simples"

• O Acrobat Sign "tokeniza" a sequência de caracteres usando espaços como delimitadores. A sequência de caracteres do exemplo acima é dividida em três tokens: Um, peixe e simples
  • Os caracteres na consulta de sequência de caracteres pertencem a um dos três diferentes tipos: letra, número ou delimitador.
  • Os caracteres tratados como delimitadores (exceto espaços) são: ~ ` ! @ # $ % ^ & * ( ) - + = { } [ ] | \ . , : ; " ' < > ? /
    • Pontos, dois pontos e apóstrofos permanecem como parte de um token se os caracteres antes e depois desse símbolo forem do mesmo tipo.
    • As aspas que delimitam toda a sequência de consulta não são delimitadores e especificam um valor de sequência de caracteres literal (frase)
    • As aspas dentro de uma sequência de consulta são delimitadores e não especificam um valor de sequência literal.
• A distinção entre maiúsculas e minúsculas foi eliminada. por exemplo, um, simples, e fish
• A pesquisa tenta então corresponder cada texto completo de cada token a um valor indexado
  • Ocorre uma tokenização mais complexa para o Título do contrato (veja abaixo)
• Uma pesquisa inclusiva é usada, o que significa que cada contrato que corresponde a pelo menos um token de pelo menos um campo pesquisável é incluído no conjunto de dados retornado
  • O conjunto de dados retornado é classificado por pontuação de relevância, com o resultado da pesquisa mais relevante no topo.

O CAMPO TÍTULO DO CONTRATO

Como observado acima, o campo Título do contrato tem uma tokenização mais sofisticada devido a um tokenizador "personalizado" adicional, que tokeniza principalmente em delimitadores de contexto (em comparação a caracteres explícitos). Esse tokenizador personalizado é diferente do padrão em que:

• Tokens de prefixo (até dez caracteres) são gerados - Um token de prefixo é a sequência de caracteres incremental de qualquer token padrão. por exemplo, se o token padrão for fish, os tokens incrementais são: f, fi, fis e fish
  • Isso permite procurar sequências parciais, desde que você comece com o primeiro caractere do token
  • As correspondências no meio da sequência de caracteres são ignoradas. Por exemplo, pesquisar a palavra rente não corresponderá à palavra apaentemente
• Divida tokens em caracteres não alfanuméricos. Por exemplo, a sequência de caracteres: Super_Ultra gera os tokens: Super e Ultra
  • Sublinhados não são delimitadores no tokenizador padrão
• Divida tokens em transições de letras maiúsculas e minúsculas. Por exemplo, a sequência de caracteres: PowerShot gera os tokens: Power e Shot
• Divida os tokens em transições de letras e números. Por exemplo, a sequência de caracteres XL500 gera os tokens: XL e 500
• Remover delimitadores iniciais ou finais de cada token. Por exemplo, a sequência de caracteres: XL---42+'Autocoder' gera os tokens: XL, 42 e Autocoder
• Remove os possessivos em inglês ('s) do final de cada token. Por exemplo, a sequência de caracteres: Dave's gera o token: Dave

Observe que a combinação dos tokenizadores padrão e personalizados permite pesquisar a sequência de caracteres completa do token (graças ao tokenizador padrão) e os tokens de prefixo (graças ao tokenizador personalizado). Ainda assim, você não corresponderá um token de prefixo que abrange um delimitador.

Exemplo: se você tiver um contrato chamado My_NDA

• O tokenizador padrão produzirá um token como este: my_nda
• O tokenizador personalizado produzirá uma série de tokens: m, meu, n, nd, nda, my_, my_n, my_nd, my_nda

Exemplo 2: se você tiver um contrato chamado XL500

• O tokenizador padrão produzirá um token como este: xl500
• O tokenizador personalizado produzirá uma série de tokens: xl500, x, xl, 5, 50, 500, xl5, xl50

Pesquisar com sintaxe de consulta especial

Conforme descrito na seção acima, a Pesquisa de contrato executa uma correspondência aproximada entre todos os campos pesquisáveis de um contrato. O conteúdo do campo pesquisável é tokenizado e, em seguida, esses tokens são comparados à sequência de consulta no momento da consulta. A Pesquisa de contrato também executa uma correspondência de prefixo de até dez caracteres para esses tokens. Se pelo menos uma correspondência de token for encontrada em um contrato, esse contrato aparecerá nos resultados da pesquisa.  Os resultados da pesquisa são classificados por pontuação de relevância, com o resultado de pesquisa mais relevante no topo.

No entanto, as correspondências de um valor de campo inteiro, correspondências de uma frase de um valor de campo, pesquisas por contratos que não contêm um token específico e pesquisas por contratos que contêm vários tokens ao mesmo tempo (não uma frase) podem ser obtidas apenas com uma sintaxe especial. A linguagem de consulta genérica do Sign (SGQL) foi desenvolvida para atender às necessidades dos clientes por esses recursos que exigem sintaxe especial.

CARACTERES E PALAVRAS RESERVADOS

A SGQL tem sete caracteres reservados:

Esses caracteres reservados são usados como operadores e definem recursos de idioma em uma consulta de pesquisa. Se um caractere reservado for usado incorretamente, um erro de sintaxe será retornado.  

Para usar caracteres reservados como caracteres regulares em uma consulta de pesquisa, eles precisam ser prefixados por "\". Por exemplo, a consulta de pesquisa

tem todos os caracteres reservados que prefixados por "\" e são tratados como caracteres regulares.

A SGQL também tem três palavras reservadas para operadores:

Os operadores devem estar em maiúsculas. Para usar operadores como tokens regulares em uma consulta de pesquisa, eles precisam ter aspas duplas. Por exemplo:

CORRESPONDÊNCIA DE FRASE

Uma consulta de correspondência aproximada regular será correspondida se QUALQUER um dos tokens aparecer em um campo (mas não necessariamente em todos). A ordem de tokens é irrelevante, pois os tokens não precisam ser exibidos juntos.

Uma consulta de correspondência de frase deve ser usada quando uma pesquisa de frase exata sem distinção entre maiúsculas e minúsculas entre um ou mais campos pesquisáveis for necessária. Isso permite fazer a correspondência quando vários tokens aparecem no mesmo campo, e esses tokens aparecem um após o outro na ordem especificada entre aspas.

Formato de sintaxe de consulta de correspondência de frases:

  ou 

Se a sintaxe de consulta não seguir as regras para uma sintaxe de consulta de correspondência de frase, a pesquisa executará uma consulta de correspondência aproximada habitual entre todos os campos pesquisáveis.

Por exemplo, a consulta

corresponderá aos contratos que contêm a frase “grupo de estudo” em qualquer um dos campos pesquisáveis. Observe que a frase “grupo - estudo” não corresponderá a esta consulta, pois ela não é uma frase exata sem distinção entre maiúsculas e minúsculas como a frase “Grupo de Estudo”.

A correspondência de frase pode aparecer em qualquer lugar dentro de uma consulta de pesquisa. Por exemplo,

corresponderá ao título “Materiais do curso para o grupo de estudo MATEMÁTICA 101”, uma vez que este título contém a palavra-chave “MATEMÁTICA”, bem como as frases “Materiais do curso” e “Grupo de estudo”.

PREFIXO DO NOME DO CAMPO

Uma consulta de prefixo de nome de campo deve ser usada ao procurar apenas um campo específico de contratos do usuário.

A consulta de prefixo de nome de campo deve conter um prefixo de nome de campo seguido por uma consulta de pesquisa. Formato da sintaxe de consulta do prefixo de nome de campo:

O prefixo de nome de campo pode aparecer na frente de um token ou na frente de uma parte entre parênteses de uma consulta. Por exemplo, na consulta de pesquisa

todos os tokens são comparados com o campo de título do contrato.

Na consulta de pesquisa abaixo

somente a palavra "Olá" tem um prefixo de nome de campo e essa palavra é comparada somente com o campo de título do contrato. As demais palavras e frases são comparadas com todos os campos pesquisáveis.

Se o <field_name> não for especificado, todos os campos compatíveis com a correspondência de frase serão consultados. Caso contrário, somente o campo <field_name> será consultado. 

Se a sintaxe de consulta não seguir as regras da sintaxe de consulta do prefixo do nome do campo, a Pesquisa de contrato usará toda a consulta como uma consulta de pesquisa e executará uma pesquisa entre todos os campos pesquisáveis. 

Por exemplo, a consulta prefixo de nome do campo:

realiza uma pesquisa somente no campo que contém o título do contrato.

Abaixo há uma lista de prefixos compatíveis para a consulta de prefixo de nome de campo. Os prefixos de nome de campo não diferenciam maiúsculas de minúsculas. 

Para compatibilidade com versões anteriores, alguns dos prefixos de nome de campo têm aliases que são equivalentes em funcionalidade aos prefixos de nome de campo originais. Esses aliases estão obsoletos e serão eventualmente removidos:

  * O prefixo de nome de campo “name” pode ser usado em vez de “title”.

 ** O prefixo de nome de campo “participantEmail” pode ser usado em vez de “email”.  

*** O prefixo de nome de campo “participantName” pode ser usado em vez de “fullName”.

CURINGAS

Um curinga ( asterisco * ) pode ser usado para fazer uma correspondência de prefixo seguida por um número ilimitado de caracteres em um token. A expansão curinga é uma operação cara que acontece no tempo de execução; logo, as seguintes regras de sintaxe devem ser seguidas para que seja possível usar esse recurso:

• Não são permitidos curingas à esquerda.
• Não são permitidos curingas no meio de um token.
• Um prefixo de nome de campo é exigido para um token que tenha um operador de expansão curinga.
• Um operador curinga não pode ser usado mais de uma vez em uma consulta.
• As consultas que contêm uma expansão curinga retornam um erro de tempo limite se o tempo de execução exceder cinco segundos.

Por exemplo, consulta

corresponde aos tokens de campo de título

e

A expansão com curinga é uma operação cara. Se usada de forma imprudente, ela consome muitos recursos do sistema e você pode ter que esperar muito pelos resultados da pesquisa. Para evitar esses problemas, o SGQL tem restrições ao uso de curingas, o que elimina os casos de uso mais caros e que consomem muitos recursos. Quanto mais específicos forem seus tokens, mais eficiente será a pesquisa. Pesquisar uma palavra ou frase específica é sempre mais eficiente do que uma pesquisa que usa um curinga.

EXPRESSÕES BOOLEANAS

O SGQL é compatível com os operadores booleanos: AND, OR e NOT, bem como o agrupamento desses operadores usando parênteses. Os operadores devem estar em maiúsculas.

O operador OR está sempre implícito entre tokens. Por exemplo,

é o mesmo que

A menos que queira incluir o operador OR por motivos de clareza, não é necessário especificá-lo.

O operador NOT se aplica somente ao token imediatamente após NOT. Para aplicar o operador NOT a vários tokens, você deve colocar esses tokens entre parênteses.

A tabela a seguir descreve a ordem em que as expressões booleanas são avaliadas.

Na tabela abaixo, é possível encontrar exemplos de consultas semanticamente equivalentes que explicam a precedência do operador caso os operadores de agrupamento (parênteses) não sejam fornecidos.