UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMTICA PROGRAMA DE PS-GRADUAO EM COMPUTAO

Aplicao de Ontologias a Bancos de Dados Semi-Estruturados por Ronaldo dos Santos Mello

Exame de Qualificao EQ-45 PGCC-UFRGS

Prof. Carlos Alberto Heuser Orientador

Porto Alegre, Fevereiro de 2000.

Sumrio
Lista de Figuras....................................................................................................................................................5 Lista de Tabelas....................................................................................................................................................7 Lista de Siglas.......................................................................................................................................................8 Resumo ...............................................................................................................................................................9 Abstract...............................................................................................................................................................10 1 Introduo........................................................................................................................................................11 2 Dados Semi-Estruturados................................................................................................................................13 3 Modelagem......................................................................................................................................................15 1..................................................................................................................................................................16 2..................................................................................................................................................................16 7..................................................................................................................................................................16 6..................................................................................................................................................................16 5..................................................................................................................................................................16 3..................................................................................................................................................................16 4..................................................................................................................................................................16 8..................................................................................................................................................................16 9..................................................................................................................................................................16 10................................................................................................................................................................16 11................................................................................................................................................................16 12................................................................................................................................................................16 13................................................................................................................................................................16 3.1 Modelos de Dados....................................................................................................................................17 3.1.1 OEM..................................................................................................................................................17 3.1.1.1 Caractersticas.............................................................................................................................17 3.1.1.2 Comparao com Outros Modelos de BD..................................................................................18 3.1.2 ADM..................................................................................................................................................18 3.1.3 Comparao entre os Modelos..........................................................................................................21 3.2 Data Guides..............................................................................................................................................22 4 Linguagens de Consulta...................................................................................................................................24 4.1 Requisitos para Consulta a Dados Semi-Estruturados.............................................................................24 4.2 Taxionomia de Linguagens para a Web...................................................................................................26 4.3 Propostas...................................................................................................................................................26 4.3.1 StruQL...............................................................................................................................................27 4.3.2 Lorel...................................................................................................................................................28 4.3.3 UnQL.................................................................................................................................................31 4.3.4 WebSQL............................................................................................................................................33 4.3.5 WQL..................................................................................................................................................34 4.3.6 WebLog.............................................................................................................................................36 4.3.7 Ulixes.................................................................................................................................................38 4.3.8 XML-QL ...........................................................................................................................................39 4.3.9 Comparao entre as Linguagens......................................................................................................44 5 Extrao de dados............................................................................................................................................47 5.1 Mediadores...............................................................................................................................................47 5.2 Wrappers...................................................................................................................................................49 5.3 Tcnicas de Extrao................................................................................................................................51 5.3.1 Extrao Sinttica..............................................................................................................................51 5.3.1.1 Extrao Manual ........................................................................................................................52 5.3.1.1.1 Estratgia de TSIMMIS.......................................................................................................52 5.3.1.1.2 Estratgia de ARANEUS.....................................................................................................55 5.3.1.2 Extrao Semi-Automtica.........................................................................................................56 5.3.2 Extrao Semntica...........................................................................................................................58 5.3.2.1 Extrao Baseada em Frames.....................................................................................................58 5.3.2.2 Extrao Baseada em Ontologias ..............................................................................................60

5.3.3 Comparao das tcnicas...................................................................................................................66 6 Sistemas ..........................................................................................................................................................68 6.1 STRUDEL................................................................................................................................................68 6.2 LORE........................................................................................................................................................69 6.3 ARANEUS...............................................................................................................................................71 6.4 Comparao entre os Sistemas.................................................................................................................74 7 Concluso........................................................................................................................................................76 Parte II Profundidade : Aplicao de Ontologias a Bancos de Dados Semi-Estruturados..............................79 8 Introduo........................................................................................................................................................79 9 Ontologias Conceitos Bsicos......................................................................................................................80 9.1 Definio..................................................................................................................................................80 9.1.1 Definio de Grubber........................................................................................................................80 9.1.2 Definio de Fikes.............................................................................................................................80 9.1.3 Definio de Bzivin.........................................................................................................................81 9.1.4 Definio de Guarino.........................................................................................................................81 9.1.5 Anlise das Definies......................................................................................................................82 9.2 Caractersticas...........................................................................................................................................82 9.3 Classificaes ..........................................................................................................................................84 9.4 Aplicaes................................................................................................................................................85 10 Especificao de Ontologias..........................................................................................................................87 10.1 Formalismos...........................................................................................................................................87 10.1.1 KIF...................................................................................................................................................87 10.1.2 Lgica de Descrio .......................................................................................................................89 10.1.3 Comparao entre os Formalismos..................................................................................................90 10.2 Linguagens.............................................................................................................................................91 10.2.1 Ontolingua.......................................................................................................................................91 10.2.2 Loom................................................................................................................................................94 10.2.3 Outras Propostas..............................................................................................................................97 10.2.3.1 UML/OCL................................................................................................................................97 10.2.3.2 Projeto KRAFT.........................................................................................................................99 10.2.4 Comparao entre as Linguagens..................................................................................................101 10.3 Sistemas................................................................................................................................................101 10.3.1 Servidor Ontolingua......................................................................................................................102 10.3.2 Ontosaurus.....................................................................................................................................105 10.3.3 WebOnto........................................................................................................................................106 10.3.4 Comparao entre os Sistemas......................................................................................................110 10.4 Metodologias........................................................................................................................................113 11 Propostas de Aplicao de Ontologias a Bancos de Dados Semi-Estruturados..........................................120 11.1 O Sistema de Informao Global Observer..........................................................................................120 11.1.1 Viso Geral....................................................................................................................................120 11.1.2 Arquitetura.....................................................................................................................................121 11.1.3 Detalhes do Processamento de Consultas......................................................................................123 11.2 A Linguagem SHOE.............................................................................................................................125 11.3 Ontobroker............................................................................................................................................129 11.3.1 Arquitetura.....................................................................................................................................129 11.3.2 Modelagem Conceitual de Documentos XML..............................................................................131 11.4 Proposta de Embley .............................................................................................................................133 11.5 InfoSleuth.............................................................................................................................................134 11.5.1 Ontologias do Sistema...................................................................................................................135 11.5.2 Arquitetura Baseada em Agentes...................................................................................................136 11.5.2 Acesso a Dados de Documentos ...................................................................................................138 11.6 MOMIS.................................................................................................................................................139 11.6.1 Construo da Ontologia Compartilhada.......................................................................................141 11.6.2 Construo da Viso Integrada de Mediao................................................................................143 11.6.3 Otimizao de Consultas Globais..................................................................................................145 11.7 WebKB.................................................................................................................................................145

11.8 Anlise das Propostas...........................................................................................................................147 12 Concluso....................................................................................................................................................151 Bibliografia.......................................................................................................................................................152

Lista de Figuras
FIGURA 3.1 Exemplo de um objeto semi-estuturado (a) e sua representao em um modelo de dados baseado em grafo (b) .................................................................... 15 FIGURA 3.2 - Exemplo de um esquema ADM ............................................................ 20 FIGURA 3.3 - Um data guide para um objeto semi-estruturado do tipo Artigo........... 22 FIGURA 4.1 - Exemplo de um modelo de dados XML ordenado................................ 39 FIGURA 4.2 - Exemplo de representao de um valor composto no modelo XML..... 40 FIGURA 5.1 - Arquitetura bsica de mediadores.......................................................... 47 FIGURA 5.2 - Dados exemplo apresentados em uma pgina HTML para extrao..... 51 FIGURA 5.3 - Parte do arquivo HTML que mantm dados sobre previso do tempo.. 52 FIGURA 5.4 - Exemplo de arquivo de entrada para o extrator...................................... 53 FIGURA 5.5 - Exemplo de objeto OEM resultante da extrao.................................... 53 FIGURA 5.6 - Trecho de programa em Editor para extrao de dados......................... 55 FIGURA 5.7 - Interface da ferramenta Nodose............................................................. 56 FIGURA 5.8 - Exemplo de um frame de definio de conceito ................................... 58 FIGURA 5.9 - Um documento exemplo dados de obiturios .................................... 59 FIGURA 5.10 - Modelo ontolgico para o domnio de obiturios ............................... 60 FIGURA 5.11 - Exemplo de um frame de descrio de dados ..................................... 61 FIGURA 5.12 - Exemplo de especificao de esquema de BD .................................... 61 FIGURA 5.13 - Exemplo de parte de uma tabela descritor/string/posio ................... 63 FIGURA 5.14 - Exemplos de inseres de dados no perfeitas .................................... 65 FIGURA 6.1 - Arquitetura do Sistema STRUDEL ....................................................... 67 FIGURA 6.2 - Arquitetura do sistema LORE ............................................................... 69 FIGURA 6.3 - Arquitetura do sistema ARANEUS ....................................................... 71 FIGURA 9.1 - Arquitetura do modelo MOF.................................................................. 80 FIGURA 9.2 - Relacionamento entre os tipos de ontologia quanto ao nvel de dependncia .................................................................................................................... 83 FIGURA 10.1 - Especificao de uma ontologia utilizando as linguagens UML e OCL 97 FIGURA 10.2 - Evoluo conjunta de metadados de um BDOO e de um modelo ontolgico antes (a) e aps (b) uma transao de atualizao ........................... 99 FIGURA 10.3 - Arquitetura do Servidor Ontolingua .................................................... 101 FIGURA 10.4 - Interface de navegao em classes de ontologias ................................ 102 FIGURA 10.5 - Interface de edio de classes de ontologias ........................................ 103 FIGURA 10.6 - Interface de navegao da ferramenta Ontosaurus ............................... 106 FIGURA 10.7 - Interface de edio da ferramenta Ontosaurus ..................................... 107 FIGURA 10.8 - Arquitetura do cliente WebOnto .......................................................... 108 FIGURA 10.9 - Interface de exibio de ontologias de WebOnto ................................ 109 FIGURA 10.10 - Janela de exibio de classe em WebOnto ......................................... 109 FIGURA 10.11 - Edio de uma classe em WebOnto ................................................... 110 FIGURA 11.1 - Tipos de relacionamento entre ontologias no sistema Observer .......... 117 FIGURA 11.2 - Arquitetura do sistema Observer .......................................................... 119 FIGURA 11.3 - Trecho de cdigo na linguagem SHOE que especifica uma ontologia . 123 FIGURA 11.4 - Instncia de um conceito descrita em SHOE ........................................ 124 FIGURA 11.5 - Interface grfica da ferramenta de marcao de SHOE ........................ 125 FIGURA 11.6 - Arquitetura da ferramenta Ontobroker .................................................. 125

FIGURA 11.7 Procedimento de extrao baseado em ontologia ................................ 129 FIGURA 11.8 Classes de agentes de InfoSleuth ......................................................... 132 FIGURA 11.9 - Exemplos de expresses de tpicos associados a elementos da ontologia .......................................................................................................................... 134 FIGURA 11.10 - Exemplos de dados de uma fonte semi-estruturada (a) e estruturada (b) para um domnio hospitalar .................................................................... 135 FIGURA 11.11 - Ontologia compartilhada gerada para um domnio hospitalar ........... 138 FIGURA 11.12 - rvore de afinidade para o domnio hospitalar exemplo ................... 139 FIGURA 11.13 - Ontologia de relaes (a) e de conceitos (b) de WebKB ................... 141 FIGURA 11.14 - Trecho de cdigo de um documento HTML (a) onde esto definidos conceitos e relaes na linguagem de WebKB referentes a uma imagem (b) presente no documento ................................................................................. 142

Lista de Tabelas
TABELA 2.1 - Diferenas entre dados tradicionais e dados semi-estruturados ............. 13 TABELA 3.1 - Comparao entre os modelos de dados OEM e ADM .......................... 21 TABELA 4.1 - Requisitos para linguagens de consulta a dados semi-estruturados atendidos pelas linguagens propostas na literatura .......................................................... 43 TABELA 4.2 - Caractersticas particulares suportadas pelas linguagens propostas na literatura ...................................................................................................................... 44 TABELA 5.1 - Comparao entre as tcnicas de extrao ............................................. 66 TABELA 6.1 - Comparao entre caractersticas dos sistemas gerenciadores de dados semi-estruturados .................................................................................................. 74 TABELA 10.1 - Comparao entre os formalismos KIF e LD ...................................... 90 TABELA 10.2 - Comparao entre as linguagens e propostas de especificao de ontologias ........................................................................................................................ 100 TABELA 10.3 - Comparao entre os sistemas de manipulao de ontologias ............ 111 TABELA 10.4 - Comparao entre metodologias para construo de ontologias ......... 115 TABELA 11.1 Comparao entre as propostas de aplicao de ontologias a BDSEs 143

Lista de Siglas
ADM BD BDSE EC DTD HTML OID OEM RI SGBD SQL URL VRML WWW XML API BDOO CE ES IA LD LDD OO RC SBC - Araneus Data Model - Banco de Dados - Banco de Dados Semi-Estruturado - Expresso de Caminho - Data Type Description - HyperText Markup Language - Object IDentity - Object Exchange Model - Recuperao de Informao - Sistema de Gerenciamento de Banco de Dados - Structured Query Language - Uniform Resource Locator - Virtual Reality Modeling Language - World Wide Web - eXtensible Markup Language Application Program Interface Banco de Dados Orientado a Objetos Comrcio Eletrnico Engenharia de Software Inteligncia Artificial Lgica de Descrio Linguagem de Descrio de Dados Orientao a Objetos/Orientado a Objetos Representao de Conhecimento Sistema Baseado em Conhecimento

Resumo
Este exame de qualificao apresenta o estado da arte de bancos de dados semiestruturados e uma relao entre eles e o conceito de ontologia atravs da anlise de propostas de aplicao de ontologias a bancos de dados semi-estruturados. A parte de abrangncia destina-se ao estudo de bancos de dados semi-estruturados. Um banco de dados semi-estruturado gerencia dados altamente heterogneos e que no possuem um esquema prvio associado, como o caso de dados da Web. Analisam-se os seguintes aspectos: modelagem, linguagens de consulta, mecanismos de extrao de dados e alguns sistemas desenvolvidos. A parte de profundidade dedicada inicialmente ao estudo de ontologias. Uma ontologia, do ponto de vista de banco de dados, uma especificao parcial de um domnio e/ou meta-domnio da realidade, que descreve basicamente conceitos, relaes e regras de integridade. Algumas definies e linguagens/sistemas de especificao so mostrados. Na seqncia, propostas de aplicao de ontologias a bancos de dados semi-estruturados so descritas e comparadas. Ontologias em bancos de dados semi-estruturados so bastante teis como suporte semntico de consenso para tornar mais eficiente o acesso e a manipulao de dados. Este trabalho segue uma abordagem de levantamento bibliogrfico, ou seja, so descritas diversas propostas relacionadas a um tpico seguida de uma anlise comparativa destas propostas.

Palavras-Chaves:

dados semi-estruturados, ontologias, representao de conhecimento, Web

modelagem

conceitual,

10

TITLE: Application of Ontologies in Semistructured Databases

Abstract
This report presents the state-of-art of semistructured databases, and a relation between them and the concept of ontology through the analysis of some works that uses ontologies in semistructured databases. The broad treatment part is dedicated to the study of semistructured databases. A semistructured database manages highly heterogeneous data that do not have an associated schema. Web data is an example. The following features are analysed: modelling, query languages, data extraction and some systems. The in-depth treatment part is first dedicated to the study of ontologies. An ontology is, in a database point of view, a partial specification of a domain and/or metadomain describing basically concepts, relationships and integrity constraints. Some definitions and specification languages/systems are shown. After, works related to the application of ontologies in semistructured databases are described and compared. Ontologies in semistructured databases are very useful as consensual semantic support for efficient data access and manipulation. This work is a survey, describing and comparing some proposals related to specific topics.

Keywords:

semistructured data, representation, Web

ontologies,

conceptual

modelling,

knowledge

11

Parte I Abrangncia : Bancos de Dados Semi-Estruturados 1 Introduo

Dados manipulados atravs de Sistemas Gerenciadores de Bancos de Dados (SGBDs) disponveis comercialmente, como tabelas ou classes de objetos complexos, apresentam uma estrutura de representao (esquema) previamente definida. O acesso e a manipulao dessas estruturas so tarefas especficas do SGBD. Ao usurio cabe formular consultas atravs de uma interface textual ou visual, ocorrendo posteriormente um mapeamento das solicitaes de dados para atributos das estruturas associadas, para fins de acesso. Por outro lado, nota-se, j h algum tempo, que boa parte dos dados disponveis para acesso eletrnico no esto mantidos em BDs. Exemplos desses dados so diretrios de arquivos de documentos (atas de reunies, processos, etc) de uma organizao ou informaes acessveis atravs da Internet. No mbito da Internet, fontes de dados da World Wide Web (WWW) (ou simplesmente dados Web) so atualmente o principal alvo de consulta a nvel mundial. A justificativa para tal fato decorre da prpria natureza desses dados. Dados Web, por exemplo, apresentam uma organizao bastante heterognea, que pode variar de um texto sem nenhuma formatao at um conjunto de registros bem formatados [Abi97, Nes97]. Alm disso, o volume desses dados bastante grande e com muitos relacionamentos. Considerando dados referentes a um curriculum vitae, pode-se ter um pequeno texto informal descrevendo dados pessoais e experincia profissional ou, no extremo oposto, um documento organizado em sees e subsees, com vrias referncias (links) para dados das empresas e instituies onde a pessoa trabalhou. A alta heterogeneidade desses dados torna complexa as atividades de pesquisa uma vez que no existe uma estrutura padro a partir do qual uma consulta possa ser formulada. Pesquisas so, em geral, realizadas atravs de navegao exaustiva ou busca por palavraschave [Ash97,Cat98, Azt97]. No primeiro caso, uma necessidade de informao do usurio pode ser invivel de ser encontrada, devido ao grande volume de dados. No segundo caso, so utilizadas tcnicas de recuperao de informao (RI), com indexao de termos presentes em textos, podendo existir pesos associados aos mesmos para indicao de relevncia no texto especfico. As desvantagens dessas tcnicas so o custo de manuteno dos ndices e o volume da resposta fornecida (muitas referncias a textos completos), ficando a anlise de relevncia da informao basicamente por conta do usurio. Dados que se enquadram nessas caractersticas so denominados dados semiestruturados. O gerenciamento desses dados traz novos desafios comunidade cientfica de BD, uma vez que a tecnologia atual de BD no pode ser aplicada, pois no possvel definir um esquema rgido de representao (nos moldes do modelo relacional ou orientado a objetos) e, conseqentemente, uma linguagem de consulta associada. A busca imediata de superaes para esses desafios, levando em conta tambm o crescente uso da Web, motiva o estudo e desenvolvimento de tcnicas de gerenciamento de dados semi-estruturados, ou seja, a pesquisa em BDs semi-estruturados (BDSEs).

12

Diversos tpicos de pesquisa fazem parte da rea de BDSEs. Os tpicos em maior evidncia so: modelagem, consulta e extrao de dados. Esses tpicos so descritos nos captulos posteriores, aps um detalhamento maior sobre a definio e as caractersticas de dados semi-estruturados, no captulo 2. O captulo 3 analisa aspectos de modelagem e detalha dois modelos de dados semi-estruturados. O captulo 4 trata de requisitos para linguagens de consulta e analisa algumas propostas presentes na literatura. O captulo 5 aborda extrao de dados, conceituando mediadores e wrappers e analisando tcnicas de extrao. O captulo 6 apresenta alguns sistemas de gerenciamento de dados semiestruturados e o captulo 7 reservado concluso.

13

2 Dados Semi-Estruturados
Uma definio objetiva de dados semi-estruturados encontrada em [Abi97b]: dados semi-estruturados so dados que apresentam uma representao estrutural irregular, no sendo nem totalmente crus (sem nenhuma estrutura) nem estritamente tipados. Dados Web, por exemplo, se enquadram nessa definio: em alguns casos os dados possuem alguma estrutura (listas de referncias retornadas por mquinas de pesquisa), em outros a estrutura est total ou parcialmente embutida no dado (documentos no formato de artigo) ou quase no apresentam informaes descritivas (imagens). Buneman [Bun97] argumenta que dados semi-estruturados so dados nos quais o esquema de representao est presente juntamente com o dado, ou seja, o mesmo autodescritivo. Isso significa que uma anlise do dado deve ser feita para que a sua estrutura possa ser identificada e extrada. As caractersticas principais de dados semi-estruturados so [Abi97b, Flo98]: Definio posteriori: esquemas para dados semi-estruturados so usualmente definidos aps a existncia dos dados, com base em uma investigao de suas estruturas particulares e da anlise de similaridades e diferenas. Essa caracterstica vai de encontro aos dados de BDs tradicionais, cujo esquema sempre definido antes dos dados (definio priori). Isso no significa que sempre existe um esquema associado a dados semi-estruturados; Estrutura irregular: colees extensas de dados semanticamente similares apresentam estruturas diferentes, podendo algumas ocorrncias terem informaes incompletas ou adicionais. Em suma, no existe um esquema padro para esses dados. Documentos com informaes sobre curriculum vitae, so um exemplo. Outro exemplo pode ser um endereo pessoal, que pode ser apresentado tanto como um tipo string como um tipo estruturado formado por rua, cidade e CEP; Estrutura implcita: muitas vezes existe uma estrutura bsica para os dados, porm, essa estrutura est implcita na forma como os dados so apresentados. necessrio realizar uma computao para obter essa estrutura; Estrutura parcial: apenas parte das informaes apresentadas podem ter alguma estrutura, seja implcita ou explcita. Por exemplo, componentes de objetos que so arquivos bitmaps so no-estruturados. J dados pessoais podem ter uma estrutura bsica implcita ou explcita. Como conseqncia, um esquema para esses dados pode nem sempre completo do ponto de vista semntico, ou seja, nem sempre todas as informaes esperadas esto presentes; Estrutura extensa: a ordem de magnitude de uma estrutura para esses dados grande, uma vez que os mesmos so muito heterogneos. Supondo os diferentes formatos para um curriculum vitae, uma unio de atributos significativos em cada formato pode produzir um esquema extenso em termos de quantidade de informaes; Estrutura evolucionria: a estrutura dos dados modifica-se to freqentemente quanto os seus valores. Dados Web apresentam esse comportamento, uma vez

14

que existe o interesse em manter sempre dados atualizados. Essa atualizao envolve normalmente incluso, alterao ou excluso de informaes; Estrutura descritiva e no prescritiva: dada a natureza irregular e evolucionria dos dados, o esquema esttico normalmente se restringe a descrever o estado corrente de poucas ocorrncias de dados similares. Dessa forma, no possvel prescrever muitas restries de integridade com relao semntica dos atributos. Um sinnimo para estrutura descritiva estrutura indicativa; Distino entre estrutura e dados no clara : como a estrutura est embutida na representao dos dados, muitas vezes a distino lgica entre estrutura e valor no clara. Pode-se ter, por exemplo, um nome mantido como um valor em uma ocorrncia de dado (string) ou como um tipo (objeto de uma classe nome, com atributos primeiro_nome e sobrenome) em outra ocorrncia. Essa caracterstica torna mais complicado o projeto de um BD para tais dados.

As caractersticas de dados semi-estruturados apresentam vrias diferenas, se comparadas com as caractersticas de dados mantidos em BDs tradicionais, como dados relacionais. A tabela 1 sumariza essas diferenas, acentuando mais ainda a necessidade de pesquisa em novas tcnicas de BD para o tratamento de dados semi-estruturados. BDs tradicionais apresentam um esquema predefinido e uma estrutura homognea a nvel de atributos e tipos. Esse esquema serve de base para a insero, consulta e outras operaes sobre os dados. Em se tratando de dados semi-estruturados, cada ocorrncia de dado pode ser heterognea nos dois aspectos mencionados anteriormente. Assim, fica muito difcil existir um estrutura padro para represent-los. Dada essa heterogeneidade, em geral a estrutura de um dado semi-estruturado est presente na prpria descrio do dado, necessitando ser identificada e extrada. Essas tarefas so complexas, uma vez que a distino entre esquema e dados nem sempre clara, se compararmos ocorrncias diferentes de dados semanticamente iguais. Como cada dado pode ter uma representao particular, um estrutura de representao para um conjunto de dados tende a ser extensa, de forma a refletir as particularidades de cada um deles. Fica tambm complicado definir restries de integridade que possam ser aplicadas a um conjunto de dados. J em um BD tradicional, todas as ocorrncias de um mesmo tipo de dado esto descritas uma nica vez em um estrutura independente e obviamente mais reduzida. Como existe regularidade de representao, mais fcil definir (ou prescrever) restries de integridade semnticas aplicveis a todas as ocorrncias de dados. TABELA 2.1 - Diferenas entre dados tradicionais e dados semi-estruturados Dados tradicionais Dados semi-estruturados Esquema predefinido Inexistncia de esquema predefinido Estrutura homognea Estrutura heterognea Estrutura independente dos dados Estrutura embutida no dado Estrutura reduzida Estrutura extensa Estrutura fracamente evolutiva Estrutura fortemente evolutiva Estrutura prescritiva Estrutura descritiva Distino entre estrutura e dado Distino entre estrutura e dado no clara clara

15

3 Modelagem
Um modelo de dados define a organizao lgica de esquemas de dados mantidos por um BD [Dat91, Kor93]. Modelos de dados para BDs tradicionais no so adequados a BDSEs, uma vez que todas as ocorrncias de dados devem apresentar a mesma estrutura. Considerando um BD relacional, fcil representar dados pessoais de um cliente, por exemplo, em uma tabela, uma vez que esses dados so geralmente padronizados (nome, RG, estado civil, endereo, etc). Por outro lado, representar ocorrncias de documentos ou pginas HTML mais complicado, dada a heterogeneidade das informaes. Assim, modelos de dados para BDSEs devem apresentar uma estrutura que suporte essa heterogeneidade. Segundo Abiteboul [Abi97b], um modelo para dados semi-estruturados deve ser um modelo simples e rico ao mesmo tempo. Um modelo simples no apresenta muitos construtores semnticos para representar um esquema. Dada a grande diversidade estrutural de dados semi-estruturados, a utilizao de um modelo complexo exigiria muitos construtores para representar essa diversidade, tornando complicado o processo de modelagem. Por outro lado, um modelo rico permite tirar vantagem de algumas estruturaes particulares para facilitar a representao de dados semi-estruturados, como tipos atmicos, colees e tipos compostos. A forma mais usual de modelar dados semi-estruturados atravs de grafos direcionados rotulados, onde os vrtices representam objetos identificveis e as arestas so arcos para outros objetos que fazem parte da sua estrutura. Um rtulo presente em um arco indica o nome do atributo do objeto de onde o arco parte (objeto origem), podendo ainda informar o tipo de dado do objeto alcanvel atravs do arco (objeto destino). Como cada ocorrncia de dado pode ter uma estrutura diferente, no deve haver restrio no nmero de arcos que partem de um dado objeto [Flo98, Bun98]. A figura 3.1 ilustra um exemplo de um objeto semi-estruturado (a) e sua representao em um modelo de grafo (b). O objeto em questo um documento de um BD de documentos que descreve um artigo. Tal artigo apresenta um ttulo, autores, instituio e endereo eletrnico dos autores, resumo e um conjunto de sees ( introduo, concluso, etc). O grafo em (b) mostra uma das possveis alternativas de representao da composio desse artigo. Pode-se imaginar uma raiz nica para todo o BD semi-estruturado (indicado pelo objeto R), que agrega todos os documentos armazenados e, na seqncia, ligaes para tipos de documentos, sendo um deles o artigo em questo. Os nmeros nos vrtices podem ser imaginados como identificadores de objetos. Tipos de dados para os arcos, apesar de no mostrados na figura, poderiam ser definidos, como por exemplo, string, para o arco Ttulo.

16

BDs Semi-Estruturados
Ronaldo Mello Carlos Heuser
UFRGS e-mails: {ronaldo,heuser}@inf.ufrgs.br

Resumo

------------------------------------------------------------------------------------------------1 Introduo

-------------------------------------------------...
n Concluso

-------------------------------------------------Bibliografia

--------------------------------------------------

(a) R
Documentos

Artigo

...

Ttulo

Autor

Autor
Carlos Heuser

Resumo
Resumo.txt

Sees Bibliografia

BDs Semi-Estruturados

Ronaldo Mello

e-mail

Instituio Instituio
UFRGS

e-mail

Introduo

...

Concluso
Conclu.txt

ronaldo@inf.ufrgs.br

heuser@inf.ufrgs.br

Intro.txt

Biblio.txt

(b) FIGURA 3.1 - Exemplo de um objeto semi-estuturado (a) e sua representao em um modelo de dados baseado em grafo (b) O modelo de grafo apropriado para representar dados semi-estruturados pois o esquema particular de cada dado j est embutido na prpria estrutura do grafo, ou seja, o dado auto-descritivo. Nesse sentido, os arcos tm uma importncia fundamental, uma vez que nomeiam os atributos e tipos que fazem parte da estrutura do dado [Suc97]. Esse modelo pode ser considerado simples e rico. Simples pois sua estrutura baseada em

17

apenas dois conceitos (vrtices e arcos) e rico pois os arcos descrevem implicitamente os tipos que fazem parte da estrutura dos objetos, como a identificao de um tipo atmico ttulo (tipo string), um conjunto de autores (vrios rtulos com o nome autor) e um tipo composto autor (formado por e-mail e instituio).

3.1 Modelos de Dados 3.1.1 OEM

3.1.1.1 Caractersticas OEM (Object Exchange Model) um modelo de dados orientado a grafo proposto no projeto Tsimmis, do Departamento de Cincia da Computao da Universidade de Stanford [Pap95,Ham97]. Esse modelo tem sido bastante aceito na comunidade de pesquisa em BDSEs por ser simples e flexvel suficiente para permitir a descrio de dados semiestruturados. OEM baseia-se na noo de objeto com identidade1, sendo os objetos os vrtices do grafo. Objetos podem ser atmicos ou complexos. No primeiro caso, existem tipos predefinidos como integer, string, gif e java. No segundo caso, definido um tipo conjunto de referncias a objetos, sendo os rtulos do tipo string. Todos os vrtices folha do grafo apresentam tipos atmicos [Abi97b]. A figura 1 (b) segue esse modelo. A especificao de um objeto em OEM apresenta a seguinte estrutura:
<rtulo, tipo, valor, OID>

Rtulo um string de tamanho varivel que descreve o que o objeto representa. Tipo pode ser um tipo atmico ou um conjunto de objetos. Valor um campo de tamanho varivel que mantm um valor compatvel com o tipo definido e OID a identificao nica do objeto ou null. O OID pode ser omitido a nvel de modelagem conceitual, uma vez que controlado por SGBDs. Em resumo, o que OEM representa so valores de dados encontrados em fontes heterogneas de dados, associando rtulos a cada um deles (arcos no grafo), que descrevem os seus significados. A seguir tem-se um exemplo de especificao de um objeto atmico (a) e um objeto complexo (b) em OEM, com base no grafo da figura 3.1 (b).
<Instituio, string, UFRGS>

(a)
<Sees, set, {intro, conclu, biblio}> intro: <Introduo, texto, Intro.txt> conclu: <Concluso, texto, Conclu.txt> biblio: <Bibliografia, texto, Biblio.txt>

(b)
1

Identidade de um objeto conhecida na literatura como Object IDentity (OID).

18

O objeto atmico Instituio representa a string UFRGS. J o objeto Sees (vrtice no folha no grafo, portanto um objeto complexo), composto pelos objetos Introduo, Concluso e Bibliografia, cujas referncias (identificadores nicos) so respectivamente intro, conclu e biblio. OEM considerado um modelo flexvel pois no existe noo de esquema fixo. Toda informao esquemtica includa nos rtulos, que podem mudar dinamicamente. Dessa forma, a heterogeneidade de representao suportada, dado que cada ocorrncia de objeto um subgrafo com rtulos e atributos apropriados. 3.1.1.2 Comparao com Outros Modelos de BD Uma modelagem em OEM pode ser facilmente representada no modelo relacional atravs de duas tabelas: Valor(OID, valor) para objetos atmicos e Membro(OID, rtulo, OID) para objetos complexos [Abi97b]. Porm, o modelo relacional no suporta identidade de objetos (exige a definio de restries de integridade para garantir a consistncia dessa identidade) nem consultas recursivas, comuns em grafos. Modelos orientados a objetos so utilizados em geral para a definio de esquemas globais em BDs heterogneos. OEM um modelo mais simples pois apresenta apenas os conceitos de identidade e aninhamento, no suportando outras caractersticas de orientao a objetos, como classes, mtodos e herana [Pap95]. Isso no significa que essas caractersticas no possam ser emuladas em OEM, como o uso de subobjetos para representar subclasses. Modelos para BDs dedutivos so compostos por fatos (relaes, por exemplo) e regras para deduo de novos fatos. Regras podem ser representadas em OEM atravs de aninhamento. Por exemplo, uma relao chamada Pessoa e uma regra dedutiva Ancestral, que determina os ancestrais de uma pessoa, podem ser modeladas como um objeto Pessoa composto por subobjetos que representam os seus ancestrais. A possibilidade de mapeamento de outros modelos de dados para OEM mostra o poder de expresso desse modelo, apesar da sua simplicidade conceitual.

3.1.2 ADM
ADM (Araneus Data Model) um modelo de dados baseado no padro ODMG (Object Database Management Group) de representao de objetos, voltado para o contexto da Web. Esse modelo foi definido no sistema ARANEUS, de responsabilidade do grupo de BD da Universit di Roma Tre [Azt97a, Azt97b]. ADM descreve a organizao lgica de dados hipertexto, sendo um modelo orientado a pginas. O conceito central nesse modelo o de esquema de pginas, conceito semelhante a um esquema de relao ou de classe em BDs relacionais e orientado a objetos, respectivamente. Um esquema de pginas modela um conjunto de pginas HTML homogneas. Cada instncia de um esquema uma pgina, que vista como um objeto com uma identificao (URL) e um conjunto de atributos.

19

Atributos em ADM podem ser do tipo monovalorado (atmico) ou multivalorado, sendo o multivalorado uma lista encadeada de objetos. Ambos podem ser definidos como opcionais, ou seja, no existe obrigatoriedade de existncia de um valor associado ao atributo, uma vez que mesmo um conjunto de pginas classificadas em um esquema podem apresentar alguma heterogeneidade. O tipo lista o nico tipo multivalorado definido porqu padres que se repetem em pginas Web esto geralmente ordenados. Outros tipos especficos do modelo so: Form: um form executa um programa que busca dados em pginas Web e gera uma pgina como resultado. Um tipo form (formulrio) uma lista virtual de tuplas2, formado por atributos que correspondem aos campos de preenchimento do form mais um link para a pgina resultado. Por exemplo, uma interface para consulta a publicaes de autores pode ser um form cuja tupla que o representa formada por dois campos: um atributo correspondente ao string de entrada (nome do autor) e um link para a pgina de resposta; Unio Heterognea: tipo que define os possveis resultados (heterogneos) de uma consulta, ou seja, consultas cujo resultado pode trazer tipos de pginas diferentes a cada execuo. Por exemplo, uma busca por palavra-chave tendo como entrada nome de autor pode, numa certa execuo, trazer um pgina com um ndice de autores, caso mais de um nome faa parte da entrada, ou diretamente a pgina com a lista de publicaes de um nico autor especificado como entrada. A unio, nesse caso, aplica-se a dois tipos de pginas: uma pgina especfica de publicaes de um autor e uma pgina de ndice de autores; Link: define um relacionamento com uma ou mais instncias de outro esquema de pginas.

Pginas podem ainda ser definidas como nicas ou no nicas. Uma pgina nica possui como caracterstica o fato de que nenhuma outra pgina apresenta estrutura semelhante a ela, como por exemplo, a pgina home de um site. Por outro lado, considerando pginas de publicaes de autores, posso ter pginas de diversos autores apresentando a mesma estrutura. Essas so pginas no nicas. Na seqncia mostrada a especificao de dois esquemas de pgina em ADM: um esquema no nico (a) e um esquema nico (b). O esquema no nico define pginas de autores, sendo formado pelos atributos nome (monovalorado) e lista de publicaes (multivalorado). Cada publicao nessa lista uma tupla onde os quatro primeiros atributos so monovalorados. O atributo RefPg do tipo link para um tipo heterogneo e define uma ligao para a pgina do evento em que a publicao foi aceita, que pode ser a pgina de uma conferncia ou de um jornal. O atributo ListaAut uma lista de tuplas formada pelo nome do autor e um link para a sua pgina pessoal, caso exista (por isso o uso da clusula OPTIONAL). O esquema (b) define uma pgina de pesquisa por autor, uma pgina especfica para esse tipo de pesquisa (por isso o uso da clusula UNIQUE). Por ser nica, um atributo URL a identifica. Essa pgina definida como um formulrio (tipo FORM) composto por um nome de autor (string de entrada para a pesquisa) e um link para uma pgina de resposta
2

A lista virtual pois as tuplas no so armazenadas nas pginas, correspondendo apenas a submisses (dados de entrada e sada) ao form em tempo de execuo.

20

da consulta, que pode ser ou a lista de publicaes de um autor especfico ou um ndice para pginas de publicaes de autores.
PAGE SCHEME PgAutor Nome: TEXT; ListaPubl: LIST OF (Autores: TEXT; Ttulo: TEXT; Referncia: TEXT; Ano: TEXT; RefPg: LINK TO PgConf UNION PgJornal; ListaAut: LIST OF (Nome: TEXT; RefPg: LINK TO PgAutor OPTIONAL;); ); END PAGE SCHEME

(a)
PAGE SCHEME PgPesquisaPorAutor UNIQUE URL /indiceAutor/index.html FormNome: FORM (Nome: TEXT; Submisso: LINK TO PgAutor UNION Pgndice); END PAGE SCHEME

(b) Um esquema ADM um conjunto de esquemas de pginas, representado como um multigrafo direcionado. Nesse multigrafo, os vrtices so esquemas de pginas e os arcos so os links entre esquemas de pginas. A figura 3.2 mostra a representao diagramtica de um esquema ADM exemplo baseado nos esquemas de pginas definidos anteriormente. Esquemas no nicos so mostrados como pilhas de pginas. A unio heterognea indicada pela letra U dentro de um crculo. A inteno principal desse modelo representar a organizao de pginas de sites na Web com diferentes nveis de estruturao, desde pginas bem estruturadas at representaes gerais com pouca estruturao. Comparado com o padro ODMG, o modelo ADM: Suporta apenas um tipo coleo: lista; No suporta herana; Suporta identidade, porm esta visvel ao usurio (URL); Define novos tipos de dados: form e unio heterognea.

21

FIGURA 3.2 - Exemplo de um esquema ADM

3.1.3 Comparao entre os Modelos

OEM foi definido com o objetivo de ser um modelo de propsito geral para representar dados de fontes semi-estruturadas. um modelo simples, cujo conceito principal de modelagem so objetos rotulados com identidade, que representam valores de dados. Como as fontes de dados so heterogneas entre si, no existe a noo de esquema fixo, sendo a representao de cada objeto definida atravs de um grafo rotulado direcionado sem restrio no nmero de arcos de sada por vrtice. Nessa representao, apenas dois tipos de dados so possveis: tipos atmicos (vrtices sem arcos de sada) ou o tipo multivalorado conjunto (vrtices com arcos de sada). Essa representao flexvel suficiente para modelar tal heterogeneidade. ADM j um modelo direcionado para a representao de sites na Web, sendo que um esquema definido nesse modelo um conjunto de definies de pginas interrelacionadas, ou seja, o conceito principal de modelagem a pgina. Por ser um modelo para um domnio mais restrito, ADM apresenta tipos de dados mais especficos (forms, unio heterognea de esquemas de pginas e links), alm de tipos atmicos convencionais e o tipo multivalorado lista. A tabela 3.1 compara as caractersticas dos dois modelos.

22

TABELA 3.1 - Comparao entre os modelos de dados OEM e ADM OEM ADM Valores rotulados Pginas Conceito principal de modelagem Atmicos; Atmicos; Tipos de dados
Conjunto.

Propsito Forma do esquema

Lista; Forms; Unio heterognea; Link. Modelagem de fontes de dados Modelagem de sites Web semi-estruturadas Esquema no fixo (grafo Conjuntos de pginas rotulado) relacionadas

inter-

O modelo OEM, dado o seu propsito mais geral para representao de fontes de dados heterogneas, tem obtido maior aceitao como modelo para BDs semi-estruturados.

3.2 Data Guides

Um data guide um sumrio preciso e conciso da estrutura de um BDSE, sendo representado em geral como um objeto em um modelo de dados semi-estruturado [Hug97]. Esse conceito procura solucionar o principal problema associado ao acesso e manipulao de dados de fontes heterogneas, que a ausncia de um esquema predefinido. Data guide um conceito similar metadado em um BD tradicional, sendo que um data guide pode ser consultado nvel de usurio ou aplicao para se descobrir a estrutura de um BDSE. A idia que a estrutura de qualquer objeto semi-estruturado esteja representada atravs de um data guide e o data guide no contenha estruturas que no existam no BDSE. Dessa forma, atende-se aos requisitos de preciso e conciso de representao estrutural de dados semi-estruturados. Data guides devem representar todos os possveis caminhos presentes na estrutura de objetos semi-estruturados mantidos no BDSE. possvel ainda que os data guides possuam anotaes, ou seja, descrevam propriedades de um conjunto de objetos alcanvel atravs de um caminho, como exemplos de valores de objetos, domnios e ndices associados, etc. A figura 3.3 mostra um data guide que representa a estrutura do objeto Artigo da figura 1 (b). Um data guide no coloca restries no nmero de arcos de um dado tipo. Isso significa que um objeto do tipo Artigo pode ter diversos subobjetos do tipo Autor, por exemplo. Data guides, pelo fato de descreverem a estrutura de dados semi-estruturados, auxiliam no processamento de consultas, em tarefas como anlise sinttica (verificar se uma dada expresso de caminho vlida, por exemplo) e determinao de planos de acesso (uso de ndices, por exemplo).

23

Root
Documentos

Artigo

Ttulo

Autor

Resumo

Sees

Instituio

e-mail

Introduo

...

Bibliografia Concluso

FIGURA 3.3 - Um data guide para um objeto semi-estruturado do tipo Artigo

24

4 Linguagens de Consulta
A consulta a fontes de dados semi-estruturados, como dados Web, um problema que ainda carece de solues definitivas, devido dificuldade de se definir uma estrutura de representao uniforme que sirva de base para as pesquisas. O que existe atualmente so ferramentas de acesso a dados. Essas ferramentas podem ser classificadas genericamente em [Cat98]: Browsers: ferramentas como o Netscape e o Internet Explorer, que permitem a investigao exaustiva de fontes de dados e o deslocamento entre fontes relacionadas via links. Durante a navegao, construda incrementalmente uma estrutura que mantm o histrico das pginas de dados visitadas pelo usurio, permitindo que esse retorne a qualquer ponto anterior ou posterior. A partir desse ponto, o usurio pode iniciar um novo caminho de pesquisa. Porm, essas ferramentas no oferecem nenhum auxlio significativo para formulao de consultas; Hunters: ferramentas que oferecem facilidades de consulta. As mais comuns so as chamadas mquinas de pesquisa, como Yahoo e AltaVista, que permitem buscas de fontes de dados por caractersticas. Essas mquinas utilizam tcnicas de RI, que se baseiam em geral em predicados booleanos onde os termos so as palavras-chave que o usurio deseja que estejam presentes nos documentos a serem recuperados. Porm, essas tcnicas ainda no apresentam uma sintaxe para formulao e uma estrutura para resposta de consultas, o que dificulta o atendimento da inteno de pesquisa do usurio.

A pesquisa direcionada consulta a dados semi-estruturados procura alcanar um estgio onde a Web e outras fontes de dados possam ser tratadas como um BD, uma vez que as ferramentas existentes atualmente no apresentam esse suporte. O atendimento desse objetivo facilitaria o acesso informao por parte do usurio. Para tanto, devem estar disponveis: (i) modelos de dados que representem esquemas de dados semi-estruturados (como OEM e ADM), (ii) linguagens de consulta para esses modelos e (iii) mecanismos de processamento e otimizao de consultas. O critrio (ii) discutido nesse captulo.

4.1 Requisitos para Consulta a Dados Semi-Estruturados

necessrio identificar as necessidades de consulta a dados semi-estruturados, de forma a guiar o desenvolvimento de linguagens de consulta aplicadas aos mesmos. Uma preocupao inicial a inexistncia de um esquema fixo ou rgido para consultas. Assim sendo, o usurio deveria ser capaz de consultar dados sem conhecer o esquema ou ainda consultar o prprio esquema, quando esse existir [Bun97]. Outra questo a heterogeneidade de tipos de atributos, que podem ocorrer em objetos semanticamente iguais, o que implica um relaxamento em relao tipagem na formulao de consultas. Linguagens de consulta tradicionais no oferecem esses suportes. Abiteboul [Abi97b] aponta algumas questes que devem ser levadas em considerao no projeto de linguagens de consulta para dados semi-estruturados.

25

Basicamente, sugerido o aproveitamento de primitivas de linguagens de consulta padro de BD (seleo, projeo, etc), facilidades como navegao no estilo hipertexto e busca por padro e consultas temporais e ao esquema. O atendimento dessas questes exige que uma fundamentao terica exista para tais linguagens, como uma lgica baseada em lgebra ou clculo relacional. Mais detalhadamente, os requisitos colocados so: Uso de uma abordagem baseada em objetos: a estrutura de objetos mais poderosa, permitindo que linguagens de consulta selecionem pores relevantes dessa estrutura que sejam de interesse para fins de comparao ou resultado; Uso de coero: deve-se lidar com a heterogeneidade de tipo e estrutural de dados semi-estruturados, quando da ocorrncia de comparaes entre atributos de objetos. Por exemplo, uma comparao entre duas medidas (como distncia) em unidades diferentes (como milhas e quilmetros) deve ser possvel de ser executada. O mesmo vale para comparaes entre estruturas diferentes, como um endereo atmico ou estruturado em rua, cidade e CEP. O uso de coero permite que tais comparaes possam ser feitas corretamente, sem que um erro seja gerado em tempo de compilao ou execuo da consulta. A aplicao desse requisito permite um relaxamento na tipagem de dados em termos de operaes de comparao; Tratamento de expresses de caminho (ECs): ECs devem permitir o percorrimento na estrutura de objetos semi-estruturados (percorrimento em grafo) para obter informao ou formular uma condio sobre um atributo. A forma mais usual de se especificar uma EC a simples concatenao de nomes de rtulos, como Artigo.Sees.Introduo para indicar a introduo de um artigo. ECs devem ainda indicar padres de busca, quando combinadas com certos caracteres especiais. Essa possibilidade extremamente til quando se desconhece total ou parcialmente a estrutura dos objetos. Por exemplo: Artigo.*.Instituio pode indicar que se deseja obter a(s) instituio(es) de origem de um artigo publicado, sem haver conhecimento do caminho a ser percorrido para se chegar nessa informao (o caracter * substitui uma EC de comprimento arbitrrio) uma busca por padro. O estudo do poder de expresso de ECs em consultas a dados semi-estruturados um tpico importante de pesquisa; Busca baseada em estrutura: dada a heterogeneidade de dados semi-estruturados, muitas vezes desejvel buscar objetos que apresentam uma certa estrutura, como por exemplo, todos os empregados que apresentam um nome e uma profisso. Linguagens funcionais (baseadas em regras) seguem essa abordagem de pesquisa, utilizando o que se chama de variveis de resto, que casam com o restante da estrutura do objeto a ser buscada, alm dos atributos obrigatrios.

26

Em resumo, tem-se o seguinte sumrio de requisitos sugeridos: 1. 3. 5. 7. 8. Consulta baseada em objetos; 2. Consultas temporais; 4. Uso de coero; 6. Uso de operaes padro de consulta a BDs tradicionais. Consulta ao esquema; Uso de ECs; Busca baseada em estrutura;

O requisito que diz respeito a facilidades para navegao estilo hipertexto vale apenas para linguagens de consulta visuais. Considerando uma linguagem textual, o uso de ECs possibilita um estilo de navegao semelhante. Por isso, essa sugesto no foi colocada no sumrio.

4.2 Taxionomia de Linguagens para a Web

A Web a fonte mais ampla e diversificada de dados semi-estruturados. Esse fato motiva o desenvolvimento de linguagens de consulta especficas. Os paradigmas principais associados a linguagens para a Web so [Flo98]: A. Linguagens para consulta a hipertextos e documentos: em geral baseiam-se em uma abordagem que mapeia internamente, atravs de uma gramtica de extrao predefinida, documentos para instncias de BDs orientados a objetos ou relacionais, para da serem consultados; B. Linguagens baseadas em grafos: suportam a formulao de ECs regulares e construo de grafos como resposta de consultas; C. Linguagens gerais para dados semi-estruturados: tambm so baseadas em grafos, porm permitem a consulta ao esquema e lidam com irregularidades estruturais como atributos inexistentes ou repetidos. Duas geraes de linguagens j so identificadas para a Web [Flo98]. A primeira gerao combina consultas baseadas em contedo e baseadas em estrutura, permitindo condies sobre padres de texto em documentos e padres de grafos descrevendo a estrutura de links. Enquadram-se no primeiro paradigma (A). A segunda gerao representa um avano em relao primeira pois suporta o acesso estrutura de objetos complexos e links e a criao de estruturas complexas como resposta. Linguagens dessa gerao podem se enquadrar em todos os trs paradigmas. Linguagens de segunda gerao so consideradas linguagens de manipulao de dados uma vez que auxiliam em tarefas de extrao de estrutura e reestruturao de dados semi-estruturados. Alm de operaes de consulta tambm oferecem operaes como definio de estruturas para extrao com base em ECs (conceito semelhante a uma viso em BDs tradicionais, que pode ou no ser materializada).

4.3 Propostas
A literatura sobre linguagens de consulta para dados semi-estruturados apresenta propostas que oferecem basicamente uma sintaxe estilo SQL para consulta a objetos

27

modelados como grafos direcionados rotulados. As sees a seguir descrevem algumas dessas propostas.

4.3.1 StruQL
StruQL a linguagem de consulta e reestruturao de dados Web do sistema STRUDEL, que aplica conceitos de BD para a organizao de Web sites (ver captulo 6). Tal linguagem permite definir uma viso integrada de dados de vrias fontes e a estrutura de exibio de sites, para fins de acesso e apresentao [Fer97a]. O modelo de dados base o OEM padro (formado por tipos atmicos ou subgrafos) com um tipo adicional chamado coleo, que mantm um ou mais OIDs. Um grafo de dados manipulvel por StruQL apresenta vrtices no folhas que representam objetos com identidade e vrtices folhas que mantm valores atmicos. O tipo coleo guarda a identidade dos objetos que so pontos de entrada no grafo. Grafos de dados representam a estrutura lgica de informaes disponveis em sites. Existem ainda os grafos de sites, formados por um ou mais grafos de dados, que descrevem a estrutura de exibio de sites. Vrtices nesse grafo so pginas (que podem conter atributos) e arestas so links entre pginas. A sintaxe geral de uma expresso em StruQL :
Where C1, ..., Cn [ Create N1, ..., Nk Link L1, ..., Lm ] Collect G1, ..., Gt

A clusula Where especifica a condio da consulta, que pode ser composta por um ou mais predicados booleanos (C1 a Cn). Um predicado aplica-se a um vrtice, valor ou rtulo e os operandos de um predicado podem ser uma EC sobre um grafo OEM. As clusulas Create e Link, opcionais, especificam os grafos de resposta. A primeira delas define os novos k nodos com identidade e a segunda define os m links entre esses nodos. A clusula Collect especifica as t colees que fazem parte do resultado. A consulta a seguir, que busca objetos de um grafo de dados que no sejam imagens, exemplifica o uso de StruQL:
Where Create Link Collect Root(p), p * q, q l q, not(isImageFile(q)) N(p), N(q), N(q) N(q) l N(q) TextOnlyRoot(N(p))

A partir do vrtice raiz do grafo (indicado por Root e associada varivel de consulta p), deseja-se buscar vrtices q alcanveis a partir de p por um caminho de comprimento zero ou maior (*) e vrtices q acessveis via q atravs de um rtulo qualquer (l), sendo que o objeto associado q no pode ser do tipo imagem (funo predefinida isImageFile verifica se um objeto ou no uma imagem). Toda vez que a condio satisfeita, funes especiais N(varivel_consulta) (chamadas funes Skolem) constrem novos vrtices para os objetos associados p, q e q (cpia dos vrtices do grafo) e definem links entre pares de vrtices q e q. A coleo de nome TextOnlyRoot contm o objeto raiz do grafo de resposta.

28

O exemplo anterior ilustra os dois conceitos principais que fazem parte da estrutura de consultas StruQL: ECs e expresses de nodo. ECs apresentam o formato:
ExpressoNodo (EN) ExpressoRegularCaminho (ERC) ExpressoNodo (EN)

O termo central, ERC, permite a construo de caminhos de comprimento arbitrrio em grafos, podendo ser um elemento atmico, como uma constante ou varivel de rtulo, ou outras ERC associadas a caracteres que simbolizam comprimentos variveis, como * ou +. Expresses de nodo (ENs) ocorrem nas trs ltimas clusulas, sendo ou uma varivel de nodo ou um termo Skolem. Um termo Skolem a aplicao de uma funo Skolem a uma EN, uma varivel de rtulo ou valores. Na clusula Create, cada Ni um termo Skolem. Na clusula Link, cada Li apresenta a forma EN1 CVR EN2, onde EN1 um termo Skolem, CVR uma constante ou varivel de rtulo e EN2 uma expresso de nodo. Por fim, na clusula Collect, cada Gi tem a forma NomeColeo(EN). Expresses de consultas em StruQL podem ser aninhadas. Esse recurso permite a definio de procedimentos (blocos) que constrem grafos de resposta com base em outros grafos previamente criados. Variveis de consulta podem ser definidas uma nica vez e reutilizadas ao longo do bloco. Essa facilidade til no refinamento de consultas. No exemplo a seguir, a partir de um grafo de entrada denominado DataGraph, extrai-se um subgrafo de sada (grafo de site - SiteGraph) cujos vrtices apresentam arestas rotuladas com os valores Paper, TechReport, Abstract e Author. Alm disso, define-se um nodo chamado Authors(), que mantm links de nome Author para todas as pginas de autores. A criao desses links tratado em um bloco interno executado toda vez que um link definido na consulta mais externa.
Input Where Create Link { Where Link } Output DataGraph Root(x), x * y, y l z, l in {Paper, TechReport, Abstract, Author} Authors(), Page(y), Page(z) Page(y) l Page(z) l = Author Authors() Author Page(z) SiteGraph

4.3.2 Lorel
Lorel (Lore language) a linguagem de consulta do SGBD Lore, em desenvolvimento na Universidade de Stanford e destinado ao gerenciamento de dados semi-estruturados (ver captulo 6) [Abi97a]. Lorel uma extenso de OQL ( Object Query Language uma linguagem padro para manipulao de objetos) para o tratamento de dados semi-estruturados, baseado no modelo OEM. Suas caractersticas principais so o uso de coero, a flexibilidade na especificao de expresses de caminho e a possibilidade de atualizao de dados.

29

O suporte coero habilita operaes de comparao e aritmticas intuitivamente vlidas entre objetos e valores quando esses apresentam tipos diferentes. Dois tipos de coero so tratados: Coero de valores e objetos atmicos : busca-se a converso dos operandos para valores que sejam compatveis, sempre que possvel. As regras aplicadas so as seguintes, considerando operaes entre tipos atmicos string, real e inteiro: a) String X real: converte string para real, se possvel; b) String X inteiro: converte ambos para real, se possvel; c) Inteiro X real: converte inteiro para real. Existem limitaes nesse tipo de coero, uma vez que nem todos os tipos atmicos so passveis de comparao, como uma imagem e um clip. Alm disso, comparaes podem falhar, como por exemplo, BD = 34 (retorna falso); Coero de objetos e conjuntos de objetos : existem vrias regras para comparao. As mais significativas so as seguintes: a) Objeto X objeto: se for igualdade, aplica-se a comparao por OID. Como operadores de desigualdade no esto definidos para objetos, uma converso de objeto para valor deve ser feita e uma comparao tentada; b) Objeto complexo X valor, objeto atmico ou conjunto de objetos : no possvel pois no se sabe exatamente o que comparar; c) Conjunto de objetos X valor ou objeto atmico : cada elemento do conjunto comparado com o valor ou objeto atmico, sendo a comparao verdadeira se a comparao para algum elemento for verdadeira.

ECs em Lorel so classificadas como simples ou gerais caso no usem ou usem caracteres especiais na especificao da expresso, respectivamente. Algoritmos de transformao realizam o mapeamento de especificaes Lorel para especificaes OQL. Supondo um BD que mantm dados de um guia de locais gastronmicos, um exemplo de consulta que envolve a especificao de uma EC simples buscar o endereo de todas as confeitarias do guia:
Select Z From Guia.confeitaria.endereo Z

ECs gerais definem expresses regulares e complementao de rtulos. Uma EC geral inicia com um nome de varivel ou objeto e pode ser seguida por um ou mais componentes. Cada componente pode ser: a) Um nome de rtulo aps um ponto (.<nome_rtulo>); b) Se c1 e c2 so componentes, ento os seguintes tambm so componentes: b1) c1c2 (conjuno); b2) c1|c2 (disjuno); b3) (c1); b4) (c1)? (0 ou 1 ocorrncia); b5) (c1)+ (1 ou mais ocorrncias);

30

c)

b6) (c1)* (0 ou mais ocorrncias); Se X um objeto do tipo string, ento .unqoute(X) um componente (A funo unquote toma o valor de X e o utiliza como um rtulo em uma EC).

Seguindo essas definies, um exemplo de EC geral : Guia.restaurante(.endereo|.logradouro)?.CEP, que busca o CEP de um restaurante, sendo que esse dado vem aps um rtulo endereo ou logradouro, sendo esses rtulos opcionais no caminho at o rtulo CEP. Outros caracteres especiais so ainda utilizados em especificaes de consulta quando no se conhece todos os rtulos dos objetos ou suas ordens relativas precisamente: o caractere % casa com zero ou mais caracteres em um rtulo e o caractere #, mais poderoso em termos de representao, casa com qualquer caminho de dado de comprimento igual ou superior zero. Lorel permite o uso de variveis de consulta, que podem ser de dois tipos: variveis de caminho ou variveis de objeto. As primeiras assumem como valor qualquer caminho de dado, podendo ser usadas em testes de igualdade ou associadas a uma funo ( path-of) que insere um caminho de dados a uma string. Essa funo til para se descobrir os caminhos at um determinado rtulo. Variveis de objeto podem ser introduzidas dentro de uma EC, com o propsito principal de distinguir duas ou mais ECs sintaticamente idnticas. As consultas a seguir exemplificam os conceitos recm comentados:
Select distinct path-of(L) From Guia.#.%@L X Where X = barato

(a)
Select N From Guia.restaurante{R}.nome N Where R.endereo{A1}.cidade = Porto Alegre and R.endereo{A2}.cidade = Florianpolis

(b) A consulta (a) define uma varivel de caminho (sempre prefixada por um caractere @) chamada L que est associada sempre com o ltimo rtulo de um caminho de comprimento arbitrrio (indicado pelo caractere # na EC) que conduz a um objeto X com valor barato. Seu objetivo descobrir os nomes de todos os rtulos que fazem parte de caminhos que conduzem ao objeto X. A consulta (b) encontra todos os restaurantes com endereos tanto na cidade de Porto Alegre quanto na cidade de Florianpolis. O uso de duas variveis de objeto distintas, A1 e A2 (variveis de objeto so definidas entre chaves) quer indicar que podem existir dois caminhos com o mesmo rtulo (endereo) a partir de um objeto restaurante (caso de restaurantes com mais de um endereo). Cada par desses caminhos fica associado com uma das duas variveis.

31

Um resultado de consulta em Lorel um conjunto de objetos OEM associado a um objeto com identidade answer, que pode ser reutilizado em futuras consultas. Um resultado pode gerar novos objetos ou se referir a objetos originais do BD. Objetos gerados so adequados, por coero, a objetos OEM, de acordo com trs regras: Se o resultado um valor atmico v, gera-se um objeto cujo tipo v; Se o resultado uma coleo de objetos, gera-se um objeto complexo com rtulos default (definidos pelo sistema) para os subobjetos; Se o resultado uma estrutura (vrios itens de dados na resposta), gera-se um objeto complexo onde os rtulos para os subobjetos so os atributos da estrutura.

Outra caracterstica de Lorel sua capacidade de atualizao de objetos. As seguintes operaes so possveis: incluso/excluso de nomes de BDs (pontos de entrada no BD); incluso de objeto atmico ou complexo; alterao de valor em um objeto e carga de um BD OEM. A primeira delas apresenta a sintaxe name <nome> := <expresso>, que associa <nome> o resultado de <expresso>, sendo que <expresso> pode ser uma consulta, um novo objeto criado ou null. A incluso de objetos se d atravs da funo new_oem(tipo_valor,valor), que cria um objeto com um tipo e valor. O tipo pode ser atmico ou o tipo complexo complex (uma estrutura onde cada campo descreve um rtulo e um conjunto de objetos OEM para cada rtulo). Objetos multimdia ( Blobs) podem tambm ser criados, atravs da funo load_OEM. Para alteraes de objetos em Lorel utiliza-se o comando update. Pode-se alterar tanto objetos nomeados (indicando os seus nomes) como subobjetos (indicando a EC que conduz at ele). Os exemplos a seguir ilustram as duas possibilidades de uso desse comando, para atualizar um objeto (a) ou vrios objetos de uma s vez (b):
Update Guia.restaurante += Pampulha

(a)
Update X.classe = caro From Guia.restaurante{X}.endereo.cidade Z Where Z = New York

(b) A consulta (a) inclui um novo restaurante, de nome Pampulha, ao guia de restaurantes. A consulta (b) altera a classe de todos os restaurantes da cidade de New York para caro. A carga de um BD OEM possvel atravs da leitura de um arquivo de descrio (com um formato prprio) de objetos, especificado no comando load <nome_arquivo>.

4.3.3 UnQL
UnQL uma linguagem para consulta a dados semi-estruturados organizados como um grafo rotulado que possui um objeto como raiz. A linguagem suporta pesquisa em profundidades arbitrrias (controladas por ECs) e pesquisa em ciclos [Bun96].

32

Consultas em profundidade no grafo so chamadas consultas de seleo. A sintaxe geral dessas consultas :
Select resposta Where gerador

Nessa sintaxe, resposta representa uma subgrafo e gerador uma construo do tipo padro grafo. Grafo um conjunto de pares (aresta,subgrafo) que o gerador tenta casar com o padro. A sintaxe bsica de um padro l t, que representa um grafo cuja raiz tem uma aresta rotulada l vinculada a um subgrafo t. Supondo o BD de guia de restaurantes da seo anterior, um exemplo de gerador seria Guia \t Root. O grafo do BD Root e o padro a ser seguido nesse grafo so subgrafos, a partir de Root, que iniciam com o rtulo Guia seguido de qualquer subgrafo abaixo desse rtulo (associam-se com a varivel t). Variveis de consulta so introduzidas em consultas UnQL com uma barra invertida, podendo ser usadas posteriormente nas clusulas select e where sem a barra. Um exemplo simples de consulta, que retorna todo o grafo do BD, :
Select t Where \l \t Root,

que busca subgrafos (t) de um rtulo qualquer (l) que parta de Root. Outro exemplo de consulta, que ilustra o uso de operadores tradicionais da lgebra relacional, a seguinte:
Select {Confeitaria {rua x, categoria z}} Where Guia restaurante {endereo rua \x} Root, Guia confeitaria {endereo rua x, categoria \z} Root

que retorna uma estrutura (projeo) que tem como raiz Confeitaria seguida de dois rtulos (rua e categoria) que conduzem a dois subgrafos associados com as variveis x e z, respectivamente. O primeiro padro na clusula where associa valores varivel x, que serve como constante no segundo padro (juno). Essa consulta busca rua e categoria de confeitarias que se situam na mesma rua de algum restaurante. Consultas mais poderosas, que buscam dados cuja profundidade no grafo no conhecida, tambm so possveis em UnQL, atravs do uso e/ou combinao de caracteres especiais. A consulta a seguir busca dados de restaurantes da cidade de Porto Alegre, supondo que no se conhea a estrutura de dados que conduz ao item de dado cidade:
Select {Restaurante t} Where _ restaurante \t Root, cidade \x t, Porto Alegre {} x

Nessa consulta, deseja-se subgrafos com dados de restaurantes (t), sendo que, a partir de um rtulo restaurante deseja-se seguir um nmero indeterminado de rtulos (indicado pelo smbolo ) at um rtulo de nome cidade seguido, novamente por indeterminados nveis (a partir do subgrafo associado varivel x), at um rtulo Porto Alegre e um subgrafo vazio logo aps (indicado por {}), supondo que Porto Alegre seja um

33

rtulo terminal (que no conduz a mais nenhuma informao). O caractere _ casa com qualquer nome de rtulo no caminho, indicando que entre Root e restaurante existe um nico rtulo intermedirio. Poder-se-ia substituir esse caractere pelo rtulo Guia, caso esse seja o nico nome de rtulo nesse caminho, como sugerem os exemplos anteriores. UnQL trata ciclos considerando sempre caminhos distintos de rtulos, partindo do pressuposto que existe sempre um nmero finito de distintas associaes de rtulos e subgrafos a variveis. Outro tipo de consulta so as chamadas consultas de reestruturao, que geram como resultado subgrafos que modificam o grafo original do BD. Essas consultas so formuladas via o comando:
traverse BD giving lista_marcadores lista_casos

BD um nome de grafo de BD, lista_marcadores uma lista do tipo X1, X2, , Xn, onde cada Xi um subgrafo representando uma reestruturao local do grafo do BD, sendo X1 a resposta da consulta. J lista_casos tem a forma:
case padro1 then Xj := ao_reestruturao case padroN then Xk := ao_reestruturao

onde um case que atende a um certo padro realiza uma modificao em um ou mais marcadores (ao_reestruturao). Um exemplo desse tipo de consulta pode ser trocar o nome de rtulos categoria por especialidade, para subgrafos abaixo de rtulos restaurante:
traverse Root giving X1, X2 case restaurante _ case categoria _ case \t _ then X1 := {restaurante X2} then X2 := {especialidade X2} then X1 := {t X1}, X2 := {t X2}

Nessa consulta so gerados dois grafos em paralelo: X1 e X2. O percorrimento sobre esses grafos ocorre em paralelo, com redirecionamento das arestas de X1 para X2 sempre que um rtulo restaurante encontrado. Isso porque X2 que est sofrendo a modificao de rtulo. A resposta o subgrafo X1.

4.3.4 WebSQL
A proposta de WebSQL tornar mais eficaz a pesquisa a documentos Web, integrando mecanismos de RI com consultas baseadas em estrutura e topologia, em um estilo SQL [Men97]. Segue-se uma abordagem relacional para representao de documentos, sendo cada documento Web associado a uma tupla em uma relao virtual chamada Documento, apresentando os seguintes atributos: URL (chave primria), ttulo, texto, tipo (HTML, postscript, imagem, etc), comprimento e ltima modificao. Os trs primeiros atributos podem ser obtidos atravs da anlise de um documento em formato HTML, enquanto os demais atravs de resultados devolvidos por mquinas de RI.

34

Outra relao definida ncora, que modela links e apresenta os atributos base (URL do documento que contm o link chave primria), href (documento referido) e rtulo (descrio do link). Trs tipos de links so definidos, considerando a topologia da rede de documentos: interior (apontam para o mesmo documento smbolo | ), local (apontam para outro documento no mesmo site smbolo ) e global (apontam para um documento em um servidor remoto smbolo ). A consulta a seguir busca links para applets a partir de documentos HTML sobre o assunto Java.
Select a.rtulo, a.href From Documento d such that d mentions Java, ncora a such that base = d Where d.type = text/html and a.rtulo contains applet;

A clusula mentions funciona como uma busca por palavra-chave enquanto contains verifica a existncia de um termo em um string. ECs regulares em consultas so construdas a partir da combinao dos smbolos de links utilizando outros smbolos que representam repetio (*) ou disjuno ( | ). Por exemplo, a expresso regular = | .* representa caminhos de comprimento zero (smbolo =) ou caminhos que iniciam com um link global e seguem por zero ou mais links locais. A consulta a seguir ilustra o uso de ECs, buscando dados de documentos no mbito do site do Instituto de Informtica da UFRGS cujo ttulo faa referncia ao assunto banco de dados:
Select d.url, d.ttulo From Documento d such that http://www.inf.ufrgs.br = | * d Where d.ttulo contains banco de dados;

A sintaxe de consultas WebSQL ligeiramente diferente do SQL padro: a clusula from avalia condies (clusulas such that e possivelmente mentions) que so enviadas a mquinas de RI acessveis pelo sistema de processamento de consultas. As pginas candidatas so ento filtradas pela condio presente na clusula where e os atributos de interesse na clusula select so buscados. Formalmente, o modelo de dados de WebSQL um grafo virtual formado por um conjunto de vrtices que correspondem a pginas, um conjunto de arestas que so links associados a uma pgina e predicados sobre pginas e links. Fisicamente, existem relaes com identidade do tipo nodo e link, sendo as relaes virtuais Documento e ncora mapeadas respectivamente para as mesmas.

4.3.5 WQL
WQL (Web Query Language) uma linguagem baseada no padro SQL3 para manipulao de documentos no formato HTML, permitindo formatao de documentos e navegao em classes e tabelas que os representam. A opo por HTML decorre do fato de que a maioria dos documentos na Web encontra-se nesse formato [Li99].

35

WQL v a Web como um grafo rotulado direcionado onde vrtices so pginas HTML e arestas so links. URLs rotulam vrtices, que so modelados como objetos complexos mantidos em um BDOO. Possuem atributos simples (como ttulo e tamanho) e estruturados, para representao de imagens, tabelas e forms. Esses dados fazem parte do que se chama estrutura intra-doc. Existe ainda a estrutura inter-doc que mantm dados sobre os links (URL e ncora). A linguagem contm duas partes: um comando do tipo select-from-where, para recuperao de dados hipermdia e um comando create-as para especificao do formato HTML resultante de uma consulta e/ou navegao. Extenses ao comando de consulta tradicional de SQL incluem: Predicados sobre a estrutura intra-doc: uso das clusulas contains e mentions; Predicados sobre a estrutura inter-doc (varredura da Web): atravs de operaes de juno e do uso da clusula depth; Casamento de imagens por similaridade : uso do predicado I_LIKE, que ativa um mdulo de casamento de imagens; Busca por similaridade semntica: uso do predicado S_LIKE, que relaciona palavras-chave semanticamente. Usa o dicionrio lxico Wordnet; Busca por similaridade sinttica (co-ocorrncia): associa uma palavra-chave com outra(s) sintaticamente relevante(s), como multimidia com CD-ROM ou biblioteca digital. Esses relacionamentos so modelados atravs de atributos complexos no modelo.

A seguir tem-se um exemplo de consulta em WQL que busca URLs de documentos do BD WebDB no mbito do site www.nec.com que possuam a palavra-chave multimdia, um form contendo a palavra support e um link para documentos no domnio .edu dentro de uma profundidade de pesquisa no grafo inferior ou igual a 3:
Select D1.URL From WebDB Where D1.URL like www.nec.com* And D1 mentions multimidia And D1 contains form F1 And F1.Contents mentions support And D1 contains link L1 And L1.URL = Doc D2.URL depth 3 And D2.URL like *.edu*

A nvel de usurio final, a especificao de comandos WQL suportada atravs de uma interface visual chamada Web in-frame Query (WebIFQ), que faz parte do ambiente sobre o qual WQL faz parte, que se chama WebDB. Essa interface possui duas janelas, que permitem (a) a formulao interativa de consultas (consulta grfica) em um estilo dragand-drop e (b) a exibio da consulta textual WQL gerada automaticamente a partir da consulta grfica. Subjanelas de (a) especificam critrios de pesquisa para estruturas intradoc e inter-doc, ativveis atravs de botes prprios. Alm disso, outros botes possibilitam a definio de projees e funes de agregao tal como na linguagem SQL.

36

Facilidades de navegao tambm esto disponveis atravs de WebIFQ para resultados de consultas. Duas formas de navegao sobre resultados existem: no formato HTML ou via uma interface grfica VRML. No primeiro caso, visualiza-se uma lista de documentos (identificados em geral pelo seu ttulo) que so exibidos como ncoras que podem ser selecionadas para a investigao dos seus atributos ou mesmo buscados por completo na Web. No segundo caso, tem-se uma interface tridimensional para exibio de objetos, com cores distintas para indicar documentos e links de documentos. O tamanho dos objetos visveis proporcional ao grau de relevncia do documento recuperado, conforme critrios como o nmero de ocorrncia das palavras-chave desejadas, nmero de acessos, etc. Esses objetos so selecionveis para obteno de informaes. Alm de formular pesquisas, possvel gerar documentos HTML customizados para resultados de consultas. Dois estilos de documentos podem ser criados: tabular e hierrquico. Em ambos os casos, utiliza-se comando create-as antes de um bloco selectfrom-where. O estilo tabular apresenta uma srie de atributos internos em sua sintaxe que permitem especificar ttulo do documento, uso ou no de frames, nomes das colunas, etc. Este exemplo mostra o uso desse estilo:
Create frame_resultado.html using table default { Table.Title = Resultado da pesquisa para a palavra-chave SQL; Table.UseFrame = ON; Table.UseCount = ON; Column1.Name = Ttulo; Column2.Name = Palavra-chave; Column3.Name = URL; } As Select D1.Ttulo, D1.PalavraChave, D1.URL From WebDB Where D1.PalavraChave mentions SQL;

Deseja-se gerar um documento HTML chamado frame_resultado, tendo como base o formato padro de criao de tabelas de WebDB. A tabela deve ter um ttulo, deve ser estruturada na forma de um frame (onde o nvel mais alto prov links para os documentos buscados pela consulta) e deve ter colunas numeradas, que correspondem aos links para os documentos. As colunas da tabela correspondem aos atributos de interesse da consulta, cujo objetivo buscar titulo, palavras-chave e URL de documentos que contenham a palavrachave SQL. Colunas no apresentam apenas o atributo nome, mas outros como forma de alinhamento, valor default, etc. O segundo estilo bastante similar sintaticamente ao primeiro, com a diferena de que existe uma funo de indentao para exibir os atributos do resultado da consulta em nveis hierrquicos. Para a consulta anterior, por exemplo, poder-se-ia exibir os documentos organizados em um primeiro nvel pelo par (URL, ttulo) e para cada um deles (uma indentao correspondendo a um segundo nvel) as suas palavras-chave.

4.3.6 WebLog
WebLog uma linguagem baseada em lgica com o objetivo de recuperar e reestruturar documentos HTML. Alm disso, acomoda conhecimento parcial que o usurio

37

tenha sobre informaes encontradas na Web, atravs do reuso de regras j definidas [Lak96]. O modelo de dados de WebLog centrado no conceito de documento (ou pgina), que apresenta grupos de informaes relacionadas. A noo de grupo subjetiva, cabendo ao usurio defini-lo de acordo com suas necessidades. Assim, um grupo pode ser delimitado por tags HTML, pode ser um pargrafo, uma lista de itens, etc. Chama-se um grupo de rel-infon e uma pgina possui um conjunto de rel-infons. Um rel-infon tem vrios atributos predefinidos, como occurs, hlink e algumas tags. Occurs mantm um conjunto de strings presentes no grupo e hlink um conjunto de links. Todos os rel-infons apresentam um ttulo (title ttulo da pgina) e uma identificao (id), que em geral um token ou a palavra-chave mais relevante. Seu vocabulrio formado por um conjunto contvel de smbolos funcionais e nofuncionais, variveis e conectivos lgicos. Uma frmula uma combinao de elementos desse conjunto com atributos do modelo de dados. Por exemplo, uma frmula pode ser simplesmente uma funo cujos argumentos sejam variveis ou nomes de atributos do modelo. Uma regra apresenta a forma Cabea Corpo, onde Cabea representa o resultado de uma consulta (projeo sobre atributos, que gera uma pgina nomeada como resposta) ou um smbolo funcional cujas variveis que so seus argumentos recebem valores determinados no Corpo. Corpo formado por uma ou mais frmulas, devendo existir uma correspondncia (casamento) entre pelo menos uma de suas variveis e as variveis da Cabea da regra. WebLog possui funes (ou predicados) predefinidas bastante teis no contexto de documentos Web, como href(<hlink-id>,<url>), que verifica o relacionamento entre o identificador de um link e sua URL destino, substring(<string>,<string>), que determina substrings de um string casamento de padres) e isa(<string>,<type>), que determina o tipo (inteiro, data, url, etc) de um objeto representado como uma string. Exemplos de consultas a seguir ilustram a funcionalidade dessa linguagem:
ans.html[title Citaes, hlink L, occurs T] http://www.informatik.uni-trier.de/ley/db/index.html[hlink L], href(L,U), U[title T]

(a)
ans(Y) ley_server_pages(U), U[title Coral, occurs S], len(S,40), substring(S,VLDB Journal), substring(S,Y), isa(Y,year)

(b) A consulta (a) busca citaes (links) presentes nos documentos do site do grupo de BD da Universidade de Concrdia Canad (instituio dos autores da linguagem). A varivel L associa-se com todos os links presentes na pgina (atributo multivalorado, indicado por ). O predicado href navega nas citaes, capturando URLs na varivel U, a partir do qual se obtm o ttulo e associa-se T. A resposta gerada em uma nova pgina chamada ans.html, que possui o ttulo Citaes e os links e ttulos das pginas referidas. Nessa consulta possvel identificar frmulas que so smbolos funcionais (como href) e smbolos no-funcionais (como U[title T], que casa o valor do atributo title de U com T). A consulta (b) ilustra uma busca por padro, desejando recuperar o ano de publicao de um artigo sobre o BD Coral do grupo de BD da Universidade de Concrdia, que apareceu no peridico VLDB Journal. Para tanto, utiliza-se (suposio) uma regra j

38

existente, chamada ley_server_pages, que recupera pginas do site do grupo de BD (em U). Para cada pgina, verifica-se se o ttulo Coral e se no texto existe um string (S) de comprimento 40 (len) referente bibliografia que cita o peridico VLDB Journal. Ento, verifica-se em S se existe um substring do tipo ano e recupera-se essa informao (em Y). Um outro exemplo de construo em WebLog, que realiza reestruturao de dados de documentos, o seguinte:
Varredura(L) http://www.informatik.uni-trier.de/ley/db/index.html [occurs Conference, hlink L] Varredura(L) Varredura(M), href(M,U), U[occurs Conference], U[hlink L] Cfp.html[title Chamadas de Trabalhos, hlink L, occurs DataSubmisso, occurs D] Varredura(L), href(L,U), U[occurs Interoperability], U[occurs P], len(P,20), substring(P,S), synonym(S, submission), substring(P,D), isa(P,date)

Nesse caso, deseja-se compilar as citaes de chamadas para trabalhos ( call for papers) do grupo de BD que tenham a palavra Interoperability como tpico de interesse. Alm disso, deseja-se incluir a data limite de submisso ( deadline) na resposta. A consulta expressa sabendo-se que, a partir de uma pgina com o string Conference, chega-se s informaes de interesse. Tambm supe-se que call for papers tm padres da forma ...submission...<data>.... A regra recursiva Varredura (segunda regra) varre a hierarquia de pginas do grupo de BD a partir de uma pgina com o string Conference, buscando (na terceira regra) satisfazer as restries da consulta e montar a estrutura de resposta na pgina Cpf.html.

4.3.7 Ulixes
Ulixes a linguagem de consulta do sistema ARANEUS (ver seo 6.3). Ulixes busca dados de um esquema de pginas baseado no modelo ADM (ver seo 3.1.2) e gera uma viso tabular materializada como resultado, visando uma posterior manipulao por um BD relacional [Atz97a, Atz97b]. Consultas Ulixes utilizam expresses navegacionais (ENs) para percorrer grafos de sites, seguindo links entre pginas e tambm explorando a estrutura hierrquica do esquema de uma pgina. A linguagem apresenta um nico comando chamado Define Table, cuja sintaxe :
Define Table As In Using Where R (B1, B2, ..., Bn) N S A1, A2, ..., An c1, c2, ..., ck

onde R o nome da relao resultado com atributos B1, B2, ..., Bn; S um esquema ADM; N uma EN sobre S; A1, A2, ..., An so os atributos de S alcanveis a partir da EN e que correspondem aos atributos da relao resultado R e c1, c2, ..., ck so predicados que fazem parte da condio da consulta e so aplicados sobre atributos alcanveis a partir da

39

EN. Um atributo Bi de R pode ser atmico ou ser uma tabela, refletindo a estrutura aninhada de uma pgina. Logo, resultados so relaes aninhadas. Supondo o mesmo esquema de pginas exemplo apresentado na descrio do modelo ADM (figura 3.2), referente a dados de autores e suas publicaes, a consulta Ulixes a seguir busca autores, ttulos e referncias bibliogrficas das publicaes de Joo da Silva ocorridas em Simpsios Brasileiros de BD (SBBDs):
Define Table SBBDPapers (Autores, Ttulos, Referncias) As PgPesquisaPorAutor.FormNome.Submisso PgAutor.ListaPubl In EsquemaPublicaes Using PgAutor.ListaPubl.Autores, PgAutor.ListaPubl.Ttulo, PgAutor.ListaPubl.Referncia Where PgPesquisaPorAutor.FormNome.Nome = Joo da Silva, PgAutor.ListaPubl.Referncia Like %SBBD%

Nessa consulta, primeiramente as condies so verificadas, de forma que apenas caminhos terminando em publicaes de Joo da Silva no SBBD sejam consideradas. interessante salientar que, como PgPesquisaPorAutor uma pgina do tipo formulrio, a clusula Where tambm usada para preencher automaticamente o formulrio, de forma transparente, com os valores de atributos necessrios para pesquisa (no caso, o nome do autor). A EN tambm restringe a navegao apenas para pginas de autores ( PgAutor), que uma das opes do tipo unio heterognea definidos no esquema de pginas.

4.3.8 XML-QL
XML-QL tem por objetivo realizar extrao, integrao e transformao de fontes de dados no formato XML [Deu99]. XML vem se popularizando como formato de documentos para a Web, devido a diversos benefcios no disponveis em HMTL, como tags definidos pelo usurio, aninhamento de elementos e validao opcional de estruturas de documentos com base em um DTD (Document Type Descriptor) uma estrutura predefinida. XML tambm vem sendo aplicada na troca de dados eletrnicos entre duas ou mais fontes de dados na Web, como por exemplo, integrao de notcias sobre determinados assuntos nesse formato. A abordagem seguida no desenvolvimento de XML-QL ver documentos XML como um BD e um DTD como um esquema. uma linguagem declarativa, relacionalmente completa, suporta vises ordenadas ou no de um documento, no rigidamente estruturada (uma vez que o esquema existe juntamente com os dados do documento) e simples de aprender e usar. XML-QL organiza dados atravs do conceito de elementos, que mantm valores estruturados e so representados por tags. Elementos podem ter atributos, como mostra o exemplo a seguir de uma DTD, referente a dados bibliogrficos:
<!ELEMENT livro (autor+, ttulo, editora)> <!ATTLIST livro ano CDATA> <!ELEMENT artigo (autor+, ttulo, ano?, (VersoCurta | VersoLonga)> <!ATTLIST artigo tipo CDATA> <!ELEMENT editora (nome, endereo?)> <!ELEMENT autor (nome?, sobrenome)>

40

Essa DTD especifica um elemento livro, composto por trs atributos: um ou mais autores, um ttulo e uma editora. Alguns desses atributos so tambm elementos, como autor, que possui um valor opcional nome (indicado por um ?) e um sobrenome. Alm disso, existem alguns atributos do tipo CDATA, que so tipados como valores string. No modelo de dados de XML-QL, um documento XML visto como um grafo. Vrtices representam elementos e so formados por um conjunto de pares atributo-valor, para os atributos diretos, como ano = 1995. Arestas so direcionadas e rotuladas com nomes de elementos, como por exemplo, livro, que conduz a um elemento livro. Vrtices folha sempre possuem um valor string e existe um vrtice distinto chamado raiz. Diversas arestas entre dois vrtices podem existir, porm um vrtice no pode ter duas arestas de sada com o mesmo rtulo e o mesmo valor. Dois tipos de modelo existem: desordenado e ordenado. No modelo desordenado, no existe ordem relativa entre elementos, como por exemplo, ttulo antes de autor. No modelo ordenado existe uma ordem total entre todos os vrtices do grafo, de acordo com a natureza dos dados, como sees e pargrafos de um texto. A partir dessa ordem total, garante-se uma ordem local sobre as arestas de sada de cada vrtice. A ordem total normalmente imposta pelo DTD. A figura 4.1 ilustra um modelo XML ordenado, onde os nmeros entre parnteses indicam ordem total e os nmeros entre colchetes as ordens parciais de arestas de vrtices. Todo vrtice de um grafo XML possui uma identidade, que um atributo identificador nico (ID) associado ao elemento ou um OID gerado automaticamente, caso um atributo ID no exista. Atributos de referncia so permitidos no modelo, sendo de dois tipos: IDREF (referncia a um elemento com chave ID) ou IDREFS (referncia a mltiplos elementos com chave ID). No grafo, essas referncias so representadas por arestas que vo do elemento referidor para o referido, como por exemplo, pessoas que so autores de artigos, sendo pessoas e artigos ramos diferentes no grafo. Outra caracterstica do modelo diz respeito aos valores dos vrtices folha, que contm apenas um valor, porm, esse pode ser composto, como partes de um nome. Nesse caso, as partes devem ser definidas como atributos do tipo CDATA. A figura 4.2 ilustra um valor composto em um grafo XML, representando, de uma forma alternativa, um nome.
(0) raiz livro [0] livro [1] (7) ano = 1999 editora [3] autor [2] (9) sobrenome [0] (12)
Heuser

(1) ano = 1995 ttulo [0] (2) BDs Semi-Estruturados sobrenome [0] (4) Heuser autor [1] ttulo [0] autor [1] (8) ontologias (5) sobrenome [0] (10)

editora [2] (3) nome [0]

(11) nome [0] (14)

(13)

(6) Campus

Mello

Campus

FIGURA 4.1 - Exemplo de um modelo de dados XML ordenado

41

CDATA
Ronaldo

sobrenome

CDATA
Mello

FIGURA 4.2 - Exemplo de representao de um valor composto no modelo XML A expressividade de XML-QL mostrada a seguir atravs de vrias consultas baseadas em um documento presente em uma URL denominada www.b.c.d/bib.xml, que contm vrias entradas para referncias bibliogrficas, descritas de acordo com o DTD exemplo. Consulta 1: retornar pares autor-ttulo de livros publicados pela editora Campus presentes em www.b.c.d/bib.xml:
Where <livro> <editora><nome> Campus </></> <ttulo> $t </> <autor> $a </> </> in www.b.c.d/bib.xml Construct <resultado> <autor> $a </> <ttulo> $t </> </>

Essa consulta utiliza variveis de consulta associadas a tags de representao de elementos, para recuperar seus valores no grafo XML. Como resposta, constri-se um novo elemento (resultado), formado pelos pares desejados. Consulta 2: buscar ttulos de livros da editora Campus e o conjunto de autores desses livros. Exemplifica o recurso de consulta aninhada para fins de agrupamento de dados na resposta. A consulta inicia com ocorrncias de livros associados varivel p, de onde se associa t os seus ttulos. Na construo do resultado, recupera-se t e todos os autores (varivel a, via subconsulta) para cada livro associado p:
Where <livro> $p </> in www.b.c.d/bib.xml <ttulo> $t </> <editora><nome> Campus </></> in $p Construct <resultado> <ttulo> $t </> Where <autor> $a </> in $p Construct <autor> $a </> </>

42

Consulta 3: buscar artigos com no mnimo um autor que tenha escrito um livro desde 1995. Essa consulta exemplifica o uso de juno atravs do casamento de elementos com o mesmo valor (variveis f e l associadas com nome e sobrenome do autor, respectivamente). A clusula element_as evita recriar um elemento artigo j existente no documento consultado:
Where <artigo> <autor> <nome> $f </> <sobrenome> $l </> </> </> element_as $a in www.b.c.d/bib.xml, <livro ano = $y> <autor> <nome> $f </> //juno pelo mesmo nome em artigo <sobrenome> $l </> //idem para sobrenome em artigo </> </> in www.b.c.d/bib.xml, y > 1995 Construct <artigo> $a </>

Consulta 4: Suponha um DTD que descreve peas compostas por outras peas e dados sobre pessoas e ttulos de suas publicaes:
<!ELEMENT pea (nome, marca, pea*)> <!ELEMENT nome CDATA> <!ELEMENT marca CDATA> <!ELEMENT pessoa (sobrenome, nome, endereo?, fone?, ttuloPublicaes*)>

O smbolo * indica que uma pea pode conter outras peas aninhadas a uma profundidade arbitrria. A consulta 4 ilustra o uso de ECs regulares, buscando nomes de peas (varivel r) que contenham a marca Ford, independente do nvel de aninhamento em que r esteja associado:
Where <pea*> <nome> $r </> <marca> Ford </> </> in www.b.c.d/bib.xml Construct <resultado> $r </>

A construo <pea*> uma EC regular, casando com qualquer seqncia de zero ou mais arestas, cada uma rotulada com o valor pea. Consulta 5: gera dados de pessoas (DTD descrito na consulta 4) com base em dados de autores. Ilustra a transformao de dados XML entre DTDs:

43

Where <$> <autor> <sobrenome> $s </> <nome> $n </> </> <ttulo> $t </> </> in www.b.c.d/bib.xml, Construct <person ID = PersonID($s, $n)> <sobrenome> $s </> <nome> $n </> <ttuloPublicaes> $t </> </>

Essa consulta mostra tambm o uso de funes predefinidas de XML-QL (funes Skolem), como PersonID, que gera um novo identificador para cada valor distinto de (sobrenome, nome). Se um valor no distinto encontrado, ento apenas anexa-se informao pessoa existente. Nesse caso, apenas ttulos de publicaes so anexadas pois endereo e telefone no fazem parte da resposta construda. O caractere $ casa com qualquer rtulo de elemento. XML-QL permite tambm a definio de funes pelo usurio, tendo documentos XML como argumentos. O corpo de uma funo so comandos XML-QL e a sua vantagem o reuso de consultas, uma vez que uma funo pode ser chamada diversas vezes aps definida, dentro de comandos XML-QL. Consulta 6: buscar dados de pessoas que pagam taxas, sendo que a informao de taxa est no documento www.irs.gov/pagadoresTaxas.xml, que descreve elementos do tipo pagadoresTaxas. Essa consulta ilustra a integrao de dados XML de diversas fontes, para obter vises combinadas de dados. Uma juno por um atributo comum aos dois documentos feita (RG):
Where <pessoa> <nome> </> element_as $n <RG> $rg </> </> in www.b.c.d/bib.xml, <pagadoresTaxas> <RG> $rg </> <taxa></> element_as $i </> in www.irs.gov/pagadoresTaxas.xml Construct <resultado> <RG> $rg </> $n $i </>

Consulta 7: buscar pessoas cujo sobrenome precede o primeiro nome. Essa consulta ilustra uma busca considerando ordem local, para modelos XML ordenados:

44

Where <pessoa> element_as $p </> in www.b.c.d/bib.xml, <nome [$i]> $x </> in $p, <sobrenome [$j]> $y in $p, $j < $i Construct <pessoa> $p </>

4.3.9 Comparao entre as Linguagens

Os sete requisitos sugeridos para uma linguagem de consulta para BDs semiestruturados no esto presentes em sua totalidade em nenhuma das linguagens descritas nas sees anteriores. Isso ocorre porque os requisitos 2, 3 e 6 (consulta ao esquema, formulao de consultas temporais e busca baseada em estrutura, respectivamente) no so atendidos pelas mesmas, talvez por serem considerados ainda suportes mais avanados de consulta. Cabe ressaltar que a busca baseada em estrutura poderia ser suportada por alguma forma de EC que garantisse que a estrutura desejada estivesse presente na hierarquia (subgrafo) do objeto alvo da consulta e no na hierarquia de objetos relacionados. Por exemplo, nome e profisso de empregados devem ser rtulos na hierarquia de objetos do tipo empregado e no na hierarquia de objetos do tipo dependente (um objeto relacionado), caso a consulta seja buscar nome e profisso de empregados. Porm, nenhuma das linguagens propostas apresenta tal funcionalidade. Os demais requisitos so atendidos pela maioria das linguagens. Quanto ao requisito 1, considera-se que toda linguagem para consulta a um modelo baseado em um grafo suporta naturalmente dados semi-estruturados com natureza estrutural complexa, podendo ser mapeado para um objeto, mesmo que o termo objeto no seja adotado e no exista o conceito de OID. Logo, a menos que um modelo de BD tenha sido explicitamente adotado (por exemplo, o modelo relacional), assume-se que esse requisito atendido. A tabela 4.1 resume os requisitos atendidos pelas linguagens propostas. Os nmeros nas colunas correspondem aos nmeros dos requisitos, conforme descritos na seo de requisitos para consulta a dados semi-estruturados. A ltima coluna informa ainda o tipo da linguagem conforme a taxionomia de linguagens para a Web. TABELA 4.1 - Requisitos para linguagens de consulta a dados semi-estruturados atendidos pelas linguagens propostas na literatura 1 4 5 7 Taxionomia Web StruQL X X X B Lorel X X X X B UnQL X X X B WebSQL X X A WQL X X A Weblog X B Ulixes X X X A XML-QL X X X B

45

Destaque especial dado a linguagem Lorel, nica que suporta coero em predicados de seleo. Por outro lado, Weblog e WQL, por no apresentarem ECs, esto mais distantes dos requisitos sugeridos. No que diz respeito a taxionomia de linguagens para a Web, exceto WebSQL, WQL e Ulixes, que executam internamente parse (anlise sinttica) de documentos com formato HMTL para fins de extrao de dados e adequao com algum modelo de dados tradicional, as demais linguagens manipulam dados organizados em grafos. Outras caractersticas, que no se enquadram nas classificaes acima, ocorrem nas linguagens: 1. Resultados nomeados: resultados de consultas podem ser armazenados no BD, como gerao de pginas HTML em WQL. Esses resultados podem ser fontes de futuras consultas; 2. Funes predefinidas: algumas linguagens, como StruQL, apresentam funes que so usadas como predicados booleanos em condies de consultas; 3. Funes definidas pelo usurio: o usurio pode definir funes para servirem tambm como predicados de filtragem de dados, como em Weblog. Essa caracterstica importante pois permite o reuso de consultas formuladas, uma vez que o corpo de tais funes so consultas; 4. Atualizao de dados: Lorel, por exemplo, permite a incluso de novos objetos e a alterao de valores em modelos de grafos; 5. Integrao com sistemas de RI: algumas linguagens para a consulta a documentos Web, como WebSQL, alm da consulta por contedo, possibilitam a busca tradicional por palavra-chave, atravs da ativao de sistemas de RI e posterior tratamento dos documentos recuperados; 6. Esquema predefinido: DTDs de XML-QL, por exemplo, so estruturas de documentos em formato XML, que facilitam o processamento de consultas. Normalmente, essa caracterstica est associada a linguagens que manipulam formatos especficos de documentos; 7. Consultas aninhadas: a possibilidade de aninhamento de consultas tem a vantagem de modularizar e refinar consultas complexas. StruQL um exemplo de linguagem que suporta essa caracterstica. A tabela 4.2 mostra o atendimento dessas caractersticas pelas linguagens propostas. As colunas correspondem aos nmeros das caractersticas. TABELA 4.2 - Caractersticas particulares suportadas pelas linguagens propostas na literatura 1 2 3 4 5 6 7 StruQL X X X Lorel X X UnQL X WebSQL X X WQL X Weblog X X X Ulixes X X

46

XML-QL

O armazenamento de resultados a caracterstica mais presente nas linguagens, ao contrrio da possibilidade de atualizao de dados e da integrao com sistemas de RI. XML-QL a linguagem que apresenta o maior nmero de caractersticas, ao contrrio de UnQL e WQL. XML-QL tambm suporta vrios dos requisitos mostrados na tabela 3, sendo, assim, a linguagem mais poderosa em termos de funcionalidades para consulta a dados semi-estruturados.

47

5 Extrao de dados
Um dos objetivos da pesquisa em BDSEs definir uma viso mais estruturada de dados semi-estruturados, de forma que os mesmos possam ser manipulados mais facilmente. Para tanto, so necessrios mecanismos que identifiquem, recuperem e estruturem dados semi-estruturados relevantes. O processo que realiza essas tarefas pode ser chamado de extrao de dados e as ferramentas que auxiliam nesse processo so chamadas extratores. Extratores retornam resultados mais precisos e mais concisos que sistemas de RI, uma vez que possuem conhecimento sobre a organizao dos dados existente nas fontes de dados e quais informaes devem ser buscadas. A extrao de dados normalmente transforma dados semi-estruturados de uma fonte de dados, como a Web, para dados adequados a um modelo de dados, seja ele semiestruturado (como OEM) ou estruturado (como o modelo relacional), ou algum formato com maior estruturao (como XML) que possa ser entendido por uma gramtica de processamento de consultas. Nesse sentido, os conceitos de mediadores e wrappers so bastante importantes, uma vez que atuam como mdulos intermedirios entre aplicaes e fontes de dados semi-estruturadas. Esses mdulos so responsveis por essas transformaes de dados. Ainda no possvel afirmar que exista uma arquitetura padro para extrao de dados, dada a diversidade de tcnicas de extrao existentes na literatura. Com base na anlise dessas tcnicas, em [Dor00] proposta uma classificao que distingue dois tipos de extrao: extrao sinttica e extrao semntica. A primeira delas extrai dados considerando padres sintticos presentes em documentos e a segunda considerando conceitos do domnio de conhecimento relevante para um conjunto de aplicaes. Os conceitos de mediadores e wrappers e as tcnicas de extrao de dados so detalhados nas sees seguintes.

5.1 Mediadores
Aplicaes que requerem dados de fontes heterogneas necessitam de uma camada de software que faa a mediao com essas fontes, envolvendo tarefas como abstrao, combinao e explicao de dados. Assim sendo, um mediador um mdulo de software que explora conhecimento codificado sobre conjuntos ou subconjuntos de dados para criar informao til para uma camada de aplicaes [Wie92]. O conceito de mediador vai alm da problemtica de acesso a dados semi-estruturados, abrangendo tambm questes de integrao de dados de BDs heterogneos. Mediao cobre uma ampla funcionalidade para disponibilizao de dados para aplicaes, agindo como uma interface inteligente para lidar com problemas de representao e abstrao presentes nas fontes de dados. Mediadores apresentam uma regra ativa e contm estruturas de conhecimento que guiam as transformaes de dados, podendo inclusive manter resultados intermedirios que podem ser consultados. As funcionalidades associadas a mediadores so: Transformao e gerao de subconjuntos de dados de BDs, utilizando vises e templates de objetos, ou seja, reorganiza BDs em novas configuraes apropriadas para aplicaes;

48

Aplicao de mtodos para obter uma quantidade apropriada de dados, como por exemplo, lidar com dados relacionados recursivamente (problema em BDs tradicionais), procurando apresentar uma resposta suficiente para uma consulta atravs de uma computao de fechamento transitivo de instncias; Aplicao de mtodos para o acesso e a combinao de dados de mltiplos BDs , procurando abstrair problemas de representao e significado de dados. Problemas de converso de valores, por exemplo, devem ser tratados nesse nvel de funcionalidade, como taxas mensais e taxas semanais, unidades monetrias diferentes, etc; Computao de abstraes de dados, que trazem dados a nveis de detalhe mais geral ou mais especfico. Operaes tpicas so sumarizaes estatsticas e pesquisa por excees; Disponibilizao de informaes textuais, como a aplicao de padres para representao de texto, visando um melhor entendimento de suas informaes. Essa funcionalidade bem adequada a fontes semi-estruturadas, como dados Web; Armazenamento de dados derivados, por questes de eficincia, visando reduzir o acesso s fontes e manuteno de um conhecimento processado para uso posterior. O atendimento dessa funcionalidade exige que o problema de controle de integridade seja resolvido.

A existncia de mediadores pressupe uma arquitetura bsica em trs camadas, como mostra a figura 5.1. A camada superior composta por aplicaes independentes, gerenciadas por tomadores de deciso. A camada intermediria formada por mltiplos mediadores, gerenciados por especialistas em domnios do conhecimento. O nmero de mediadores depende das necessidades de formas de informao a serem usadas por uma ou mais aplicaes. A camada inferior compe-se de vrias fontes de dados, gerenciados por administradores de dados. Aplicaes
servios de rede

Mediadores
servios de rede

Fontes de Dados FIGURA 5.1 - Arquitetura bsica de mediadores Pela figura 5.1, v-se duas interfaces providas por servios de rede, que so as interfaces dos mediadores com as aplicaes e com as fontes de dados. A interface aplicao-mediador deve ser uma linguagem declarativa e extensvel (que permita a incorporao de novas funes), de modo a prover flexibilidade, composabilidade e iterao na comunicao com os mediadores. A interface mediador-fonte deve ser uma

49

linguagem de acesso a dados. Mediadores que combinam dados devem ter conhecimento para realizar filtragens e junes. Como podem ocorrer incompletudes (valores inexistentes para certos atributos), junes do tipo outer-joins so necessrias. Diversos aspectos devem ser considerados no projeto de uma arquitetura que apresenta mediadores: Um mediador deve ser mantido por um ou um pequeno grupo de especialistas, responsveis pela manuteno das suas regras de transformao; Dados eventualmente presentes em mediadores podem servir de entrada para outros mediadores ou mesmo serem consultados diretamente por usurios ou aplicaes. Essa segunda situao particularmente til quando o mediador informa diretamente fatos como restaurantes com melhores preos, melhores profissionais de consultoria com base no nmero de clientes ou de publicaes, etc; Mediadores podem ser especializados, para prover melhor extensibilidade, facilitar a manuteno e permitir mais escolhas s aplicaes. Portanto, a camada intermediria da arquitetura pode ser composta por uma hierarquia de especializao de mediadores, com relacionamentos de associao para troca de informao; Eventos (triggers) podem ser disparados dos sistemas gerenciadores das fontes de dados para os mediadores relacionados, de modo a manter a integridade quando da ocorrncia de atualizao de dados ou da estrutura das mesmas. No caso de atualizao de dados, um conhecimento obtido pelo mediador pode se tornar invlido (como o caso dos melhores consultores), exigindo, muitas vezes a interveno do especialista responsvel para eventuais correes que no sejam feitas de forma automtica; Linguagens de acesso a mediadores so motivo de pesquisa, devendo incluir capacidades funcionais de SQL, iterao, teste e ranqueamento. Novos predicados de seleo so necessrios para selees inteligentes como buscar os melhores alunos de uma turma qualquer, com base em alguns critrios que muitas vezes devem ser combinados, como notas e freqncia.

5.2 Wrappers
Wrapper um software usado para vincular outros componentes de software. Sua funo encapsular uma fonte de dados para torn-la usvel de uma forma mais conveniente que a sua representao original [Wra9?]. Um wrapper diferente de um mediador. Um mediador combina dados de vrias fontes de dados, enquanto um wrapper prov uma interface simplificada para uma nica fonte de dados ou mais de uma fonte que tenham uma interface comum de acesso. Um wrapper pode ainda adicionar funcionalidade a uma fonte de dados, como por exemplo, prover uma camada de acesso para um sistema de arquivos, para facilitar a manipulao dos seus dados. Wrappers agem como um mdulo intermedirio entre uma ou mais aplicaes e uma ou mais fontes de dados com interface comum. Se uma aplicao requisita dados

50

utilizando uma linguagem X baseada em um modelo de dados Y e existe uma fonte de dados manipulvel atravs de uma linguagem Z baseada em um modelo W, o wrapper deve traduzir uma entrada (solicitao) X para Z e o resultado baseado no modelo W para uma sada no modelo Y. Assim, pressupe-se que, se mais de uma aplicao acessa o mesmo wrapper, todas apresentam a mesma linguagem e o mesmo modelo. Essa traduo de linguagem e modelo aplica-se bem a um contexto de dados semiestruturados, toda vez que uma aplicao deseja uma viso estruturada de um conjunto de dados presentes em uma fonte como a Web, por exemplo. O objetivo do wrapper, nesse contexto, funcionar como um extrator de dados, identificando e adequando valores de dados com o esquema presente na aplicao. Wrappers variam nas linguagens e modelos que suportam (relacional, orientado a objetos, dedutivos, etc) e na sofisticao de sua funcionalidade. Os nveis de funcionalidade so basicamente quatro, sendo que um determinado nvel pode incorporar a funcionalidade do nvel anterior: 1. 2. 3. 4. Entrada: consulta Entrada: atualizao Entrada: inscrio Entrada: consulta sobre capacidades - Sada: resposta; - Sada: OK/no OK; - Sada: notificao de aceitao; - Sada: lista de capacidades.

No nvel 3 entende-se que o wrapper autoriza o seu uso para novas aplicaes possam utiliz-lo e o nvel 4 permite que aplicaes consultem a sua funcionalidade. No existe uma arquitetura padro para wrappers, seja interna (componentes funcionais) ou externa (por exemplo, a existncia de uma hierarquia de composio de wrappers). Porm, algumas classes funcionais podem ser identificadas: Funcionalidade genrica: considera operaes que ocorrem por causa do tipo da fonte de dados e no do seu contedo. Exemplo: converso de SQL3 para SQL independe do esquema de dados. Esse tipo de converso pode ser aplicada para uma fonte especfica, como por exemplo, SGBDs Oracle; Funcionalidade especfica: considera operaes que ocorrem por causa do contedo da fonte de dados (esquema), supondo um esquema imutvel e no importando o desenvolvedor da fonte (qual SGBD relacional, por exemplo). Exemplo: converses monetrias; Estrutura de controle: considera mudanas na forma pela qual solicitaes e respostas so passadas. Exemplo: uma fonte de dados sncrona pode ser manipulada por um wrapper assncrono que mantm as respostas em buffers at envi-las aplicao; Notificao de erros: considera um wrapper como um mdulo que reporta erros aplicao, como por exemplo, mensagens geradas pela fonte de dados (talvez devidamente adequadas a um formato mais legvel) ou resultados de erros de recuperao de falhas dentro do prprio wrapper; Chamadas a servios externos: considera que um wrapper pode solicitar servios de outros mdulos para realizar tarefas complexas. Exemplo: uso de

51

uma ontologia3 para transformar uma consulta em termos semnticos, antes de submet-la a uma fonte de dados. O projeto de um wrapper deve levar em conta respostas a uma srie de questionamentos, com vistas a facilitar o seu desenvolvimento. Alguns desses questionamentos so: 1. 2. 3. 4. 5. 6. 7. Quais fontes de dados sero suportadas pelo wrapper? Qual o estilo da interface externa? Qual a funo do wrapper? Quais linguagens de fontes de dados e modelos sero suportadas? Por qu as fontes de dados sero suportadas por wrappers? Como o wrapper ser construdo? Qual a arquitetura interna?

As perguntas de 1 a 4 ajudam na seleo de um wrapper ou na definio de requisitos de um novo wrapper. A pergunta 5 d uma idia da complexidade do wrapper (seu objetivo funcional). A pergunta 6 auxilia na escolha do paradigma de programao e a pergunta 7 identifica os mdulos, suas funes e a possibilidade de reuso de mdulos existentes.

5.3 Tcnicas de Extrao

As tcnicas de extrao presentes na literatura utilizam abordagens semiautomticas para extrao de dados e so implementadas como wrappers ou mdulos que realizam tarefas de filtragem e adequao de dados e se comunicam com wrappers. A adequao de dados produz um resultado estruturado baseado em modelos semiestruturados ou estruturados, ou ento gera formatos de arquivos (por exemplo, XML) que possam ser interpretados posteriormente. Essas tcnicas podem ser classificadas em extrao sinttica e extrao semntica [Dor00].

5.3.1 Extrao Sinttica

A extrao sinttica pressupe conhecimento da sintaxe de formatos de documentos Web para realizar a extrao de dados. Considera delimitadores de regies do texto, como tags HTML, para identificar dados relevantes a serem extrados, existindo conhecimento prvio sobre onde esses dados iniciam e terminam nessas regies. Nesse tipo de extrao no existe um esquema associado aos dados de interesse. Documentos devem ser percorridos por completo e analisados, para a extrao de todos os dados. Exemplos de duas estratgias que seguem essa tcnica de extrao so descritos na seqncia. A primeira delas segue uma abordagem dita manual de extrao e a segunda uma abordagem semi-automtica.

O conceito de ontologia explicado em detalhes na parte II deste exame de qualificao. A princpio podese pensar em uma ontologia como sendo um modelo conceitual de um domnio da realidade.

52

5.3.1.1 Extrao Manual Extrao manual baseia-se em uma especificao manual da entrada para o extrator, que informa exatamente onde os dados se encontram nos documentos. Dois exemplos so comentados a seguir.
5.3.1.1.1 Estratgia de TSIMMIS

A estratgia utilizada pelo projeto TSIMMIS, da Universidade de Stanford, nos Estados Unidos, realiza extrao de dados com base em um programa que converte pginas HTML em objetos de BD [Ham97]. Esse programa, que serve como entrada para o extrator, composto por um conjunto de comandos definido por um usurio especializado, onde so declarados os dados de interesse nas pginas e como organiz-los em objetos adequados ao modelo OEM. Wrappers que recebem consultas direcionadas a pginas HTML utilizam o extrator para recuperar dados relevantes em OEM, sendo, aps, a consulta executada e objetos OEM que satisfazem a condio retornados aplicao. Para exemplificar o processo de extrao, considera-se uma pgina HTML que mantm informaes atualizadas sobre previso do tempo e temperatura, como ilustra a figura 5.2. Parte do arquivo HTML que mantm esses dados exemplo encontra-se na figura 5.3.
Qui, 20 Jan 2000 Sex, 21 Jan 2000

Pas
ustria Blgica Dinamarca Inglaterra ...

Cidade
Viena Bruxelas Copenhague Londres

Previso
neve chuva nevoeiro nevoeiro

alta/baixa
-2 / -7 3 / -1 3/0 1 / -2

Previso
neve nublado chuva nevoeiro

alta/baixa
-2 / -7 0 / -4 -2 / -5 0 / -2

FIGURA 5.2 - Dados exemplo apresentados em uma pgina HTML para extrao Um exemplo de arquivo de entrada para o extrator mostrado na figura 5.4. Esse arquivo possui uma seqncia de comandos que descreve os passos de extrao. Cada comando tem a forma: [variveis, fonte, padro]. Na seo variveis so definidas variveis que mantero os resultados extrados. Fonte descreve o texto de entrada a ser considerado e padro d indicaes de como encontrar o texto na pgina. O processo de extrao consiste da execuo de cada comando do arquivo de entrada. No arquivo da figura 5.4 existem 5 comandos de extrao separados por colchetes. A interpretao desses comandos a seguinte: Comando 1: busca o contedo do arquivo cuja URL est indicada no campo fonte e armazena na varivel raiz. O smbolo # significa extrair; Comando 2: solicita que o resultado da aplicao do contedo do campo padro seja armazenado na varivel temperatura. O padro descarta tudo at a primeira ocorrncia da string </TR> (o smbolo * significa descartar) na segunda definio de tabela e armazene os dados entre </TR> e </TABLE>;

53

Comando 3: divide o contedo da varivel temperatura em pores de texto usando o string <TR ALIGN=left> como delimitador (separa, na verdade, as linhas de cada cidade). Os resultados so mantidos na varivel _tempCidade (o smbolo _ indica varivel temporria seu contedo no includo no resultado). Nessa situao (diviso em pores), tem-se _tempCidade como uma varivel do tipo lista, sendo que futuras filtragens so aplicadas a cada membro da lista; Comando 4: extrai o contedo dos membros da lista para o array tempCidade, iniciando pelo segundo membro (valor 1, pois a numerao inicia em zero. Isso elimina o cabealho da tabela). O valor 0 (segundo parmetro) indica a ltima clula a ser includa, contando-se do fim para o incio da lista (extrai at o final da lista, nesse caso); Comando 5: extrai valores individuais de cada posio do array (correspondentes s colunas da tabela), para variveis que iro compor parte da resposta.
1 <HTML> 2 <HEAD> 3 <TITLE> INTELLCAST: tempo na Europa </TITLE? 4 <A NAME=europa></A> 5 <TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 WIDHT=509> 6 <TR> 7 <TD colspan=11><I> Selecione uma cidade para previso local</I><BR></TD> 8 </TR> 9 <TR> 10 <TD colspan=11><I> Temperaturas listadas em graus Celsius </I><BR></TD> 11 </TR> 12 <TR> 13 <TD colspan=11><BR NOSHADE SIZE=6 WIDTH=509></TD> 14 </TR> 15 </TABLE> 16 <TABLE CELLSPACING=0 CELLPADDING=0 WITDH=514> 17 <TR ALIGN=left> 18 <TH COLSPAN=2><BR></TH> 19 <TH COLSPAN=2<I> Qui, 20 Jan 2000</I></TH> 20 <TH COLSPAN=2<I> Sex, 21 Jan 2000</I></TH> 21 </TR> 22 <TR ALIGN=left> 23 <TH><I> Pas </I></TH> 24 <TH><I> Cidade </I></TH> 25 <TH><I> Previso </I></TH> 26 <TH><I> alta/baixa </I></TH> 27 <TH><I> Previso </I></TH> 28 <TH><I> alta/baixa </I></TH> 29 </TR> 30 <TR ALIGN=left> 31 <TD> ustria </TD> 32 <TD> <A HREF=http://www.intellicast.com/tempo/vie/>Viena</A></TD> 33 <TD> neve </TD> 34 <TD> -2 / -7 </TD> 35 <TD> neve </TD> 36 <TD> -2 / -7 </TD> 37 </TR> 38 <TR ALIGN=left> 39 <TD> Blgica </TD> 40 <TD> <A HREF=http://www.intellicast.com/tempo/bru/>Bruxelas</A></TD> 41 <TD> chuva </TD> 42 <TD> 3 / -1 </TD> ... ...

FIGURA 5.3 - Parte do arquivo HTML que mantm dados sobre previso do tempo

54 1 [[ raiz, 2 get (http://www.intellicast/com/tempo/europa/), 3 # 4] 5 [temperatura, 6 raiz, 7 *<TABLE*<TABLE</TR>#</TABLE>* 8 ], 9 [_tempCidade, 10 split (temperatura, <TR ALIGN=left>), 11 # 12 ], 13 [tempCidade, 14 _tempCidade[1:0], 15 # 16 ], 17 [pais, p_url,, cidade, tempo_hoje, alta_hoje, baixa_hoje, tempo_amanha, alta_amanha, baixa_amanha, 18 tempCidade, 19 *<TD>#</TD>*HREF=#>#</A>*<TD>#</TD>*<TD>#/#</TD>*<TD>#</TD>*<TD>#/#* 20 ]]

FIGURA 5.4 - Exemplo de arquivo de entrada para o extrator O resultado da extrao um objeto OEM (figura 5.5) cuja estrutura segue a ordem de gerao das variveis persistentes durante a execuo dos comandos. Assim, tem-se raiz como o vrtice raiz do objeto complexo seguido de um subobjeto complexo temperatura e assim por diante.
raiz complex { temperatura complex { tempCidade complex { pais string ustria p_url url http://www... cidade string Viena tempo_hoje string neve alta_hoje string -2 ... } tempCidade complex { pais string Blgica p_url url http://www... cidade string Bruxelas tempo_hoje string chuva alta_hoje string 3 ... ...

FIGURA 5.5 - Exemplo de objeto OEM resultante da extrao O arquivo de entrada exemplo especifica construtores como get e split. Esses construtores e outros predefinidos simplificam os passos de extrao, uma vez que implementam operaes importantes para a organizao de dados Web, aumentando, assim, o poder do extrator.

55

5.3.1.1.2 Estratgia de ARANEUS

Outra estratgia a utilizada pelo projeto ARANEUS, da Universidade de Roma Tre, Itlia, que utiliza uma linguagem de programao chamada Editor, para acesso e reestruturao de documentos HTML [Atz97c]. Cada programa em Editor acessa um conjunto de documentos, vistos como strings, utilizando comandos bsicos de edio de texto como search (seleo de regies do texto), copy/cut/replace (reestruturao de texto) e replace. O comando search pesquisa documentos com base em padres que indicam delimitadores e a regio do texto (substring representado pelo smbolo *) a ser extrada. Um exemplo de trecho de programa em Editor o seguinte:
loop search (HTMLPage, <H1>*</H1>); copy (HTMLPage); paste (ToC); end loop;

Esse trecho de programa copia todos as partes de texto entre as tags <H1>, presentes na pgina HTMLPage, para um novo documento chamado ToC. Para tanto, pesquisa-se a pgina para localizar todos os substrings do documento presentes entre as tags <H1> e </H1> (padro especificado), copia-se essa substring para uma rea de transferncia (uso do comando copy) e ento transfere-se os contedos dessa rea para o novo documento (comando paste). O comando loop indica que o comando deve ser executado at o ltimo padro <H1>*</H1> ser encontrado no documento. Editor capaz de reestruturar textos, construindo tabelas como resultado. Suponha uma pgina HTML com dados de pintores, chamada PaintList, que possui seus nomes e ttulos de suas obras, da qual deseja-se extrair uma tabela com cabealho Ttulo e Autor e os valores desses dados. Suponha ainda que a pgina apresenta a forma:
<LI> <A HREF=ref> ttulo </A> (autor)

onde <LI> denota um item de uma lista, ttulo e autor so valores, ref indica uma URL em cada item e o trecho <A HREF=ref> ttulo </A> especifica que, quando o ttulo do autor for selecionado, a pgina cuja URL o valor de ref seja acessada. A figura 5.6 mostra o trecho de programa em Editor que executa essa tarefa. Analisando o cdigo, v-se que o comando replace gera resultados em uma tabela de nome table (cabealho e transferncia de valores) e a iterao especificada pelo comando loop pesquisa por substrings nas linhas de itens no texto, extraindo-as, retirando partes desnecessrias (tags e parnteses comando Cut) e transferindo-as para table. Os resultados gerados por Editor podem ser de duas formas: uma representao de um documento estruturado, contendo informaes de apresentao desejadas pelo usurio (apresentado em formato HTML) ou uma forma de tabela que pode ser interpretada e inserida em um BD relacional. Comandos Editor podem ser encapsulados em um wrapper que pode ser gerado como um programa independente.

56 replace (table, Ttulo \t Autor \n); replace (table, -------------------- \t -------------------- \n); loop search (PaintList, <LI>*)); copy (PaintList); paste (temp); replace (table); search (temp, <LI>*>; Cut (temp); search (temp, *</A> (; Cut (temp); replace (table); replace (table,(, ); replace (table,), ); End loop

FIGURA 5.6: Trecho de programa em Editor para extrao de dados A fraqueza tanto dessa estratgia quanto da anterior est no fato do processo de extrao ser especificado de forma manual por especialistas. Alm disso, alteraes no formato dos documentos de interesse exige alterao nos programas de extrao. Por outro lado, os arquivos gerados atendem plenamente s necessidades de dados das aplicaes, uma vez que se tem preciso completa sobre as informaes extradas. 5.3.1.2 Extrao Semi-Automtica Na extrao semi-automtica, o extrator oferece facilidades para a especificao da sua entrada para o usurio, ou seja, a especificao dos critrios de extrao para uma determinada classe de documentos. Essa estratgia particularmente til para documentos que no apresentam indicadores explcitos de estrutura, como arquivos de e-mail, anncios, ordens de servio, etc. A diferena dessa estratgia para a anterior que o usurio apenas indica, como entrada para o extrator, as regies do texto nas quais ele deseja extrair dados e o mesmo detecta, posteriormente, de forma automtica, os dados relevantes. Um exemplo de estratgia que segue essa abordagem a ferramenta Nodose, que constri wrappers de forma semi-automtica para classes de documentos especficos [Ade99]. Nodose apresenta uma interface grfica na qual o usurio carrega um documento inicial e o decompe hierarquicamente em estruturas aninhadas, conforme a natureza estrutural do prprio documento. Por exemplo, se um endereo aparece com freqncia, seleciona-se partes do texto que contenham endereos (estrutura de mais alto nvel) e, posteriormente, pode-se selecionar os seus componentes, como rua e CEP. Na seqncia, uma amostra de documentos adicionais da mesma classe so carregados e sofrem parse. As estruturas aprendidas pela ferramenta (que funciona como uma mquina de inferncia) so aplicadas a esses documentos e os seus dados extrados. Caso surjam erros, pelo fato do documento apresentar alguma variao estrutural, esses so corrigidos pelo usurio atravs da interface, permitindo que a ferramenta aprenda um pouco mais sobre as variaes estruturais dos documentos. O processo termina quando os dados de todos os documentos da amostra forem extrados com sucesso. Os dados extrados so organizados em formato XML ou um formato tabular que pode ser incorporado a um BD relacional. O processo de extrao realizado totalmente de forma interativa. A interface de Nodose apresenta algumas opes bsicas na forma de botes e duas reas de

57

visualizao: uma para o documento e outra para a estrutura em rvore que vai sendo gerada a medida que o usurio seleciona partes do texto para definir a estrutura hierrquica dos dados (Figura 5.7). As opes bsicas da ferramenta permitem adicionar um documento, adicionar/remover um nodo, remover uma subrvore e minerar. Durante a interao com a ferramenta, o usurio seleciona inicialmente no documento os elementos estruturais de mais alto nvel e a partir do texto referente a esses elementos, vai gerando subelementos, selecionando novamente partes do texto dos elementos. Se existem muitas ocorrncias de subelementos no restante do texto, pode-se solicitar ferramenta que infira os elementos restantes (opo minerar). Caso erros sejam encontrados, o usurio os corrige e solicita uma reminerao. Dessa forma, a gramtica correta do subelemento (e conseqentemente da estrutura do documento) vai sendo aprendida. Quando novos documentos de amostra forem submetidos interface, novos erros podem ser encontrados. Se isso ocorre, realizam-se novamente correes e remineraes.

FIGURA 5.7 - Interface da ferramenta Nodose Ao final desse processo, um componente executvel independente pode ser gerado (um wrapper). Esse wrapper faz o parse de documentos e gera um dos dois formatos de sada: XML ou tabelas. A ltima verso de Nodose apresenta um aprimoramento no processo de minerao no que diz respeito deteco de erros. Considerando informaes estatsticas como mdia de comprimento dos elementos e desvio padro, o minerador tem melhores subsdios para notificar o usurio sobre um elemento que seja uma possvel anomalia no documento. Se realmente essa anomalia for um erro de edio no documento, o usurio pode optar por

58

rejeitar esse elemento ou reedit-lo. Caso o usurio aceite o elemento, as estatsticas so atualizadas automtica ou manualmente. A contribuio principal dessa estratgia que o extrator aproveita o conhecimento do usurio para inferir as regras de extrao e os limites razoveis de valores dos elementos com base nas estatsticas. Experimentos realizados coletaram documentos de diversas categorias e formatos de marcao, sendo a mdia de encontro de erros verdadeiros da ordem de 83%.

5.3.2 Extrao Semntica

Uma extrao dita semntica quando est baseada em um modelo abstrato da realidade que descreve conceitos que podem estar relacionados e apresentam atributos que o caracterizam. Esse modelo serve como entrada para o extrator, que identifica valores desses atributos nas fontes de dados semi-estruturadas e gera instncias desses conceitos como resultado. Dois exemplos desse tipo de extrao so descritos: extrao baseada em frames e extrao baseada em ontologias. 5.3.2.1 Extrao Baseada em Frames A extrao baseada em frames a estratgia empregada pela ferramenta InfoExtractor, desenvolvida pelo projeto Dyade Mdiation do instituto francs INRIA, cujo objetivo prover componentes de software integrados para acesso a fontes de dados na Internet [Smi9?]. InfoExtractor reconhece estruturas implcitas em documentos e identifica informao pertinente a conceitos predefinidos em um modelo abstrato de documento, retornando uma verso estruturada desses conceitos. No modelo abstrato, predefinido para um certo domnio, um documento particionado em regies chamadas contextos de avaliao (CAs), onde certos conceitos so pesquisados. Existem frames de definio de conceitos (FDCs) definidos, que contm informao necessria para encontrar uma instncia de um conceito (IC) em um CA. Uma IC pode ela prpria ser considerada um CA, formando assim uma hierarquia de conceitos. Como fragmentos de um conceito podem estar em CAs diferentes, possvel um conceito aparecer em mltiplos CAs. Considera-se que todo documento apresenta um ou mais CAs, identificveis inicialmente por suas sees fsicas (como cabealho, resumo, etc) conforme a classe do mesmo. O processo de identificao e estruturao da informao toma inicialmente um CA conhecido e de mais alto nvel (por exemplo, o cabealho de um documento), recupera os FDCs relativos aos conceitos que podem estar presentes nesse CA (por exemplo, data de publicao dentro do cabealho), classifica o CA em grupos de avaliao (GAs) e avalia recursivamente cada GA. A idia de um GA que nele ICs no se sobrepem. ICs podem apenas se sobrepor dentro de um mesmo CA, mas em GAs diferentes. Nessa avaliao, buscam-se ICs que casam com a definio presente em algum FDC. Essas instanciaes constituem uma verso estruturada de informao relevante, que pode ser armazenada e indexada para consultas futuras.

59

A figura 5.8 mostra a descrio de um FDC para um suposto domnio de documentos especficos para ofertas de emprego. FDCs contm toda a informao necessria para o reconhecimento de ICs, sejam elas mais gerais ou mais especializados. No exemplo da figura 15, temos uma IC genrica, que descreve uma parte do texto do corpo do documento referente a uma oferta de emprego, como por exemplo: Vaga para auxiliar de escritrio: empresa do ramo imobilirio; experincia de dois anos comprovada. Fone: 3333333 . Todo FDC tem expresses regulares que descrevem os padres inicial e final de texto que casam com ICs, caso existam. No exemplo, o padro inicial uma linha com zero ou mais espaos em branco seguido de uma letra maiscula e terminando com :. Alm disso, palavras-chave embutidas podem estar presentes no texto para facilitar o reconhecimento. Quando diversos FDCs candidatos casam com o string analisado, as palavras-chave e seus pesos so consultados e o FDC com maior escore o vencedor. Pores do texto que no casam com nenhum FDC so ignorados. NomeConceito CA PadroIdentificao PalavrasChave FinalPadro OrdemAvaliao StatusAvaliao Domnio ItemOfertaEmprego Corpo /^s*[A-Z]/&&/:/
CAs para o conceito Expresso regular que define o possvel incio da IC Palavras-chave e pesos usados para identificar a presena de uma IC fim da IC GA para o conceito Informa se a presena do conceito obrigatria Classes de documentos no Qual o conceito se aplica

Responsvel (0.25), empresa (0.33), vaga (0.5), gerencia (0.5), auxiliar (0.4), experincia (0.4) Expresso regular que define o <null> 1 Opcional OfertasEmprego

FIGURA 5.8 - Exemplo de um frame de definio de conceito O resultado da extrao de InfoExtractor so tabelas que mantm, para cada CA, as seguintes informaes sobre seus conceitos: Nome (por exemplo, FoneEmpresa); Grau de certeza da extrao (por exemplo, 80%); String que o instancia (por exemplo, 3333333).

Esse resultado pode ser futuramente processado por outros mdulos para fins de armazenamento ou manipulao. Esses outros mdulos podem inclusive ser wrappers que estruturem esses dados em instncias de conceitos mais genricos (como Ofertas de Emprego e Empresas, por exemplo), mais adequados s necessidades de aplicaes. A vantagem principal da estratgia o suporte a refinamentos sucessivos na anlise de GAs, possibilitando encontrar conceitos estruturados (como um endereo composto por

60

rua, nmero e CEP). Porm, exige-se uma definio prvia e manuteno de FDCs do domnio de interesse. 5.3.2.2 Extrao Baseada em Ontologias Extrao baseada em ontologias aplicada a dados Web que possuem um nmero de constantes (stings) identificveis em seus documentos e cujos conceitos do seu domnio podem ser descritos em uma ontologia relativamente pequena, que serve como base para o reconhecimento e extrao de informaes [Emb98a]. Um exemplo de domnio de pequena escala so dados de obiturios, cujos documentos descrevem constantes como nome, idade, datas de nascimento e morte da pessoa falecida e dados de familiares. A figura 5.9 mostra um documento desse tipo.
Joo da Silva Nosso amado Joo da Silva, com idade de 41 anos, faleceu na manh de Sbado, 7 de maro de 1998, devido a um acidente de automvel. Ele nasceu em 4 de agosto de 1956 em Porto Alegre, filho de Pedro Silva e Maria Silva. Casou com Rita da Silva em 1 de junho de 1981. Joo deixa Rita; os filhos Jlio (9), Jorge (8), Juliana (6); pais; trs irmos, Dario (Marta), Paulo (Joana), Marco (Rosana), e duas irms, Ana (Srgio) Motta e Snia (Manoel) Pereira. Um filho, Jonas, o precedeu na morte. Os servios funerais ocorrero s 12 horas, meio-dia, da Sexta, 13 de maro de 1998, no cemitrio central, na rua dos Andradas, 350. Amigos podem comparecer entre as 5 e 7 horas. Quinta, na capela Santana, na avenida Independncia, 1302, das 10:45 s 13:00. O enterrro ocorrer na Sexta, no cemitrio da azenha.

FIGURA 5.9 - Um documento exemplo dados de obiturios Os passos seguidos por essa abordagem so os seguintes: 1. Define-se um modelo ontolgico do domnio; 2. Faz-se o parse da ontologia e gera-se um esquema de BD e regras para o casamento de constantes e palavras-chave; 3. Extrai-se dados do documento atravs de um extrator de registro, que separa o texto em parties do tamanho de registros, removendo partes desnecessrias como tags e apresentando-o como um documento no-estruturado; 4. Invoca-se um reconhecedor que usa as regras do passo 2 para extrair do documento no-estruturado os conceitos e seus relacionamentos de acordo com o modelo ontolgico; 5. Preenche-se o BD usando heursticas para determinar quais constantes so inseridas em quais registros do esquema do BD. Utiliza-se para essa tarefa um gerador de registros. Esses passos so detalhados a seguir com base no domnio de obiturios.

61

Passo1 Especificao da Ontologia A ontologia consiste de um modelo objeto-relacionamento e de frames de descrio de dados (FDDs - encapsulam as propriedades de conceitos) que descrevem regras de extrao que facilitam o reconhecimento de constantes. A figura 5.10 ilustra a ontologia para o domnio exemplo. Nesse modelo, retngulos pontilhados representam conjuntos de objetos lxicos (constantes ou atributos) e retngulos com trao contnuo representam conjuntos de objetos com identidade (conceitos). O modelo suporta restries de cardinalidade, como o fato de que um funeral ocorre em uma ou mais endereos (1:*) e um endereo pode ou no pertencer a um funeral (0:1). Relacionamentos ternrios so descritos por losangos, como a indicao de que uma pessoa falecida tem um relacionamento de parentesco (irmo, primo, etc) com um ou mais nomes de pessoas.
Idade 1:* DataNascimento: Data DataMorte: Data 1:* has 1:* has DataEnterro: Data 1:* EndereoEnterro: Endereo has 1:* DataFuneral: Data 1:* 0:1 0:1 has EndereoFuneral: Endereo 1:* has 0:1 has has 0:1 1 0:* NomeFalecido: Nome 1:* -> 1 NomeParente: Nome 1:* ->1 Relacionamento (Grau de parentesco) DataViglia: Data

PessoaFalecida 0:1 0:1 0:1 0:* has 1 has

1:* has has 1 0:1 0:1 Viglia 1:*

0:1 Enterro 0:1 has 1

has 1:* EndereoViglia: Endereo 1:*

0:1 0:1 has 1:* has

0:1 has HorrioIncio: Horrio HorrioFim: Horrio

Funeral

1:*

HorrioFuneral: Horrio

FIGURA 5.10 - Modelo ontolgico para o domnio de obiturios Passo 2 Gerao do Esquema do BD e dos FDDs Uma especificao textual da ontologia definida gerada e serve como entrada para o parse, resultando nos FDDs (descreve as regras e padres lxicos) e uma especificao do esquema de BD. As figuras 5.11 e 5.12 mostram, respectivamente, exemplos de partes de FDDs para as constantes Nome, NomeParente e Relacionamento e parte do esquema gerados. Na figura 5.11, v-se, por exemplo, a especificao da constante Nome e de suas regras de extrao e padres associados. Todo nome composto de um primeiro nome (First) e um sobrenome (Last) separado por um ou mais espaos em branco (\s+). Um nome tambm um padro que inicia com uma letra maiscula seguido de letras minsculas, podendo ocorrer uma inicial de nome intermedirio (indicado pelo padro

62

opcional ([A-Z]\.\s+)?) antes do sobrenome. Na seo lexicon (descreve constantes lxicas) esto descritas extensas listas de nomes e sobrenomes, respectivamente nos arquivos first.dict e last.dict.
Nome matches [80] case sensitive Constant { extract First, \s+, Last; }, ... { extract [A-Z][a-zA-Z]*\s+([A-Z]\.\s+)?, Last; }, ... Lexicon { First case insentive; Filename first.dict; }, { Last case insentive; Filename last.dict; }; End; NomeParente matches [80] case sensitive Constant { extract First, \s*\(, First, \)\s*, Last; substitute \s*\([^)]*\) -> ; ... End; ... Relacionamento matches [14] Constant { extract irmo; context \birmos?\b; }, { extract irm; context \birms?\b; }, ... Keyword \bfilho\b, \bcasado\b, ... End; ...

FIGURA 5.11 - Exemplo de um frame de descrio de dados

Object: PessoaFalecida; Nonlexical: Viglia {DataViglia, EndereoViglia, ... Lexical: Data, DataNascimento, DataMorte, ... PessoaFalecida: NomeFalecido [1]; PessoaFalecida: Idade [0:1], PessoaFalecida: DataNascimento [0:1], PessoaFalecida: DataMorte [0:1], PessoaFalecida: Funeral [0:1], PessoaFalecida: DataFuneral [0:1], ... Viglia: PessoaFalecida [0:*] has Viglia [1]; Viglia: Viglia [0:1] has DataViglia [1:*]; ... PessoaFalecidaRelacionamentoNomeParente: PessoaFalecida [0:*] has Relacionamento [1:*] to NomeParente [1]; ...

FIGURA 5.12 - Exemplo de especificao de esquema de BD NomeParente uma especializao de Nome, sendo que, para casos onde existe um nome intermedirio entre parnteses (sobrenome de solteira para mulheres), a regra aplica uma substituio a esse padro que elimina o nome intermedirio. Relacionamento indica

63

os tipos de grau de parentesco permitidos e as palavras-chave de contexto que geralmente indicam (do pistas) sobre a ocorrncia de um conceito. A figura 5.12 ilustra a descrio de conjuntos de objetos lxicos e no-lxicos e seus relacionamentos (clusula has) associados. A ltima especificao descreve o relacionamento ternrio. Passo 3 Extrao de Registros No-Estruturados Nesse momento, deve-se investigar pginas na Web e classific-las como sendo pginas de obiturios (etapa ainda no implementada). Em seguida, aplica-se um extrator de dados, que separa informao dentro da pgina em pores de dados (registros) que representam instncias de conceitos na ontologia. Para tanto, o seguinte algoritmo aplicado: 1. Monta-se uma rvore cuja hierarquia representa o aninhamento de tags HTML (chamada rvore de tags). Um exemplo de ramo dessa rvore pode ser a seqncia de tags html-body-table-..., sendo html a raiz padro; 2. Busca-se o nodo com a maior subrvore, ou seja, maior nmero de filhos. Esse nodo contm os registros de interesse pois representa a estrutura principal do documento; 3. Para cada subrvore desse nodo, conta-se o nmero de ocorrncias de cada filho (tags), concentrando-se em tags dominantes (TDs), ou seja, tags com alta freqncia; 4. Aplica-se, ento, a chamada heurstica da maior ocorrncia: se existe apenas uma TD, ela selecionada como separadora de registros; se existe mais de uma, verifica-se se elas tm o mesmo nmero de ocorrncias ou esto dentro de outra tag tendo o mesmo nmero de ocorrncias. Se alguma das duas condies for verdadeira, seleciona-se alguma delas como separadora, seno aplica-se a heurstica do desvio padro. A heurstica do desvio padro encontra o comprimento de cada segmento de texto para TDs idnticas e calcula o desvio padro desses comprimentos. Isso feito para todas as TDs. A TD escolhida aquela com menor desvio padro, uma vez que registros de interesse tm aproximadamente o mesmo comprimento; 5. Encontrada a tag separadora (TS), modifica-se o documento da seguinte forma: insere-se a string ##### aps cada ocorrncia da TS e remove-se as tags do documento. Assim, tem-se todos os registros de interesse (dados de obiturios) devidamente separados. Passos 4 e 5 Reconhecimento de Conceitos e Relacionamentos e Gerao de Instncias para o Esquema do BD Para cada registro de interesse (ou registro no-estruturado) no documento, realizam-se 2 passos: 1. Produz-se uma tabela do tipo descritor/string/posio (TAB), consistindo de constantes e palavras-chave reconhecidas no registro de interesse;

64

2. Casam-se atributos do esquema do BD com valores da TAB, gerando-se instncias. A figura 5.13 descreve parte de uma TAB gerada para o obiturio da figura 16. A gerao da TAB resultado da aplicao das regras de casamento descritas nos FDDs. Cada entrada em TAB descreve uma constante ou palavra-chave. O primeiro campo, descritor, se for uma constante, mantm o nome do conjunto de objetos ao qual a constante pertence, seno, apresenta o formato KEYWORD(x), onde x o nome do conjunto de objetos ao qual a palavra-chave se aplica. O segundo campo, string, guarda a constante ou palavra-chave propriamente dita, com possveis transformaes realizadas pelas regras dos FDDs. Os dois ltimos campos descrevem as posies inicial e final no texto, respectivamente.
NomeParente | Joo da Silva | 1 | 13 NomeFalecido | Joo da Silva | 1 | 13 NomeParente | Joo da Silva | 28 | 39 NomeFalecido | Joo da Silva | 28 | 39 KEYWORD(Idade) | idade | 46 | 51 Idade | 41 | 56 | 57 KEYWORD(DataMorte) | faleceu | 64 | 70 DataNascimento | 7 de Maro de 1998 | 92 | 109 DataMorte | 7 de Maro de 1998 | 92 | 109 DataEnterro | 7 de Maro de 1998 | 92 | 109 DataFuneral | 7 de Maro de 1998 | 92 | 109 DataViglia | 7 de Maro de 1998 | 92 | 109 KEWORD(Relacionamento) | nasceu em 4 de Agosto de 1956 em Porto Alegre, filho de | 144 | 191 Relacionamento | pais | 144 | 191 KEYWORD(DataNascimento) | nasceu | 144 | 149 DataNascimento | 4 de Agosto de 1956 | 154 | 172 DataMorte | 4 de Agosto de 1956 | 154 | 172 ...

FIGURA 5.13 - Exemplo de parte de uma tabela descritor/string/posio O processo de reconhecimento utiliza heursticas para escolher constantes como pertencentes a um determinado conjunto de objetos, sempre que a mesma aparece associada a mais de um deles. Por exemplo, Joo da Silva aparece na TAB exemplo como NomeParente ou NomeFalecido. Como no existem palavras-chave para NomeFalecido, essa constante obrigatria no modelo ontolgico e est no incio do texto, define-se Joo da Silva como pertencente a NomeFalecido, removendo-se outras entradas errneas para essa constante. Outro exemplo a data 7 de Maro de 1998, que associada DataMorte pois existe uma palavra-chave (faleceu) para a conceito DataMorte bem prxima a essa constante no texto. O passo de gerao de instncias toma como entrada TAB e o esquema do BD para construir tuplas para os dados extrados. Primeiramente so gerados comandos de criao de tabelas e posteriormente comandos de insero no esquema , ambos na linguagem SQL. Esse passo tambm comandado por heursticas motivadas por restries na descrio do esquema do BD:

65

1. Heursticas individuais: so as heursticas para associao de valores (constantes) a conjuntos de objetos, como j foi exemplificado anteriormente. Para valores que aparecem no mximo uma vez, baseia-se na proximidade de palavras-chave, como no exemplo do conceito DataMorte, ou na primeira ocorrncia de um valor pertencente ao conjunto de objetos em questo, como no caso de NomeFalecido, caso no existam palavras-chave; 2. Heursticas Grupo-Funcional: so as heursticas que tratam grupos funcionais (GFs). Um grupo funcional um conjunto de objetos que aparece vrias vezes junto com seus conjuntos de objetos funcionalmente dependentes, como no caso de Viglia e seus objetos HorrioIncio e HorrioFim. GFs geralmente aparecem como uma unidade em um documento. Portanto, buscam-se GFs prximos dentro dos limites dos chamados delimitadores de contexto, que so certas palavras-chave. No ltimo pargrafo do obiturio da figura 5.9, a palavra-chave funeral (ou funerais) geralmente vem antes de informaes sobre viglias e a palavra-chave enterro vem depois. Nesse intervalo, procuram-se por GFs formados pelas constantes DataViglia, EndereoViglia, HorrioIncio e HorrioFim; 3. Heursticas de Grupos Aninhados: so as heursticas que tratam relacionamentos ternrios ou superiores. Esses relacionamentos ocorrem em textos atravs de uma estrutura aninhada onde, aps um certo valor, seguem-se os seus valores associados, os quais podem tambm estar aninhados. Restries de cardinalidade podem simplificar o aninhamento e sugerir ordens potenciais. Por exemplo, no relacionamento ternrio PessoaFalecida-RelacionamentoNomeParente, NomeParente determina funcionalmente o relacionamento de parentesco. Assim, a heurstica indica que o aninhamento implcito para uma pessoa falecida o grau de parentesco seguido dos nomes de parentes, como por exemplo, a constante filhos seguida dos trs nomes de pessoas ( Jlio, Jorge e Juliana), no obiturio da figura 5.9. Os comandos de insero gerados como resultado da aplicao das heursticas so bastante precisos, mas no perfeitos. Alguns exemplos no elegantes so ilustrados na figura 5.14: a omisso dos dados de data e endereo da viglia ocorrem porqu esses valores so os mesmos dados do funeral da pessoa falecida, previamente inseridos na tupla de PessoaFalecida. Tambm os dados de alguns parentes, como filhos, no esto completos e poderiam ser inferidos do texto. Essa estratgia tem o propsito de automatizar completamente a gerao de wrappers com base em uma ontologia definida por um ou mais especialistas em um certo domnio. Uma experincia prtica de aplicao da estratgia obteve resultados na ordem de 90% de revocao (nmero de documentos do domnio com extrao correta / nmero de documentos do domnio) e 75% de preciso (nmero de documentos do domnio com extrao correta / total de documentos analisados) na extrao de constantes.

66 Insert into PessoaFalecida Values (1001, Joo da Silva, 41, 7 de Maro de 1998, 4 de Agosto de 1956, 5001, 13 de Maro de 1998, rua dos Andradas, 350, 12 horas, 0, , ) Insert into Viglia Values (7001, 1001, , , 5, 7); ... Insert into PessoaMortaRelacionamentoNomeParente Values (1001, filho, Jorge); ...

FIGURA 5.14 - Exemplos de inseres de dados no perfeitas

5.3.3 Comparao das tcnicas

A diferena bsica entre as tcnicas de extrao sinttica e semntica que a primeira exige a definio de delimitadores para guiar o extrator, enquanto a segunda baseia-se em um modelo de descrio da realidade. O uso de um modelo de domnio da realidade, com especificao de padres e restries facilita o entendimento da semntica dos dados no momento da extrao, porm, exige algoritmos mais complexos para reconhecimento de conceitos e relacionamentos (como as heursticas da extrao baseada em ontologias) e aplica-se a um domnio mais restrito do conhecimento, para o qual os conceitos so vlidos. J na extrao sinttica, aplicam-se apenas parses sobre os documentos, porm, para classes de documentos com alta heterogeneidade estrutural, a preciso da extrao fica mais comprometida. Comparando as abordagens de extrao sinttica, temos a estratgia manual que exige uma completa especificao/atualizao manual do processo de extrao pelo usurio. Apenas usurios especializados na programao desse processo podem lidar com o extrator. Alm disso, o sucesso da extrao depende de existncia de tags corretamente definidas para delimitar os dados de interesse. Por outro lado, a extrao apresenta alta preciso, para documentos da mesma classe. A estratgia semi-automtica auxilia mais o usurio na especificao do processo de extrao e mais adequado para o tratamento de documentos de uma mesma classe que apresentem uma certa heterogeneidade. Porm, a definio das regras de extrao trabalhosa pois est baseada em amostragem de documentos. J no caso das abordagens de extrao semntica, a estratgia baseada em frames suporta refinamentos sucessivos para a determinao de estruturas aninhadas, mas seu modelo mais pobre que a estratgia baseada em ontologias. Essa segunda estratgia suporta relacionamentos e restries de cardinalidade em seu modelo, que justamente por ser mais rico, exige uma anlise mais complexa por parte do extrator. A tabela 5.1 resume as comparaes feitas, adicionando outras caractersticas encontradas na anlise das estratgias: formato do resultado e funcionalidade dentro do contexto de um BDSE.

67

TABELA 5.1 - Comparao entre as tcnicas de extrao Extrao Sinttica Extrao Semntica Vantagens
Pode ser aplicada a documentos Web de diversos formatos, como HTML e XML; Menor complexidade; Aplica-se a domnios mais amplos. Exige delimitadores nos documentos; Menos precisa. Facilita mais o entendimento estrutura do documento; Mais precisa. Maior complexidade; Aplica-se a domnios mais restritos. da

Desvantagens

Manual Vantagens

Semiautomtica

Baseada frames

em Baseada ontologias

em

Maior preciso para documentos bastante homogneos

Desvantagens

Resultados

Auxilia o usurio na especificao do processo de extrao; Adequado a documentos com maior heterogeneidade . do Exige especificao e Especificao processo de extrao atualizao completamente manual trabalhosa do processo de extrao; Exige tags bem definidas nos documentos. Tsimmis Araneus Arquivos XML; Objetos Arquivos Tabelas. OEM HTML; Tabelas Wrappers Gera acessam os wrappers resultados extrados

Suporta Modelo mais rico refinamentos sucessivos para determinao de estruturas aninhadas

Modelo mais pobre

Processo de extrao mais complexo

Tabelas

Tabelas de relacionais

BDs

Funcionalidade

Gera wrappers

Wrappers acessam Gera wrappers os resultados extrados

68

6 Sistemas
Este captulo descreve alguns sistemas de gerenciamento de dados semiestruturados descritos na literatura. nfase dada nas suas arquiteturas, modelos de dados e linguagens utilizadas, com alguns comentrios sobre seus mdulos internos.

6.1 STRUDEL
STRUDEL um sistema de gerenciamento de sites da Web desenvolvido nos laboratrios da AT&T [Fer97b, Fer98]. Seu objetivo a constuo e a manuteno de sites com base em vises de dados de fontes heterogneas. A definio de vises pode ser aplicada em diversos nveis: na representao lgica de uma informao no sistema, na representao de estrutura de pginas com relacionamentos via links e na forma de apresentao de pginas em HTML. Para tanto, STRUDEL possui um modelo de dados uniforme que suporta essas representaes, uma linguagem que acessa e reestrutura as informaes representadas nesse modelo e mdulos que integram e transformam dados de fontes heterogneas. A arquitetura do sistema pode ser vista na figura 6.1. O modelo de dados adotado um modelo de grafo estilo OEM, que representa objetos atmicos e complexos. Os dados manipulados em todas as interfaces entre mdulos da arquitetura so objetos vistos como grafos.
Grafo de Pginas HTML Templates HTML Gerador HTML Grafo de Site Mquina de Gerenciamento de Sites Processador de Consultas Grafo de Dados Mediador Repositrio de Dados Strudel

Wrapper

Wrapper

BD relacional/ BDOO

Pginas HTML

FIGURA 6.1 - Arquitetura do Sistema STRUDEL

69

A representao lgica de dados no sistema chamada grafo de dados, sendo resultado da integrao de dados de fontes por um mdulo Mediador. Essas fontes podem ser BDs ou sites externos que mantm pginas HTML. O mdulo Mediador j recebe esses dados representados na forma de grafos, adequando-os ao modelo conceitual do sistema. Os mdulos Wrappers so responsveis por receber consultas do Mediador, convert-las para consultas nas fontes de dados e posteriormente converter os resultados para objetos na forma de grafos, repassando-os para o Mediador. Mediadores tambm so responsveis pelo armazenamento e acesso a grafos de dados criados pelo sistema (dados internos), que so mantidos no Repositrio de Dados Strudel. Consultas ao sistema podem envolver tanto dados internos como externos, cabendo ao Mediador buscar e combinar esses dados para montar os grafos de dados de resposta. A Mquina de Gerenciamento de Sites processa consultas sobre a Web e atualizaes de dados internos, com o auxlio dos mdulos Mediadores e Processador de Consultas. Esse mdulo combina diversos grafos de dados, gerando um grafo de site com os dados requeridos pelo usurio. O Gerador HTML materializa um grafo de site como um grafo de pginas HTML, conforme a viso que se deseja ter dos dados para fins de apresentao. Para tal tarefa, uma linguagem de templates HTML utilizada. Baseado nas estruturas e mtodos presentes nos templates HTML para determinados contextos, esse mdulo associa informaes aos vrtices dos grafos de pginas que do detalhes sobre a forma de apresentao do dado. O mdulo Processador de Consultas gera planos de execuo de consultas considerando otimizaes sobre dados na forma de grafos, como fatorizao de prefixos comuns em expresses regulares, que evita mltiplas varreduras de um mesmo caminho no grafo. Otimizaes tradicionais, aplicadas a operaes de seleo, projeo e juno, so tambm executadas. STRUDEL apresenta uma linguagem nica para consulta e reestruturao de dados de sites, que a StruQL (ver seo 4.3.1). Expresses StruQL acessam grafos de dados gerados pelo Mediador como abstraes de fontes de dados ou mantidos no Repositrio e definem grafos de sites como vises de grafos de dados. STURDEL atualmente um prottipo sofrendo experimentaes. Pesquisas futuras em relao ao sistema dizem respeito ao suporte evoluo dinmica de sites, definio de uma interface grfica para acesso ao sistema e integrao com ambientes de programao, como ferramentas para criao e gerenciamento de Web sites.

6.2 LORE
LORE (Lightweight Object REpository) um sistema de BD desenvolvido na Universidade de Stanford, Estados Unidos, destinado ao gerenciamento de dados semiestruturados, no exigindo a vinculao de dados a um esquema, porm, tirando vantagem da estrutura de objetos quando essa existe [Hug97]. LORE utiliza o modelo de dados OEM para a representao de objetos semi-estruturados, a linguagem Lorel para consulta e atualizao de dados e DataGuides que mantm dinamicamente o estado corrente do BD, facilitando a explorao da estrutura e a formulao de consultas (ver captulos 3 e 4).

70

A arquitetura de LORE est representada na figura 6.2. O acesso ao sistema se d atravs de uma interface chamada Lore Application Program Interface (API). Essa interface que recebe instrues de: Aplicaes que manipulam dados semi-estruturados; Uma interface textual destinada a desenvolvedores para o acesso a pequenos BDs ou para o aprendizado de funcionalidades do sistema; Uma interface grfica HTML, destinada ao usurio final.

A API de LORE uma pequena coleo de classes C++. Toda vez que um programa cliente conecta-se a um BD LORE, pode submeter operaes de BDs atravs dos mtodos dessas classes. A interface grfica permite a escolha de um BD, sendo que um Data Guide referente ao esquema estrutural dos dados apresentado. O usurio pode, ento, formular consultas textuais ou visuais. Consultas visuais so especificadas no estilo query-by-exemple, usando o data guide para selecionar ECs e definir critrios de seleo. Resultados de consultas ocorrem em HTML, em um formato hierrquico para facilitar a navegao. Objetos complexos podem ter seus subobjetos apresentados em mais de uma pgina, com links para relacion-las.
Interface Textual Interface Grfica HTML Aplicaes

API Resultados Prprocessamento (Lorel para OQL) Consultas Gerao do plano de consulta Utilitrios:
Gerenc. Data Guides; Carregador; Gerenc. de ndices

Compilao de consultas Otimizao da consulta Mquina de Dados

Parsing Requisies no de consultas

Gerenciador de Objetos

Operadores de Consulta

Gerenciador de Dados Externos

Fontes de Dados Externas

(Acesso para Consulta)

Armazenamento Fsico

FIGURA 6.2 - Arquitetura do sistema LORE A camada de Compilao de Consultas consiste de um Parser (anlise sinttica da consulta), um Pr-processador (converte consultas Lorel em consultas OQL), um Gerador de Plano de Consulta (gera uma rvore de processamento de consulta) e um Otimizador (realiza transformaes na rvore, decide o uso de ndices e envia a Mquina de Dados).

71

A camada da Mquina de Dados compreende diversos mdulos: Operadores de Consulta: so uma lgebra para objetos OEM, responsveis pela execuo de planos de consulta. Essa lgebra apresenta operadores tradicionais de BDs relacionais, como seleo e projeo, assim como novos operadores para, por exemplo, navegao em ECs (scan) e juno de vrtices (join); Gerenciador de Objetos: um tradutor entre objetos OEM e suas respectivas representaes a nvel de armazenamento fsico (arquivos), executando primitivas como busca de objetos, comparao entre dois objetos, execuo de operaes de coero de dados, iterao sobre subobjetos de um objeto complexo e cache de objetos freqentemente recuperados do BD. LORE um sistema desenvolvido sem ter nenhum SGBD tradicional como camada de acesso a dados; Gerenciador de Dados Externos: o mdulo que habilita a recuperao e integrao transparente de dados de fontes externas no processamento de consultas. Para tanto, utiliza wrappers e metadados embutidos no prprio esquema de um objeto externo (objetos externos so identificados apropriadamente pelo sistema). Esses metadados do informao sobre a localizao do wrapper que busca e traduz esse objeto para OEM, o intervalo de validade do objeto e alguns argumentos que servem para restringir o nmero de objetos buscados na fonte externa, como por exemplo, palavras-chave relevantes, caso o objeto extrado seja um conjunto de publicaes de um autor, sendo autor um objeto interno; Utilitrios: so um conjunto de ferramentas auxiliares do sistema: Gerenciador de ndices: controla os dois tipos de ndices suportados por LORE: lindex (ndice hash para arestas, retornando os objetos de onde o rtulo parte OID + rtulo) e vindex (ndice B-Tree para rtulos e valores rtulo + operador + valor retornando os objetos atmicos que tm um aresta de chegada e um valor satisfazendo um operador, como > 5). Planos de consulta que utilizam ndices em uma rvore de processamento de consulta inicialmente localizam os objetos de interesse nos vrtices folha da rvore atravs de vindexs e aps utilizam uma seqncia de lindexs para atravessar a rvore no sentido bottomup, tentando casar completamente o processamento com a EC da consulta; Carregador: aceita uma descrio textual de incluso de dados (arquivo de carga) e os incorpora ao sistema. Essa uma das formas de incluso de dados em LORE, alm do uso de comandos update de Lorel (ver seo 4.3.2); Gerenciador de Data Guides: mantm descries estruturais de dados semiestruturados presentes em BDs LORE. Na verdade, so metadados sobre objetos OEM, sendo eles prprios mantidos como objetos OEM (ver seo 3.1.1).

Diversos trabalhos relacionados LORE esto em pesquisa e desenvolvimento, como o suporte a transaes, vises e triggers, indexao por palavras-chave e aumento no poder de expresso da interface grfica, equiparando-a como o poder de expresso de Lorel.

6.3 ARANEUS

72

ARANEUS definido como um sistema de gerenciamento de bases Web (SGBW), ou seja, um repositrio de dados Web com um gerenciamento no estilo de BD [Atz97a, Mec98a, Mec98b]. Uma base Web uma coleo de dados que pode conter dados estruturados, como BDs tradicionais ou semi-estruturados, como sites da Web. ARANEUS um projeto em desenvolvimento, coordenado pela Universidade de Roma, Itlia. As caractersticas principais do sistema so: Modelo de dados orientado a pginas; Linguagens para extrao de dados (definio de wrappers), criao, atualizao e reestruturao de sites Web; Mtodos para projeto e implementao de sites Web.

A arquitetura de ARANEUS encontra-se na figura 6.3. O modelo de dados do sistema o ADM, que representa Web sites como uma coleo de esquemas de pginas interrelacionadas atravs de links (ver seo 3.1.2). O mdulo Gerenciador de Objetos ADM manipula, a nvel lgico, objetos ADM aninhados, decompondo-os em tabelas e utilizando um SGBD relacional para armazen-los. Dessa forma, o mapeamento entre os dois modelos controlado por esse mdulo.
SGBW ARANEUS Gerenciador de Objetos ADM

Ulixes U s u r i o Interface com o Usurio

Penelope PDL PML

Editor Interface com SGBD Interface com Servidor HTTP

Biblioteca de Wrappers

Internet

..... .....

..... .....

SGBD

Servidor HTTP

Sites Locais

Sites Web

FIGURA 6.3 - Arquitetura do sistema ARANEUS Usurios tm acesso a dados internos e externos atravs de uma Interface HTML. Dados externos ao sistema podem ser pginas HTML (Web sites) no geradas no mbito do sistema ou tabelas de BDs. Pginas HTML so extradas, reestruturadas e representadas como objetos ADM. O processo de extrao e reestruturao responsabilidade de wrappers gerados a partir da linguagem Editor (ver seo 5.3.1.1.2) e mantidos em uma Biblioteca de Wrappers. Alm disso, dados internos referentes a sites locais so mantidos no repositrio do sistema.

73

A linguagem Ulixes permite a consulta a esquemas de pginas ADM atravs de expresses navegacionais (ver seo 4.3.7). Consultas a dados externos exigem o acesso Biblioteca de Wrappers. Os resultados gerados so controlados pelo Gerenciador de Objetos ADM, que podem ser materializados como tabelas relacionais. Novos sites podem ser criados e administrados atravs da linguagem Penelope. Penelope define e manipula vises sobre objetos ADM que podem ser materializadas como pginas HTML para fins de apresentao em browsers. O desenvolvimento de novos sites segue os seguintes passos em ARANEUS: 1. Projeta-se o site (esquema ADM) utilizando uma metodologia de projeto especfica; 2. Mapeia-se a estrutura ADM para uma representao hipertexto utilizando PDL (Penelope Definition Language), que descreve a estrutura de um esquema de pginas em termos de tabelas relacionais aninhadas. Essa estrutura ADM pode inclusive ser um resultado de consulta ou extrao realizada pela linguagem Ulixes; 3. Gera-se o site utilizando PML (Penelope Manipulation Language) [Sin98]. Supondo a existncia de um esquema de pginas gerado por Ulixes referente a publicaes do pesquisador Joo da Silva, materializado como uma tabela PublicaesJoo (Autores, Ttulo, Referncia (referncia bibliogrfica), Ano, RefParaPgina (link para uma URL)), deseja-se uma viso hipertexto em que as publicaes estejam organizadas pelo ano em que foram publicadas. Na seqncia, so mostrados exemplos de definio de duas vises (comando Define Page da PDL) (a) e a gerao das mesmas (comando Generate da PML) (b):
DEFINE PAGE PginaAno AS URL URL(<Ano>); Ano: TEXT <Ano>; ListaTrabalhos: LIST OF ( Autores: Ttulo: Referncia: RefParaPgina: FROM PublicaesJoo DEFINE PAGE PginaJoo UNIQUE AS URL resultado.html; ListaAnos: LIST OF ( Ano: TEXT <Ano>; RefParaPgAno: LINK TO PginaAno ( URL(<Ano>))); FROM PublicaesJoo (a) GENERATE PginaJoo; GENERATE PginaAno; (b)

TEXT <Autores>; TEXT <Ttulo>; TEXT <Referncia>; LINK TO PginaConferncia UNION PginaPeridico <RefParaPgina>);

A especificao do exemplo (a) reestrutura os dados da tabela, gerando dois esquemas de pginas para apresentao:

74

Um esquema nico chamado PginasJoo, a ser gerado com o nome resultado.html. Esse esquema mantm uma lista de anos e links para as pginas referentes a publicaes daquele ano; Um esquema que mantm as publicaes de cada ano, com informaes sobre autores, ttulo, referncia bibliogrfica e link para a conferncia ou peridico onde o trabalho foi publicado. Esses dados so obtidos dos atributos da tabela indicada na clusula From.

Assim, tem-se especificada uma pgina ndice ( resultado.html) e pginas com informaes de publicaes para cada ano. Links para as pginas de cada ano esto presentes na pgina ndice, sendo as URLs de cada ano definidas automaticamente atravs da funo URL(<Ano>). A gerao dessas pginas e o preenchimento automtico das mesmas com os valores da tabela PublicaesJoo o resultado dos comandos Generate. O comando Generate permite ainda especificar tabelas auxiliares que contenham dados adicionais a serem inseridos nas pginas HTML, com o sentido de atualizar as informaes. Outro comando da PML, Remove, exclui URLs que satisfazem uma condio ou mesmo esquemas de pginas hipertexto. Tanto Ulixes como Penelope implementam lgebras para o acesso a dados, respectivamente, uma lgebra navegacional e uma lgebra de objetos. A primeira atua sobre estuturas aninhadas (representaes de pginas), retornando um conjunto de tuplas. A lgebra de objetos atua sobre vises relacionais, gerando especificaes em HTML. Detalhes sobre essas lgebras no foram encontrados nas referncias bibliogrficas sobre ARANEUS. Pesquisas futuras referentes ao sistema esto direcionadas inferncia de estrutura da Web (engenharia reversa de sites), tcnicas de otimizao de consultas, algoritmos eficientes para deteco de mudanas em sites e manuteno incremental de vises hipertexto.

6.4 Comparao entre os Sistemas

A tabela 6.1 descreve alguns pontos de comparao entre as caractersticas dos sistemas analisados. Colunas com um smbolo ? indicam que a informao no foi encontrada para o sistema em questo. O sistema STRUDEL tem como principal contribuio a separao entre vises lgicas de dados (desejadas pelos usurios) e a forma como os dados esto armazenados em fontes internas e externas. Alm disso, diversas verses de sites (com maior ou menor detalhe de informao) podem ser gerados em pginas HTML, para fins de apresentao. O uso combinado de mediadores e wrappers na arquitetura facilita essas abstraes. A definio de uma linguagem nica e de alto nvel para acesso, gerao e reestruturao de dados de sites Web e de mtodos de otimizao aplicados a dados semi-estruturados tambm so pontos positivos do sistema. A linguagem de reestruturao de ARANEUS, por outro lado, apresenta maior expressividade, por ser apresentar mais construtores de estrutura.

75

TABELA 6.1 - Comparao entre caractersticas dos sistemas gerenciadores de dados semi-estruturados STRUDEL LORE ARANEUS Gerenciamento de sites Gerenciamento de dados Gerenciamento de sites Objetivo Funcionalidades
Web Definio de vises lgicas de dados; Definio de apresentaes HTML; Otimizao de consultas em grafos. semi-estruturados Gerenciamento de metadados; Otimizao de consultas em grafos; lgebra para grafos; Gerenciador de armazenamento fsico; Gerenciador de ndices para grafos; Interface grfica para acesso a dados e metadados. Orientado a grafo Orientado a grafo (OEM) (OEM) StruQL Lorel Consulta; Consulta; Reestruturao. Atualizao; Coero automtica; Mediadores + Wrappers Wrappers ? ?

Web Definio de vises relacionais; Definio de apresentaes HTML; Linguagem procedural para extrao de dados; lgebra para consulta; Interface grfica para acesso a dados.

Modelo de dados Linguagem Nome de consulta Facilidades

Orientado a pginas (ADM) Ulixes Consulta

Extrao

Arquitetura Tcnica

Wrappers Sinttica manual

LORE o sistema que apresenta o maior nmero de funcionalidades, do ponto de vista de um SGBD, para o gerenciamento de dados semi-estruturados: otimizao de consultas baseada em lgebra, controle de acesso eficiente ao meio fsico, suporte a ndices para objetos OEM, manuteno de metadados e interao com o usurio atravs de uma interface grfica. Sua linguagem, Lorel, a mais poderosa dos trs sistemas, apresentando suporte no s para consulta, mas para atualizao e coero de dados. Apenas no apresenta facilidades de apresentao. A filosofia de ARANEUS bastante semelhante a de STRUDEL, no sentido de propiciar diferentes vises de dados Web a nvel lgico e de apresentao. Porm, o sistema no apresenta uma camada de mediao para integrao de dados. ARANEUS define linguagens de alto nvel para extrao, consulta e apresentao de dados Web. A definio de uma linguagem procedural para extrao evita o desenvolvimento de gramticas de extrao, que so complexas, dada a heterogeneidade de dados semi-estruturados. Seu modelo de dados direcionado a estruturao de dados Web representados em pginas, sendo mais poderoso para esse formato de dado, porm, menos geral que modelos orientados a grafos.

76

7 Concluso
BDSEs mostra-se um tpico bastante atual de pesquisa na rea de BDs, motivado principalmente pela popularidade de dados Web e sua necessidade de acesso de forma simples pelos usurios e com resultados de consultas precisos e concisos. As ferramentas disponveis atualmente com o objetivo de pesquisar a Web no atendem a essas necessidades. O objetivo final, ento, manipular dados semi-estruturados, como a Web, da mesma forma que se manipulam dados em BDs tradicionais. Algumas tendncias podem ser concludas com base no levantamento feito nesse trabalho. Primeiramente, tem-se duas categorias de sistemas de BDSEs: 1. Destinados gerncia de dados semi-estruturados de modo geral; 2. Destinados gerncia especfica de dados Web, como pginas ou sites. Em ambos os casos, utiliza-se um modelo de dados flexvel orientado a grafos para melhor representar a heterogeneidade de dados semi-estruturados. Nesse modelo, vrtices representam objetos e arestas direcionadas representam subobjetos ou valores atmicos. Essa estrutura hierarquizada, devendo existir pontos de entrada que indiquem o nvel mais alto de um objeto complexo ou um BD que mantm um conjunto de objetos como filhos. Nos sistemas da categoria dois, esse modelo pode ser abstrado para pginas (vrtices) e links (arestas) e apresentar uma maior estruturao, de forma a manter atributos especficos do domnio, como URL, data da ltima alterao, lista de itens da pgina, etc. Quanto a linguagens de consulta, vrias propostas existem, preocupadas com navegao em estruturas de grafo. Para tanto, uma sintaxe de definio de expresses regulares de caminho fundamental para a recuperao da estrutura de objetos. Algoritmos eficientes de otimizao ou lgebras para grafos devem ser implementados para minimizar o tempo de percorrimento e a passagem pelo mesmo caminho mais de uma vez. Para sistemas da categoria dois, existem, em geral, mecanismos para reestruturao do resultado de consultas, a fim de gerar novos sites ou simplesmente facilitar a navegao. Nota-se, por outro lado, a ausncia de requisitos importantes nas linguagens analisadas, como a busca baseada em estrutura e o uso de coero, fundamentais no tratamento de dados semiestruturados. A pesquisa em extrao de dados tem revelado vrias estratgias semi-automticas, baseadas principalmente em anlises sintticas ou aplicao de heursticas. Essas estratgias sempre consideram padres presentes na descrio de documentos ou de linguagens de marcao (XML, HTML, etc) que organizam o texto de documentos. Esse fator ainda limita bastante a reusabilidade dessas tcnicas para qualquer fonte de dados. A arquitetura de consenso para extrao parece ser a que utiliza wrappers para extrair dados e retorn-los de forma adequada ao modelo de dados do sistema e mediadores para combinar esses resultados em uma resposta nica. Quando no existe um mdulo mediador explcito, o processador de consultas normalmente realiza a tarefa de integrao de dados. Porm, uma camada de mediao interessante de ser implementada quando o modelo de dados tem pouca semntica, procurando resolver questes como nomenclatura de atributos, atributos inexistentes ou com tipos distintos, etc.

77

Diversos pontos ainda continuam em aberto em BDSEs, dada a carncia de literatura a respeito, como por exemplo, atualizao de dados e propagao de modificaes, armazenamento e indexao, gerncia de transaes, restries de integridade, autorizao, interoperabilidade com SGBDs tradicionais, etc. No se sabe se as tcnicas tradicionais de BDs para essas questes devem ser modificadas ou no. Particularmente, os problemas de atualizao e interoperabilidade so complexos pois dados semi-estruturados evoluem rapidamente e so heterogneos. Outra questo que tem despertado interesse diz respeito a semntica de consultas em BDSEs, do ponto de vista do usurio final. Linguagens de consulta acessam a estrutura em grafo de documentos e objetos atravs de ECs, que esto fortemente vinculadas estrutura sinttica de documentos. Por exemplo, suponha o seguinte trecho de documento em XML:
... <pessoa> <nome> Joo Santos </nome> <habilidade> SQL </habilidade> <habilidade> C++ </habilidade> </pessoa> ... <cursos> <tpico> SQL </tpico> <participantes> <nome> Maria Souza </nome> <nome> Pedro Silva </nome> ... </participantes> ... </cursos> ...

Uma consulta que deseja buscar todas as pessoas que possuem conhecimento de SQL retorna Joo Santos como resposta, pois, na estrutura sinttica hierrquica desta pessoa existe a habilidade nesta linguagem. Porm, est implcito, pela anlise do restante do trecho do documento, que Maria Souza e Pedro Silva tambm possuem conhecimento de SQL pois realizaram um curso sobre a linguagem. Em documentos com ampla variabilidade estrutural torna-se trabalhoso e mesmo invivel especificar todos os padres sintticos onde uma certa informao pode estar presente. Neste contexto, seria interessante a especificao de consultas declarativas no em termos de padres sintticos, mas sim semnticos, considerando conceitos do domnio de interesse que estivessem presentes nos documentos. Uma soluo para tal problema o uso de ontologias, que podem ser aplicadas como modelos conceituais de um conjunto de fontes de dados semi-estruturados. Duas vantagens importantes decorrem desta aplicao: Ontologias definem o vocabulrio conceitual comum para usurios ou aplicaes formularem consultas. Esse vocabulrio inclui entidades, relacionamentos, atributos, restries de integridade, etc;

78

Ontologias, por embutirem regras dedutivas (herana da sua ampla aplicao na rea de Inteligncia Artificial (IA)), podem prover conhecimento adicional ao usurio, como por exemplo, o fato de que participantes de cursos so pessoas e que tem habilidade nos tpicos cursados.

A parte II desse Exame de Qualificao trata do tema ontologias e de algumas propostas presentes na literatura que tentam aplic-la a BDSEs, inclusive para a execuo de consultas.

79

Parte II Profundidade : Aplicao de Ontologias a Bancos

de Dados Semi-Estruturados 8 Introduo
Originalmente, o termo ontologia proveniente da Filosofia, sendo empregado para descrever a existncia de coisas no mundo. Na Cincia da Computao, ontologias vm sendo aplicadas desde o incio da dcada de 90 na rea de Inteligncia Artifical (IA) para representao computacional de conhecimento em reas como engenharia de conhecimento e processamento de lngua natural. Neste contexto, pode ser entendida como uma especificao formal e explcita de uma conceitualizao consensual. Recentemente, ontologias vm sendo utilizadas nas reas de BD e RI como suporte interoperabilidade de fontes de dados distribudos e heterogneos. Do ponto de vista de BD, uma ontologia pode ser vista como uma especificao parcial de um domnio da realidade, que descreve basicamente conceitos, relaes entre conceitos e regras de integridade. Na literatura existem vrios trabalhos voltados especificao e consulta a dados baseados em ontologias. Porm, no existem ainda muitos trabalhos que aplicam ontologias a dados semi-estruturados. A motivao para o uso de ontologias em BDSEs vem da anlise das fraquezas das alternativas de acesso a dados semi-estruturados disponveis: Mquinas de RI e tcnicas de parse de linguagem natural: so limitados no entendimento semntico das fontes de dados; Pesquisa por padro e por casamento de estrutura: exigem documentos com uma estruturao uniforme, que seja de conhecimento do usurio; Metadados como anotaes em linguagens de marcao: requerem editores e analisadores especializados para interpretao semntica.

Ontologias mostram-se como uma soluo para estas questes uma vez que, como comentado no captulo 7, do suporte a consultas declarativas, no estilo de consultas a BDs, a conceitos e relaes do domnio, evitando expresses de navegao em estruturas complexas de dados semi-estruturados. Alm disso, provem uma camada semntica (estrutura abstrata indicativa) sobre fontes de dados heterogneas e melhoram a interoperao entre estas fontes pois possvel atravs delas mapear e combinar dados extrados, considerando tambm o reuso de ontologias existentes. Esta segunda parte deste exame apresenta e compara trabalhos que aplicam ontologias para estas finalidades. Esta parte de profundidade est organizada da seguinte maneira: o captulo 9 discute vrios entendimentos dados a ontologias e tenta contextualiz-la para a rea de BD. O captulo 10 apresenta formalismos, linguagens e sistemas para especificao de ontologias. O captulo 11 o ncleo deste trabalho pois d um panorama de propostas de aplicao de ontologias a BDSEs, procurando investigar e comparar as finalidades de uso, alm de tipos e elementos conceituais especificados. Finalmente, o captulo 12 apresenta as concluses desta parte de profundidade.

80

9 Ontologias Conceitos Bsicos

9.1 Definio
O termo Ontologia j conhecido e aplicado a bastante tempo nas reas da Filosofia e da Epistemologia, significando, respectivamente, um sujeito de existncia (uma contabilizao sistemtica da Existncia) e um conhecimento ou saber. Recentemente, na dcada de 90, esse conceito passou a ser utilizado na Cincia da Computao, mais especificamente na rea de IA, para descrever conceitos e relacionamentos utilizados por um agente ou uma comunidade de agentes (conhecimento compartilhado) [Gru93]. A definio de Ontologia dentro do contexto da Cincia da Computao ainda no est consolidada, porm, vem sofrendo aprimoramentos a medida que desperta o interesse de um nmero crescente de pesquisadores da rea. Algumas definies existentes so apresentadas a seguir.

9.1.1 Definio de Grubber

Tom Grubber, pesquisador em representao e compartilhamento de conhecimento, na rea de IA, um dos pioneiros na introduo do conceito de ontologia na Cincia da Computao: Uma Ontologia uma especificao explcita de uma conceitualizao. [Gru93]. Uma conceitualizao pode ser entendida como: os objetos, conceitos e outras entidades que so assumidos como presentes em uma rea de interesse, assim como os relacionamentos entre eles. uma abstrao simplificada do mundo que se deseja representar. Dentro do contexto da IA, o propsito de ontologias permitir compartilhamento e reuso de conhecimento, estabelecendo uma concordncia no uso de um vocabulrio consistente com respeito a um universo de discurso. Esse vocabulrio define o que existe, o que deve ser representado. Com base nesse vocabulrio, consultas e inferncias podem ser feitas por sistemas baseados em conhecimento. Assim, na prtica, uma ontologia define termos (nomes de entidades no universo de discurso) associados a textos que descrevem o que os mesmos significam e axiomas formais que restringem a interpretao e o uso desses termos. Por exemplo, supondo um universo de discurso relativo a uma empresa, termos relevantes podem ser empregado, chefe e departamento. Nesse contexto, um axioma possvel pode ser (gerencia(X,Y)), indicando que no possvel X gerenciar Y, se X estiver associado a um empregado e Y a um departamento.

9.1.2 Definio de Fikes

Segundo Richard Fikes, tambm pesquisador da rea de IA:

81

Uma Ontologia uma provedora de informao para um vocabulrio utilizado na representao de conhecimento. [Fik]. O entendimento sobre um provedor de informao semelhante viso pratica de Gruber, ou seja, mantm definies e sentenas, sendo definies os smbolos de um vocabulrio e sentenas os axiomas que restringem esses smbolos. A especificao desse provedor de informao (ontologia) deve ser naturalmente possvel atravs de uma linguagem de representao de conhecimento pois essas incluem em sua sintaxe um conjunto de smbolos (vocabulrio) e regras de inferncia (axiomas).

9.1.3 Definio de Bzivin

Jean Bzivin, pesquisador da rea de Engenharia de Software (ES), afirma que a Engenharia de Modelos uma parte essencial da ES, pois lida com meta-modelos para a definio de modelos associados aplicaes. Nesse contexto, alm do desenvolvimento do software propriamente dito, deve-se desenvolver os metadados (ou meta-modelos) necessrios para os softwares, sendo as ontologias esses meta-modelos [Bz9?]. O modelo MOF (Meta-Object Facility) um exemplo de arquitetura de referncia para modelagem, que descreve metadados e apresenta quatro nveis, como mostra a figura 9.1.
Meta-modelo (Entidade, relao, ...)

Modelo

(Classe, mtodo, atributo, ...) (Clientes, contas, agncias, ...) (Joo Silva, 3333-3, Centro, ...)

Esquema Exemplos

FIGURA 9.1 - Arquitetura do modelo MOF Em MOF, alm de uma arquitetura de modelagem padro, composta pelos trs ltimos nveis (Modelo-Esquema-Exemplos), existe um nvel superior chamado Metamodelo, que descreve conceitos primitivos usados para construir modelos. Assim sendo, Uma Ontologia um meta-modelo que contm os conceitos e relaes que so relevantes para uma dada tarefa de modelagem.

9.1.4 Definio de Guarino

Nicola Guarino apresenta de uma outra forma a definio de conceitualizao de Gruber, afirmando que ela significa um conjunto de regras informais que restringem a estrutura de um pedao da realidade, usada por um conjunto de agentes para identificar,

82

isolar e organizar objetos e relaes relevantes. [Gua97]. Guarino enfatiza a definio da estrutura e de restries associadas aos conceitos da realidade e suas inter-relaes. Com base nessa definio, Guarino critica aqueles que encaram uma conceitualizao apenas como uma terminologia ou uma taxionomia, pois a parte estrutural desconsiderada. A definio, ento, de ontologia, dada por ele: Uma Ontologia representao explcita e parcial de uma conceitualizao. V-se uma ontologia, nesse caso, tambm como uma abstrao parcial da realidade, ou seja, no se tem a pretenso de representar todos os conceitos de um universo de discurso. Com essa nova definio, uma ontologia aproxima-se mais da rea de BD, dada a semelhana de sua definio com a definio de um modelo conceitual, que representa uma abstrao parcial e descreve estrutura e restries.

9.1.5 Anlise das Definies

Identificando as palavras-chave presentes nas definies dadas, vemos que uma ontologia abrange: Relacionado aos fatos da realidade: objetos, entidades, vocabulrio, termos, estrutura de um pedao da realidade, metadados; Relacionado semntica da realidade: axiomas, sentenas, relaes, regras ou restries; Relacionado modelo: meta-modelo, abstrao parcial da realidade, modelo conceitual.

Com base nessa coletnea de palavras, pode-se compreender uma ontologia, de um ponto de vista de BD, como sendo uma especificao parcial de um domnio da realidade, que descreve conceitos, relaes entre eles e regras de integridade. A idia de ontologia como modelo e meta-modelo sugere que diversos nveis ontolgicos podem existir e se relacionar. Essa afirmao no tem a inteno de ser uma definio nova e fechada sobre uma ontologia. Ela apenas indica um ponto de vista assimilado com base nas definies anteriores, visando facilitar a compreenso do conceito em trabalhos a serem apresentados nos prximos captulos. As caractersticas de ontologias, a seguir, facilitam o seu entendimento.

9.2 Caractersticas
Ontologias herdam inicialmente caractersticas de bases de conhecimento, porm apresentam diferenas em relao a elas [Fik]. Ontologias enfatizam usabilidade em mltiplas tarefas ou situaes, uma vez que so parte de uma linguagem de representao. Assim, sua nfase na descrio de classes de objetos ao invs de indivduos do mundo real e na representao de propriedades gerais de relaes e funes ao invs de descrever inferncias especficas. Na terminologia da BD, uma ontologia apenas um modelo

83

conceitual, portanto, no mantm instncias. Uma base de conhecimento mantm instncias. Apesar da afirmao anterior, dentro do contexto especfico de BDSEs, tem-se uma sutil diferena entre uma ontologia e um modelo conceitual. Um modelo conceitual um modelo que descreve, dentre outras coisas, a estrutura dos dados do BD em um alto nvel de abstrao. Porm, uma ontologia no representa a estrutura das fontes de dados associadas a ela, apenas prope uma estrutura de consenso para conceitos e relaes que so teis para grupos de usurios, sendo essa estrutura instanciada pelo BDSE atravs de tradues realizadas por wrappers e mediadores. Assim, uma ontologia um mecanismo de interpretao parcial ou total do universo de dados semi-estruturados de uma ou mais fontes, no existindo obrigatoriamente uma correspondncia direta entre possveis estruturas implcitas ou explcitas dessas fontes e a estrutura da ontologia. Nesse sentido, uma ontologia desenvolvida no com a finalidade de definir a estrutura de um BDSE e sim visando definir um vocabulrio de trabalho para um grupo de usurios. Outro aspecto importante associado a ontologias, bastante enfatizado em termos de pesquisa, o reuso de conhecimento definido em ontologias j existentes. Esse fator afeta o desenvolvimento de ferramentas e metodologias, exigindo que existam mecanismos de traduo entre formalismos de representao e a definio de nveis de reuso. Esses nveis sugerem que ontologias estejam organizadas em mdulos de conhecimento, que especificam nveis de detalhamento desse conhecimento. Nesse sentido, interessante desenvolver amplas ontologias, contendo conhecimento de senso comum e uma capacidade de aumentar esse conhecimento atravs da recuperao de fontes de dados online. Hwang [Hwa99] descreve caractersticas fundamentais que devem ser consideradas na construo de uma ontologia: Aberta e dinmica: para adaptar-se a mudanas e aprimoramentos no domnio associado, uma ontologia deve ser aberta e dinmica tanto estruturalmente como algoritmicamente (comportamento). Idealmente, essa evoluo deve ser a mais automatizada possvel; Escalvel e interopervel: uma ontologia deve ser facilmente escalvel para um amplo domnio e adaptvel a novos requisitos. Deve ser possvel integrar mltiplas ontologias em uma nica, com solues para o tratamento de taxionomias conceituais diferentes. Essa caracterstica exige que a ontologia seja simples e clara; De fcil manuteno: mesmo que uma ontologia atenda ao requisito de ser dinmica, a sua manuteno deve ser fcil. Novamente, se sua definio simples e clara, mais facilmente ela pode ser inspecionada por especialistas humanos; Semanticamente consistente: a ontologia deve, obviamente, manter conceitos e relacionamentos coerentes; Independente de contexto: uma ontologia no deve conter termos muito especficos em um certo contexto, quando essa lida com fontes de dados de

84

larga escala. Isso dificulta a associao da semntica de cada fonte com os conceitos da ontologia e a integrao de ontologias. Em resumo, as caractersticas levantadas a respeito de ontologias so: 1. Modelo conceitual; 3. Modelo reusvel; 5. Modelo escalvel e interopervel; 7. Modelo semanticamente consistente; 2. Modelo mais amplo que um esquema de BD; 4. Modelo aberto e dinmico; 6. Modelo de fcil manuteno; 8. Modelo independente de contexto.

9.3 Classificaes
Uma ontologia pode ser classificada segundo dois critrios: nvel de detalhe e nvel de dependncia [Gua9?]. No primeiro caso, quanto mais detalhada for a ontologia, mais ela se aproxima do significado pretendido do vocabulrio, porm, exige uma linguagem de representao mais rica e de difcil integrao com outras ontologias. Ontologias detalhadas so chamadas ontologias off-line, pois no so compartilhadas. Por outro lado, se a ontologia simples, j desenvolvida tendo em mente o compartilhamento e o reuso por diversos grupos de usurios, sendo uma ontologia on-line. Um exemplo de ontologia pode ser uma especificao de Thesaurus, que pode ser utilizado por aplicaes que desejam aproveitar seus tipos de relacionamento. Quanto ao nvel de dependncia, existem quatro tipos de ontologias, cujo relacionamento de especializao entre elas mostrado na figura 9.2.
Ontologia de Nvel Superior

Ontologia de Domnio

Ontologia de Tarefa

Ontologia de Aplicao

FIGURA 9.2 - Relacionamento entre os tipos de ontologia quanto ao nvel de dependncia Uma ontologia de nvel superior descreve conceitos muito gerais, como espao, tempo, objeto, assunto, ao, etc, de um domnio ou problema particular. um tipo de ontologia interessante pois pode ser reusada por diversas ontologias de grupos de usurios. Uma ontologia de domnio e uma ontologia de tarefa descrevem um vocabulrio para um domnio genrico (como medicina ou automveis) e para uma tarefa ou atividade genrica (como diagnstico ou venda), respectivamente, especializando termos da ontologia de nvel superior.

85

Uma ontologia de aplicao depende tanto de um domnio quanto de uma tarefa particular, sendo uma especializao de ambas. Corresponde a regras impostas por conceitos do domnio quando executam uma certa tarefa, como por exemplo, substituio de uma unidade sobressalente de um automvel. Pode existir ainda o conceito de ontologia de representao, que descreve metadados necessrios definio de outros tipos de ontologia. Correspondem a primitivas (como por exemplo, conceito, atributo e relao) de uma linguagem de representao de conhecimento. Esse tipo de ontologia pode ser usada ainda no processo de integrao de ontologias, como uma tradutora entre especificaes feitas em linguagens de representao diferentes.

9.4 Aplicaes
Ontologias tm sido aplicadas na rea de IA h vrios anos, como uma teoria lgica que restringe os modelos de uma linguagem lgica [Gua97]. Nesse sentido, dado um conjunto de smbolos no-lgicos (predicados e funes) de uma linguagem lgica, uma ontologia prov axiomas que restringem o sentido dos predicados, como por exemplo, casado(X,X), indicando que uma pessoa no pode estar casada consigo mesma. Essa noo de teoria lgica vem sendo aplicada em diversas subreas da IA, como sistemas de aquisio e representao de conhecimento e sistemas de processamento de linguagem natural. No segundo caso, uma ontologia pode manter a definio de termos referentes a elementos gramaticais da linguagem e seus relacionamentos, facilitando uma tarefa de anlise sinttica, por exemplo. Em sistemas de aquisio de conhecimento, mecanismos de inferncia so facilitados pelas definies de relacionamentos entre conceitos de um domnio, permitindo a derivao de novos dados. O uso de ontologias em sistemas de informao tem por finalidade a manuteno de conceitos, em um alto nvel de abstrao (como modelos e/ou meta-modelos), que sejam teis para vrias aplicaes. Em BD, ontologias tem sido aplicadas principalmente em BDs heterogneos e Data Warehouses como modelos conceituais globais, resultantes de uma concordncia na definio de entidades e relacionamentos. Mediadores integram os esquemas locais de uma federao de BDs ao esquema ontolgico [Ont99 ???]. Mais recentemente, a rea de sistemas de RI emprega tambm ontologias como provedores de semntica para o vocabulrio de certas classes de documentos, detectando melhor a relevncia de documentos em uma busca por termos que so palavras-chave. Considerando BDSEs, que lidam com fontes de dados heterogneas, ontologias so importantes no sentido de manter esquemas de conceitos relevantes da realidade e suas relaes, de modo a guiar, por exemplo, a extrao e a estruturao de dados. Como em BDs heterogneos, a inteno definir um modelo conceitual global, que abstraia a localizao, o acesso e a transformao necessrios para se obter um dado. Porm, em BDSEs no se tem necessariamente fontes locais estruturadas como em um sistema de BD heterogneo. Como em sistemas de RI, a inteno definir uma semntica, uma interpretao sem ambigidade para os dados, porm, no em termos de palavras-chave e sim em termos de ocorrncias de conceitos nas fontes de dados. Exemplificaes do uso de ontologias nessa rea encontram-se no captulo 11.

86

Atualmente, uma das tendncias de aplicao de ontologias est sendo a rea de comrcio eletrnico (CE). Um esforo nesse sentido o grupo Ontology.org (informaes esto disponveis no site http://www.ontology.org), um frum industrial e de pesquisa acadmica dos Estados Unidos dedicado a usar ontologias no sentido de facilitar a formao e sustentao de empreendedores e parcerias em CE. O comrcio eletrnico, mais precisamente o comrcio na Internet, ser o espao determinante da maioria das atividades de negcio, governamentais e pessoais no futuro. Como a tendncia a proliferao de diversos sistemas de CE, cada um com suas configuraes e formas de uso, necessria uma padronizao dos modelos de negcio, processos e arquiteturas destes sistemas. Essa padronizao no uma tarefa fcil pois as prticas comerciais variam muito por razes tcnicas, polticas, etc, ainda mais quando existem parcerias. Uma soluo para esse problema o uso de ontologias compartilhadas como base para a interoperao entre parceiros de negcios em mercados eletrnicos. A idia que o uso de ontologias aceleram a penetrao do CE dentro de setores variados da sociedade, reduzindo, alm disso, a necessidade de uma padronizao muito rgida, que poderia ser um fator limitante. Nesse sentido, uma tendncia de padronizao o uso da linguagem XML para uma representao sinttica (atravs de tags especiais) de conhecimento especfico de CE. Ontologias poderiam ser vinculadas a especificaes XML para prover o suporte semntico.

87

10 Especificao de Ontologias
A pesquisa em especificao de ontologias vem ocorrendo desde o incio da dcada de 90 na rea de IA, com a produo de formalismos de especificao orientados lgica, que servem de base para linguagens de mais alto nvel utilizadas em sistemas de manipulao de ontologias. Algumas propostas recentes, a nvel de especificao de esquemas conceituais na rea de sistemas de informao, tambm esto surgindo. As sees seguintes descrevem alguns desses mecanismos de especificao.

10.1 Formalismos
A comunidade cientfica da rea de IA definiu algumas linguagens formais para RC em bases de conhecimento, que tem sido aproveitadas como auxlio na definio de conceitualizaes, mais especificamente, na descrio estrutural e de restries de integridade de conceitos e relaes. Os formalismos mais empregados so KIF e a lgica de descrio, descritos a seguir.

10.1.1 KIF
KIF (Knowledge Interchange Format) uma linguagem para intercmbio de conhecimento entre sistemas computacionais, desenvolvida pelo Grupo de Lgica da Universidade de Stanford, Estados Unidos [Gen92]. Apesar de estar baseada em linguagens como Prolog, no tem a inteno de ser uma linguagem para usurios humanos nem apresentar uma sintaxe de alto nvel para representao de conhecimento (RC). Porm, um formalismo logicamente abrangente (permite a expresso de sentenas lgicas arbitrrias), podendo-se inclusive definir atravs dele novos construtores que possibilitem representar conhecimento. A sintaxe de KIF define expresses que podem ser de trs tipos: termos, sentenas e definies. Termos so os elementos sintticos bsicos da linguagem, a partir do qual objetos do domnio de discurso so descritos. Esses elementos englobam constantes atmicas (caracteres, nmeros e strings), listas (seqncias finitas de objetos), conjuntos, variveis, funes e expresses condicionais. Alguns exemplos so: 3 (constante numrica 3); ?x (varivel x); (+ 3 ?x) (funo aritmtica de adio, cujo resultado a soma da constante 3 com o valor da varivel x); (listof vero outono inverno primavera) (lista formada por quatro strings); (if (> 1 ?x) 1 (>?x 1) ?x 0) (expresso condicional if que retorna o maior valor dentre a constante 1 e o valor da varivel x, ou ainda zero, caso ambas as comparaes forem falsas.

88

Tipos podem ser associados a termos nmericos, como ( integer t), que define t como uma varivel do tipo inteira. Diversas funes predefinidas permitem manipular valores numricos, strings, conjuntos e listas. Uma sentena composta de um ou mais termos. Sentenas podem ser expresses lgicas ou expresses que utilizam o quantificador existencial (exists) ou o universal (forall). Uma expresso lgica pode ser uma negao ( not), disjuno (or), conjuno (and), implicao ( ou ) ou equivalncia (). Um exemplo que abrange esses tipos de expresses pode ser:
(forall (?x) ( (member ?x NrosMesesAno) (and (> ?x 0) (< ?x 13) ) ) )

Essa sentena retorna verdadeiro se para todo (uso do quantificador universal) elemento x do conjunto NrosMesesAno (funo predefinida member) implica que x encontra-se no intervalo de valores entre 1 e 12. Definies conferem a KIF um carter de linguagem extensvel, que permite a especificao de conceitualizaes do mundo atravs de objetos, funes e relaes. Definies representam as expresses de mais alto nvel da linguagem, que so formadas por uma ou mais sentenas. Um objeto um conceito do domnio, que pode ser primitivo ou composto. No segundo caso temos uma composio de objetos, o que no ocorre no primeiro caso. A definio de um objeto possvel atravs do operador defobject. O exemplo a seguir mostra uma definio simples de um objeto de nome origem, que representa a origem de um sistema de coordenadas cartesianas, atravs de uma lista constante de trs zeros, um para cada coordenada:
(defobject origem := (listof 0 0 0))

Nesse operador, o argumento esquerda da atribuio um nome de objeto e o argumento direita uma sentena KIF. Nada impede que uma lista ou conjunto seja formada por outros objetos, possibilitando assim, a definio de objetos compostos. Uma funo um tipo de inter-relacionamento entre objetos que associa uma seqncia finita de objetos (argumentos) a um nico objeto (valor). Esse objeto valor definido com base nos objetos do argumento. A noo de funo similar em alguns casos noo de regras de produo da linguagem Prolog. Por exemplo, a funo a seguir (operador deffunction) retorna o av paterno de uma pessoa, supondo a existncia de uma outra funo que determina o pai de uma pessoa:
(deffunction AvPaterno (?x) := (Pai (Pai ?x) ) )

Outro exemplo mais simples uma funo para o clculo do valor absoluto de um nmero, que retorna o prprio nmero, caso esse seja positivo, ou troca o seu sinal, se for negativo:
(deffunction abs (?x) := (if (= ?x 0) ?x (- ?x) ) )

89

Uma relao tambm um inter-relacionamento entre objetos, voltado mais diretamente para associaes que ocorrem no domnio. Formalmente, uma relao define um conjunto arbitrrio de listas finitas de objetos, onde cada lista uma seleo de objetos e o resultado dessas selees so os objetos que satisfazem a relao. Dois exemplos de definio de relao (operador defrelation) so os seguintes: (i) (ii)
(defrelation solteiro (?x) := (and (homem ?x) (not (casado ?x) ) ) ) (defrelation pessoa (?x) :=> (mamfero ?x) )

O exemplo (i) estabelece uma relao do tipo solteiro para todos os homens que no so casados e o exemplo (ii) associa todo objeto que uma pessoa a um mamfero. Nota-se, atravs dessas definies, que vrias associaes podem ser especificadas, como associaes de propriedades a objetos (determinar que um homem solteiro) e de generalizao (toda pessoa um mamfero).

10.1.2 Lgica de Descrio

Lgica de descrio (LD) um formalismo que expressa conhecimento sobre conceitos e hierarquias de conceitos, sendo uma sublinguagem da lgica de predicados especificada no Departamento de Cincias da Computao da Universidade de Rutgers, Estados Unidos [Bor95]. considerado um formalismo mais claro que o clculo de predicados e programao em lgica pois no necessita de variveis e conseqentes raciocnios para substituio e definio de escopo. Vrios sistemas de RC tem sido construdos usando como base variaes sintticas da LD para diversas aplicaes, como gerenciamento de software, sistemas de planejamento e processamento de lngua natural. A base da LD so as noes de conceito e regra. Um conceito um predicado unrio interpretado como um conjunto de indivduos. Uma regra um predicado binrio interpretado como uma relao entre indivduos. A partir de conceitos e regras primitivos, utilizam-se construtores como unio, interseco e quantificao de regras para definir novos conceitos e regras ou produzir resultados de consultas. As principais tarefas especificadas via LD so inferncia, classificao e verificao de submisso (existncia de relacionamentos de generalizao/especializao). A definio de conceitos e regras ocorre a partir de conceitos primitivos (j definidos) e construtores de termos da linguagem. O exemplo a seguir ilustra a definio do conceito Estudante:
Estudante and ( prim (Pessoa), all (NroMatrcula, INTEGER), at-least (1, NroMatrcula), at-most (1, NroMatrcula), all (Nvel, one-of (1,2,3,4)), at-least (1, Nvel), at-most (1, Nvel) )

Essa descrio quer dizer que um estudante uma pessoa (especializao do conceito primitivo Pessoa), possui, no mnimo um e no mximo um nmero de matrcula que deve ser um valor inteiro, assim como apenas um nvel que deve ser um valor dentre 1,

90

2, 3 e 4. Nessa definio so usados diversos construtores de termos, como all, at-least e one-of, que auxiliam na indicao de propriedades, relacionamentos e restries de um conceito. Um outro exemplo a definio de uma disciplina avanada:
DisciplinaAvanada and ( prim (Disciplina), at-most (20, Matriculados), all (Ensinado-por, prim (Professor) )

Neste caso, tem-se uma especializao do conceito Disciplina, que deve ter no mximo 20 alunos matriculados e cujo(s) instrutor(es) deve(m) ser professor(es). Para tanto, especificado um relacionamento com o conceito Professor estabelecido atravs da propriedade de nome Ensinado-por e uma restrio sobre um relacionamento herdado (Matriculados). Como terceiro exemplo, mostrada a definio da relao Matriculados, indicando estudantes matriculados em disciplinas em uma certa data:
Matriculados and ( all (Est, prim (Estudante), at-least (1, Est), at-most (1, Est), all (Disc, prim (Disciplina), at-least (1, Disc), at-most (1, Disc), all (Quando, prim (Data), at-least (1, Quando), at-most (1, Quando) )

LD descendente de um formalismo chamado KL-ONE, conhecido como lgica terminolgica, uma lgica que aplica raciocnios sobre definies. LD, em particular, aplica dois tipos de raciocnios: Raciocnio sobre relaes entre descries, como por exemplo, a expresso (and (Disciplina, at-most (15, Matriculados)) mais geral que a definio de DisciplinaAvanada. Logo, essa expresso uma generalizao de DisciplinaAvanada. J (at-most 12 Matriculados) uma expresso disjunta de DisciplinaAvanada; Raciocnio de identificao de indivduos que satisfazem a descrio, como por exemplo, descobrir que Tpicos Especiais em BD uma DisciplinaAvanada, dado um conjunto de valores de dados pertencente a ela.

A aplicao desses raciocnios anloga s inferncias realizadas por linguagens de programao em lgica, dado que conceitos e relaes como predicados unrios e binrios, respectivamente. Esses raciocnios so interessantes do ponto de vista de BD, pois aumentam o poder semntico da modelagem.

10.1.3 Comparao entre os Formalismos

Ambos os formalismos baseiam-se em dois paradigmas: OO e programao em lgica. O primeiro adotado na definio estrutural de conceitos e relaes, suportando composio, herana e associaes entre objetos. O segundo usado na programao de definies, associando objetos a fatos e relaes a regras. A partir disso, pode-se inferir a estrutura e as relaes de instncias de conceitos.

91

KIF apresenta uma sintaxe extensa e de mais baixo nvel, semelhante ao clculo de predicados. Define objetos, relaes, funes e sentenas de modo geral que podem ser teis para a especificao de restries de integridade. LD tem uma sintaxe compacta e clara, voltada a definies propriamente ditas. Apresenta especificaes de mais alto nvel, mais prximas da estrutura sinttica de linguagens de definio de dados (LDDs) de BDOOs. Sua definio de objetos embute restries de integridade associadas s propriedades dos objetos. A tabela 10.1 resume a anlise feita. TABELA 10.1 - Comparao entre os formalismos KIF e LD KIF LD Paradigmas OO e de programao em lgica Suporte a objetos complexos, herana e associaes Suporte inferncia de objetos e relaes entre eles Sintaxe extensa e mais rica Sintaxe compacta e mais clara Sintaxe de mais baixo nvel Sintaxe de mais alto nvel (semelhante ao clculo de predicados) (semelhante a uma LDD/BDOO) Define objetos, relaes, funes e Define objetos com restries sentenas de uso geral (restries de integridade) integridade embutidas e relaes

de

10.2 Linguagens
Esta seo descreve uma viso geral de duas populares linguagens de especificao de ontologias no mbito da IA: Ontolingua e Loom. Ambas esto baseadas nos formalismos descritos anteriormente, representando conhecimento atravs de objetos, sobre o qual inferncias podem ser realizadas automaticamente. Apenas essas duas linguagens so comentadas, pois as demais possuem o mesmo propsito e apresentam ligeiras variaes sintticas. Outras propostas para definio de ontologias, que fogem ao contexto da IA, tambm so apresentadas.

10.2.1 Ontolingua
Ontolingua uma linguagem para especificao de ontologias desenvolvida na Universidade de Stanford [Gru92]. A base dessa linguagem o formalismo KIF, permitindo o empacotamento de sentenas KIF em uma sintaxe de definio com maior significado ontolgico. Basicamente, so apresentadas primitivas (dentro do paradigma OO) para definio de classes e relaes com possveis restries, mais a possibilidade de organizar essas classes em hierarquias de herana. Ontolingua se prope a ser um formato cannico de representao de ontologias. O servidor Ontolingua (descrito na seo sistemas) permite a traduo de suas especificaes para outras linguagens de representao de ontologias, ou seja, sua sintaxe foi definida objetivando portabilidade para outras linguagens de representao. Outro enfoque dado a capacidade de Ontolingua de especializar ontologias, permitindo meta-descries que podem ser usadas em outras descries. Isso implica em modularizao e reuso de vocabulrio de conceitualizao.

92

A sintaxe bsica de Ontolingua define termos do tipo relaes, classes e funes. Uma relao um conjunto de tuplas que representa um relacionamento entre objetos. Cada tupla uma seqncia ordenada e finita de objetos. Uma classe mantm restries que indicam quem pode ser membro ou instncia dela. Uma funo uma relao onde o ltimo item da tupla representando os argumentos o valor de retorno da funo. O termo define-class define uma classe, informando um nome, uma varivel de instncia como argumento, um string de documentao e um conjunto de sentenas KIF rotuladas. Os rtulos especificam condies necessrias e/ou suficientes para a instncia ser membro da classe. A seguir so mostrados dois exemplos simples:
(define-class CoresPrimrias (?cor) Define extensionalmente as cores primrias como sendo vermelho, verde ou azul :iff-def (member ?cor (vermelho verde azul))) (define-class Trabalhador (?p) Um trabalhador uma pessoa que tem um emprego :def (and (Pessoa ?p) (Emprego ?p)))

A definio da classe CoresPrimrias apresenta a varivel de instncia cor, seguida de uma explicao da classe e a sentena KIF que a define. A sentena indica que cor deve ser membro do conjunto formado pelos valores vermelho, verde e azul. O rtulo iff-def define a condio necessria e suficiente para instanciao. O segundo exemplo define a condio necessria (def) para ser um trabalhador: pertencer classe Pessoa e ter uma relao com algum emprego. A definio de relaes e funes tem uma sintaxe semelhante definio de classes, com algumas variaes em termos de rtulos permitidos. A definio da relao Casado associa, por definio, duas pessoas, com a restrio (indicada no rtulo axioms) de que essa relao deve ser do tipo associao de valores nicos (clusula single-valued).
(define-relation Casado (?p1 ?p2) Relaciona pessoas que esto casadas umas com as outras. Uma pessoa s pode estar casada com apenas uma pessoa diferente. :def (and (Pessoa ?p1) (Pessoa ?p2)) :axioms (single-valued Casado))

O rtulo axioms define restries que no envolvem argumentos (variveis). As restries de axioms so normalmente relaes de segunda ordem, ou seja, metadefinies predefinidas em Ontolingua utilizadas na definio de novos conceitos ou relaes. Nesse caso, single-valued equivale a seguinte sentena KIF:
( (and (casado ?x ?y) (casado ?x ?z)) (= ?y ?z))

O exemplo de definio de funo a seguir realiza somas numricas entre dois nmeros:
(define-function SomaNumrica (?n1 ?n2) Resulta na adio de dois nmeros

93

:result-variable: ?total :constraints: (and (number ?n1) (number ?n2) (number ?total)) :lambda-body (+ ?n1 ?n2))

A interpretao dos rtulos a seguinte: result-variable declara a varivel de retorno; constraints define restries no intrnsecas definio dos argumentos, ou seja, podem atuar como pr- e ps-condies; lambda-body denota o valor da funo em termos dos seus argumentos. Conforme comentado anteriormente, Ontolingua predefine termos que capturam convenes utilizadas em sistemas baseados em frames orientados a objetos, uma forte tendncia em termos de representao de conhecimento. Esses termos predefinidos so chamados relaes de segunda ordem, uma vez que so definidos com base nos trs termos bsicos. Relaes de Segunda ordem definem a chamada Ontologia de Frames, uma meta-descrio de conceitos do paradigma orientado a objetos, (instncias, subclasses, slots (atributos), tipos, etc), com a finalidade de padronizar a definio de ontologias de domnio e de tarefa. Alguns exemplos so mostrados na seqncia: Instance-of: um objeto instncia de uma classe se e somente se for membro do conjunto denotado pela classe (classe tambm uma relao de segunda ordem). O termo (instance-of objeto classe) equivale ao termo (classe objeto), como por exemplo, (instance-of p Pessoa) (Pessoa p):
(define-relation instance-of (?objeto ?classe) :iff-def (and (class ?classe) (member (listof ?objeto) ?classe))

Subclass-of: uma classe C1 subclasse de uma classe pai C2 se todas as instncias de C1 so tambm instncias de C2 (e ambas so instncias da classe predefinida class). O conceito de subclasse transitivo, ou seja, se ( subclass-of C1 C2) e (subclass-of C2 C3) ento (subclass-of C1 C3):
(define-relation subclass-of (?classe-filha ?classe-pai) :iff-def (and (instance-of ?classe-pai class) (instance-of ?classe-pai class) (forall ?instancia ( (instance-of ?instancia ?classe-filha) (instance-of ?instancia ?classe-pai)))) :constraints (transitive subclass-of))

Value-type: O par (valor, tipo) de uma relao binria R com respeito a um dado elemento d uma restrio sobre os valores de R quando R aplicado d. A restrio especificada como a classe C tal que quando R(d,t) ocorre, t uma instncia de C:
(define-relation value-type (?d ?R ?t) :iff-def (and (instance-of ?R binary-relation) (instance-of ?t class) (forall ?valor ( (holds ?R ?d ?valor)

94

(instance-of ?valor ?t))))

A classe binary-relation uma relao de segunda ordem. Supondo uma ontologia de domnio aplicado a referncias bibliogrficas, especificada atravs de Ontologia, um exemplo de definio do conceito de autor a seguinte:
(define-class Autor (?a) Autor uma pessoa que escreve coisas. Um autor deve ter criado no mnimo um documento. Nesta ontologia, um autor conhecido pelo seu nome real :def (and (instance-of Pessoa ?a) (= (value-cardinality ?a AUTOR.NOME) 1) (value-type ?a AUTOR.NOME biblio-nome) (>= (value-cardinality ?a AUTOR.DOCUMENTOS) 1) ( (Autor.nome ?a ?nome) (Pessoa.nome ?a ?nome))))

Nesse exemplo, dada a relao AUTOR.NOME, que mapeia toda instncia da classe autor para algum nome, temos as seguintes restries: todo autor tem apenas um nome (cardinalidade igual a 1) e o valor da relao AUTOR.NOME aplicada a instncias de autor deve ser instncia da classe biblio-nome. Ainda, o nome do autor e o nome da pessoa devem ser os mesmos. Ontolingua tem sido bastante aplicado na descrio de amplas ontologias em diversos projetos de pesquisa, como a Enterprise Ontology, da Universidade de Edimburgo [Usc97] e a Physsys Ontology, da Universidade de Twente, Holanda [Utw??]. Alm disso, diversos departamentos da Universidade de Stanford, como a Medicina, tem aplicado a linguagem para definir vocabulrios especficos.

10.2.2 Loom
Loom uma linguagem para representao e inferncia de conhecimento inspirada em lgica de descrio e na idia de raciocnio terminolgico. Loom um projeto de pesquisa do grupo de IA da University of Southern California, Estados Unidos [Loo9?]. Loom no define apenas conhecimento, mas tambm fatos que podem ser considerados ocorrncias desse conhecimento no mundo real. Loom segue dois paradigmas: orientado a objetos e baseado em regras. Nesse sentido, existe uma forte analogia entre conhecimento e classe e entre fato e instncia. O paradigma de regras possibilita as inferncias de novos fatos com base na anlise do conhecimento e de regras de integridade especificados. Dois tipos de linguagens esto embutidas em Loom: linguagem de modelagem, responsvel por definies, implicaes e restries de conhecimento, e linguagem de comportamento, que define mtodos e regras de produo. Diversos exemplos de especificao so mostrados a seguir, considerando um domnio de uma linha de produo industrial automatizada. Nesse domnio, robs controlam uma linha de produo, cujos produtos so aparelhos de tamanhos e pesos variados, que so acondicionados em caixas. Essas caixas, quando quase cheias, so transportadas at um depsito.

95

A linguagem de modelagem define conceitos (defconcept) e relaes (defrelation), que podem ter restries associadas. Fatos tambm fazem parte dessa linguagem. Alguns exemplos de especificao so:
a) b) c) d) e) f) g) h) i) (defconcept Rob) (defconcept Rob-de-Fbrica :is (:and Rob (:exactly 2 brao-rob))) (defconcept Objeto-Fsico :constraints (:and (:exactly 1 peso) (:exactly 1 tem-localizao))) (defconcept Coisa-Frgil :is-primitive Objeto-Fsico) (defconcept Produo-Fbrica :is-primitive Objeto-Fsico) (defconcept Aparelho-Pesado :is-primitive Produo-Fbrica :constraints (:the peso-em-quilos 3)) (defconcept Aparelho-Leve :is-primitive Produo-Fbrica :constraints (:the peso-em-quilos 1)) (defconcept Peso-Em-Quilos :is (:and Number (:through 0 +INFINITY))) (defrelation peso-em-quilos :domain Objeto-Fsico :range Peso-Em-Quilos :attributes :single-valued) (defrelation tem-localizao :domain Objeto-Fsico)

j)

Esses exemplos mostram uma sintaxe clara, o que evidencia a caracterstica declarativa de Loom. Conceitos podem ser definidos atravs das clusulas is ou is-primitive, sendo a segunda clusula responsvel pela definio de elementos primitivos, ou seja, elementos cujos detalhes so desconhecidos, como o caso do conceito Produo-Fbrica (exemplo (e)). Restries so especificadas atravs das clusulas :constraints (definem condies necessrias para instanciao), :domain e :range (restingem tipo e valores permitidos, respectivamente). Essas duas ltimas clusulas aplicam-se definio de relaes. Relaes definem como as regras de uma instncia de conceito so preenchidas, ou seja, regem os associaes entre conceitos e restries associadas. O exemplo (i) indica que existe uma relao entre um conceito Peso-Em-Quilos e um Objeto-Fisico, tendo essa relao a propriedade de ser single-valued. Loom tambm define implicaes, que indicam relacionamentos de especializao (exemplo (k)), assim como permite especificaes mais complexas, como mostram os exemplos a seguir:
k) l) (implies Aparelho-Leve Coisa-Frgil) (def-relation tem-item :is-primitive containeritem :domain Container-Fsico :range Objeto-Fsico :attributes :closed-world) (defrelation peso-dos-itens :is (:satisfies (?container ?peso) (sum (peso (tem-item ?container)) ?peso)) :domain Container-Fsico :range Peso-Em-Quilos) (defconcept Caixa-Quase-Cheia :is (:and Caixa (:at-least 8 tem-item)))

m)

n)

96

Duas consideraes so significativas nesses exemplos. Primeiramente, em (l), temse uma relao primitiva entre conceitos container e item que tem a caracterstica de seguir a semntica de mundo fechado (conceito familiar na rea de RC). Essa semntica aplicada definio da relao implica que todas as instncias de itens em um container C de fato so todas as instncias de C. Em uma semntica de mundo aberto, essa implicao no verdadeira. Essa caracterstica necessria para que a soma dos pesos dos itens de um container possa ser computado na relao do exemplo (m) atravs da funo sum (funo predefinida de Loom). Fatos em Loom informam sobre uma instncia de um conceito. Dois construtores so usados: tell (adiciona uma instncia no BD) e tellm (alm de adicionar uma instncia, verifica, atravs de inferncias, se novos fatos tambm devem ser gerados). Um exemplo em tellm :
(tellm (Aparelho-Leve a1) (tem-item caixa1 a1))

O resultado da execuo desse comando produz os seguintes fatos no BD:

(Aparelho-Leve a1) (tem-item caixa1 a1) (Coisa-Frgil a1) (peso-dos-itens caixa1 4)

Os dois ltimos fatos so deduzidos com base nos conceitos, relaes e implicaes j definidos nos exemplos anteriores. A linguagem de comportamento especifica aes e regras de produo. Aes so implementadas atravs de um conjunto de mtodos, cada um com uma implementao particular para um determinado tipo de situao. Por exemplo, pode-se pensar em uma ao Movimenta-Objeto, que conduz um objeto para uma localizao. Dependendo das caractersticas desse objeto, a ao de movimentao diferente: um objeto que uma Coisa-Frgil deve ser movido com mais cuidado que um Objeto-Fsico qualquer. Dessa forma, dois mtodos devem ser implementados, um para cada tipo de objeto. A seguir ilustrada uma definio de mtodo em Loom ( defmethod), que descarrega os itens de uma caixa no mesmo local em que est a caixa:
(defmethod Descarrega-Caixa (?caixa) :situation (Caixa ?caixa) :response ((format t Descarregado o contudo da caixa ~S~%, ?caixa) (do-retrieve ?item (tem-item ?caixa ?item) (forget (tem-item ?caixa ?item) (tell (tem-localizao ?item (tem-localizao ?caixa)))))

Esse mtodo aplicado para objetos que so caixas. O corpo do mtodo informa que a caixa cujo valor est indicado na varivel ?caixa foi descarregado e, para cada item da caixa, executa dois fatos sobre o BD: remove a relao entre esse item e a caixa em que estava contido e relaciona esse item com a localizao em que vai residir, que a mesma

97

localizao da caixa. Esse exemplo ilustra a capacidade de Loom como linguagem de programao. Regras de produo indicam tarefas a serem invocadas sempre que um evento particular ocorre. Analogamente, regras de produo so gatilhos de BD. A execuo dessas regras ocorre quando atualizaes so feitas no BD, podendo novos fatos, obtidos por inferncia das definies, serem tambm executados. O comando defproduction cria regras de produo, como mostra o exemplo:
(defproduction P1 :when (Caixa-Quase-Cheia ?caixa) :schedule (Remove-Caixa-Cheia ?caixa))

A clusula when especifica a condio para a execuo da regra (sempre que uma caixa estiver quase cheia por definio, com 8 itens) e schedule indica as aes a serem executadas. Loom encontra-se distribudo em mais de oitenta universidades e corporaes, como ferramenta de auxlio no desenvolvimento de projetos nas reas de planejamento, ES e integrao inteligente de informao.

10.2.3 Outras Propostas

10.2.3.1 UML/OCL Uma recente proposta para a especificao de ontologias sugere o uso de um subconjunto das linguagens UML (Universal Modelling Language) e OCL (Object Constraint Language), padres para o desenvolvimento de aplicaes OO [Cra99]. Tem-se como justificativa o fato de que as linguagens existentes so destinadas definio de ontologias como sistemas de RC. Essas linguagens so complexas e pouco utilizadas fora do mbito dos laboratrios de IA. Sistemas OO podem perfeitamente descrever e manipular ontologias, pois suportam abstraes poderosas para representar conceitos/relaes e mtodos para a sua manuteno. Os benefcios da UML esto na sua popularidade como ferramenta na rea de anlise e projeto OO e o fato de sua notao ser mais fcil de compreender do que notaes baseadas em KIF e LD, uma vez que apresenta uma representao grfica padro, importante para a navegao em ontologias. OCL uma linguagem poderosa, permitindo expressar restries de integridade que no so possveis de especificar nas linguagens vistas anteriormente. UML modela entidades e relacionamentos atravs de um diagrama de classes do domnio e diagramas de objetos para mostrar instncias nomeadas particulares dessas classes, quando necessrias. O diagrama de classes mostra classes com indicao de atributos e seus tipos, mais a assinatura de mtodos. Relacionamentos de herana, associao e agregao so suportados e restries de cardinalidade de relacionamentos podem ser descritas, com indicao do sentido de navegao no relacionamento, para sua

98

correta interpretao. OCL restringe valores de atributos e possveis instncias de um relacionamento, alm de especificar procedimentos para verificao de integridades. A idia utilizar o diagrama de classes para representar conceitos e relaes de ontologias. Como no h padro para especificar mtodos, utiliza-se a OCL para tal tarefa, alm das especificaes de restries de integridade. Descries OCL, juntamente com comentrios a ttulo de documentao sobre as classes, so indicados em diagramas de objetos vinculados aos diagramas de classes. A figura 10.1 mostra parte da especificao de uma ontologia sobre um catlogo de CDs de msica clssica. Diagramas de classes so retngulos com trs divises (nome da classse e definio de atributos e mtodos) e diagramas de objetos so retngulos na forma de folha de papel. Relacionamentos de herana so linhas tracejadas com setas da classe especializada para a genrica; relacionamentos de associao so linhas slidas e relacionamentos de agregao (relacionamentos de dependncia) so linhas slidas com um losango ao lado da classe agregadora. Nesse domnio, um CD formado por uma seqncia ordenada de um ou mais itens. Isso percebido pela cardinalidade no relacionamento entre CD e ItemNoCD (1..* {ordeded}), sendo que um item pertence a um nico CD. Um CD tambm formado por vrias Trilhas ordenadas, sendo que um item ocupa uma ou mais dessas trilhas. Itens e trilhas so componentes dependentes de um CD. Um intrprete (grupo ou indivduo) realiza gravaes. Cada gravao est presente em um item do CD.
-- Trilhas e nmeros de itens so consecutivos, iniciando em 1 <<invariant>> self.Trilha.Nmero->includesAll(Sequence(1..self.Trilha->size)) <<invariant>> self.ItemNoCD.Nmero->includesAll(Sequence(1..self.ItemNoCD->size)) Intrprete Indivduo

1..* 0..*

Grupo

CD Ttulo: string NroCatlogo: integer 1..1

{ordered} 1..*

{ordered}

1..1

1..*

ItemNoCD

Gravao

0..* 1..1 Gravadora: string Nmero: integer Movimentos: Sequence(integer) Data: date TrilhaInicial: integer

1..1
{ordered}1..*

Trilha Nmero: integer

-- Especificao de quais trilhas pertencem a qual item <<invariant>> self.Trilha[Nmero].Nmero = Sequence (self.TrilhaInicial..self.TrilhaIncial + self.Movimentos->size 1)

FIGURA 10.1 - Especificao de uma ontologia utilizando as linguagens UML e OCL Exemplos de especificaes OCL so as restries vinculadas s classes CD e ItemNoCD. No segundo caso, por exemplo, o nmero de trilhas pertences a um item deve ser a seqncia que comea na trilha inicial e termina no tamanho do nmero de

99

movimentos do mesmo menos 1. Essa especificao restringe as possveis instncias no relacionamento de agregao entre Trilhas e Itens. A palavra-chave self indica uma instncia; sequence, um tipo lista ordenada e size uma funo que retorna o nmero de elementos de uma sequence. Alguns pontos precisam ser amadurecidos com relao a essa proposta: Formalizao: a linguagem que descreve UML no formal, apenas uma descrio em linguagem natural usada. Necessita-se formaliz-la; Raciocnio automtico: em uma linguagem de especificao de ontologias, no basta poder de expresso para descrever o domnio, mas tambm para o raciocnio automtico necessrio. Deve-se estudar tipos de inferncia possveis e desejveis sobre especificaes UML em conjunto com OCL. Inferncias sobre OCL seriam fundamental para operaes de manipulao de dados, como a aplicao de regras de produo de Loom. Poder-se-ia definir em OCL um conjunto de restries e gatilhos padro que possa ser aplicado automaticamente em qualquer ontologia; Meta-modelos: o modelo MOF (figura 25) poderia ser usado como meta-modelo para descrever conceitos bem gerais (nvel 1). Num segundo nvel, esses conceitos seriam representados em UML e no nvel 3 os modelos ontolgicos seriam descritos como especializaes das descries UML.

10.2.3.2 Projeto KRAFT O projeto KRAFT, um projeto conjunto das Universidades de Aberdeen, Cardiff e Liverpool, no Reino Unido, pretende combinar tecnologia das reas de IA e BDOO em um sistema multi-agente para troca e reuso de conhecimento na forma de restries [Paz98]. A arquitetura desse sistema formada por quatro componentes principais: wrappers e mediadores, que atuam sobre fontes de dados, uma ontologia compartilhada pelos agentes que mantm conhecimento em uma semntica comum e facilitadores, que usam a ontologia para realizar raciocnio baseado em conhecimento. Quando uma fonte de dado junta-se ao sistema, deve-se descrever explicitamente a forma como o mesmo concorda com a ontologia. Quando essa fonte pertence a um domnio desconhecido para a ontologia, deve-se definir novos conceitos e relaes ou estender a ontologia. KRAFT define duas linguagens para lidar com ontologias: uma linguagem de descrio ontolgica (LDO) - extenso de uma linguagem de definio de dados de um BDOO, que define a parte estrutural do modelo ontolgico, com suporte documentao e uma linguagem de manipulao ontolgica (LO), que manipula um modelo ontolgico, completando hierarquias de conceitos, adicionando relacionamentos e descrevendo slots (atributos) para capturar melhor a semntica dos dados. Tem-se, na verdade, dois modelos de descrio de metadados: o meta-modelo do BDOO e o modelo ontolgico, que um espelho do meta-modelo do BDOO. A LDO padro atua sobre o meta-modelo e a LDO estendida mais a LO atuam sobre o modelo ontolgico.

100

Descries nessas linguagens so feitas em arquivos padro de definio de conhecimento. Essa descrio carregada pelo sistema quando da definio ou atualizao de domnios. O exemplo a seguir ilustra um trecho de cdigo presente nesse arquivo:
%%e extend module modelo_ontologico %%e declare mo_slots_restrio %%e ->> mo_mtodo_slots %%e declare valores_permitidos(mo_slots_restrio) %%e ->> string; ... declare data ->> entity declare ms(data) ->> string ... %%o include ms(data) in mo_slots_restrio %%o valores_permitidos(ms(data)) %%o = [janeiro, fevereiro, ...] ...

Nesse trecho de cdigo tem-se trs categorias de especificao: Esquemas LDO padro: definem conceitos e relaes para o meta-modelo do BDOO e consequentemente para o modelo ontolgico. No apresentam strings de prefixao; Extenses ao modelo ontolgico (LDO): descrevem extenses ao modelo ontolgico. So prefixados pelo string %%e; Atualizaes de definies ontolgicos (LO): descrevem informao til como slots ou relacionamentos, a serem adicionados ao modelo ontolgico. So prefixados pelo string %%o.

Nesse exemplo, declara-se primeiramente, como extenso ao modelo de dados ontolgico, em LDO, uma subclasse da classe mo_mtodo_slots chamada mo_slots_restrio, que permite a restrio de valores de atributos. Na seqncia, ainda em LDO, novos conceitos so definidos: uma entidade data e um ms como componente de uma data. O modelo ontolgico posteriormente atualizado, declarando-se que ms instncia de mo_slots_restrio, cujos valores permitidos so as strings correspondentes aos meses do ano. A figura 10.2 d uma idia da evoluo do meta-modelo do BDOO e do modelo ontolgico, antes (a) e depois (b) da execuo do trecho de cdigo exemplo.
mo_coisa metaobjeto metaentidade mo_coisa mo_classe data mo_policoisa metaobjeto metaentidade data metafuno

mo_classe mo_policoisa
mo_mtodo_slots

metafuno

mo_mtodo_slots mo_mtodo_restrio ms [janeiro, fevereiro, ...]

ms Meta-modelo do BDOO

Modelo ontolgico

Meta-modelo do BDOO

Modelo ontolgico

101

(a) (b) FIGURA 10.2 - Evoluo conjunta de metadados de um BDOO e de um modelo ontolgico antes (a) e aps (b) uma transao de atualizao As linguagens LDO e LO so uma extenso da linguagem funcional Daplex, para suporte descrio de metadados e restries ao modelo ontolgico. Daplex a linguagem de definio de dados do BDOO P/FDM, adotado por KRAFT.

10.2.4 Comparao entre as Linguagens

As duas principais linguagens de especificao de ontologias esto baseadas em formalismos OO para RC, ou seja inferncia de conhecimento sobre um modelo conceitual OO. A proposta da UML/OCL, apesar de no ter suporte inferncia tambm considera essa caracterstica importante. Logo, uma tendncia para uma linguagem de especificao ontolgica a unio dos paradigmas OO e dedutivo, de forma a facilitar a representao de conceitos e relaes. A tabela 10.2 compara as caractersticas das linguagens e propostas de especificao apresentadas. TABELA 10.2 - Comparao entre as linguagens e propostas de especificao de ontologias Ontolingua Loom Propostas UML-OCL KRAFT Formalismo KIF LD No possui No apresentado Paradigma(s) OO + dedutivo OO + dedutivo OO OO Caractersticas Classes; Classes; Classes; Classes; 4 Especificadas Relaes; Relaes; Relaes ; Relaes; Funes; Herana; Herana; Herana; Herana; Restries; Restries; Mtodos. Restries; Instncias; Instncias; Instncias. Mtodos; Mtodos. Gatilhos. Loom a linguagem mais expressiva pois apresenta o maior nmero de caractersticas que podem ser especificadas. Juntamente com Ontolingua, possui capacidades dedutivas e apresentam base formal. Uma tendncia que tambm surge com as duas propostas, mais recentes na literatura, o interesse pelo uso de ontologias na rea de sistemas de informao. Nesse contexto, ontologias so vistas como BDs de conceitos e relaes, onde o foco de ateno a captura da semntica estrutural e comportamental de termos utilizados em vocabulrios familiares a grupos de usurios.

10.3 Sistemas
4

Define explicitamente dois tipos de relacionamentos: associao e agregao.

102

Esta seo apresenta uma viso geral de sistemas para manipulao de ontologias, que auxiliam nas tarefas de definio, manuteno e consulta. Todas so ferramentas grficas de alto nvel e tem por base uma linguagem de especificao que acessa bases de conhecimento que mantm ontologias.

10.3.1 Servidor Ontolingua

O Servidor Ontolingua (SOnt) um ambiente de desenvolvimento de ontologias desenvolvido no Laboratrio de Sistemas de Conhecimento da Universidade de Stanford [Far96]. O propsito principal do mesmo facilitar o desenvolvimento colaborativo (concorrente) de ontologias, atravs de mecanismos de bloqueio, da anlise de definies alternativas de mltiplos autores e do acesso a uma biblioteca de mdulos ontolgicos reusveis. A base para o especificao de ontologias a linguagem Ontolingua, cuja interao facilitada atravs de uma interface grfica, que tambm permite a navegao em ontologias j existentes. A figura 10.3 mostra a arquitetura de SOnt. O Servidor/Editor de Ontologias permite a construo e modificao de ontologias e o acesso biblioteca de ontologias. possvel estender ou restringir definies presentes na biblioteca. Usurios ( colaboradores) podem navegar, construir e manter ontologias atravs de browsers HTTP/HTML em sesses compartilhadas de acesso, com recursos de notificao, comparao e investigao de modificaes realizadas. Um protocolo de rede com uma API habilita o acesso ao SOnt por aplicaes remotas que desejam consultar ou modificar ontologias. Mdulos tradutores permitem o mapeamento de descries ontolgicas em Ontolingua para outros formatos de representao de conhecimento, como Loom.

FIGURA 10.3 - Arquitetura do Servidor Ontolingua Contribuies do SOnt no que diz respeito ao reuso de ontologias so o modelo semntico de incluso e o modelo sinttico de entrada e saida (E/S). O primeiro preocupa-se com a traduo do vocabulrio (axiomas) de uma ontologia A quando uma ontologia B deseja incluir A. Conflitos de nomes de smbolos so detectados pelo ambiente

103

e ento, deve-se renomear axiomas, de forma a manter vocabulrios disjuntos entre duas ontologias, ou realizar a unio de ontologias (axiomas de A so unidos aos axiomas de B), estabelecendo-se um relacionamento entre A e B. O modelo sinttico de E/S resolve problemas de referncias a termos presentes em outras ontologias quando no h relacionamento de incluso entre elas. Para tanto, uma sintaxe especial do tipo nome_termo@nome_ontologia usado para indicar um termo de uma certa ontologia. possvel renomear termos importados de outras ontologias para nomes menores e mais significativos, como auto@veculo para carro. Do ponto de vista do usurio final, SOnt uma interface grfica para navegao estilo hipertexto e para construo de ontologias. A interface de navegao possibilita a investigao de classes de uma ontologia. A partir de uma listas de classes de uma ontologia, pode-se selecionar uma delas para consulta. Esta seleo exibe uma tela de definio (um exemplo para a classe Automveis mostrado na figura 10.4) que mostra slots e axiomas que representam restries no vinculadas a slots. possvel ainda ver termos que foram inferidos a partir de outros atravs de destaques para relacionamentos de herana, relacionamentos de associao, etc. Um boto especfico (Go) permite saber onde a informao inferida foi definida originalmente.

FIGURA 10.4 - Interface de navegao em classes de ontologias Uma interface similar utilizada para a construo de ontologias. cones especiais encontram-se ao lado das informaes de termos existentes ou recm-definidos. Quando

104

selecionados, exibem um formulrio de edio que permitem ao usurio incluir as suas propriedades (facetas) (figura 10.5). Diversas outras funcionalidades grficas esto a disposio dos usurios: Manuteno de ontologias: pode-se comparar visualmente duas ontologias e ver as transformaes de uma ontologia em outra, quando ocorre reuso. Existe suporte para dividir uma grande ontologia em mdulos menores e para a incluso de documentao informal; Compartilhamento de ontologias: uma ontologia criada pode ser includa na biblioteca para posterior reuso. possvel pesquisar a biblioteca atravs de palavras-chave, padres, etc; Desenvolvimento cooperativo de ontologias: essa considerada uma das funes mais significativas de SOnt. Duas facilidades principais existem: - Controle de acesso a usurios e grupos : semelhante aos controles presentes em sistemas de arquivo multi-usurio, como permisses de escrita/leitura; - Sesses multi-usurio: suporte ao trabalho em grupo simultneo. Quando um usurio abre uma sesso, pode associar um grupo a ela, possibilitando a colaborao de outros membros. Servios de notificao informam modificaes feitas.

FIGURA 10.5 - Interface de edio de classes de ontologias

105

SOnt um ambiente adequado tanto a usurios novatos quanto especializados, permitindo a customizao da sua interface. Existe uma documentao on-line sobre o sistema, incluindo help e tutoriais. O ambiente encontra-se disponvel na Web (http://ontolingua.stanford.edu) e tem sido aceito com sucesso pela comunidade cientfica, dado o aumento freqente no nmero de usurios registrados.

10.3.2 Ontosaurus
Ontosaurus uma ferramenta de suporte s tarefas de navegao e edio de ontologias. Especificaes na linguagem Loom so geradas para novas ontologias [Swa96a, Swa96b]. um produto desenvolvido pelos mesmos pesquisadores que desenvolveram Loom. Ontosaurus ferramenta para uso na Web, implementada em CL-HTTP, uma linguagem para programao de servidores Web com cdigo Lisp orientado a objetos. O cdigo Lisp faz interface com Loom, aproveitando muitas das suas funcionalidades. Pginas HTML so geradas dinamicamente para exibir resultados de pesquisas e formulrios HTML so usados para edio. Diversas funcionalidades esto disponveis para as tarefas de Ontosaurus atravs de uma interface grfica que exibe vrias informaes relacionadas simultaneamente. Durante a navegao, por exemplo, possvel investigar o contedo de um conceito ao mesmo tempo em que a estrutura da ontologia ao qual ele pertence tambm pode estar visvel. Durante a edio, possvel decompor um conceito em outros mais especializados e reutilizar conceitos de outras ontologias. Mecanismos de bloqueio impedem a edio simultnea de dados. A figura 10.6 mostra a interface de navegao de Ontosaurus, composta por trs partes (frames): o painel de controle, no topo, que mantm funes da ferramenta (seleo, carga, armazenamento de ontologias e busca por conceitos, relacionamentos ou instncias); o frame de contedo ( direita) que sempre exibe dados da ontologia em algum nvel de especializao de conceitos e o frame de informaes relacionadas ( esquerda), que mantm dados que o usurio deseja que fiquem fixos na tela. Para evitar acessos freqentes ao servidor Ontosaurus pelos usurios clientes, as pginas de resultado de consulta trazem sempre todos os dados relacionados com um item investigado. Por exemplo, para um conceito (ou classe), sempre so mostrados: nome, documentao, imagem (se existir), definies com links para conceitos relacionados, sub/super conceitos, instncias e regras. O incio de uma atividade de navegao pode ser feito, aps a indicao de uma ontologia alvo para pesquisa (Theory), atravs da seleo de um link referente a um conceito de mais alto nvel ou da indicao de uma expresso regular de consulta. Na figura 10.6, foi selecionada a ontologia AIRCRAFT (conceitos sobre aviao) e solicitados os conceitos que iniciam com o string air. Na seqncia, na mesma figura, foi selecionado a classe de conceito FIXED-WING-AIRCRAFT, sendo a sua definio em Loom mostrada no frame direito, assim como conceitos diretamente relacionados. possvel, atravs do link Find Matching Instances, investigar as instncias de uma classe de conceito.

106

A figura 10.7 mostra a interface de edio de Ontosaurus, que apresenta o mesmo layout da interface de navegao. Neste exemplo, est-se modificando a definio da instncia A-10 da classe BOMBER, uma subclasse de FIXED-WING-AIRCRAFT. A edio de um conceito pode ser feito apenas se o mesmo no estiver bloqueado. Essa indicao est permanentemente visvel na interface atravs da frase Edit lock ou Edit unlock. Quando um conceito est desbloqueado, opes do tipo New e Edit esto disponveis para que se possa criar ou modificar um conceito. Expresses Loom complexas podem tambm ser definidas em um campo texto apropriado (no visvel na figura exemplo). Alteraes podem ocorrer tanto a nvel de definio quanto a nvel de valor de slot. No primeiro caso, aproveita-se o mecanismo de inferncia de Loom para posicionar corretamente o conceito editado na hierarquia de conceitos, aps verificao de integridade. No segundo caso, se no houver violao de restries, a modificao efetivada. Ontossaurus possui tradutores para Ontolingua e KIF, assim como para esquemas C++ (arquivos headers e fontes). Uma verso demonstrativa de Ontossaurus, permitindo apenas navegao em algumas ontologias j definidas, pode ser encontrado em http://www.isi.edu/isd/ontosaurus.html.

10.3.3 WebOnto
WebOnto uma ferramenta para navegao, edio e criao de ontologias baseada em uma arquitetura cliente-servidor para a Web [Dom98]. Uma interface grfica de manipulao direta a caracterstica forte de interao com o usurio, permitindo com que representaes grficas de ontologias e conceitos sejam selecionados com o mouse para fins de investigao e modificao. A arquitetura do sistema dividida em arquitetura do servidor e do cliente. O servidor WebOnto construdo sobre um servidor LispWeb HTTP, escrito em Common Lisp e com suporte ao protocolo HTTP, disponibilizando funes de alto nvel para gerao de pginas HTML. O servidor interage com uma biblioteca de ontologias escrita em OCML, uma linguagem para modelagem de conhecimento. Dentre as funes principais do servidor esto a leitura e escrita de dados nessa biblioteca, a converso de estruturas OCML em strings ASCII para a transmisso via HTTP para clientes e o bloqueio de ontologias para edio. Completando a arquitetura do servidor, um mdulo broadcaster permite o que se chama de dilogo entre projetistas de uma ontologia, enviando solicitaes e dados de um cliente para outros clientes registrados em uma sesso de edio. A arquitetura do cliente mostrada na figura 10.8. O mdulo principal o tratador de comandos, que converte em comandos os eventos de entrada do usurio. Esses comandos podem ser solicitaes de dados que so enviados para o broadcaster, que os converte em strings ASCII para o mdulo de conexo HTTP, que abre uma conexo com o servidor e os envia. Informaes retornadas pelo servidor so novamente convertidas em comandos entendidos pelo tratador de comandos via mdulo receptor. Dados de ontologias, recebidos como resultado de uma consulta, vm empacotados como strings ASCII, que so traduzidos pelo mdulo parser de estrutura. Tambm so enviados cabealhos (headers) de todos os itens de dados OCML, contendo o nome do item, seu tipo e nomes de itens relacionados, como subclasses. O

107

parser converte essa representao em objetos internos em Java que so mantidos no armazenador de cabealhos, que os mdulos de visualizao acessam para fins de exibio. Esses cabealhos so ainda utilizados pelo exibidor de estrutura, que os formata em uma estrutura a ser exibida em janelas apropriadas.

108

109

FIGURA 10.6 - Interface de navegao da ferramenta Ontosaurus A figura 10.9 mostra a interface de exibio de ontologias, que divida em trs partes: uma rea de exibio, que mostra uma representao grfica dos conceitos de uma ontologia e seus relacionamentos, uma lista de todos os objetos (classes, instncias, relaes, etc) da mesma e uma barra de opes, com um menu e um conjunto de botes. A lista de objetos pode ser reduzida, caso o usurio deseje manter apenas alguma categoria de dado, como por exemplo, instncias. Como a interface de manipulao direta, qualquer objeto da rea grfica ou da lista de objetos pode ser selecionado e sua definio investigada. A figura 10.10 mostra uma janela de exibio de uma classe selecionada na interface. Uma caracterstica interessante de WebOnto que, como os dados so mantidos localmente, sua exibio pode ser controlada pelo cliente. Neste caso, cores diferentes indicam tipos de dados diferentes, como por exemplo, nomes de classes na cor verde e nomes de slots na cor lils. O usurio pode, a qualquer momento, entrar no modo de edio de ontologias, atravs da opo de menu Edit. Nesse modo, a interface modificada para permitir a edio e criao de objetos (figura 10.11). cones permitem editar um objeto previamente selecionado e desfazer a ltima ao de edio. Botes do tipo Classe e Instncia aparecem na rea de exibio grfica, para possibilitarem a criao de objetos destes tipos. Na figura 10.11, v-se a edio da classe set-as-list, uma classe j existente. Editar um objeto significa entrar ou alterar uma especificao OCML.

110

FIGURA 10.7 - Interface de edio da ferramenta Ontosaurus WebOnto foi desenvolvida no Instituto de Mdias de Conhecimento da Open University, no Reino Unido. Informaes sobre a ferramenta podem ser encontradas em http://webonto.open.ac.uk/, inclusive com a possibilidade de interao com um demonstrativo.

10.3.4 Comparao entre os Sistemas

O propsito de todos os sistemas analisados o mesmo: servir como ferramenta, disponvel na Web, para a navegao, consulta e edio de ontologias. Outras caractersticas tambm so consenso: A adoo de uma arquitetura cliente/servidor, sendo o servidor o gerenciador de uma biblioteca ontolgica e os clientes, usurios das ferramentas. Atravs de

111

um protocolo HTTP, clientes manipulam dados dessa biblioteca. WebOnto o sistema que apresenta uma arquitetura mais sofisticada, na qual os clientes mantm estruturas ontolgicas locais, para minimizar o acesso ao servidor; Suporte ao trabalho cooperativo na construo de novas ontologias, controlado principalmente via mecanismos de bloqueio de ontologias ou partes delas. Porm, detalhes desse suporte no so comentados em nenhum dos sistemas; Interao com o usurio atravs de uma interface grfica para navegao entre itens de dados, sejam eles ontologias, classes ou instncias, e suas propriedades. Para qualquer item exibido, todos os seus itens relacionados so igualmente mostrados, como por exemplo, indicaes de subclasses e instncias de uma classe sendo investigada. Mltiplas informaes podem estar visveis simultaneamente, como definies de classes e instncias. Alm disso, todas as interfaces esto disponveis para acesso na Web.

FIGURA 10.8 - Arquitetura do cliente WebOnto Os trs sistemas foram desenvolvidos em momentos diferentes, sendo alguns base para outros. O Servidor Ontolingua (SOnt) o mais antigo, tendo servido de base para Ontosaurus. WebOnto o mais recente e modificou certas caractersticas dos dois primeiros. Ontosaurus adotou um enfoque diferente em relao ao SOnt quanto biblioteca ontolgica: ao invs de diversos pequenos mdulos ontolgicos, com o intuito de favorecer o reuso, Ontosaurus desenvolveu uma nica e ampla ontologia, a partir do qual outras mais especficas compartilham conhecimento. WebOnto manteve o enfoque de biblioteca de SOnt, aprimorou a arquitetura cliente/servidor e desenvolveu uma interface de manipulao direta sobre uma representao diagramtica de ontologias. SOnt e Ontosaurus utilizam uma interface estilo hipertexto. Quanto as facilidades de consulta, SOnt permite consultas por palavras-chave e em Ontosaurus pode-se definir expresses regulares de pesquisa. WebOnto possibilita a reduo de informao exibida na navegao atravs da indicao dos tipos de itens de dados de interesse, como por exemplo, apenas instncias ou apenas classes.

112

FIGURA 10.9 - Interface de exibio de ontologias de WebOnto

FIGURA 10.10 - Janela de exibio de classe em WebOnto

113

FIGURA 10.11 - Edio de uma classe em WebOnto Em termos de facilidades no processo de edio, SOnt apresenta mais recursos, como a adoo de um modelo de incluso (resolve conflitos de nomes de conceitos e referncias a conceitos de outras ontologias), permisses de acesso a grupos e usurios, notificao de mudanas e comparao de modificaes feitas. Assim como em Ontosaurus, SOnt permite a decomposio de conceitos na definio ou modificao de ontologias, utiliza mecanismos de inferncia para deduzir relacionamentos e abstrai a linguagem de especificao durante o processo. WebOnto apresenta como principal vantagem o mecanismo de broadcast para comunicao entre projetistas, porm, obriga o usurio a conhecer a linguagem de especificao para definir ou alterar novos conceitos. Por fim, SOnt e Ontosaurus possuem suporte a outras linguagens de especificao, alm da linguagem nativa do sistema. Tradues entre linguagens so feitas automaticamente. A tabela 10.3 sumariza os resultados da anlise comparativa dos sistemas.

10.4 Metodologias
Diversas metodologias para construo de ontologias encontram-se definidas, porm, essa rea ainda no est amadurecida pois no existem ainda metodologias de uso extensivo. Um estudo recente na literatura tenta diagnosticar o estado da arte nessa rea, analisando caractersticas de algumas metodologias [Lop99]. O estudo realizado tomou por base o padro IEEE Standard for Developing Software Life Cicle, que recomenda tcnicas e atividades para o desenvolvimento de software. Esse padro foi adequado ao desenvolvimento de ontologias. Os seguintes processos so sugeridos pelo padro: 1. Processo do modelo de ciclo de vida de software: identifica e seleciona um ciclo de vida de desenvolvimento de ontologias; 2. Processo de gerenciamento de projeto: cria uma plataforma para o projeto, garantindo o gerenciamento do ciclo de vida do produto. Envolve atividades como iniciao, monitoramento e controle de qualidade da ontologia;

114

TABELA 10.3 - Comparao entre os sistemas de manipulao de ontologias

Servidor Ontolingua Funcionalidades Arquitetura Trabalho cooperativo Facilidades de navegao Linguagem especificao base Biblioteca ontolgica Ontosaurus WebOnto
Navegao, consulta e edio de ontologias Cliente/Servidor Todas suportam, com mecanismo de bloqueio para atualizao Uso de interface grfica para navegao em itens de dados; Exibio de itens relacionados a um item sendo investigado; Mltiplas informaes podem ser exibidas simultaneamente; Todas as interfaces de navegao esto disponveis na Web. Loom OCML de Ontolingua Composta de vrias pequenas ontologias Manipulao direta Busca por nome e seleo direta; Reduo de dados exibidos; Mantm dados localmente de Servio de broadcast

Composta de vrias Composta de uma nica e pequenas ontologias ampla ontologia Hipertexto Hipertexto Estilo de interface Facilidades de consulta Busca por nome e palavra- Busca por nome e expresso chave regular

Modelo para incluso; Decomposio conceitos; Permisses de acesso a Uso de inferncia; grupos e usurios; Notificao e Abstrao da linguagem comparao de de especificao modificaes; Decomposio de conceitos; Uso de inferncia; Abstrao da linguagem de especificao Sim Sim No Traduo para outras

Facilidades de edio

linguagens especificao

de

3. Processo de desenvolvimento orientado: envolve produo, instalao, operao, manuteno e retirada de uso. Apresenta trs grupos: a) processo de pr-desenvolvimento: estudo do ambiente e anlise de viabilidade. No caso de ontologias, deve-se revisar as possibilidades de integr-la a outros sistemas; b) processo de desenvolvimento: construo da ontologia, considerando: b1) processo de requisitos: especificar uma ontologia, mesmo que parcialmente; b2) processo de projeto: desenvolver uma representao coerente e bem organizada da ontologia, que atenda aos requisitos definidos; b3) processo de implementao: transforma a representao da etapa anterior em uma especificao em linguagem de programao.

115

c) processo de ps-desenvolvimento: envolve instalao, operao, suporte e manuteno da ontologia; 4. Processo integral: garante o trmino satisfatrio e a qualidade das funes do projeto. feita em paralelo com a etapa 3, incluindo atividades como verificao/validao, configurao, documentao e treinamento. A anlise de metodologias levou em considerao nove critrios. Os cinco primeiros analisam pontos gerais das metodologias e os quatro ltimos a maturidade das mesmas. Os critrios so: 1. Herana da engenharia de conhecimento: qual a influncia da engenharia de conhecimento tradicional; 2. Detalhamento da metodologia: quais atividades e tcnicas propostas pela metodologia so exatamente especificados; 3. Recomendaes para formalizao do conhecimento: quais formalismos (lgica, frames ou objetos, etc) so propostos para representar conhecimento; 4. Estratgia para construo de ontologias: discusso de qual das seguintes estratgias usada: a) dependente de aplicao: a ontologia construda com base na BC da aplicao por meio de um processo de abstrao; b) semi-dependente de aplicao: possveis cenrios do uso da ontologia so identificados no estgio de especificao; c) independente de aplicao: o processo de desenvolvimento totalmente independente do uso da ontologia por sistemas de RC, agentes, etc. 5. Estratgia para identificao de conceitos: partindo do mais concreto para o mais abstrato (bottom-up), vice-versa (top-down) ou do mais relevante para o mais concreto e mais abstrato (middle-out); 6. Ciclo de vida recomendvel: que ciclo de vida apresentado; 7. Diferenas entre a metodologia e o padro IEEE; 8. Tcnicas recomendadas: quais tcnicas so propostas para realizar as atividades; 9. Quais ontologias tem sido desenvolvidas usando a metodologia. Cinco metodologias foram analisadas. Sucintamente, suas caractersticas so as seguintes: Metodologia de Uschold e King: prov guidelines (guias) para o desenvolvimento de ontologias, produzindo especificaes textuais precisas e no ambguas de conceitos, relaes e termos que se referem a conceitos e relaes. Seus passos so: 1. Identificao do propsito da ontologia para um dado domnio; 2. Construo: 2.1 captura: identificao de conceitos chave e seus relacionamentos no domnio de interesse; 2.2 codificao: representao do conhecimento adquirido em uma linguagem formal; 2.3 integrao: adequar ontologias existentes nova ontologia.

116

3. Avaliao: julgamento tcnico das ontologias e verificao dos ambientes de software associados; 4. Documentao: estabelecer guidelines para documentar ontologias, conforme o seu tipo e propsito. Metodologia de Grninger e Fox: define um modelo lgico de conhecimento a ser especificado pela ontologia. Inicialmente feita uma descrio informal desse modelo e aps, uma formalizao em lgica de primeira ordem. Seus passos so: 1. Captura de cenrios motivadores: a criao de ontologias motivada por cenrios, que surgem em aplicaes como relatos de problemas ou exemplos no endereados adequadamente por ontologias existentes. So propostas solues, a nvel de descries informais de objetos e relaes; 2. Formulao de questes de natureza informal : requisitos so expressos na forma de questes que a ontologia deve responder usando sua terminologia. Respostas so dadas na forma de axiomas e definies. Uma resposta pode ser reutilizada para atender a uma questo mais geral (composio de respostas); 3. Especificao formal da terminologia: envolve dois passos: 3.1 obteno de uma terminologia informal: extrao de termos relevantes das questes; 3.2 formalizao: com base nos termos extrados, um formalismo como KIF pode ser usado para especificao da terminologia. 4. Formulao de questes de competncia formal utilizando a terminologia; 5. Especificao de axiomas e definies para os termos utilizando a linguagem formal: atravs de sentenas de primeira ordem, definem-se termos e suas restries. Objetos e axiomas adicionais podem ser criados para representar as solues; 6. Definio de condies para caracterizar a completude da ontologia: especificao de condies sobre as quais as solues sejam completas. Metodologia de Amaya Berneras et al.: desenvolve ontologias conforme as necessidades de aplicaes, investigando a possibilidade de reuso de conhecimento e integrao de ontologias. Seus passos, no desenvolvimento de uma ontologia de aplicao, so: 1. Especificao da aplicao: definio do contexto e componentes que a aplicao tenta modelar (termos e tarefas); 2. Projeto preliminar: obteno, com base nas definies do passo anterior, de vises do mundo globais de acordo com categorias ontolgicas determinadas. Envolve pesquisa a ontologias existentes, que podem ser modificadas para uso pela aplicao; 3. Refinamento e estruturao da ontologia : obteno de um projeto definitivo atravs do refinamento das vises de mundo identificadas.

117

METHONTOLOGY: constri ontologias a partir de um ciclo de vida evolutivo baseado em refinamento de prottipos. Apresenta trs categorias de atividades que devem ser aplicadas da maneira que a equipe de desenvolvimento achar mais adequada, quantas vezes forem necessrias. Essas atividades so: 1. Atividades de gerenciamento de projeto: - Planejamento: identifica tarefas, como arranj-las, tempo e recursos gastos. Essencial quando ocorre reuso de ontologias ou ontologias com diversos nveis de abstrao; - Controle: garante o cumprimento das tarefas de forma planejada; - Garantia de qualidade: garante uma qualidade satisfatria para os produtos feitos (software, documentao, etc). 2. Atividades orientadas ao desenvolvimento: - Especificao: informa por qu a ontologia ser construda e usos pretendidos; - Conceitualizao: estrutura o domnio em modelos significativos a nvel de conhecimento; - Formalizao: transforma o modelo conceitual em um modelo formal; - Implementao: constri modelos computveis em uma linguagem computacional; - Manuteno: atualiza e corrige a ontologia. 3. Atividades de suporte: executadas em paralelo com as atividades em 2: - Aquisio de conhecimento; - Avaliao: julga tecnicamente as ontologias e seus ambientes de software e documentao; - Integrao de ontologias: toda vez que ocorre reuso; - Documentao: a respeito das fases executadas e resultados produzidos; - Gerenciamento de configurao: mantm verses da documentao, software e descrio da ontologia. SENSUS: especifica estruturas ontolgicas para o auxlio a aplicaes de processamento de lngua natural. Ontologias so especificadas considerando definies pr-existentes na prpria ontologia SENSUS. Os passos da metodologia so: 1. Especifica uma srie de termos como sementes; 2. Vincula essas sementes SENSUS manualmente; 3. Todos os conceitos no caminho das sementes para a raz de SENSUS so includos na nova ontologia; 4. Termos que podem ser relevantes para o domnio em questo so adicionados, caso no existam; 5. Quando existem muitos caminhos no relacionamento entre dois termos, deve-se indicar manualmente quais deles permanecero na ontologia.

118

A tabela 10.4 compara as cinco metodologias com relao aos nove critrios de anlise descritos. Os nmeros presentes nas linhas so os nmeros dos critrios TABELA 10.4 - Comparao entre as metodologias para construo de ontologias Uschold e King Grninger e Fox Amaya Berneras Methontology Sensus 1
Adequada parcialmente engenharia de conhecimento pois no apresenta estudo de viabilidade nem prototipao Apesar da metodologia identificar questes, no h uma diviso clara dos estgios envolvidos na engenharia de conhecimento No descreve No descreve atividades e tcnicas atividades e tcnicas em detalhes em detalhes No h Usa lgica recomendaes Adequa-se tradio da engenharia de conhecimento. Constri ontologias em paralelo com o desenvolvimento de sistemas baseados em conhecimento (SBCs) No descreve atividades e tcnicas em detalhes No h recomendaes Baseada em uma No segue a tradio da metodologia para engenharia de desenvolvimento de conhecimento SBCs

2 3

4 5 6

Independente de Semi-dependente de aplicao aplicao Middle-out Middle-out No proposto um proposta apenas ciclo de vida uma ordem de execuo de atividades. Porm, no possvel saber se a metodologia admite um ciclo de vida No menciona No menciona gerenciamento, gerenciamento, pre pspre psdesenvolvimento desenvolvimento e projeto; e projeto; No leva em No leva em conta: estudo do conta: ambiente, estudo treinamento e de viabilidade, gerenciamento de treinamento e configurao gerenciamento de configurao

Dependente de aplicao Top-down Utiliza o mesmo ciclo de vida usado no desenvolvimento da aplicao para o qual a ontologia servir

Grande parte da metodologia bem detalhada D liberdade de escolha com relao formalizao. Uma ferramenta de apoio gera cdigo de definio da ontologia Independente de aplicao Middle-out Ciclo de vida baseado em prottipos evolutivos

No descreve atividades e tcnicas em detalhes Redes semnticas

Semi-dependente de aplicao Bottom-up No proposto um ciclo de vida

No menciona gerenciamento, pre psdesenvolvimento e projeto; No leva em conta: treinamento, gerenciamento de configurao, documentao, verificao e validao No so detalhadas No so detalhadas No so detalhadas tcnicas tcnicas tcnicas Ontologias tm sido desenvolvidas em Domnios complexos de negcios Ontologias tm sido desenvolvidas em projetos complexos em um domnio especfico

No menciona No menciona modelo do ciclo gerenciamento, pr- e de vida do ps-desenvolvimento e software e pr- projeto desenvolvimento; No leva em conta: iniciao do projeto, treinamento, instalao, suporte e retirada No so tcnicas detalhadas

Apenas tcnicas para a atividade de controle devem ser detalhadas Ontologias tm sido Ontologias tm sido desenvolvidas no desenvolvidas em domnio de redes diferentes domnios eltricas

Ontologias tm sido desenvolvidas na rea militar

119

Algumas concluses foram feitas com o estudo e posterior anlise comparativa dessas metodologias. Primeiramente, nenhuma das metodologias madura, se comparadas com o padro IEEE. MEHTONOLOGY a mais amadurecida de todas, porm, o suporte ao processo de pr-desenvolvimento necessrio, assim como o detalhamento de algumas atividades e tcnicas. Outro ponto que se percebe que no h consenso quanto ao propsito das metodologias. SENSUS, por exemplo, utiliza mtodos completamente diferente das demais. No possvel afirmar ainda se interessante caminhar no sentido de uma metodologia padro para especificao de ontologias ou se devem co-existir diversas metodologias aceitas. Por outro lado existe consenso na questo de integrao de ontologias, favorecendo principalmente o reuso de conceitos de alto nvel de uma ontologia quando se constri outras. Constataes diretamente obtidas a partir da anlise direta da tabela 9.4 o fato da maioria das metodologias herdar atividades dos mtodos de desenvolvimento de SBCs e utilizarem uma estratgia middle-out para identificao de conceitos. A primeira se justifica pela ampla aplicabilidade de ontologias para esse tipo de sistema. A segunda talvez pelo fato de ser mais natural definir os conceitos de percepo mais imediata num primeiro momento e a partir deles derivar conceitos mais genricos e/ou mais especializados conforme a necessidade.

120

11 Propostas de Aplicao de Ontologias a Bancos de Dados Semi-Estruturados

11.1 O Sistema de Informao Global Observer 11.1.1 Viso Geral
Sistemas de Informao Global (SIGs) tm como caracterstica o gerenciamento de repositrios de dados distribudos e altamente heterogneos, como o caso da Web. Um BDSE pode ser pensado como um suporte para um SIG. Diversos problemas relacionados a consultas a dados de SIGs existem: muitas diferenas no formato (tipos de atributos) e na estrutura (forma de armazenamento) dos repositrios; repositrios com vocabulrios conceituais diferentes; respostas imprecisas, pois pode no ser possvel identificar a semntica adequada dos dados de alguns repositrios e a possibilidade de selecionar novos repositrios para a aplicao de uma mesma consulta. Observer um SIG em desenvolvimento na Universidade Politcnica de Madrid, Espanha, que utiliza ontologias para o processamento de consultas [Nie98]. Ontologias so consideradas, neste contexto, metadados, organizados em uma hierarquia de especializao de termos (conceitos e regras especificados em LD), que capturam a semntica do contedo dos dados de repositrios, abstraindo heterogeneidade e distribuio de dados. Usurios formulam consultas diretamente sobre uma ontologia selecionada, podendo inclusive definir as suas prprias ontologias, sem que os termos definidos estejam necessariamente presentes em algum repositrio de dados. Adota-se a abordagem de manter vrias ontologias relacionadas, ao invs de uma nica e ampla ontologia, para no forar o uso de um vocabulrio global que dificulte a compreenso dos usurios. A estruturao de uma ontologia como uma hierarquia de termos til pois mantm uma classificao que permite inferncias em consultas e definies de termos (termos mais gerais ou mais especficos) e elimina especificaes redundantes de restries, uma vez que existe herana de definio. A figura 11.1 mostra os dois tipos de relacionamento que envolvem as ontologias do sistema. Crculos representam ontologias e BDs representam repositrios de dados.
O2 O1 O3 O4

R1

R2

R3

R4

R5

FIGURA 11.1 - Tipos de relacionamento entre ontologias no sistema Observer Os tipos de relacionamento so os seguintes:

121

Relacionamentos entre ontologias (linhas contnuas): cada termo de uma ontologia pode ter uma informao de relacionamento com termos da mesma ou de outras ontologias (mapeamento entre ontologias). Os tipos de relacionamento suportados so: sinnimos, mais geral que, menos geral que, interseco (abstrao de um termo t1 tem interseco com a abstrao de um termo t2), disjuno (no h interseco entre t1 e t2) e cobertura (abstrao de t1 coberta pelo conjunto de termos T, sendo cada termo de T menos geral que t1); Relacionamentos entre ontologia e repositrio de dados (linhas tracejadas) : cada termo da ontologia possui uma informao de mapeamento que o relaciona com estruturas dos repositrios de dados nos quais a ontologia se relaciona. Conforme mostra a figura, cada ontologia descreve um pequeno conjunto de repositrios, ou seja, um repositrio alcanado por apenas uma ontologia. Essa abordagem tem as seguintes vantagens: (i) evita que existam exaustivos e redundantes mapeamentos de todas as ontologias para todos os repositrios; (ii) se a estrutura de um repositrio muda, basta alterar apenas o mapeamento da ontologia que o acessa e (iii) simplifica o processamento de consultas, uma vez que apenas um mapeamento deve ser executado para um repositrio.

Esses mapeamentos so o ponto chave do sistema no que diz respeito ao encapsulamento de vocabulrios e da heterogeneidade dos repositrios de dados. Na seqncia, a arquitetura do sistema descrita, assim como a sua dinmica de funcionamento.

11.1.2 Arquitetura
A arquitetura de Observer distribuda, sendo formada por trs componentes principais (figura 11.2): o servidor de ontologias, o gerenciador de relacionamentos inter-ontologias (GRI) e o processador de consultas. O servidor de ontologias encapsula o acesso s ontologias de um conjunto de repositrios de dados presentes em um nodo componente do sistema. Disponibiliza dois tipos de servios: informaes intensionais sobre uma ontologia e respostas a consultas sobre ontologias. No primeiro caso, retorna informaes sobre a estrutura de qualquer ontologia do nodo, como: enumerao de termos, definio de um termo em LD, lista de termos gerais/especializados de um termo, verificao do tipo de um termo (primitivo ou definido), instncias de um termo e representao grfica de uma ontologia. Dada uma consulta em LD e um nome de ontologia, o servidor de ontologias retorna tuplas de dados dos repositrios que satisfazem a consulta. Para tanto, mapeamentos de termos para estruturas de dados dos repositrios so executados e wrappers especficos so invocados para realizarem o acesso aos mesmos. Informaes de mapeamento so representadas na forma de tuplas e envolvem o uso de uma lgebra relacional estendida. Um exemplo de mapeamento de um conceito chamado Livro o seguinte:
CONCEPT Livro: < [Union [Selection pub-BDI.publication [= pub-BDI.publication.formato Livro]] [Selection bib-BDI.ref [= bib-BDI.ref.type Livro]]], pub-BDI.publication.cdigo, string>

122

Nessa expresso de mapeamento, tem-se uma relao como primeiro argumento, que define uma expresso na lgebra relacional estendida, seguido do(s) atributo(s) da relao que identificam seus objetos e o tipo desse(s) atributo(s). Neste exemplo, o conceito Livro est presente em duas fontes de dados catalogadas no sistema: pub-BDI e bib-BDI. Essa lgebra atua como uma linguagem de consulta intermediria entre a especificao textual em LD e a linguagem de consulta ou mtodo de acesso que o wrapper utiliza para o acesso aos repositrios de dados. Wrappers em Observer podem acessar qualquer repositrio de dados, desde BDs at fontes semi-estruturadas. No segundo caso, o wrapper deve acessar diretamente os dados, devendo ter capacidades mnimas de consulta. Para tanto, mantm-se um esquema conceitual que descreve entidades, relacionamentos e atributos independentes da organizao de dados das fontes. Quando o wrapper invocado, so passados como argumentos: uma referncia fonte de dado e selees/projees sobre atributos deste esquema conceitual em uma linguagem de consulta genrica. O wrapper processa a especificao nessa linguagem (esse processamento genrico, para todo wrapper que acessa uma fonte de dados semi-estruturada) aps um mapeamento dos dados extrados para atributos do esquema conceitual.

FIGURA 11.2 - Arquitetura do sistema Observer O GRI permite que uma consulta possa ser enviada para outras ontologias, alm da ontologia alvo, atravs da manuteno de relacionamentos entre definies de termos de ontologias diferentes. Atravs do GRI possvel expandir uma consulta para outras ontologias, traduzindo-se os termos da ontologia alvo (OA) para outra ontologia a ser pesquisada. A definio dos tipos de relacionamento, descrito na seo anterior, feita manualmente, em tempo de criao de uma ontologia. Relacionamentos so ou entre dois

123

conceitos ou entre duas regras. Funes de transformao definem relacionamentos entre valores de uma regra e de outras regras, como por exemplo, datas em formatos diferentes. Diversas funes so oferecidas pelo GRI: nome de reas de conhecimento (clusters), as ontologias de um cluster, o nodo onde se encontra uma ontologia, relacionamentos entre pares de termos em duas ontologias, traduo de valores de uma regra em uma ontologia para valores de uma regra relacionada em outra ontologia, etc. O armazenamento de termos no GRI baseado no conceito de termo cannico, que representa um conceito ou regra geral. Novos termos, quando relacionados a um termo cannico tornam-se seus sinnimos. Para termos mais gerais/mais especficos e termos disjuntos, so mantidas apenas duas tabelas que relacionam dois termos cannicos (simplifica o nmero de relacionamentos). Relacionamentos de interseco e de cobertura so pares de termos cannicos ou de ontologias, com um percentual de interseco/cobertura associado. Funes de transformao apresentam trs argumentos: nome, paresRO1, paresRO2. O segundo e o terceiro argumentos mantm conjuntos de pares (regra, ontologia) e o corpo da funo traduz valores de regras de paresRO1 para valores de regras equivalentes em paresRO2. O processador de consultas tem por objetivo prover consultas semanticamente ricas em um ambiente onde diferentes vocabulrios so usados, muito comum em fontes de dados semi-estruturados. A caracterstica forte deste componente a transformao de uma consulta para outra semanticamente similar, de forma a aplic-la a outra ontologia. Tal transformao medida (com base no nmero de restries que foram mapeadas com sucesso) e deve ser mantida abaixo de um limite mximo de perda de informao definido pelo usurio. Os passos de uma consulta em Observer so: construo, acesso e expanso, sendo os dois ltimos cclicos, terminando quando o usurio estiver satisfeito com o resultado. No primeiro passo, atravs de uma interface grfica, o usurio seleciona uma OA e edita a consulta, com auxlio do sistema e sem ter que conhecer uma especificao textual em LD. Na definio da condio da consulta, o usurio pode selecionar um termo T de outra ontologia, o que ocasiona a criao de um novo termo T na OA e um relacionamento entre T e T. Aps a edio, o sistema verifica se existem restries contraditrias ou redundantes. Para o acesso a dados, o processador de consultas invoca o servidor da ontologia, que com o auxlio do GRI, de informaes de mapeamento e dos wrappers, recupera e correlaciona as informaes, passando o resultado de volta ao processador. Caso o usurio desejar enriquecer a consulta, ocorre o que se chama de expanso: uma nova OA selecionada e a consulta reescrita na linguagem (vocabulrio de termos) desta nova OA, preservando-se o mximo possvel a semntica da mesma. Caso esta traduo (reescrita) no for completa, o percentual de perda de informao dessa traduo no pode ser inferior ao limite de perda estipulado pelo usurio. No ocorrendo este problema, o acesso a essa nova OA feita e o ciclo se repete.

11.1.3 Detalhes do Processamento de Consultas

Uma consulta formulada pelo usurio internamente especificada como uma expresso em LD pela interface grfica e ento enviada para processamento. O processamento de uma consulta realizado em quatro passos:

124

1. Traduo da consulta LD em uma expresso na lgebra relacional estendida que se refere aos repositrios de dados relevantes; 2. Definio do plano de consulta. Para tanto, a expresso da lgebra dividida em expresses individualizadas para cada repositrio e convertida para a linguagem de consulta do mesmo ou para a linguagem de consulta genrica, no caso de um repositrio sem servio de gerenciamento de dados; 3. Execuo do plano de consulta. Na montagem da resposta, quando os termos envolvidos na consulta esto em mais de um repositrio, deve-se correlacionar as respostas de cada um deles. Caso algum atributo da resposta no exista em algum repositrio, seu valor recebe null; 4. Apresentao da consulta ao usurio. No passo 3, a correlao ocorre atravs dos seguintes passos: 1. Traduo dos esquemas dos repositrios de dados para o esquema da OA : nomes de atributos para nomes de respectivos termos e aplicao de funes de transformao inversas para adequao de domnios de valores; 2. Unio das respostas de repositrios de dados : remove-se objetos redundantes, atualiza-se objetos incompletos (valores nulos); 3. Correlao de respostas de ontologias diferentes: ocorre toda vez que a consulta expandida para uma outra ontologia, alm da OA. Deve-se adequar as respostas das ontologias com o esquema da ontologia alvo. Para tal tarefa, invocado o GRI, que traduz valores constantes para a semntica da OA. Na apresentao da resposta para o usurio, primeiramente so mostrados os dados da OA e, aps, os dados das ontologias relacionadas. A apresentao se d na forma de tabelas relacionais com informao de medida de perda de informao associada. O usurio, de posse dessa resposta pode: concluir a pesquisa, modificar o parmetro de limite (percentual) de perda mxima de informao e resubmeter a mesma consulta ou solicitar uma expanso da consulta com ou sem modificao do limite de perda. A expanso da consulta uma tarefa complexa pois deve lidar com vocabulrios de diversas ontologias, que nem sempre possuem correspondncia. Primeiramente, deve-se adequar a consulta da OA para a ontologia selecionada para expanso (ontologia candidata OC) atravs da reescrita dos termos da OA no vocabulrio de termos da OC (via GRI). Caso ocorra uma traduo completa, o resultado da consulta ser a unio/correlao dos termos de ambas. Caso ocorra apenas uma traduo parcial (apenas parte das restries da consulta pode ser aplicada, pois no h correspondncia para todos os termos), essa traduo armazenada para eventualmente ser utilizada com a interseco de tradues parciais de outras OCs pesquisadas que gerem uma traduo completa. Tradues parciais geram uma traduo completa quando o seu conjunto de termos cobre os termos especificados na condio da consulta. Por exemplo, suponha uma consulta que se aplica a um objeto Ob de uma ontologia O1, com uma condio sobre os termos a1, a2 e a3 de Ob. Se uma ontologia O2 representa Ob com os termos a1 e a2 e uma ontologia O3 representa Ob com os termos

125

a2 e a3, uma traduo completa ocorre quando combinamos as tradues parciais de Ob aplicadas a O2 e O3, ou seja: Ob(O2, condio sobre a1 e a2) Ob(O3, condio sobre a2 e a3). Obviamente, isto somente vlido se existem mapeamentos entre os termos de O1 e O2 e entre os termos de O1 e O3. Uma alternativa para evitar o problema de visitar vrias OCs at se gerar uma traduo completa (o que nem sempre possvel) substituir os termos no traduzidos pela interseco de termos pais ou unio de termos filhos na hierarquia de termos de ontologias, para os quais existe traduo. Porm, existe sempre uma perda de informao associada com essa substituio. Dois percentuais so necessrios para o clculo desta perda: o percentual de diferena terminolgica entre dois termos em ontologias diferentes (determina a chamada perda intensional) e o percentual de diferena entre a extenso de um objeto e a extenso dos objetos genricos (perda extensional). O processador de consulta testa vrios planos de execuo, aplicando substituies diferentes e medindo as perdas. O plano com menor perda que gera uma traduo completa e que no supera o limite de perda mxima estipulado pelo usurio o escolhido. Essa alternativa de obteno de traduo completa tentada sempre que uma OC candidata no gera uma traduo completa. Caso o percentual de perda de informao seja proibitivo, a traduo parcial mantida e parte-se para uma nova OC e o processo se repete.

11.2 A Linguagem SHOE

SHOE (Simple HTML Ontology Extensions) uma linguagem, desenvolvida na Universidade de Maryland, Estados Unidos, que estende a linguagem HTML com tags orientadas a conhecimento, provendo uma estrutura para aquisio deste conhecimento [Hef99]. Taxionomias e regras de inferncia disponveis em ontologias que so referidas em SHOE habilitam a descoberta de conhecimento implcito. Esta linguagem foi desenvolvida, a ttulo de experincia, para um domnio veterinrio, mais especificamente, para aplicaes que lidam com informaes referentes a doenas que afetam o gado bovino (sistemas DGB). SHOE faz parte de um ambiente cuja arquitetura composta por uma ontologias, disponveis no site do ncleo de pesquisas DGB, uma ferramenta de marcao SHOE, que produz documentos em SHOE, um browser SHOE chamado Expos e uma BC chamada Parka. A ferramenta de marcao destinada a pesquisadores que desejam disponibilizar informao na forma de pginas Web. Estas pginas, aps anlise, so adicionadas a lista de sites que Expos acessa. Conhecimento SHOE descoberto adicionado Parka. Applets Java, disparados atravs de uma interface grfica com o usurio disponvel no site do ncleo DGB, acessam Parka para responder consultas e atualizar displays. Ontologias so desenvolvidas tambm atravs da sintaxe SHOE, que especifica hierarquia de conceitos (categorias), relacionamentos e regras de inferncia. Os relacionamentos foram projetados considerando as pesquisas usuais que poderiam ser feitas na Web, que geralmente compreendem navegao em links. Assim, relaes como inverso e transitividade so mais exploradas. Atributos de conceitos e relacionamentos so definidos atravs de regras. A figura 11.3 mostra um fragmento da especificao da ontologia em

126

SHOE. O enfoque, para o domnio da aplicao est em trs conceitos: materiais (animais, agentes de doena e tecidos), processamentos (sobre os materiais) e produtos finais (para combater doenas).

127

128

A ferramenta de marcao adiciona a semntica da ontologia a pginas HTML. Pginas SHOE descrevem uma ou mais instncias, unicamente identificveis com base na URL, que representam um conceito. A descrio de uma instncia consiste da ontologia que esta faz referncia, o conceito que a classifica e suas relaes. A figura 11.4 mostra um exemplo de instncia codificada em SHOE.

FIGURA 11.3 - Trecho de cdigo na linguagem SHOE que especifica uma ontologia A insero de marcaes semnticas SHOE facilitada via uma interface grfica onde um documento HTML pode ser criado e o usurio pode selecionar ontologias, categorias e relaes e associar valores a regras. Conceitos de diversas ontologias podem ser associados a dados de um mesmo documento. No caso de pginas HTML criadas externamente que possuam informao relevante, definem-se pginas de sumrio com tags SHOE e links para essas pginas. A figura 11.5 mostra a edio das regras de uma instncia de uma certa URL, definida conforme a ontologia chamada TSE. Instncias editadas geram cdigo similar ao mostrado nesta figura. Expos a ferramenta que pesquisa pginas Web com marcao SHOE, extrai o conhecimento das mesmas e o armazena em Parka. Apenas pginas indicadas em uma lista de sites so visitadas, para evitar a investigao completa da Web. Parka uma BC escalvel e suporta relacionamentos M:N e relacionamentos de herana e instanciao. Herana a nico tipo de inferncia suportado por ela. A nvel de interao com o usurio existe uma interface grfica de consulta Parka, disponvel no site do ncleo DGB. O usurio constri consultas grficas atravs da seleo interativa de conceitos e relaes da ontologia. Consultas conjuntivas podem ser formuladas e predicados predefinidos para comparaes numricas, tratamento de strings e outros podem ser igualmente selecionados. Projees podem ser definidas em termos de variveis vinculadas a atributos e/ou conceitos. Respostas so tabelas com colunas correspondendo s

129

variveis da consulta mais a indicao da URL do documento recuperado, que pode ser selecionada para investigao. FIGURA 11.4 - Instncia de um conceito descrita em SHOE

11.3 Ontobroker

11.3.1 Arquitetura
Ontobroker uma ferramenta baseada em ontologias da Universidade de Karlsruhe, Alemanha, que processa descries de contedo em HTML, XML e RDF, provendo recuperao inteligente de informao [Erd99, Fen99]. A ferramenta possui uma arquitetura formada por quatro componentes que interagem com ontologias (figura 11.6). A mquina de consulta recebe consultas e as responde, verificando o contedo de um BD cujos dados so preenchidos pelo agente de informao e pela mquina de inferncia. O agente de informao responsvel pela coleta de conhecimento factual da Web, utilizando vrios estilos de meta-anotaes diretas, como XML e HTML-A. A mquina de inferncia usa fatos e a terminologia e os axiomas das ontologias para derivar conhecimento factual adicional. As ontologias so o princpio geral de estruturao de dados da Web: o agente de informao as utiliza para extrair fatos, a mquina de inferncia para inferir fatos, o gerenciador de BD para estruturar o BD e a mquina de consulta para prover auxlio na formulao de consultas. A mquina de consulta atua sobre uma linguagem nica para consulta e representao de dados que se baseia em uma expresso elementar de consulta do tipo: x c attribute(x) = v, a partir do qual expresses mais complexas so construdas. Essa linguagem chamada lgica de frames (um formalismo lgico OO presente em alguns BDs dedutivos). As ontologias so formalizadas nesta linguagem, que permite a especificao de hierarquias de herana mltipla de conceitos, relacionamentos, atributos e regras de derivao de novos conhecimentos. Suas especificaes so mantidas no BD.

130

A nvel de usurio final, uma interface grfica com recursos de navegao em ontologias permite a formulao de consultas interativas e a derivao de consultas textuais em lgica de frames, com apresentao de resultados tabulares.

FIGURA 11.5 - Interface grfica da ferramenta de marcao de SHOE

FIGURA 11.6 - Arquitetura da ferramenta Ontobroker O agente de informao extrai conhecimento de quatro formas:

131

HTML-A: integra anotaes semnticas em documentos HMTL atravs de um browser para coletar pginas, extrair anotaes e convert-las (parse) para um formato estendido chamado HTML-A, que fica armazenado no BD; Wrappers: acessam fontes de dados que no utilizam as linguagens de anotao da ferramenta, como alguns documentos HTML que possuem alguma estrutura; RDF: analisa anotaes RDF (anotaes semnticas a documentos que no levam em conta a sua estrutura), utilizando um parser que traduz suas descries em triplas que so mantidas no BD; DTDs XML: DTDs gerados a partir da ontologia associam semntica a documentos XML. Esse processo comentado na prxima seo.

O agente de informao responsvel pela manuteno do BD da ferramenta. Periodicamente, ele coleta informao da Web e faz cache da mesma. A mquina de inferncia utiliza essa cache para responder consultas, utilizando uma estratgia semelhante s mquinas de RI. Esta mquina trabalha tambm em background, tomando fatos do BD e retornando fatos inferidos ao mesmo. Essa estratgia desvincula quase sempre a mquina da consulta da mquina de inferncia, ou seja, a mquina de consulta no necessariamente ativa a mquina de inferncia em tempo de execuo da consulta, para no comprometer a performance na obteno da resposta.

11.3.2 Modelagem Conceitual de Documentos XML

XML vem ganhando popularidade como linguagem de marcao para a Web e, ao contrrio de HTML, prov tags com propsito semntico que podem ser explorados para as mais diversas finalidades. Porm, essas propriedades no esto claras fora do escopo das aplicaes que os utilizam. Levando isto em conta, o agente de informao de Ontobroker mapeia conceitos e atributos de ontologias para elementos de uma estrutura XML atravs de DTDs. As ontologias, neste contexto, funcionam como unificadoras da sintaxe de documentos XML e propiciam consultas realmente semnticas sobre os mesmos, que abstraem a sua estrutura. A tarefa de mapeamento descrita anteriormente feita por um mdulo do agente de informao chamado DTDMaker, que recebe especificaes ontolgicas em lgica de frames e gera arquivos DTD XML. Os DTDs gerados definem classes de conceitos que auxiliaro na marcao de documentos XML. Em linhas gerais, a traduo feita por DTDMaker a seguinte: Conceitos da ontologia tipo elemento no DTD; Atributos de conceitos da ontologia subelementos no DTD; Atributos que representam relacionamentos na ontologia subelementos que tem como tipo o elemento correspondente ao conceito relacionado, sendo o seu contedo do tipo atmico string PCDATA (tipo padro de DTDs).

Herana especificada em DTDs atravs das chamadas entidades parmetro, que definem strings que podem substituir uma entidade ao longo da DTD. Neste caso, cada string representa um subconceito.

132

Na seqncia, mostrada uma especificao parcial de uma ontologia em lgica de frames (a) e seu correspondente DTD (b). A diretiva ENTITY indica entidades parmetro, ELEMENT especifica conceitos e os nomes dentro de parnteses so subelementos ou atributos PCDATA. O smbolo * indica que mais de uma ocorrncia pode estar presente nos subelementos. A declarao do elemento autor um exemplo de especificao de relacionamento em DTD, que indica que um ou mais elementos da entidade pessoa (%Pessoa) pode ser um autor. Regras de integridade, indicadas atravs da clusula FORALL, no apresentam correspondncia na DTD.
Object[ ]. Pessoa:: Object. Empregado:: Pessoa. EquipeAcadmica:: Empregado. Estudante:: Pessoa. EstudanteDoutorado:: Estudante. Publicao:: Object. Livro:: Publicao. Artigo:: Publicao. ... Pessoa[nome =>> string; email =>> string; telefone =>> string; publicao =>> Publicao, editor =>> Livro]. Publicao[autor =>> Pessoa; ttulo =>> string; ano =>> number; abstract =>> string]. Livro[editor =>> Pessoa]. ... FORALL Pes1, Pub1 Pub1: Livro[editor ->> Pes1] <-> Pes1: Pessoa[editor ->> Pub1] ...

(a)
<!ENTITY %Pessoa Pessoa | Empregado | EquipeAcadmica | Estudante | EstudanteDoutorado > <!ENTITY %Publicao Publicao | Livro | Artigo > <!ELEMENT Pessoa (#PCDATA | nome | email | telefone | publicao | editor)*> <!ELEMENT Publicao (#PCDATA | autor | ttulo | ano | abstract)*> <!ELEMENT Livro (#PCDATA | autor | ttulo | ano | abstract | editor)*> ... <!ELEMENT autor (#PCDATA | %Pessoa;)*> <!ELEMENT ttulo (#PCDATA> <!ELEMENT ano (#PCDATA)*> <!ELEMENT editor (#PCDATA | %Book; | %Pessoa;)*> ...

(b) Cabe salientar que a especificao de um DTD no impe nenhuma restrio sobre qual dos elementos definidos deve ser o elemento raiz em documentos XML, assim como a obrigatoriedade de existncia de todos os subelementos. Por exemplo, um documento pode trazer dados de Livros publicados (elementos do tipo Livro como raiz), tendo como subelementos apenas autores, ttulo e ano, como indica o trecho a seguir em XML:
<!DOCTYPE Livro SYSTEM ka2.dtd> ... <Livro> <ttulo> Sistema de Banco de Dados </ttulo>

133

<ano> 1994 </ano> <autor> Henry Korth </autor> <autor> Abraham Silberschatz </autor> </Livro> ...

O cabealho indica ka2.dtd como sendo o arquivo DTD, gerado por Ontobroker, que especifica os conceitos ontolgicos instanciados no documento. Neste caso, instncias do conceito Livro esto sendo declaradas. DTDMaker gera ainda identidades para os conceitos mapeados, de forma a identificar instncias de forma no ambgua. Por exemplo, uma declarao de OID para um conceito pessoa utiliza o tipo ID de XML:
<!ATTLIST Pessoa OID ID #IMPLIED> ... <!ATTLIST autor OIDREF CDATA #IMPLIED> ...

Neste mesmo trecho de cdigo v-se uma forma alternativa de representao de relacionamento, atravs da declarao de um tipo OIDREF para autor. Assim, uma instanciao para autor em XML pode ter como valor o identificador de um pessoa ou seus nomes. A principal vantagem de DTDMaker que, com base nos DTDs gerados, documentos XML podem ser produzidos de acordo com a semntica da ontologia. Posteriormente, com a coleta dos seus dados agente de informao, consultas tradicionais de BD possam ser feitas sobre os documentos. Neste processo de coleta, novamente a ontologia consultada para gerar instncias de BD adequadas s especificaes XML. Esse processo de mapeamento ainda necessita de aprimoramentos, uma vez que uma DTD no expressiva suficiente para representar uma ontologia. Algumas pontos a ttulo de exemplo so: o fato dos atributos no serem locais a um conceito, como editor, que pode ser um atributo tanto de Livro quanto de Pessoa (pode gerar interpretaes errneas de relacionamentos); dois conceitos na ontologia com um mesmo nome de atributo (iro gerar dois elementos iguais na DTD), a falta de suporte a restries, etc.

11.4 Proposta de Embley

Uma das estratgias de extrao de dados, apresentada na seo 5.3.2.2, utiliza ontologias como suporte semntico fundamental para a coleta e estruturao de dados de documentos semi-estruturados [Emb98b]. Esta estratgia particularmente interessante para classes de documentos de certos domnios, como anncios classificados, informaes tursticas, etc, que apresentam constantes facilmente identificveis (ricos em dados) e seguem um certo padro de discurso. Os detalhes da estratgia de extrao encontram-se descritos na seo 5.3.2.2. A inteno, nessa seo, apenas evidenciar a aplicao de ontologias neste tipo de tarefa de um BDSE. A ontologia um modelo conceitual do domnio (estilo diagrama entidaderelacionamento) no qual os dados de um conjunto de documentos fazem parte. Ela serve de

134

entrada, juntamente com um documento semi-estruturado, para uma procedimento de extrao que produz como sada um documento estruturado e filtrado com relao a ela, conforme mostra a figura 11.7. O parser da ontologia gera trs arquivos: regras, lista de objetos e esquema SQL. O arquivo de regras descreve as regras para identificao de objetos da ontologia (conceitos, atributos e relacionamentos), como constantes vlidas, expresses regulares que descrevem o formato de atributos e palavras-chave associadas. O esquema SQL uma seqncia de comandos de criao de tabelas resultante do mapeamento do modelo conceitual. A lista de objetos uma associao entre os objetos da ontologia e as declaraes das tabelas do esquema SQL, mais as indicaes de restries de cardinalidade.
Ontologia de Aplicao Parser da Ontologia Regras para Constantes e Palavras-chave Lista de Objetos, Relacionamentos e Restries

Esquema SQL

Documento

Reconhecedor de Constantes e Palavraschave Tabela Nome/String/Posio

Gerador de Texto Estruturado Documento Filtrado e Estruturado (BD)

FIGURA 11.7 Procedimento de extrao baseado em ontologia Para cada documento de entrada, dois procedimentos so feitos utilizando os arquivos gerados: reconhecimento de constantes e palavras-chave e gerao de texto estruturado. O reconhecedor produz uma tabela nome/string/posio com base na anlise do documento e do arquivo de regras. O gerador utiliza esta tabela para povoar o BD, utilizando a lista de objetos e o esquema SQL. O reconhecedor tem por incumbncia identificar strings no texto conforme as expresses regulares, gravando o seu nome (atributo ou palavra-chave), valor (string) e posio no texto. O gerador se vale de heursticas, baseadas na anlise de restries da lista de objetos e dos elementos da tabela, para gerar tuplas do esquema SQL e inseri-las no BD. O projeto da ontologia importante para que a extrao tenha sucesso. Quanto mais detalhada a ontologia, mais informao semntica est disponvel para a compreenso e identificao de dados relevantes dos documentos.

11.5 InfoSleuth

135

O sistema InfoSleuth resultado de um projeto que visa desenvolver solues para os problemas de acesso e manipulao de dados heterogneos em um ambiente distribudo como a Internet [Per98, Unr98]. Utiliza uma abordagem baseada em agentes cooperativos na rede, cada um com uma especialidade, para obteno e anlise de informao em diversos nveis de abstrao. Alm dos agentes, o sistema conta ainda com vrias ontologias, que descrevem conceitos de domnios de aplicao, anlises e eventos. Essas duas ltimas especificaes dirigem processos de anlise, integrao e monitoramento de mudanas sobre dados. Fontes de dados heterogneos e aplicaes formadas por rede de agentes completam a arquitetura do sistema.

11.5.1 Ontologias do Sistema

Ontologias de domnio so modeladas como diagramas entidade-relacionamento (ER), especificando conceitos como entidades, alm de relacionamentos, atributos e hierarquias de herana. O exemplo a seguir mostra parte de uma especificao textual (hierarquias de herana de conceitos) de uma ontologia derivada de um ER, que expressa fatos de interesse para profissionais que lidam com anlise de informao (PAI) na Internet:
PAIFatos (data-incio, data-fim, fonte) Publicidade (companhia, atividade, produto, categorias-tecnolgicas, URL) Competio (companhia1, companhia2, categorias-tecnolgicas, produto) Colaborao (companhia1, companhia2, categorias-tecnolgicas, produto) PreoInformao (produto, preo-mdio, preo-superior, preo-inferior) Produto (nome, companhia, categorias-tecnolgicas) BensConsumo (categoria-consumo) ConsumoEletrnico (categoria-eletrnica, mdia-vida, dimenses) ConsumoSoftware (categoria-software, sistemas-operacionais) Tecnologia (nome-categoria, frase-identificao) PadroTemporal (data-incio, data-trmino, expresso-domnio) Desvio (valor, limite-aprendido)

Alm da representao de esquemas conceituais, Infosleuth modela eventos e anlises atravs de ontologias. Eventos provem mudanas ou observaes analticas em dados. Modificaes em instncias ontolgicas (vises) ocorrem quando dados so alterados nas fontes heterogneas ou diretamente nas vises. Essas modificaes so detectadas via investigaes peridicas nas fontes ou, no sentido oposto, triggers para as fontes so ativados em virtude de mudanas na viso. As entidades principais do tipo evento so: domnio, data mining e compostos. Eventos do tipo domnio so responsveis por operaes de insero e remoo de instncias de vises ontolgicas de dados trazidas das fontes, quando uma modificao percebida. Eventos data mining modelam derivaes estatsticas de dados, mantendo informaes como: dados necessrios, as fontes que os mantm, procedimentos de derivao, etc. Eventos compostos so construdos a partir de outros eventos atravs de operadores de composio como seqncia, disjuno e repetio. O exemplo a seguir ilustra uma especificao de viso ontolgica, que gera automaticamente uma instncia de evento de domnio:
DATA VIEW Notcias (notcia_URL, categoria_tecnolgica, nome_companhia) = select URL, categorias-tecnolgicas, companhia from Publicidade

136

where companhia = Microsoft using PAI ontology;

O efeito desta especificao a criao de uma viso materializada de nome Notcias, com alguns atributos da entidade Publicidade e de um evento de monitorao da fonte de dados respectiva e tambm de propagao de atualizaes feitas na viso. A ontologia de anlise d suporte intercomunicao de agentes durante tarefas de anlise de dados. Toda vez que um agente de execuo de tarefa realiza uma operao de anlise, ele cria uma instncia de uma atividade analtica da ontologia (inicializa a operao), especificando os recursos de dados, filtragens a serem feitas, pr-processamento dos dados e algoritmos de anlise necessrios. Um exemplo de entidade desta ontologia, muito utilizada em tarefas InfoSleuth, a anlise de deteco de desvio, que detecta desvios em uma corrente de valores numricos. Baseia-se em anlises de desvio padro de expectncias, como por exemplo, expectncia = mdia e desvio padro = [-2x mdia, +2x mdia].

11.5.2 Arquitetura Baseada em Agentes

InfoSleuth apresenta diversas classes funcionais de agentes. Cada classe representa um determinado tipo de atividade no sistema, sendo que certos agentes podem atuar em mais de uma classe. A figura 11.8 mostra estas classes funcionais. Sempre que uma tarefa deve ser executada pelo sistema, um conjunto de agentes selecionado e organizado em um grafo de fluxo onde vrtices representam agentes que realizam alguma transformao nos dados e arcos indicam os dados sendo transmitidos. Padres de planos de tarefas so disponibilizados pelo sistema para ajudar na montagem dos grafos, sendo incumbncia dos agentes intermedirios instanciar agentes que possam resolver a tarefa solicitada. Um agente escolhido caso tenha condies de prover uma capacidade (operao sobre dados) sobre elementos do domnio ontolgico para produzir outros elementos do mesmo domnio. Essas informaes fazem parte da definio dos agentes. A dinmica de execuo de tarefas a seguinte: entra uma solicitao na rede de agentes atravs de um agente de usurio, especificando o domnio de interesse mais a operao desejada. Esta solicitao capturada por um agente de execuo de tarefa, que a avalia e a associa com um padro de plano de tarefa. O agente intermedirio instancia o plano com os agentes necessrios, sendo que, toda vez que agentes entram, saem ou modificam suas capacidades, o plano reavaliado e ajustado para continuar operando. Os dados do resultado gerados so passados ao agente de usurio. Agentes de recursos atuam como wrappers, trazendo informao das fontes de dados como recursos adequados ao modelo ontolgico. Cada agente de recurso apresenta, na sua definio, as suas capacidades, ou seja, o fragmento ontolgico que sabe extrair de uma determinada fonte. Pode aceitar tanto consultas como solicitaes de notificao de mudanas caso uma viso materializada tenha mudado na fonte. Para a ontologia descrita na seo anterior, exemplos de especificaes de capacidades de agentes de recursos podem ser:
R1 ConsumoEletrnico (nome, companhia, categorias-tecnolgicas, categorias-eletrnicas) R2 Produto (nome, companhia, categorias-tecnolgicas) with constraint companhia = Microsoft

137

O agente R1 tem capacidade de extrair as seguintes informaes sobre fatos relacionados a bens de consumo eletrnico: nome, companhia, categorias tecnolgicas e categorias eletrnicas. O agente R2 tem capacidade de extrair informaes sobre produtos da companhia Microsoft. Agentes monitoram suas fontes de dados para manter atualizadas as suas especificaes de capacidade.

FIGURA 11.8 Classes de agentes de InfoSleuth Agentes de consulta multi-recurso atuam como mediadores, sendo responsveis pelo processamento distribudo de consultas e integrao de resultados enviados pelos agentes de recursos. Decompem uma consulta em diversas subconsultas que buscam fragmentos horizontais (instncias) e verticais (partes de atributos) conforme as capacidades dos agentes de recursos. Heursticas de processamento de consulta so empregadas para minimizar o volume de dados a ser tratado. Para tanto, planos de consulta so montados e tcnicas de otimizao aplicadas. Agentes data mining e agentes sentinelas suportam notificaes desejadas pelos usurios sobre a forma como os dados esto se co-relacionando/modificando ou execues de eventos de monitorao sobre vises ontolgicas. Exemplos de notificaes de usurio podem ser: Notifique-me se as companhias Netscape e Microsoft tm um colaborador em comum e Notifique-me se os anncios de tecnologia de banco de dados das companhias Oracle e Informix esto mais ativas que o normal. Agentes data mining recebem eventos da ontologia de eventos de anlise como entrada (uma notificao tambm um evento), retornando anlises estatsticas e sumrios dos dados. Agentes sentinelas tm uma funcionalidade mais ampla, pois monitoram no apenas eventos de anlise, mas tambm eventos de domnio e compostos. Podem, inclusive, ativar agentes data mining, caso parte da execuo de um evento exija uma atividade de anlise. Ambos interagem com agentes de

138

recursos para obter dados. Agentes sentinelas enviam tambm notificaes de mudanas em vises.

11.5.2 Acesso a Dados de Documentos

Ontologias de domnio em InfoSleuth tm uma caracterstica indicativa, semelhante a um data guide. Atributos de entidades so usados como uma lista de evidncias que podem ser pesquisados no corpo do texto de documentos na Internet. Consultas so especificadas, a nvel de usurio, em SQL, sendo retornados documentos ou tuplas referentes aos dados solicitados. No caso de dados textuais, toda entidade ontolgica apresenta um relacionamento chamado has_document, que a relaciona com documentos em que est presente. InfoSleuth utiliza uma mquina de RI para o acesso a dados de documentos, composta por diversos operadores de consulta que podem ser combinados para aumentar a expressividade das pesquisas. Estes operadores so: <word> (w1): verifica se w1 uma palavra no corpo do texto; <phrase> (w1, w2, ..., wn): verifica se w1, w2, ..., wn formam uma frase (em alguma ordem) no corpo do texto; <sentence> (w1, w2, ..., wn): verifica se w1, w2, ..., wn aparecem em alguma sentena (em alguma ordem) no corpo do texto; <thesaurus> (w1): verifica se uma expanso a nvel de Thesaurus aparece no corpo do texto para w1; <stem> (w1): verifica se algum radical de w1 aparece no corpo do texto; <topic> (t1): tpico que pode ser predefinido utilizando uma combinao de operadores; <accrue> (t1, t2, ..., tn): verifica se os tpicos t1, t2, ..., tn aparecem no corpo do texto, podendo cada um deles ter um peso associado.

Cada componente de um diagrama ER pode ter associado uma expresso de tpico (ET), que so operadores <accrue> utilizados para consultar colees de documentos baseado em contedo. Supondo um domnio de relaes poltico-partidrias, um exemplo de diagrama ER e suas correspondentes ETs mostrado na figura 11.9. ETs para atributos e relacionamentos so ditos parametrizados pois dependem do contexto da consulta que se refere a eles. No caso do atributo profisso, por exemplo, um predicado de seleo na consulta pode ser profisso = presidente, o que conduz a uma busca por padro onde o contedo de <input> substitudo por presidente. Agentes de recursos responsveis pelo acesso a dados textuais recebem consultas sobre entidades ontolgicas em SQL e realizam um mapeamento para uma ET geral a ser submetida mquina de RI. Esta ET geral uma combinao das ETs de todos os elementos da ontologia envolvidos na consulta. Por exemplo, a seguinte consulta busca documentos referentes ao presidente Fernando Henrique Cardoso:

139

FIGURA 11.9 - Exemplos de expresses de tpicos associados a elementos da ontologia

select has_document from Pessoa where nome = Fernando Henrique Cardoso and profisso = presidente

Esta consulta refere-se entidade pessoa e aos atributos nome e profisso. Esses elementos apresentam os seguintes ETs:
Entidade pessoa => <TOPIC> (pessoa) Atributo pessoa.nome => <PHRASE> (<input>) Atributo pessoa.profisso => <ACCRUE> (<SENTENCE> [pessoa.nome], <STEM> (indicado) ... )

Com base nestas ETs, a ET geral gerada :

<ACCRUE> ( <TOPIC> (pessoa), <PHRASE> (<WORD> (Fernando) <WORD> (Henrique) <WORD> (Cardoso)), <ACCRUE> (<SENTENCE> (<PHRASE> (<WORD> (Fernando) <WORD> (Henrique) <WORD> (Cardoso)), <STEM> (indicado), <WORD> (presidente)) ... ) )

Esse processo de mapeamento suporta ainda certos tipos de juno (que podem ser derivadas atravs dos atributos de entidades presentes nas ETs dos relacionamentos) e heursticas para determinao de prioridades na ordem de aplicao de predicados de seleo sobre atributos. No h suporte de mapeamento para projeo de atributos do resultado, o que exige um ps-processamento sobre padres de texto retornados que possam ser associados s ETs destes atributos. O suporte a junes explcitas em consultas est sendo estudado e implementado.

11.6 MOMIS
MOMIS (Mediator envirOnment for Multiple Information Sources ) um ambiente para integrao e consulta a fontes de dados estruturados e semi-estruturados, em desenvolvimento na Universidade de Modena, Itlia [Ber99]. Uma abordagem baseada em

140

um modelo conceitual utilizada para a integrao de informao de fontes de dados, cuja arquitetura apresenta as seguintes caractersticas: Um modelo conceitual ou ontolgico OO especificado na linguagem ODL I3, uma linguagem padro de mediao do grupo I3/POB, que introduz construtores para suportar integrao semntica; Wrappers para traduo de esquemas em representaes ODLI3; Componentes mediador e processador de consultas, baseado em duas ferramentas j disponveis: ARTEMIS e ODB-Tools.

A base de informao do sistema um Thesaurus que serve como uma ontologia compartilhada para as fontes de dados. Esta ontologia descrita na LD OLDC a partir de descries ODLI3. Como exemplo, pode-se imaginar um domnio hospitalar, na qual se deseja integrar dados de dois departamentos: cardiologia (fonte semi-estruturada) e de tratamento intensivo (BD relacional). A figura 11.10 ilustra dados dessas duas fontes, respectivamente: em (a) temos dados semi-estruturados em um modelo estilo OEM e em (b) um conjunto de tabelas. Esse exemplo utilizado para explicar o processo de gerao da ontologia compartilhada.

(a)
Paciente (cdigo, primeiro_nome, sobrenome, endereo, teste, id_doutor) Doutor (id, primeiro_nome, sobrenome, fone, endereo, disponibilidade, cargo) Teste (nmero, tipo, data, laboratrio, resultado) PacienteDispensado (cdigo, data, observaes)

(b) FIGURA 11.10 - Exemplos de dados de uma fonte semi-estruturada (a) e estruturada (b) para um domnio hospitalar

141

11.6.1 Construo da Ontologia Compartilhada

A integrao de dados exige que os dados de fontes semi-estruturadas sejam organizados em uma estrutura chamada padro de objeto. Um padro de objeto uma classe que corresponde a um rtulo estruturado do grafo OEM e seus atributos. Para os dados da figura 11.10, geram-se os seguintes padres de objetos:
PadroPaciente (Paciente, {nome, endereo, exame*, quarto, leito, terapia*, mdico*}) PadroMdico (Mdico, {nome, endereo, fone, especialidade}) PadroEnfermeira (Enfermeira, {nome, endereo, nvel, paciente}) PadroExame (Exame, {data, tipo, resultado})

Aps este procedimento, traduz-se classes de padres de objetos e relaes de fontes estruturadas para classes ODLI3. ODLI3 possui construtores especficos para lidar com dados semi-estruturados: unio (clusula union - expressa estruturas de dados alternativas, como por exemplo, endereo como string ou como valor composto) e opcionalidade (smbolo * indica que um atributo pode ser opcional em algumas instncias). Classes ODL I3 so, em seguida, traduzidas para a LD OLCD. Um exemplo de especificao ODL I3 para a classe Paciente no departamento de Cardiologia a seguinte:
Interface Paciente (source semistructured Departamento-Cardiologia) { attribute string nome; attribute string endereo; attribute set<Exame> exame*; attribute integer quarto; attribute integer leito; attribute string terapia*; attribute set<Mdico> mdico*; };

Para a definio do Thesaurus, deve-se descrever trs tipos de relacionamentos terminolgicos entre termos: sinnimo-de (t1 SYN t2), termo-mais-geral-que (t1 BT t2) e termo-relacionado-a (t1 RT t2). O relacionamento simtrico termo-mais-geral-que termo-mais-especfico-que (t1 NT t2). A descoberta destes relacionamentos uma tarefa semi-automtica feita com o auxlio da ferramenta ODB-Tools. Os quatro passos de definio do Thesaurus ou da ontologia compartilhada so os seguintes: Passo 1: extrao automtica de relacionamentos (via ODB-Tools) A partir de especificaes OLCD, extraem-se relacionamentos BT e NT diretamente das hierarquias de herana e relacionamentos RT das hierarquias de agregao. Outros relacionamentos RT so extrados de especificaes de chaves estrangeiras. Quando uma chave estrangeira tambm primria, tanto na relao original quanto na referida, relacionamentos BT e NT so tambm extrados. Outros relacionamentos, para classes e atributos, podem ser automaticamente extrados com o auxlio do sistema lxico WordNet, sendo estes relacionamentos apresentados ao projetista para confirmao.

142

O resultado deste passo, para os dados exemplo, considerando o departamento de Cardiologia como sendo DC e o departamento de Tratamento Intensivo como sendo DT, so: <DT.Paciente RT DT.Doutor>, <DC.Enfermeira RT DC.Paciente>, <DC.Paciente RT DC.Mdico>, <DC.Paciente RT DC.Exame>, <DT.Paciente BT DT.PacienteDispensado>, <DT.Paciente RT DT.Teste> . Os relacionamentos derivados a partir de WordNet so: <DT.Doutor BT DC.Mdico>, <DT.Teste SYN
DC.Exame>, <DC.Paciente.nome DT.Paciente.sobremone>. BT DT.Paciente.primeiro_nome>, <DC.Paciente.nome BT

Passo 2: Integrao e reviso de relacionamentos Neste momento, o projetista pode inserir novos relacionamentos para classes e atributos, considerando a sua experincia no domnio do conhecimento. Os novos relacionamentos so: <DT.Doutor BT CD.Enfermeira>, <DT.Paciente SYN DC.Paciente>,
<DC.Paciente.mdico BT DT.Paciente.id_doutor>, <DC.Exame.resultado SYN DT.Teste.resultado>. <DC.Enfermeira.nvel SYN DT.Doutor.cargo>,

Ainda neste passo gerado um esquema virtual, resultante da reviso de relacionamentos. O objetivo promover relacionamentos terminolgicos para relacionamentos semnticos atravs da resoluo de conflitos estruturais: SYN para equivalncia, BT para generalizao e RT para agregao. Neste esquema, descries de classes so reescritas da seguinte forma: para relacionamentos SYN, uniformiza-se a estrutura das classes. Para relacionamentos BT, adiciona-se os atributos da classe genrica especializada e, para relacionamentos RT, um novo atributo de agregao definido nas duas classes relacionadas. Passo 3: Validao de relacionamentos (via ODB-Tools) Neste passo, realizado de forma automtica, validam-se os relacionamentos presentes no esquema virtual atravs de uma anlise de compatibilidade de domnios de atributos, gerando indicaes de relacionamentos vlidos (1) ou invlidos (0). Assim, dados dois atributos Ai e Aj, com domnios respectivos di e dj, valem as seguintes regras: <Ai SYN Aj>: vlido se di dj ou se um domnio especializao de outro; <Ai BT Aj>: vlido se di dj; <Ai NT Aj>: vlido se di dj.

Caso um domnio di for do tipo union, um relacionamento vlido se pelo menos o domnio de um dos componentes de di for compatvel com dj. Relacionamentos marcados como invlidos mesmo assim so mantidos na ontologia pois podero vir a se tornar vlidos caso mudanas ocorram nas definies dos dados. Alguns exemplos de marcaes feitas so as seguintes:
<DC.Paciente.mdico BT DT.Paciente.id_doutor> <DC.Paciente.nome BT DT.Paciente.primeiro_nome> <DC.Paciente.nome BT DT.Paciente.sobrenome> <DC.Enfermeira.nvel SYN DT.Doutor.cargo> <DC.Exame.resultado SYN DT.Teste.resultado> [0] [1] [1] [0] [1]

143

Passo 4: Inferncia de novos relacionamentos (via ODB-Tools) Novos relacionamentos de generalizao/especializao e agregao so definidos atravs da aplicao de mecanismos de inferncia sobre o esquema virtual. Como resultado, tem-se: <DT.Paciente RT DC.Mdico>, <DT.Paciente RT DC.Exame>, <DC.Paciente RT DT.Doutor>,
<DC.Paciente RT DT.Teste>, <DT.PacienteDispensado RT DT.Doutor>, <DT.PacienteDispensado RT DT.Teste>, <DT.PacienteDispensado RT DT.Doutor>, <DT.PacienteDispensado RT DC.Mdico> .

A ontologia compartilhada gerada aps a execuo destes passos vista na figura 11.11, com indicao dos relacionamentos apenas entre classes. Relacionamentos inferidos so indicados por linhas tracejadas.

11.6.2 Construo da Viso Integrada de Mediao

A ontologia definida apresenta conceitos relacionados de diferentes fontes de dados. Porm, a definio de um esquema global (viso integrada de dados) fundamental para se ter uma interface uniforme para fins de consulta. O gerenciamento deste esquema fica a cargo do mdulo mediador de MOMIS.

FIGURA 11.11 - Ontologia compartilhada gerada para um domnio hospitalar Para tanto, so associados coeficientes de afinidade (valores entre 0 e 1) a relacionamentos entre classes ontolgicas de fontes de dados diferentes, com base nos seus nomes e seus atributos. Em seguida, um procedimento de clusterizao hierrquica classifica as classes de acordo com estes coeficientes, gerando uma rvore de afinidade que tem classes como folhas e nodos intermedirios com um valor de afinidade associado as classes do seu cluster (subrvore). A determinao dos coeficientes e da rvore de afinidade so tarefas da ferramenta ARTEMIS. Um exemplo de rvore de afinidade para o domnio hospitalar mostrado na figura 11.12. Na seqncia, um procedimento de determinao de esquemas globais executado interativamente com o projetista. Este procedimento possui dois passos:

144

FIGURA 11.12 - rvore de afinidade para o domnio hospitalar exemplo 1. Para cada cluster Cli definido pelo projetista associa-se uma classe global Ci. Os atributos de Ci resultam da aplicao das seguintes regras aplicadas sobre relacionamentos vlidos: Para atributos com relacionamento SYN, apenas um deles selecionado como atributo global; Para atributos com relacionamento BT/NT, o atributo mais geral em Cli selecionado como atributo global. Por exemplo, para o cluster Cl1, o seguinte conjunto de atributos globais produzido: nome, cdigo, endereo, exame*, quarto, leito, terapia*, data, observao e mdico*; 2. Definem-se regras de mapeamento para atributos globais para os atributos locais presentes nas classes de Cli, inclusive com indicao de valores defaults e nulos. O esquema global do mediador ento composto pelas classes globais geradas para todos os clusters. Regras de integridade tambm podem ser especificadas para cada classe global, para expressar relacionamentos semnticos entre fontes de dados diferentes. Um exemplo parcial de classe global com uma regra de integridade associada a classe Hospital_Paciente (definida em correspondncia ao cluster Cl1 da figura 11.12):
Interface Hospital_Paciente { attribute nome mapping_rule (DT.Paciente.primeiro_nome and DT.Paciente.sobrenome), DC.Paciente.nome; attribute mdico mapping_rule DC.Paciente.mdico, DT.Paciente.id_doutor; attribute departamento mapping_rule DC.Paciente = Cardiologia, DT.Paciente = Tratamento Intensivo, DT.PacienteDispensado = Tratamento Intensivo } rule R1 forall X in Hospital_Paciente: (X.Exame.resultado = problemas corao) then X.departamento = Cardiologia;

145

11.6.3 Otimizao de Consultas Globais

O processador de consultas de MOMIS transforma uma consulta global a nvel de usurio Q em uma consuta Q que incorpora restries implcitas descritas nas regras de integridade das classes globais envolvidas na consulta. Esse processo adiciona predicados extras na clusula where. Essa adio otimiza o processamento pois pode limitar a traduo de Q para consultas locais associadas a cada fonte de dados: uma consulta local gerada se e somente se todos os atributos da clusula where tm uma correspondncia no nula no esquema da fonte de dados. Isto verificado atravs das regras de mapeamento. Por exemplo, suponha a seguinte consulta global Q, que busca nomes de pacientes com resultado de exame igual a problemas corao: Q: select nome from Hospital_Paciente where Exame.resultado = problemas corao; Aplicando a regra de integridade R1 da classe global Hospital_Paciente, Q expandida para Q: Q: select nome from Hospital_Paciente where Exame.resultado = problemas corao and departamento = Cardiologia; Aps, deve-se traduzir Q para subconsultas nas fontes de dados envolvidas. Neste caso, trs classes so candidatas: DT.Paciente, DT.PacienteDispensado e CD.Paciente. As duas primeiras so eliminadas pois no atendem as regras de mapeamento para o atributo departamento.

11.7 WebKB
WebKB uma ferramenta para indexao, anotao e explorao de conhecimento em documentos da Web, em desenvolvimento na Universidade de Griffith, Austrlia [Mar99]. Para tanto, uma linguagem geral para RC utilizada, baseada no formalismo de grafos conceituais. Um grafo conceitual (GC) uma notao grfica linear que define associaes e especializaes entre termos formais predefinidos em uma ampla ontologia. WebKB define operadores aplicados a GCs e estende a sua notao para outras formas de RC como estruturas HTML, textos indentados e ingls formalizado. A arquitetura da ferramenta apresenta trs componentes: uma mquina de pesquisa para busca de texto/conhecimento, que pode gerar novos documentos, uma interface de pesquisa de texto/conhecimento em HTML, incluindo um editor de conhecimento na linguagem da ferramenta e uma ontologia nica. A ontologia foi projetada para facilitar a criao de ontologias de aplicao e a construo de comandos de conhecimento. uma extenso do BD lxico WordNet, possuindo em torno de 200 tipos de relaes bsicas entre conceitos, classificadas em relaes temticas, matemticas, espaciais, temporais, retricas e argumentativas. Tambm define prximo de 200 tipos de conceitos gerais, necessrios para representar conhecimento e assinaturas de tipos relaes. A existncia desta ontologia

146

permite categorizar semanticamente objetos criados por usurios. A figura 11.13 ilustra parte da ontologia de relaes (a) e de conceitos (b).Coisa) RelaoBinria(Coisa,
RelaoBinriaComponente(Coisa, Coisa) . . . RelaoBinriaSituao(Situao, Coisa) . . . RelaoBinriaOrdenao(Coisa, Coisa) Descrio(Situao, Descrio) RelaoBinriaProcesso(Processo, Coisa) Subprocesso(Processo,Processo)

(a)
Coisa Entidade EntidadeTemporal ... ... Situao Estado ... Processo Evento

EntidadeInformao . . . Propriedade

Descrio

(b) FIGURA 11.13 - Ontologia de relaes (a) e de conceitos (b) de WebKB WebKB utiliza abordagens lxica, estrutural e baseada em conhecimento na definio de comandos de consulta e de definio de conhecimento. A abordagem lxica utilizada para processamento de documentos da Web atravs de um comando estilo Unix chamado accessibleDocFrom, que lista documentos acessveis direta ou indiretamente a partir de um certo nmero de links. O comando exemplo a seguir lista documentos HTML acessveis a partir de uma URL seguindo at dois nveis de links e que incluam o string knowledge no seu cdigo HTML:
AccessibleDocFrom maxlevel 2 HTMLonly http://www.foo.com/foo.html | grep knowledge

As abordagens estrutural e baseada em conhecimento so empregadas na linguagem geral para RC. Atravs de tags especiais HTML (<KR> ... </KR>) ou entre os smbolos $( e )$, embutem-se comandos de especificao, indexao ou consulta a conhecimento em documentos da Web. Os termos da ontologia so utilizados nestes comandos para definir ocorrncias de relaes ou conceitos. Essa estratgia procura aproximar a definio do conhecimento da fonte de dados em que ele se encontra. A figura 11.14 mostra um trecho de cdigo de um documento HTML (a) onde esto especificadas, na linguagem de WebKB, relaes entre o conceito Barco (pontos negros) e os conceitos Ilha e Mar, para uma imagem (campo alt) litornea (b) presente neste documento. Indexao pode ser aplicada a qualquer elemento de um documento textual ou HTML, seja ele uma sentena, seo, referncia, imagem, o documento completo, etc. O trecho de cdigo na seqncia define uma indexao sobre a segunda ocorrncia da sentena o veculo vermelho presente em um documento HTML:

147

... <h4> Ilhas e Praias: </h4> <p> <KR language = GC> <img src = http://meganesia.int.gu.edu/au/praia.gif (a) (b) alt = [Barco] { (Prximo) -> [Ilha]; FIGURA 11.14 - Trecho de cdigo de um documento HTML (a) onde esto (Sobre) -> [Mar]; definidos }> conceitos e relaes na linguagem de WebKB referentes a uma imagem (b) presente no documento </KR> ... $ (Indexation (Context: Language: GC; Ontology: http://www.bar.com/topLevelOntology.html; Repr_author: phmartin; Creation_date: Mon sep 14 02:32:21 PDT 1998; Indexed_doc: http://www.bar.com/exemplo.html; ) (DE: (2nd occurence) o veculo vermelho) (Repr: [Cor: vermelha] <- (Cor) <- [Veculo]) )$

A interface grfica de WebKB permite a formulao de consultas atravs da seleo de termos da ontologia e especificao de restries para seleo. Especificaes na linguagem de WebKB para consulta a GC so gerados e executados, podendo trazer como resultado qualquer estrutura de dados ou mesmo um documento completo, indicado atravs de hiperlinks que podem ser selecionados. A especificao indicada no campo Repr do trecho de cdigo anterior um exemplo de consulta que pode buscar imagens ou documentos completos onde exista informao a respeito de veculos vermelhos. Outras caractersticas interessantes da ferramenta so a possibilidade de definio de comandos de gerao de conhecimento e o embutimento de comandos de consulta em documentos. No primeiro caso, possvel a criao de bases de conhecimento formados por GCs, que so, na verdade, especializaes de termos da ontologia ou instncias de termos. No segundo caso, pode-se associar uma consulta a um link presente em um documento HTML e, quando este link ativado, a consulta processada, gerando um documento HTML (documento virtual) com a estrutura de resultado da consulta. A gerao de documentos virtuais interessante para melhor adaptar o contedo do documento semntica da ontologia, facilitando a compreenso das informaes para o usurio.

11.8 Anlise das Propostas

148

As propostas apresentadas nas sees anteriores apresentam vrias caractersticas no que diz repseito ao software desenvolvido e as abordagens de aplicao de ontologias. A tabela 11.1 compara essas caractersticas entre as propostas. Cabe salientar que algumas caractersticas, embora no explicitamente descritas nas propostas, foram deduzidas com base na arquitetura dos softwares. Por exemplo, o fato de ontologias existentes servirem de base para novas uma vantagem inerente a ontologias, ainda mais se existe um BD que mantm a sua definio. Esta deduo vale, por exemplo, para a Proposta de Embley e InfoSleuth. TABELA 11.1 Comparao entre as propostas de aplicao de ontologias a BDSEs
Observer Tipo software de
Sistema de informao global Servidor de ontologias; Gerenciador de relacionamentos inter ontologias; Processador de consultas Nvel superior; Domnio

SHOE
Ambiente para anotao e consulta Ferramenta de anotao; Browser de documentos; BC

Ontobroker
Ferramenta de anotao e consulta

Proposta de Embley
Mdulo de extrao de dados Parser da ontologia; Reconhecedor de constantes e palavraschave; Gerador de texto estruturado

InfoSleuth
Sistema de manipulao de dados semiestruturados Funcionalidade baseada em agentes para interao com o usurio, processamentos de consultas, controle de atualizao, operaes analticas e de data mining Domnio; Tarefa; Aplicao

MOMIS
Ambiente para integrao e consulta Modelo conceitual OO; Wrappers; Mediadores; Processador de consultas

WebKB
Ferramenta de anotao, indexao e consulta Mquina de consulta; BD

Arquitetura

Mquina de consulta; BD; Agente de informao; Mquina de inferncia

Tipos de ontologia suportados Elementos ontolgicos mantidos

Domnio

Domnio

Domnio

Domnio

Conceitos; Relaes; Regras de mapeamento para fontes de dados

Conceitos; Relaes; Regras de inferncia

Conceitos; Relaes; Regras de inferncia

Conceitos; Relaes

Funes para as quais a ontologia fornece suporte semntico

Processa mento de consultas; Esquema conceitual

Anotao de conhecimento; Inferncia de conhecimento; Esquema conceitual

Anotao de conhecimento; Inferncia de conhecimento; Esquema conceitual

Extrao de conhecimento; Esquema conceitual

Requisitos do domnio; Ontologias existentes M:N

Conceitos; Relaes; Processos de anlise; Eventos; Padres para consulta a documentos Processamento de consultas; Processamento de atualizaes e anlises; Esquema conceitual Requisitos do domnio; Ontologias existentes M:N

Conceitos; Relaes; Regras de mapeamento para fontes de dados; Restries de integridade Processa mento de consultas; Esquema conceitual

Nvel superior; Domnio; Tarefa; Aplicao Conceitos; Relaes

Anotao de conhecimento; Indexao de conhecimento; Esquema conceitual

Base para definio de ontologias Relao ontologia fonte dados

Requisitos domnio

do

Requisitos do domnio; Ontologias existentes M:N

Requisitos do domnio; Ontologias existentes 1:N

Fontes de dados

Requisitos do domnio; Ontologia nica 1:N

1:N

1:N

149

Em termos de softwares apresentados, tem-se desde sistemas de grande porte, como Observer, at mdulos destinados a uma dada tarefa que utiliza ontologias, como a Proposta de Embley. Suas arquiteturas refletem, obviamente, os seus objetivos, sendo comum grande maioria a existncia de mdulos de consulta baseada em ontologias para dados Web (aplicao mais comum de ontologias). Quanto complexidade da arquitetura, alguns softwares se destacam. Observer apresenta um mecanismo sofisticado baseado em ontologias para aumentar a escalabilidade de consultas em fontes de dados heterogneas. A manuteno de relacionamentos inter-ontologias permite ao processador de consultas expandir uma consulta para outras ontologias com traduo automtica de termos. A Proposta de Embley gera, a partir de um domnio ontolgico, esquemas estruturados e regras para extrao de conhecimento de documentos, sendo este conhecimento adequado ao esquema gerado. InfoSleuth gerencia atualizaes alm de consultas, mantendo a consistncia entre instncias ontolgicas materializadas e as fontes de dados de onde as mesmas advm. Esta funcionalidade caracterstica nica de Infosleuth. Ainda, diversas propostas materializam o conhecimento de fontes estruturadas e semi-estruturadas em BDs ou vises, para facilitar a realizao de consultas, como o caso de SHOE, Ontobroker, InfoSleuth e WebKB. Porm, nem todas elas apresentam solues para a garantia de consistncia destes dados materializados, como SHOE. As ontologias definidas diferem principalmente em termos de tipos e elementos definidos. Ontologias de domnio esto presentes em todas as propostas, pois refletem diretamente os requisitos de dados e funes de qualquer software. Alguns sistemas, como WebKB, apresentam ontologias de nvel superior predefinidas como base para novas ontologias. a nica proposta que permite a definio de todos os tipos de ontologias. InfoSleuth, ao contrrio da maioria das propostas, que definem apenas conceitos e relaes, o sistema mais sofisticado em termos de elementos ontolgicos suportados, permitindo que ontologias de tarefas compostas por procedimentos analticos e eventos sejam definidos. Outras propostas definem regras associadas a conceitos e relaes. SHOE e Ontobroker, por exemplo, descrevem regras para inferncia de conhecimento. Em MOMIS, o projetista pode especificar restries de integridade a elementos ontolgicos, tornando a ontologia muito semelhante descrio de um esquema de BD. Quanto relao ontologia-fonte de dados, o enfoque mais natural e flexvel a possibilidade do conhecimento de uma fonte de dados estar associado a diversos domnios, ou seja, ter diversas interpretaes semnticas. Algumas propostas, porm, restringem esta relao para o caso 1:N, considerando apenas documentos especficos de um certo domnio, como MOMIS e Ontobroker. Observer mantm o mapeamento do conhecimento de uma fonte de dados para apenas uma ontologia, porm, este conhecimento pode ser traduzido para termos de outras ontologias relacionadas. A definio de ontologias segue, na maioria dos casos, princpios bsicos como uma especificao de requisitos do domnio alvo e o reuso de ontologias pr-existentes. Observer a nica proposta que no leva em conta integrao de ontologias no processo de definio. Apenas relaciona, posteriormente, termos de uma nova ontologia com os termos de outras. MOMIS merece destaque neste critrio de comparao pois a nica proposta que constri ontologias a partir das definies de fontes de dados semi-estruturados e estruturados, aplicando um algoritmo de extrao e combinao de dados. Quanto ao propsito de aplicao de ontologias, comum a todas as propostas a utilizao de ontologias como esquemas conceituais a partir do qual consultas com carter

150

semntico podem ser formuladas. Observer, InfoSleuth e MOMIS empregam ontologias no processamento de consultas para, respectivamente, expandir uma consulta a vrias conceitualizaes semanticamete relacionadas, realizar consultas por contedo a documentos fracamente estruturados e restringir fontes de dados a serem pesquisadas atravs da aplicao de restries de integridade associadas a elementos ontolgicos. SHOE, Ontobroker e WebKB utilizam ontologias como base semntica para a anotao de conhecimento em documentos da Web em formatos como HTML e XML. Estes documentos so posteriormente investigados e seu conhecimento armazenado em um BD, para fins de consulta. SHOE e Ontobroker realizam ainda inferncia sobre conhecimento armazenado em termos de descoberta de relacionamentos de herana. WebKB permite a especificao de ndices de elementos ontolgicos associados a trechos de documentos. A principal fraqueza destas abordagens que apenas documentos novos ou com permisso de escrita so passveis de anotao, o que no se aplica a maioria dos documentos j existentes. SHOE tanta contornar este problema atravs da criao de pginas de sumrio, com anotaes semnticas para pginas j existentes. Por fim, InfoSleuth se destaca pelo emprego de ontologias como suporte para a dinmica de aplicaes, definindo eventos e procedimentos de anlise associados a conceitos, responsveis, muitas vezes, pela manuteno de consistncia de atualizaes de dados.

151

12 Concluso
Ontologia um conceito que vem se tornando popular em Cincia da Computao pois prov um entendimento comum e compartilhado de algum domnio que pode ser comunicado entre pessoas e computadores, possibilitando reuso de conhecimento. Na prtica, ontologias desenvolvidas dizem respeito principalmente modelos estticos de conhecimento para domnios especficos, representados por hierarquias de herana de conceitos, relaes, atributos e instncias atravs de formalismos OO ou baseados em lgica de primeira ordem. Poucas propostas levam em conta aspectos dinmicos e a noo de ontologia como mantenedora de conhecimento universal, independente do seu uso. O uso pioneiro de ontologias em IA, que analisa fontes de dados usando tcnicas de RC, por exemplo, motivou a sua aplicao em BDSEs. A definio de um domnio de representao de dados facilita a legibilidade e a preciso de acesso a dados semiestruturados. O captulo anterior mostrou um panorama da aplicao de ontologias no tratamento de dados semi-estruturados. Como pode ser constatado, a finalidade bsica de uma ontologia servir como um esquema conceitual que d suporte semntico a consultas. A conceitualizao definida em uma ontologia ou anotada diretamente nos dados das fontes ou extrada atravs de wrappers e mediadores. Algumas propostas tambm a empregam no processamento de consultas e extrao de dados semi-estruturados atravs de regras de mapeamento de conceitualizaes, regras de integridade e heursticas voltadas a domnios especficos. Ainda, em alguns casos, ontologias descrevem metadados como conceitos e relaes de alto nvel de abstrao para facilitar o desenvolvimento de ontologias de domnio, de tarefas e de aplicaes. Porm, no consenso a vinculao de novas ontologias a uma nica e ampla ontologia universal, devido a problemas como o uso imposto de um vocabulrio global, manuteno de consistncia e outros. A maioria das propostas prefere lidar com vrias pequenas ontologias e com a possibilidade de reuso de conhecimento. Observa-se, nas propostas analisadas, que existem vrios softwares onde o usurio interage com ontologias atravs de interfaces amigveis para tarefas de especificao e consulta a dados. Porm, manipulao de ontologias um tema que carece, na literatura, de propostas que digam respeito atualizao, controle de consistncia entre instncias ontolgicas, fontes de dados e ontologias relacionadas, assim como restries de integridade. Estas propostas podem se valer de solues existentes nas reas de BDs distribudos e heterogneos, levando em conta que BDSEs no lidam apenas com fontes de dados que so esquemas de BDs, mas tambm com documentos que apresentam pouca ou nenhuma estruturao, por exemplo. Como comentado no incio deste captulo, segundo crena de vrios pesquisadores, a tendncia a popularizao de ontologias como meio de busca mais eficiente de dados na Internet atravs de sistemas gerenciadores de BDSEs. Esta uma importante motivao para que solues efetivas em termos de manipulao e metodologias de construo de ontologias sejam encontradas.

152

Bibliografia
[Abi97a] ABITEBOUL, S.; QUASS, D.; MCHUGH, J.; WIDOM, J.; WIENER, J.L. The Lorel Query Language for Semistructured Data. International Journal on Digital Libraries , v.1, n.1, p.68-88, Apr. 1997. [Abi97b] ABITEBOUL, S. Querying Semistructured Data. In: INTERNATIONAL CONFERENCE ON DATABASE THEORY, 1997, Delphi, Greece. Proceedings... [S.l.:s.n.]: 1997. p.1-18. [Ade99] ADELBERG, B.; DENNY, M. Building Robust Wrappers for Text Sources . Chicago: Departament of Computer Science, Northwestern University, 1999. Technical Report. [Ash97] ASHISH, N.; KNOBLOCK, C. Wrapper Generation for Semi-structured Internet Sources. SIGMOD Record, v.26, n.4, p.8-15, Dec. 1997. [Atz97a] ATZENI, P.; MECCA, G.; MERIALDO, P. To Weave the Web. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATABASES (VLDB'97), 23., 1997, Athens. Proceedings... [S.l.]: Morgan Kaufmann, 1997, p.206-215. [Atz97b] AZTENI, P.; MECCA, G.; MERIALDO, P. Semistructured and Structured Data in the Web: Going Back and Forth. SIGMOD Record, v.26, n.4, p.16-23, Dec. 1997. [Atz97c] ATZENI, P.; MECCA, G.; MERIALDO, P. Cut and Paste. In: SIGMOD INTERNATIONAL SYMPOSIUM ON PRINCIPLES OF DATABASE SYSTEMS (PODS97), 16., Tucson, Arizona, USA. Proceedings... [S.l.:s.n.]: 1997. p.144-153. [Ber99] BERGAMASCHI, S.; CAETANO, S.; VINCINI, M. Semantic Integration of Semistructured and Structured Data Sources. SIGMOD Record, v.28, n.1, p.54-59, Mar. 1999. [Bz9?] BZIVIN, J. Whos Afraid of Ontologies? Disponvel http://www.metamodel.com/oopsla98-cdn-workshop/bezivin (agosto de 1999). por WWW em

[Bor95] BORGIDA, A Description Logics in Data Management. IEEE Transactions on Knowledge and Data Engineering, v.7, n.5, p.1-15. Oct. 1999. [Bun97] BUNEMAN, P. Semistructured Data. In: SIGMOD INTERNATIONAL SYMPOSIUM ON PRINCIPLES OF DATABASE SYSTEMS (PODS97), 16., Tucson, Arizona, USA. Proceedings... [S.l.:s.n.]: 1997. p.117-121. [Bun96] BUNEMAN, P.; DAVIDSON, S.; HILLEBRAND, G.; SUCIU, D. A Query Language and Optimization Techniques for Unstructured Data. In: ACM SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA (SIGMOD96), Montreal, Canad. Proceedings... New York: ACM Press, 1996, p.505-516. [Cat98] CATARCI, T.; IOCCHI,.L.; NARDI,.D.; SANTUCCI, G. Accessing the Web: Exploiting the Data Base Paradigm. In: INTERDISCIPLINARY WORKSHOP ON BUILDING, MANTAINING AND USING ORGANIZATIONAL MEMORIES (OM98), 1., 1998. Brighton, UK. Proceedings... [S.l.:s.n.]: 1998. [Cra99] CRANEFIELD, S.; PURVIS, M. UML as an Ontology Modelling Language. In: IJCAII99 WORKSHOP ON INTELIGENT INFORMATION (III99), 1999, Stockholm, Sweden. Proceedings... Karlsruhe: CEUR Publications, V.23, University of Karlsruhe, 1999. [Dat91] DATE, C.J. Introduo a Sistemas de Banco de Dados. Rio de Janeiro: Campus, 4a, 1991. 674 p.

153

[Deu99] DEUTSCH, A.; FERNANDEZ, M.; FLORESCU D.; LEVY, A.; SUCIU. D. A Query Language for XML. In: WORLD WIDE WEB CONFERENCE (WWW8), 1999, Toronto, Canada. Proceedings... Toronto: University of Toronto, 1999. [Dom98] DOMINGUE, J. TADZEBAO and WEBONTO: Discussing, Browsing, and Editing Ontologies on the Web. In: KNOWLEDGE ACQUISITION FOR KNOWLEDGE-BASED SYSTEMS WORKSHOP, 11., 1998, Banff, Canada. Proceedings... [S.l.:s.n.]: 1998. [Dor00] DORNELES, C. F. Extrao de Dados de Semi-Estruturados Baseados em uma Ontologia . Porto Alegre: PGCC da UFRGS, 2000. (Dissertao de Mestrado) [Emb98a] EMBLEY, D.W.; CAMPBELL, D.M.; JIANG, Y.S.; NG, Y.-K.; SMITH, R.D. A ConceptualModelling Approach to Extracting Data from the Web. In: INTERNATIONAL CONFERENCE ON CONCEPTUAL MODELING (ER98), 17., 1998, Singapore. Proceedings... Berlin: Springer-Verlag, 1998. (Lecture Notes in Computer Science, v.1507). [Emb98b] EMBLEY, D.W.; CAMPBELL, D.M.; LIDDLE, S.W.; SMITH, R.D. Ontology-Based Extraction and Structuring of Information from Data-Rich Unstructured Documents. In: INTERNATIONAL CONFERENCE ON INFORMATION AND KNOWLEDGE MANAGEMENT, 7., 1998, Bethesda, Maryland, USA. Proceedings... New York: ACM Press, 1998. [Erd99] ERDMANN, M.; STUDER, R. Ontologies as Conceptual Models for XML Documents. In: KNOWLEDGE ACQUISITION FOR KNOWLEDGE-BASED SYSTEMS WORKSHOP, 12., 1999, Banff, Canada. Proceedings... [S.l.:s.n.]: 1999. [Far96] FARQUHAR, A.; FIKES, R.; RICE, J. The Ontolingua Server: a Tool for Collaborative Ontology Construction. Stanford: Knowledge Systems Laboratory, Stanford University, 1996. (Technical Report KSL-96-02). [Fen99] FENSEL, D.; ANGELE, J.; DECKER, S.; ERDMANN, M.; SCHNURR, H.P.; STAAB, S.; STUDER, R.; WITT, A On2broker: Semantic-Based Access to Information Sources at the WWW. In: WORLD CONFERENCE ON THE WWW AND INTERNET (WEBNET 99), 1999, Honolulu, Hawai, USA. Proceedings... [S.l.:s.n.]: 1999. [Fer97a] FERNANDEZ, M.; FLORESCU, D.; LEVY, A.; SUCIU, D. A Query Language for a Web-Site Management System. SIGMOD Record, v.26, n.3, p.4-11, Set. 1997. [Fer97b] FERNANDEZ, M.; FLORESCU, D.; KANG, J.; LEVY, A.; SUCIU, D. STRUDEL: A Web-site Management System. In: ACM SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA (SIGMOD97), 1997, Tucson, Arizona, USA. Proceedings... New York: ACM Press, 1997, p.549552. [Fer98] FERNANDEZ, M.; FLORESCU, D.; LEVY, A.; SUCIU, D. Web-Site Management: The Strudel Approach. IEEE Data Engineering Bulletin, v.21, n.2, p.14-20, 1998. [Fik] Fikes, R.E. Ontologies: What are they, and wheres the research? Disponvel por WWW em http://www-ksl.stanford.edu/KR96/FikesPositionStatement.html (setembro de 1999). [Flo98] FLORESCU & LEVY & MENDELZON. Database Techniques for the World Wide Web: A Survey. SIGMOD Record, v.27, n.3, p.59-74, Mar. 1997. [Gen92] GENESERETH, M.R.; FIKES, R.E. Knowledge Interchange Format, Version 3.0 Reference Manual. Stanford: Computer Science Departament, Stanford University, 1992. (Report Logic-92-1). [Gru91] GRUBER, T.R. Ontolingua: A Mechanism to Support Portable Ontologies . Stanford: Knowledge Systems Laboratory, Stanford University, 1991. (Technical Report KSL-91-66).

154

[Gru93] GRUBER, T.R. A Translation Approach to Portable Ontologies. Knowledge Acquisition, v.5, n.2, p.199-200, 1993. [Gua97] GUARINO, N. Understanding, Building and Using Ontologies: A Commentary to Using Explicit Ontologies in KBS Development, by van Heijst, Schreiber, and Wielinga. International Journal of Human and Computer Studies, v.46, n.2/3, p. 293-310, 1997. [Gua9?] GUARINO, N. Semantic Matching: Formal Ontological Distinctions for Information Organization, Extraction, and Integration. In: Information Extraction: A Multidisciplinary Approach to an Emerging Information Technology. Berlin: Springer Verlag, p.139-170. [Ham97] HAMMER, J.; GARCIA-MOLINA, H.; CHO, J.; ARANHA, R.; CRESPO, A. Extracting Semistructured Information from the Web. In: WORKSHOP ON MANAGEMENT OF SEMISTRUCTURED DATA, 1997, Tucson, Arizona, USA. Proceedings... New York: ACM Press, 1997, p.18-25. [Hef99] HEFLIN, J.; HENDLER, J.; LUKE, S. Applying Ontologies to the Web: A Case Study. In: INTERNATIONAL WORK-CONFERENCE ON ARTIFICIAL AND NATURAL NEURAL NETWORKS (IWANN'99), 1999. Proceedings... Berlin: Springer-Verlag, v.II, 1999, p.715-724. [Hug97] McHUGH, J.; ABITEBOUL, S.; GOLDMAN, R.; QUASS, D.; WIDOM, J. Lore: A Database Management System for Semistructured Data. SIGMOD Record, v.26, n.3, p.54-66, Sep. 1997. [Loo9?] LOOM Users Guide, version 1.4. Disponvel em WWW em http://www.isi.edu/isd/LOOM/LOOMHOME.html. (dezembro de 1999). [Kor93] KORTH, H.F.; SILBERSCHATZ, A. Sistema de Banco de Dados. So Paulo: Makron Books, 4a, 1993. 748 p. [Lak96] LAKSHMANN, L.V.S.; SADRI, F.; SUBRAMANIAN, I.N. A Declarative Language for Querying and Restructuring the Web. In: IEEE WORKSHOP ON RESEARCH ISSUES IN DATA ENGINEERING (RIDE-NDS96), 1996, New Orleans, Louisiana, USA. Proceedings... [S.l.:s.n.]: 1996. [Li99] LI, WEN-SYAN et al. WebDB Hypermidia Database System. IEICE Transactions On Information Systems, v.E00 A, n.1, Jan 1999. [Mar99] MARTIN, P.; EKLUND, P. Embedding Knowledge in Web Documents. In: WORLD WIDE WEB CONFERENCE (WWW8), 1999, Toronto, Canada. Proceedings... Toronto: University of Toronto, 1999. [Mec98a] MECCA, G.; ATZENI, P.; MASCI, A; MERIALDO, P.; SINDONI, G. The ARANEUS Web-Base Management System. In: ACM SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA (SIGMOD98), 1998, Seattle, Washington, USA. Proceedings... New York: ACM Press, 1998, p.544-546. [Mec98] MECCA, G.; ATZENI, P.; MASCI, A; MERIALDO, P.; SINDONI, G. From Databases to WebBases: The ARANEUS Experience. Roma: Universit Degli Studi di Roma Tre, 1998. 25p. (Relatrio Tcnico RT-DIA-34-1998). [Men97] MENDELZON, A. O.; MIHAILA, G. A.; MILO, T. Querying the World Wide Web. International Journal on Digital Libraries, v.1, n.1, p. 54-67, Apr. 1997. [Nes97] NESTOROV, S.; ABITEBOUL, S.; MOTWANI, R. Inferring Structure in Semistructured Data. SIGMOD Record, v.26, n.4, p.39-43, Dec. 1997.

155

[Nie98] NIETO, E.M. OBSERVER: An Approach for Query Processing in Global Information Systems based on Interoperation across Pre-existing Ontologies . Zaragoza: Departamento de Informtica e Ingeniera de Sistemas, Universidad de Zaragoza, 1998. 200p. (Tesis Doctoral). [Pap95] PAPAKONSTANTINOU, Y.; GARCIA-MOLINA, H.; WIDOM, J. Object Exchange Across Heterogeneous Information Sources. In: INTERNATIONAL CONFERENCE ON DATA ENGINEERING, Taipei, Taiwan. Proceedings... [S.l.:s.n.]: 1995, p.251-260. [Paz98] PAZZAGLIA, J.C.R.; EMBURRY, S.M. Bottom-Up Integration of Ontologies in a Database Context. In: KNOWLEDGE REPRESENTATION MEETS DATABASES (KRDB98), 5., 1998, Seattle, Washington, USA. Proceedings... Karlsruhe: CEUR Publications, University of Karlsruhe, 1998, p.7-1/77. [Per98] PERRY, B.; TAYLOR, M.; UNRUH, A. Information Aggregation and Agent Interaction Patterns in InfoSleuth. Austin: Microeletronics and Computer Technology Corporation, Texas, 1998. (Technical Report MCC-INSL-104-98). [Sin98] SINDONI, G. Incremental Maintenance of Hypertext Views. In: WORKSHOP ON THE WEB AND DATABASES (WebDB98), Valencia, Spain, 1998. Proceedings... Berlin: Springer Verlag. 1998. [Smi9?] SMITH, D.; LOPEZ, M. Information Extraction for Semi-Structured Documents . Disponvel por WWW em http://www.inria.com/infoextractor. [Suc97] SUCIU, D. Management of Semistructured Data. SIGMOD Record, v.26, n.4, p.4-7, Dec. 1997. [Swa96a] SWARTOUT, B.; PATIL, R.; KNIGHT, K.; RUSS, T. Ontossaurus: A Tool for Browsing and Editing Ontologies. In: KNOWLEDGE ACQUISITION FOR KNOWLEDGE-BASED SYSTEMS WORKSHOP, 10., 1996, Banff, Canada. Proceedings... [S.l.:s.n.]: 1996. [Swa96b] SWARTOUT, B.; PATIL, R.; KNIGHT, K.; RUSS, T. Toward Distributed Use of Large Scale Ontologies. In: KNOWLEDGE ACQUISITION FOR KNOWLEDGE-BASED SYSTEMS WORKSHOP, 10., 1996, Banff, Canada. Proceedings... [S.l.:s.n.]: 1996. [Unr98] UNRUH, A.; MARTIN, G.; PERRY, B. Getting Only What You Want: Data Mining and Event Detection Using InfoSleuth Agents. Austin: Microeletronics and Computer Technology Corporation., 1998. (Technical Report MCC-INSL-113-98). [Usc97] USCHOLD, M.; KING, M.; MORALEE, S.; ZORGIOS, Y. The Enterprise Ontology, Edimburgh: Artificial Inteligence Applications Institute, University of Edimburgh, 1997. (Technical Report AIAI195). [Utw9?] University of Twente Centre for Telematics and Information Technology . Disponvel por WWW em http://www.ctit.utwente.nl/. [Wie92] WIEDERHOLD, G. Mediators in the Architecture of Future Information Systems. Computer, v. 25, n.3, March, 1992, p.38-49. [Wra9?] Wrappers. Disponvel por WWW em http://www.objs.com./survey/wrap.htm. (dezembro de 1999).