Aquisição de Vocabulário num
Sistema de Interrogações em Língua Natural
Porfírio P. Filipe 1 , Nuno J. Mamede 2
1 Inst.
Sup. de Eng. de Lisboa, R. Conselheiro Emídio Navarro, 1949-014 Lisboa, Portugal
[email protected]
2 Instituto
Superior Técnico, Av. Rovisco Pais, 1049-001 Lisboa, Portugal
[email protected]
Resumo. No sistema EDITE, um sistema de interrogações em língua natural
para bases de dados, as perguntas do utilizador são traduzidas para uma
linguagem lógica intermédia que é posteriormente traduzida para Structured
Query Language (SQL instrução SELECT), sendo então processadas por um
sistema de gestão de bases de dados que devolve as respostas. Para apoiar o
processo de tradução usa-se um módulo, denominado Modelo Conceptual, que
contém informação sobre o domínio representado na base de dados. Este artigo
descreve uma linguagem declarativa que pode ser usada para definir o
conteúdo do modelo conceptual. O trabalho descrito foi integrado num sistema
usado para formular perguntas em língua natural através da Internet.
1 Introdução
A evolução tecnológica provoca um contínuo desenvolvimento dos sistemas que
usam língua natural, especialmente os que exploram arquitecturas que transformam
sistemas de interrogações que acedem a bases de dados relacionais em agentes
relacionais, integrando língua natural e gráficos explorando as vantagens de ambas as
modalidades [1][5]. A comunicação com o computador foi sempre uma barreira
difícil de ultrapassar. Os utilizadores, para conseguirem tirar partido dos meios
disponibilizados pelo computador, demoram a adaptar-se e, em muitos casos, tem de
existir formação adequada. Esta limitação exige da parte dos projectistas de sistemas
informáticos um esforço para virtualizar determinados comportamentos que facilitem
a comunicação com os utilizadores.
Cada vez mais, no dia a dia, o utilizador comum tem necessidade de consultar
informações que se encontram numa base de dados (BD). Os sistemas de gestão de
base de dados (SGBD), mais comuns, são acedidos empregando a linguagem
Structured Query Language (SQL), mais especificamente a instrução SELECT.
Quando o utilizador pretende interrogar directamente um SGBD, usando SQL, tem
necessidade de conhecer, entre outras coisas menos importantes, a estrutura da base
de dados e saber codificar as interrogações no formato de instruções SELECT. Como
alternativa podem ser desenvolvidas aplicações informáticas para minimizar estes
inconvenientes. Para que o utilizador não tenha de se preocupar com pormenores de
realização, é preferível que as perguntas sejam formuladas em língua natural (LN).
É nesta linha de ideias que surge o sistema EDITE [4][9][10], um sistema de
interrogações em língua natural, que permite aos utilizadores indicarem as perguntas
em LN (Português, Francês, Inglês ou Espanhol) como alternativa à utilização de
linguagens formais para formular interrogações, diálogos ou ecrãs gráficos. O EDITE
disponibiliza uma forma directa e eficiente de consultar uma base de dados
dispensando a aprendizagem de uma linguagem artificial. No entanto, o utilizador não
é dispensado de conhecer a cobertura linguística que é possível utilizar na formulação
de perguntas e que é depende do domínio da aplicação.
Fig. 1. Modelo Relacional do Modelo Conceptual
O princípio de funcionamento do sistema de interrogações é a tradução das
perguntas em língua natural para instruções SELECT. A tradução é feita por etapas:
análise morfológica; análise sintáctica; análise semântica; e tradução para SQL [6][7],
sendo respeitados os constrangimentos conceptuais associados ao domínio da
aplicação. A análise semântica utiliza um modelo conceptual do domínio para
seleccionar as interpretação correctas de cada pergunta.
A estrutura de dados do modelo conceptual é expressa por um modelo de dados
relacional e o seu conteúdo define o vocabulário disponível. O modelo conceptual
também contém toda a informação de apoio á tradução que é dependente da base de
dados do domínio.
O diagrama entidade/associação do modelo de dados relacional que suporta o
modelo conceptual e que também disponibiliza informação de apoio a tradução para
Error! Reference source not found. SQL é apresentado na Fig 1. As tabelas e
colunas indicadas a sombreado contêm dados dependentes da base de dados do
domínio; as outras definem informação do modelo conceptual relativa ao domínio.
Quando se pretende que o sistema de interrogações compreenda uma palavra da
língua natural é necessário acrescentar os símbolos que a representam no modelo
conceptual. A aquisição de vocabulário é o procedimento, descrito neste artigo, que
determina o conjunto de símbolos a incluir no modelo conceptual, e actualiza a base
de dados correspondente (descrita na Fig1).
2 Conceitos
Para clarificar alguns aspectos relacionados com a aquisição de vocabulário
apresentam-se os seguintes conceitos:
Conhecimento Global: abrange todo o conhecimento.
Conhecimento da Aplicação: é uma porção do conhecimento global que contempla
um assunto específico vulgarmente designado por domínio da aplicação.
Conhecimento Explícito: é o conhecimento obtido por consulta directa, sem
inferência, a partir da base de dados do domínio.
Conhecimento Implícito: é o conhecimento obtido a partir da base de dados do
domínio através de um mecanismo de inferência.
Conhecimento Representado: é todo o conhecimento implícito e explícito.
Função de Equivalência: define o algoritmo que permite determinar os dados
associados a um símbolo a partir dos dados associados a outros símbolos
(argumentos da função de equivalência).
Símbolo Equivalente: é definido por uma função de equivalência e está associado
ao conhecimento implícito da base de dados do domínio.
Símbolo Sinónimo: é um símbolo equivalente em que a função de equivalência é a
função identidade.
Símbolo Base : é definido directamente a partir da estrutura relacional da base de
dados do domínio e está associado ao conhecimento explícito.
Símbolo Simples: tem associado uma única palavra na língua natural.
Símbolo Composto: tem associado mais do que uma palavra na língua natural.
Vocabulário Base: conjunto das palavras que referem conceitos representados por
símbolos base no modelo conceptual.
3 Aquisição de Vocabulário
O processo de aquisição de vocabulário baseia-se na associação de palavras da língua
natural a símbolos representados no modelo conceptual. Não existe nenhuma
limitação em quantidade de entidades, propriedades ou associações, que podem ser
representadas (extensibilidade). Uma primeira abordagem consiste em determinar um
conjunto de símbolos, correspondentes às palavras que são empregues num grupo de
perguntas que permitam obter todo o conhecimento explícito da base de dados do
domínio. No entanto a aquisição isolada de palavras é difícil de controlar, dificultando
a percepção do conhecimento incluído no modelo conceptual depois de se adicionar
mais um símbolo. Em alternativa aconselha-se que seja considerado um texto em
língua natural sem grandes pormenores técnicos, visto na perspectiva do utilizador
pouco especializado. O texto é analisado frase a frase, traduzindo-as para predicados
de aquisição de vocabulário, que exprimem os factos enunciados nas frases.
Devido aos símbolos usados na representação do modelo conceptual referirem os
mesmos conceitos expressos através das palavras da língua natural, a aquisição de
vocabulário confunde-se com a caracterização dos símbolos usados no modelo
conceptual. Este processo de aquisição é independente da língua porque o que é
representado simbolicamente são os conceitos expressos pelas palavras [2][3][8].
3.1 Identificação de Símbolos
A representação de conhecimento está limitada pelo detalhe considerado na
representação adoptada e pela forma como o conhecimento é estruturado. A
representação no modelo conceptual deve ter o mesmo detalhe da base de dados do
domínio. Assim, o modelo conceptual tem de representar entidades, propriedades e
associações às quais correspondem tabelas (ou vistas), colunas e associações (chaves
estrangeiras) da base de dados do domínio, ou seja, o modelo conceptual contém
informação sobre a estrutura da base de dados do domínio (meta-informação definida
por um modelo relacional). A aquisição de vocabulário a partir de um texto em língua
natural fornece um enquadramento que ajuda a determinar os conceitos importantes.
É sempre útil observar diagramas, figuras ou outras formas de descrever
conhecimento que possam ajudar na definição das perguntas permitidas. As
metodologias de análise orientadas por objectos devem servir de guia para a aquisição
de vocabulário [12].
3.2 Predicados para Aquisição de Vocabulário
Os predicados de aquisição de vocabulário permitem exprimir factos do domínio da
aplicação que se pretendem representados no modelo conceptual, podendo um mesmo
conceito ser expresso por diferentes predicados dependendo da forma como é
interpretado. Este predicados: são usados para definir conceitos associados ao
domínio (conceptual) da aplicação e para definir informação de apoio à tradução
dependente da base de dados do domínio.
Para optimizar o processo de aquisição de vocabulário é importante ter em conta a
herança através da hierarquia de tipos, caso contrário, a quantidade de predicados de
aquisição aumenta desnecessariamente dificultando a extensibilidade e a reutilização
do modelo conceptual. Um domínio agrupa um conjunto de símbolos que contempla
um tema específico. A indicação do domínio a que um símbolo ou associação
(constrangimento conceptual) pertencem, durante a aquisição de vocabulário, facilita
a reutilização do modelo conceptual noutros domínios (portabilidade).
3.2.1 Constantes @Global, @Virtual, @Transitive e @Ser
São definidos quatro símbolos constantes com significado pré-definido. O símbolo
@Global representa o domínio que agrupa os símbolos e os constrangimentos
conceptuais que são válidos em qualquer domínio.
O símbolo @Virtual representa o domínio que agrupa os símbolos e os
constrangimentos conceptuais que só existem representados no modelo conceptual, ou
seja, que não têm dados associados na base de dados do domínio. Os conceitos
representados no domínio @Virtual não estão contemplados na base de dados do
domínio por serem muito gerais ou muito específicos.
O símbolo @Transitive indica uma associação. Esta associação vai permitir a
pesquisa, em tempo de execução, de associações compostas com base na
transitividade.
O símbolo @Ser indica uma associação. Esta associação é uma associação que para
além de ter um tratamento comum também é usada para definir uma relação de
herança na hierarquia de tipos.
3.2.2 Predicado Domain(Nome_Domínio)
Este predicado estabelece o domínio corrente que passará a ser usado como valor por
omissão durante o processo de aquisição de vocabulário. O predicado Domain usa a
tabela DOMAIN do modelo relacional do modelo conceptual para manter uma lista
actualizada dos domínios existentes.
3.2.3 Predicado Symbol(Designação, Alias [,Tipo] [,Condição])
O predicado Symbol efectua a declaração de um símbolo (Alias), que corresponde a
uma primitiva da linguagem lógica [9][11] usada para expressar a semântica, no
domínio corrente. O argumento Designação deve ser entendido como um comentário
do símbolo usado para interpretar o seu significado. O argumento opcional Tipo está
relacionado com informação de apoio à tradução e indica qual o tipo ou a função de
visualização associada ao símbolo declarado. Quando não é indicado nenhum tipo
assume-se que o tipo é VARCHAR(255). O argumento opcional Condição também está
relacionado com informação de apoio à tradução e indica uma condição SQL a juntar
na cláusula WHERE da tradução quando o símbolo declarado é referido nas
condições a que a resposta deve obedecer. O predicado Symbol preenche as colunas
DESIGNATION, ALIAS, _TYPE_ e _CONDITION_ da tabela SYMBOL do modelo de dados
relacional do modelo conceptual.
3.2.4 Predicado eSymbol(Equivalente, Expressão [,Domínio])
Este predicado expressa uma equivalência entre símbolos, definindo como se obtém o
valor atribuído a um símbolo equivalente a partir de valores atribuídos a outros
símbolo (base ou equivalentes). O primeiro argumento refere o símbolo que está a ser
definido. O segundo argumento, designado genericamente por Expressão, pode ser
um Alias de um símbolo, o que transforma a equivalência na definição de um
símbolo sinónimo (caso particular de equivalência). O segundo argumento também
pode ser uma função de equivalência com uma lista de argumentos ou uma expressão
SQL iniciada pelos sinais ‘+’ ou ‘-‘. O argumento Domínio indica qual o domínio em
que a equivalência é válida. Se não estiver preenchido usa-se o domínio corrente.
O predicado eSymbol preenche pela ordem dos seus argumentos, respectivamente,
as colunas E_SYMBOL e B_SYMBOL da tabela EQ_SYMBOL do modelo de dados relacional.
Os vários argumentos da função de equivalência vão dar origem, caso existam, a
vários registos na tabela EQ_SYMBOL, um por cada argumento que é especificado na
coluna B_SYMBOL. O domínio é guardado na coluna SYMBOL.COD_DOMAIN
3.2.5 Predicado Assoc(Nome, Ent, Ent_Prop [,Domínio] [,Condição])
O predicado Assoc define a associação (no sentido directo), cujo o nome é referido no
primeiro argumento ( Nome), entre o segundo argumento ( Ent) e o terceiro argumento
(Ent_Prop). Estas associações são do tipo um para muitos sendo o sentido da
associação determinado com base na sua cardinalidade, o sentido directo é lido no
sentido muitos para um. O argumento opcional Domínio tem o mesmo significado que
no predicado eSymbol e o argumento Condição tem o mesmo significado que no
predicado Symbol.
O predicado Assoc preenche, pela ordem dos seus argumentos, as colunas ASSOC,
PARAM1, PARAM2, COD_DOMAIN e _CONDITION_ da tabela ASSOCIATION do modelo de
dados relacional. A coluna ASSOCIATION._TYPE_ é sempre preenchida com o carácter
‘D’ que corresponde à representação de associações expressas no sentido directo.
Quando existe mais do que uma associação entre dois símbolos, elas são consideradas
equivalentes entre si. Quando existem várias associações equivalentes apenas a que
tem o identificador de associação mais baixo (coluna ASSOCIATION.COD_ASSOC) está
representada na base de dados do domínio, sendo designada por associação base. No
caso de se pretenderem definir associações que não são equivalentes e que envolvem
as mesmas entidades, deve suspeitar-se que as entidades envolvidas estejam a
desempenhar múltiplos papéis; nessa situação deve ser definido um símbolo
equivalente para cada papel. Quando se pretende indicar que uma associação goza da
propriedade transitiva define-se uma associação com os mesmos argumentos
indicando no argumento Nome, o símbolo pré-definido @Transitive. Quando se
pretende indicar que uma associação também pertence à hierarquia de tipos define-se
uma associação em que o argumento Nome é o símbolo pré-definido @Ser.
3.2.6 Predicado iAssoc(Nome, Ent_Prop, Ent [,Domínio] [,Condição])
Este predicado define a associação no sentido inverso entre o segundo argumento e o
terceiro argumento cujo nome é referido no primeiro argumento. Os argumentos têm
o mesmo significado que no predicado Assoc. A coluna ASSOCIATION._TYPE_ é
sempre preenchida com o carácter ‘I’ que corresponde à representação de associações
expressas no sentido inverso, sendo o preenchimento das restantes colunas da tabela
ASSOCIATION idêntico ao do predicado Assoc.
3.2.7 Predicado cAssoc(Associação, Instâncias_de_Predicados_Assoc)
O predicado cAssoc define uma associação, cujo nome é indicado no primeiro
argumento, que não está directamente representada na base de dados do domínio, mas
que se obtêm a partir da composição de duas ou mais associações. O segundo
argumento é uma lista de instâncias de predicados (associações directas ou inversas)
que são membros da composição e é explicitado usando o formato:
{Assoc1|iAssoc1,Assoc2|iAssoc2[,<Assoc3|iAssoc3>,…]}.
A composição de
uma associação que só tem uma componente é uma associação equivalente que pode
ser directamente expressa pelo predicado Assoc.
Cada predicado Assoc ou iAssoc (convertido no respectivo Assoc) da lista de
instâncias é referido na coluna M_COD_ASSOC originando um registo na tabela
C_ASSOCIATION do modelo de dados relacional.
3.2.8 Predicado Occurrence(Entidade, Propriedade, Valor [,Código])
O predicado Occurrence define a ocorrência de valores que não figuram na base de
dados do domínio mas são importantes para a tradução, permitindo associar
determinados valores a propriedades. O primeiro argumento refere uma entidade, o
segundo argumento uma propriedade, o terceiro um valor (cadeia de caracteres) e o
quarto, que é opcional, refere o código usado para indicar o valor expresso no terceiro
argumento. Quando o quarto argumento não é especificado assume-se a codificação
através de um número inteiro sequencial. Um caso particular de valores de
propriedades que também são representáveis pelo predicado Occurrence são os
nomes próprios que referem, implicitamente, entidades. Quando na pergunta do
utilizador surge um nome próprio, é necessário identificar na base de dados do
domínio qual a tabela e a coluna a que o nome se refere. O predicado Occurrence
preenche pela ordem dos seus argumentos as colunas OC_ENTITY, OC_ATTRIBUTE,
CODE e VALUE da tabela OCCURRENCE do modelo de dados relacional.
3.2.9 Predicado Default(Ent_Prop, Ent_Prop)
Este predicado permite exprimir a propriedade subentendida quando se refere uma
entidade ou a entidade subentendida quando se refere uma propriedade. Qualquer dos
argumentos pode referir uma entidade ou uma propriedade. O predicado Default
preenche as colunas SYMBOL1 e SYMBOL2 da tabela DEFAULT do modelo de dados
relacional. Por exemplo, a propriedade nome pode, num domínio, representar por
omissão uma entidade, existindo no entanto várias entidades com a propriedade nome.
Noutro domínio a propriedade nome pode representar outra entidade distinta.
Uma situação análoga acontece quando se refere uma entidade sem referir uma
propriedade em particular. Por exemplo, uma referência à entidade pessoa, pressupõe
que se pretende referir a propriedade mais significativa de pessoa que, por hipótese,
pode ser a propriedade nome.
3.2.10 Predicado PK(Entidade, Propriedade)
O predicado PK expressa conhecimento sobre as colunas das tabelas da base de dados
do domínio que constituem as chaves primárias. O primeiro argumento refere uma
entidade que é representada por uma tabela à qual pertence a chave primária e o
segundo argumento refere uma propriedade que é representada por uma coluna que
pertence à chave primária. Cada chave primária é representada por um ou mais
predicados PK. Este predicado preenche pela ordem dos seus argumentos as colunas
ENTITY e PK_ATTRIBUTE da tabela KEY_PK do modelo de dados relacional. Cada
predicado PK origina um registo na tabela KEY_PK com o número de sequência
indicado na coluna PK_NSEQ.
3.2.11 Predicado FK(Entidade, Entidade, Propriedade)
O predicado FK expressa conhecimento sobre as colunas das tabelas da base de dados
do domínio que constituem as chaves estrangeiras. O primeiro e o segundo argumento
referem entidades que são representadas por tabelas e o terceiro argumento refere uma
propriedade que é representada por uma coluna que pertence à chave estrangeira.
Uma chave estrangeira é representada por um ou mais predicados FK. Cada predicado
FK origina um registo na tabela KEY_FK com o número de sequência indicado na
coluna FK_NSEQ.
3.3 Abordagens para Aquisição de Vocabulário
Interessa considerar para efeitos de aquisição de vocabulário duas abordagens
caracterizadas por duas situações: uma em que a instalação é nova, outra em que se
realiza uma adaptação a um sistema informático existente.
Numa instalação nova em que não existe nada definido, deve-se começar por
especificar completamente o vocabulário, incorporando todo o conhecimento
importante do domínio da aplicação na representação do modelo conceptual,
expressando-o através de predicados de aquisição de vocabulário. Deve-se considerar
como base de trabalho do processo de aquisição de vocabulário um texto em língua
natural, que resuma os factos que descrevem o conhecimento do domínio a
incorporar. O processamento orientado frase a frase, vai conduzir à determinação do
conjunto de predicados de aquisição de vocabulário. Seguidamente deve ser gerado o
modelo relacional de dados da base de dados do domínio a partir do modelo
conceptual. A base de dados concebida desta forma, é a mais adaptada ao sistema de
interrogações e conduz a uma simplificação do processo de tradução para SQL
minimizando a informação de apoio à tradução.
Quando se quer adaptar o sistema de interrogações em língua natural a uma base de
dados do domínio já existente, deve-se, numa primeira fase, associar um símbolo a
cada tabela, coluna ou chave estrangeira (predicados Symbol). Numa segunda fase,
devem-se definir as associações expressas pelas associações do modelo relacional da
base de dados do domínio (predicado Assoc). Numa terceira fase, deve-se alargar o
âmbito da representação do modelo conceptual (enriquecimento do vocabulário base)
definindo símbolos equivalentes (predicado eSymbol), associações equivalentes
(predicado Assoc e iAssoc), associações compostas (predicado cAssoc) e
associações transitivas (predicado Assoc).
4 Exemplos
Exemplo 1: Considere-se que se pretende representar o facto “pessoa tem estado
civil” em que na base de dados do domínio a propriedade “estado civil” é
representada directamente numa coluna PESSOA.ESTADO_CIVIL que contém as letra
inicias: ‘S’ – “SOLTEIRO”, ‘C’ – “CASADO”, ‘D’ – “DIVORCIADO” e ‘V’ –
“VIÚVO”. A aquisição de vocabulário pode ser expressa por:
Symbol(estado civil, ESTADO_CIVIL)
Symbol(pessoa, PESSOA)
Assoc(TER, PESSOA, ESTADO_CIVIL)
Occurrence(PESSOA, ESTADO_CIVIL, SOLTEIRO, S)
Occurrence(PESSOA, ESTADO_CIVIL, CASADO, C)
Occurrence(PESSOA, ESTADO_CIVIL, DIVORCIADO, D)
Occurrence(PESSOA, ESTADO_CIVIL, VIÚVO, V).
Exemplo 2: Se se considerar que a entidade pessoa desempenha os papéis realizador
e actor, quando pessoa se relaciona com filme a aquisição de vocabulário é
essencialmente expressa por:
eSymbol(PESSOA, ACTOR)
eSymbol(PESSOA, REALIZADOR)
Se
fosse
simplesmente
definido:
Assoc(REALIZAR, FILME, REALIZADOR)
Assoc(REPRESENTAR, FILME, ACTOR)
e
Assoc(REPRESENTAR, FILME, PESSOA) significava, erradamente, que realizar um
filme é equivalente a representar um filme.
Exemplo 3: Para representar os factos “porta bagagem contém mala” e “mala contém
roupa” com a intenção de possibilitar a conclusão através de transitividade do facto
“porta bagagem contém roupa” a aquisição de vocabulário é expressa por:
Assoc(REALIZAR,
FILME,
PESSOA)
Assoc(CONTER, MALA, ROUPA)
Assoc(CONTER, PORTA_BAGAGEM, MALA)
Assoc(@Transitive, PORTA_BAGAGEM, MALA).
Exemplo 4: Considere-se que se está a referir uma base de dados de aluguer de
veículos, onde a hierarquia de tipos sobre veículos é:
A hierarquia de tipos é representada por um
Ve ículo
ícul o
conjunto de associações @Ser. Neste exemplo, as
associações, que representam a hierarquia de tipos
Automóvel
Camião
Automóvel
Cami ão
são:
Assoc(@Ser, MOTA, VEICULO)
Assoc(@Ser, AUTOMOVEL, VEICULO)
Mota
Mota
Assoc(@Ser, CAMIAO, VEICULO).
Exemplo 5: O facto empresa vende produtos pode ser definido como a composição
das associações que caracterizam os factos empresa possui loja e loja vende produtos
sendo a aquisição de vocabulário expressa pelo predicado:
cAssoc(VENDER, {POSSUIR(EMPRESA, LOJA), VENDER(LOJA, PRODUTO)}).
Se na lista de associações membros da composição forem referidas associações
expressas no sentido inverso, estas são convertidas nas associações correspondentes
expressas no sentido directo.
Exemplo 6: Se o utilizador do sistema de interrogações perguntar “Quais os hotéis
com sauna?” a pergunta deve ser interpretada como “Quais os nomes dos hotéis com
sauna?”, assumindo que à entidade “hotel” está associada a propriedade por omissão
“nome”. O facto de à entidade “hotel” estar associado por omissão a propriedade
“nome” é indicado pelo predicado: Default(HOTEL, NOME).
Exemplo 7: Se o facto de uma “freguesia” ter identificação própria apenas no
contexto do respectivo “concelho” for caracterizado no modelo relacional da base de
dados do domínio por uma chave primária com duas colunas COD_FREG (“número
sequencial da freguesia dentro de cada concelho”) e COD_CONC (“número sequencial
do concelho”), a aquisição de vocabulário é realizada por:
Symbol(número sequencial da freguesia, COD_FREG, INTEGER)
Symbol(número sequencial do concelho, COD_CONC, INTEGER)
Symbol(concelho, CONCELHO)
Assoc(TER,FREGUESIA,DESCRICAO)
Symbol(freguesia, FREGUESIA)
PK(CONCELHO, COD_CONC)
Symbol(descrição, DESCRICAO)
PK(FREGUESIA, COD_CONC)
Assoc(TER, CONCELHO, DESCRICAO)
PK(FREGUESIA, COD_FREG)
O diagrama entidade/associação da Fig 2 ilustra uma parte do modelo relacional da
base de dados do domínio a que os predicados PK se referem.
Exemplo 8: Se uma “pessoa” for caracterizada na base de dados do domínio pelo
“número do bilhete de identidade”, “nome” e “freguesia de recenseamento” (como no
diagrama entidade/associação da Fig 2), o essencial da aquisição de vocabulário é
expresso por:
Symbol(bilhete de identidade, nBI)
Symbol(pessoa, PESSOA)
Symbol(nome, NOME)
Assoc(TER, PESSOA, NOME)
Assoc(VOTAR,PESSOA,FREGUESIA)
PK(PESSOA, nBI)
FK(PESSOA, FREGUESIA, COD_CONC)
FK(PESSOA, FREGUESIA, COD_FREG).
Neste exemplo os predicados FK podem ser determinados automaticamente a partir da
definição da chave primária da entidade “freguesia” constituída pelas coluna
COD_CONC e COD_FREG (são iguais).
Se a “pessoa” passar a ter também
uma associação com a “freguesia de
nascimento” não se pode estabelecer
a associação “pessoa tem freguesia
de nascimento” directamente com
“freguesia” pois seria considerado
que o facto “pessoa tem freguesia de
Fig. 2. Exemplo de Representação de Chaves
recenseamento” é equivalente a
“pessoa
tem
freguesia
de
nascimento”. Tem-se, então, de utilizar a definição de símbolos equivalentes a
freguesia, para representar os dois papéis. O diagrama entidade/associação da Fig 3
mostra parte do modelo relacional da base de dados do domínio a que se refere o
exemplo anterior.
Fig. 3. Exemplo de Associação Dupla
A aquisição de vocabulário, neste caso, é expressa, essencialmente, por:
Symbol(freguesia recenseamento, FREG_REC)
Symbol(freguesia nascimento, FREG_NASC)
eSymbol(FREG_REC, FREGUESIA)
FK(PESSOA, FREG_REC, COD_CONC_REC)
eSymbol(FREG_NASC, FREGUESIA)
FK(PESSOA, FREG_REC, COD_FREG_REC)
Assoc(VOTAR, PESSOA, FREG_REC)
FK(PESSOA,FREG_NASC,COD_CONC_NASC)
Assoc(NASCER, PESSOA, FREG_NASC)
FK(PESSOA,FREG_NASC,COD_FREG_NASC).
5 Conclusão
O processo de aquisição de vocabulário define o conhecimento representado no
modelo conceptual usando o conhecimento explícito da base de dados do domínio.
Para alargar o âmbito da representação (cobrir a maior porção possível do
conhecimento do domínio da aplicação) podem definir-se símbolos equivalentes
usando funções de equivalência (para inferir conhecimento implícito).
A extensibilidade do modelo conceptual é assegurada por uma estrutura relacional
que não tem limitações de dimensão e cujo carregamento é facilitado pela utilização
de predicados de aquisição de vocabulário. A portabilidade do modelo conceptual é
assegurada pela associação de um domínio a cada conceito.
O processo de aquisição de vocabulário embora possa ser parcialmente
automatizado, reveste-se de aspectos que exigem sensibilidade para questões que
dependem, em última instância, de cada situação particular, não dispensando a
participação de agentes humanos.
O sistema aqui descrito faz parte do trabalho desenvolvido para o sistema
INTOURISM [http://www.caib.es/ibit], um projecto que pretende estimular o
comércio electrónico de produtos e serviços de pequenas e médias empresas na área
do turismo, sendo possível a formulação de perguntas em língua natural através da
Internet.
Referências
1. Allen, J. 1995. “Natural Language Understanding”. The Benjamin/Cummings Publishing
Company, Inc.
2. Androutsopoulos I., Ritchie G., Thanisch, P. 1993. “An Efficient and Portable Natural
Language Query Interface for Relational Databases”. Proceedings of the 6 th International
Conference on Industrial & Engineering Applications of Artificial Intelligence and Expert
Systems, Edinburgh, U.K., pages 327-330. Gordon and Breach Publishers Inc., U.S.A.
3. Androutsopoulos, I. 1993. “Interfacing a Natural Language Front-End to a Relational
Database (MSc thesis)”. Technical paper 11, Dept. of AI, Univ. of Edinburgh.
4. Androutsopoulos, I. 1994. “Natural Language Interfaces - An Introduction”. Journal of
Natural Language Engineering, Cambridge University Press.
5. Cohen, P.R. 1991. “The Role of Natural Language in a Multimodal Interface”. Technical
Note 514, Computer Dialogue Laboratory, SRI International, 1991.
6. Filipe, P. 1999, “Sistema de Interrogações em Língua Natural para Bases de Dados:
Modelo Conceptual, Aquisição de Vocabulário e Tradução”, M.Sc. Dissertation. Instituto
Superior Técnico, Universidade Técnica de Lisboa.
7. Mamede, N, Filipe, P., 1999. “From Logic to SQL in Natural Language Interfaces for
Databases”.
8. Grosz, B. J., Appelt, D. E., Martin, P. A., Pereira, C. N. 1987. “TEAM: An Experiment in the
Design of Transportable Natural-Language Interfaces”. Artificial Intelligence 32, pages
173-243. Elsevier Science Publishers B.V. (North-Holland).
9. Marques, L. 1996. “Edite - Um Sistema de Acesso a Base de Dados em Língua natural
Análise Morfológica, Sintáctica e Semântica”, .M.Sc. Dissertation. Instituto Superior
Técnico, Universidade Técnica de Lisboa.
10.Reis, P., Mamede, N. 1996. “LIL-SQL. Processamento de Interrogações LIL por Tradução
para SQL”. Technical Report. Grupo de Sistemas e Serviços Telemáticos, INESC.
11.Reis, P., Mamede, N., Matias, J. 1997. Edite – A Natural Language Interface to Databases: a
New Dimension for an Old Approach in “Proceeding of the Fourth International Conference
on Information and Communication Technology in Tourism”, ENTER’ 97, Edinburgh,
Scottland.
12.Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., 1991. “Object-Oriented
Modeling And Design”, Printice-Hall.