UNIVERSIDADE FEDERAL DO CEARÁ UFC PROGRAMA DE MESTRADO E DOUTORADO EM CIÊNCIA DA COMPUTAÇÃO CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 1 UNIVERSIDADE FEDERAL DO CEARÁ UFC PROGRAMA DE MESTRADO E DOUTORADO EM CIÊNCIA DA COMPUTAÇÃO CURSO DE CIÊNCIA DA COMPUTAÇÃO DIEGO SÁ CARDOSO MANUTENÇÃO INCREMENTAL DE VISÕES RDF MATERIALIZADAS FORTALEZA 2015

2 2 DIEGO SÁ CARDOSO MANUTENÇÃO INCREMENTAL DE VISÕES RDF MATERIALIZADAS Dissertação submetida à Coordenação do Curso de Pós- Graduação em Ciência da Computação, da Universidade Federal do Ceará, como requisito parcial para a obtenção do grau de Mestre em Ciências da Computação. Área de concentração: Banco de Dados Orientadora: Profa. Dra. Vânia Maria Ponte Vidal Coorientadora: Dra. Valéria Magalhães Pequeno FORTALEZA 2015

3 3 DIEGO SÁ CARDOSO MANUTENÇÃO INCREMENTAL DE VISÕES RDF MATERIALIZADAS Dissertação submetida à Coordenação do Curso de Pós- Graduação em Ciência da Computação, da Universidade Federal do Ceará, como requisito parcial para a obtenção do grau de Mestre em Ciências da Computação. Aprovada em / / BANCA EXAMINADORA Profa. Drª. Vânia Maria Ponte Vidal (Orientadora) Universidade Federal do Ceará UFC Drª. Valéria Magalhães Pequeno (Coorientadora) INESC-ID, Lisboa, Portugal Prof. Dr. Marcos A. Casanova Pontifícia Universidade Católica do Rio de Janeiro - PUC Prof. Dr. José Maria da Silva Monteiro Filho Universidade Federal do Ceará UFC

4 4 Dedico esta dissertação aos meus pais (José Wilson e Maria Lêda) pelo apoio incondicional que ofereceram à minha formação...

5 5 AGRADECIMENTOS A Deus, a fortaleza que torna possível o impossível e que sempre iluminou os meus passos durante esta caminhada. A meus pais que sempre me incentivaram aos estudos e a se esforçar para alcançar meus sonhos. A professora Vânia minha orientadora, por quem sou muito grato pela orientação e paciência durante esses anos, sempre me incentivando a dá o meu melhor e a praticar a arte da pesquisa. Ao professor José Maria meu co-orientador, por quem também sou muito grato pelo apoio durante a minha jornada no mestrado, me ajudando e me dando dicas que foram essenciais para o meu progresso e finalização desta dissertação. A Valéria Pequeno, pela paciência e ajuda na revisão deste trabalho. Aos meus amigos, Manoel Mariano, Diego Victor, José Wellington, Narciso Arruda, Régis Pires, Macedo Maia, Monica Regina pela amizade e companheirismo durante todo o processo deste mestrado.

6 6

7 7 Acredite no melhor pense seu melhor, estude seu melhor, nunca fique satisfeito com menos que seu melhor, tente seu melhor, e no longo prazo as coisas se revelarão para o melhor (Henry Ford)

8 8 RESUMO RDF (do inglês Resource Description Framework) tornou-se padrão para a publicação de dados estruturados na web. Uma vez que a maioria dos dados de empresas estão armazenados atualmente em sistemas de banco de dados relacional, o problema da publicação de dados relacionais em formato RDF desempenha um papel importante. Uma maneira geral e flexível para publicar dados relacionais em formato RDF é criar visões RDF dos dados relacional subjacentes. O conteúdo das visões pode ser materializado com o intuito de melhorar o desempenho da consulta e disponibilidade de dados. Para ser útil, uma visão materializada precisa ser mantida continuamente a fim de refletir dinamicamente as atualizações da fonte. Basicamente, existem duas estratégias para a manutenção de visões materializadas: re-materialização e a manutenção incremental. A rematerialização é caracterizada pela materialização de todos os dados da fonte relacional (inviável em vários casos por questão de desempenho e tempo); enquanto a manutenção incremental modifica periodicamente parte dos dados da visão para refletir as atualizações das fontes de dados relacionais (otimiza o processo, já que apenas parte dos dados referentes as atualizações na fonte são modificados). Tem sido demonstrado que a manutenção incremental geralmente supera a re-materialização completa da visão (ABITEBOUL et al, 1998), (ALI; FERNANDES; PATON, 2000). Este trabalho propõe um framework para automatizar o processo de manutenção incremental de uma visão RDF. O framework desenvolvido gera, de forma semiautomática, os mapeamentos entre uma fonte de dados relacional e uma ontologia. A partir dos mapeamentos, regras são geradas em forma de triggers que automatizam o processo de manutenção incremental da visão RDF. Palavras-chave: Ontologias, Visão Materializada, RDF, Banco de dados relacional, Mapeamentos, Manutenção incremental, Web Semântica.

9 9 ABSTRACT RDF (Resource Description Framework) has become standard for publishing structured data on the web. Since most business data currently are stored in relational database systems, the problem of publishing relational data in RDF format plays an important role. A general and flexible way to publish relational data in RDF format is to create RDF views of the underlying relational data. The content of the visions can be materialized in order to improve query performance and data availability. To be useful, a materialized view needs to be maintained continuously to reflect dynamically the updates from the source. Basically, there are two strategies for maintaining materialized views: re-materialization and Incremental maintenance. The re-materialization is characterized by the materialization of all the relational data source (not feasible in many cases in a matter of performance and time); while the incremental maintenance periodically modifies part of the vision of the data to reflect the updates of the relational data sources (optimizes the process, since only part of the data updates in the source has changed). It has been shown that the incremental maintenance generally outweigh the complete re-materialization of view (ABITEBOUL et al., 1998), (ALI; FERNANDES; PATON, 2000). This paper proposes a framework to automate the incremental maintenance process of a RDF view. The framework generates in a semiautomatic way, the mappings between a relational data source and an ontology. From the mappings, rules are generated in the form of triggers that automates the incremental maintenance process of RDF view. Keywords: Ontology, Materialized View, RDF, Relational Database, schema mappings, incremental view maintenance, Semantic Web.

10 10 Lista de Figuras Figura 1.1 Problema da manutenção de visões Figura 1.2 Passos principais da estratégia de manutenção da visão Figura 2.1 Camadas da Web Semântica Figura 2.2 Grafo RDF com uma única tripla Figura 2.3 Exemplo de uma consulta SPARQL Figura 2.4 Inserção, deleção e modificação com SPARQL Update Figura 2.5 Inserção em SPARQL Update Figura 2.6 Exemplo de inserção em SPARQL Update Figura 2.7 Deleção em SPARQL Update Figura 2.8 Exemplos de deleções em SPARQL Update Figura 2.9 Modificação em SPARQL Update Figura 2.10 Exemplo de uma operação MODIFY em SPARQL Update Figura 2.11 Infraestrutura atual de Linked Data Figura 3.1 Arquitetura geral da plataforma D2RQ Figura 4.1 Esquema do banco de dados ISWC_REL Figura 4.2 Ontologia de domínio CONF_OWL Figura 4.3 Estado do banco de dados ISWC_REL Figura 5.1 Esquema da visão exportada ISWC_RDF Figura 5.2 Regras para a manutenção da visão V com seus updates sobre a relação relevante R Figura 5.3 Algoritmo Generate_GVU_INSERTonR Figura 5.4 Procedimento GVUI[CA1] Figura 5.5 Problema de manter incrementalmente uma visão Figura 5.6 Procedimento GVU_INSERTonPapers Figura 5.7 View update U retornados pelo procedimento GVU_INSERTonPapers Figura 5.8 Algoritmo Generate GVU_DELETEonR Figura 5.9 Procedimento GVUD[CA1] Figura 5.10 Procedimento GVU_DELETEonOrganizations Figura 5.11 View update U retornados pelo procedimento GVU_DELETEonOrganizations Figura 5.12 Novo estado V 2 da visão Figura 6.1 Principais componentes da ferramenta RUBYA Figura 6.2 Configuração para o acesso à base ISWC_REL Figura 6.3 Estrutura de triggers, store procedures e métodos JAVA Figura 6.4 Framework RUBYA Figura 6.5 Configuração da Ontologia de Domínio... 81

11 11 Figura 6.6 Tela principal para a criação das ACs Figura 6.7 Criação de uma ACO para a propriedade dc:creator Figura 6.8 Lista com as ACs criadas até o momento Figura 6.9 Exemplo de criação de um filtro de seleção Figura 6.10 Lista de ACs do estudo de caso Figura 6.11 Esquema da visão RDF a partir das ACs do estudo de caso Figura 6.12 Triggers, Store procedure e botão Create Procedures Figura 6.13 Tela de apresentação dos métodos JAVA Figura 6.14 Métodos JAVA gerados para a relação Topics Figura 6.15 Servidor Fuseki na url "localhost:// Figura 6.16 GVU_INSERTonOrganizations(t) Figura 6.17 View update U retornado pelo procedimento GVU_INSERTonOrganizations(t) Figura 6.18 SPARQL Update U executado pelo View Controller no RFD-Store Figura 6.19 Estado da visão RDF após o insert em Organizations Figura 6.20 GVU_DELETEonRel_Paper_Topics(t) Figura 6.21 View update U retornado pelo procedimento GVU_DELETEonRel_Paper_Topics(t) Figura 6.22 SPARQL Update U executado pelo view controller no RDF-Store Figura 6.23 Estado da visão RDF após o Delete em Rel_Paper_Topics... 94

12 12 Lista de Tabelas Tabela 4.1 Exemplos de Assertivas de Correspondência de Classe (ACCs) Tabela 4.2 Exemplos de Assertivas de Correspondência de Objetos (ACOs) Tabela 4.3 Exemplo de Assertivas de Correspondência de Dados (ACDs) Tabela 4.4 Predicados embutidos Tabela 4.5 Regras de transformação Tabela 4.6 ACs entre ISWC_REL e CONF_OWL Tabela 4.7 Regras de transformação relacionadas às ACs da Tabela Tabela 4.8 Triplas geradas por aplicar as regras de transformação da Tabela 4.7 no estado da figura Tabela 5.1 Funções embutidas... 67

13 13 LISTA DE ABREVIATURAS E SIGLAS AC ACC ACO Assertiva de Correspondência Assertiva de Correspondência de Classe Assertiva de correspondência de objeto ACD Assertiva de correspondência de dados IRI OWL RDF Internationalized resource identifier Web Ontology Language Resource Description Framework SPARQL SPARQL Protocol and RDF Query Language TAG URI XML W3C The W3C Technical Architecture Group Uniform Resource Identifier extensible Markup Language World Wide Web Consortium WWW World Wide Web

14 14 Sumário 1 INTRODUÇÃO MOTIVAÇÃO E CARACTERIZAÇÃO DO PROBLEMA PROPOSTA OBJETIVOS DA DISSERTAÇÃO ORGANIZAÇÃO DA DISSERTAÇÃO FUNDAMENTAÇÃO TEÓRICA INTRODUÇÃO WEB SEMÂNTICA A Origem da Web Semântica Arquitetura em Camadas da Web Semântica RESOURCE DESCRIPTION FRAMEWORK (RDF) Conceitos e Sintaxe Serialização de RDF RDF Schema (RDFS) WEB ONTOLOGY LANGUAGE (OWL) SPARQL SPARQL UPDATE Insert Data e Delete Data Modify data LINKED DATA FUSEKI CONCLUSÕES TRABALHOS RELACIONADOS INTRODUÇÃO TRIPLIFY VIRTUOSO JENA SESAME PLATAFORMA D2RQ R3M LDIF CONCLUSÕES ASSERTIVAS DE CORRESPONDÊNCIA INTRODUÇÃO ESTUDO DE CASO CONCEITOS BÁSICOS E NOTAÇÃO ADOTADA... 50

15 4.4 DEFINIÇÃO DE ASSERTIVAS DE CORRESPONDÊNCIA REGRAS DE TRANSFORMAÇÃO GERADAS PELAS ACS EXEMPLOS DE ACS E REGRAS DE TRANSFORMAÇÃO USANDO AS REGRAS DE TRANSFORMAÇÃO PARA GERAR O GRAFO RDF CONCLUSÕES ABORDAGEM PROPOSTA INTRODUÇÃO PROCESSO PARA MANUTENÇÃO INCREMENTAL Geração do Esquema da Visão RDF exportado VM Geração das Regras de Manutenção Incremental de V ALGORITMO PARA COMPILAR GVU_INSERTONR ALGORITMO PARA COMPILAR GVU_DELETEONR CONCLUSÕES RUBYA RULES BY ASSERTIONS INTRODUÇÃO PRINCIPAIS COMPONENTES GUI (Graphical User Interface) GRVS (Generate RDF view schema) GVMR (Generate Rules) View Controller IMPLEMENTAÇÃO DO ESTUDO DE CASO Criação de um Mapeamento entre ontologia e base de dados relacional Criação das Assertivas de Correspondência Geração do esquema da visão RDF Geração das Regras Geração dos Procedimentos JAVA Métodos gerados pela ferramenta no Banco de dados e materialização da visão CONCLUSÕES CONCLUSÃO E TRABALHOS FUTUROS CONTRIBUIÇÕES LIMITAÇÕES... ERRO! INDICADOR NÃO DEFINIDO. 7.3 PUBLICAÇÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A APÊNDICE B APÊNDICE C

16 APÊNDICE D

17 17 1 INTRODUÇÃO A Web é atualmente um grande espaço global de dados e documentos distribuídos em diversas fontes heterogêneas. Uma nova metodologia de Web, chamada Web de Dados, visa definir e padronizar o caminho para que os dados sejam publicados de forma semântica funcional em formato RDF (do inglês: Resource Description Framework). A Web Semântica fornece tecnologias para efetivamente publicar, recuperar e descrever dados distribuídos na Web permitindo, assim, o compartilhamento dos dados entre aplicações, empresas e comunidades. De forma resumida essas tecnologias são: RDF, que consiste em um modelo de dados simples que une expressividade e extensibilidade permitindo interligar itens entre diferentes fontes de dados; URI (do inglês Universal Resource Identifier) que é usado na forma de um nome global. Linguagem SPARQL (do inglês SPARQL Protocol and RDF Query Language), a linguagem de consulta recomendada pela W3C (do inglês: World Wide Web Consortium) para recuperar e manipular dados armazenados no formato RDF (PRUD HOMMEAUX; SEABORNE, 2013). SPARQL-UPDATE (SCHENK; GEARON; PASSANT, 2010), a linguagem de atualização de grafos RDF. Como parte do desenvolvimento da Web Semântica, surgiu o conceito de Linked Data. Linked data pode ser definido como um conjunto de boas práticas para publicar e conectar conjuntos de dados estruturados na Web, com o intuito de criar a Web de Dados (CYGANIAK; BIZER, 2011). Para que os dados oriundos de bancos de dados relacionais possam ser publicados a partir de uma representação semântica e que estejam de acordo com os padrões de Linked Data, existem dois enfoques: (a) Enfoque virtual, na qual os dados são consultados através de uma consulta SPARQL, que é então traduzido para SQL. (b) Enforque materializado, onde é necessário que os dados das fontes relacionais sejam convertidos em RDF (materialização) e consultados utilizando o SPARQL sem a necessidade de tradução para o SQL. Um ponto relevante é que uma visão materializada precisa ser mantida continuamente para refletir dinamicamente as atualizações da fonte.

18 Motivação e Caracterização do Problema RDF tornou-se um padrão para publicação de dados estruturados sobre a Web, e, como a maioria das empresas armazenam os dados utilizando sistemas de banco de dados relacionais, o problema de publicar dados relacionais no formato RDF torna-se muito atrativo. Uma maneira geral e flexível para publicar dados relacionais em RDF é criar visões RDF do dado relacional subordinado. Os conteúdos das visões podem ser materializados para melhorar o desempenho das consultas e dados disponíveis. Entretanto, para ser útil, uma visão materializada deve ser continuamente atualizada a fim de refletir dinamicamente as atualizações na fonte de dados. Basicamente existem duas estratégias para a manutenção de visões, a rematerialização que realiza a conversão de todos os dados da fonte para o formato dos dados da visão (RDF) em tempos pré-estabelecidos, e a manutenção incremental que modifica periodicamente parte dos dados da visão para refletir as atualizações na base de dados. É de conhecimento geral que a manutenção incremental geralmente é mais eficiente que a rematerialização da visão (ABITEBOUL et al., 1998), (ALI; FERNANDES; PATON 2000). Neste presente trabalho é utilizada a manutenção incremental haja vista que a grande maioria das aplicações utiliza uma enorme quantidade de dados, tornando a rematerialização inviável por questões de desempenho. De forma resumida, o problema de manter visões de forma incremental é ilustrado na Figura 1.1. Nesta Figura, Mv é o mapeamento que define a visão V sobre a fonte de dados S. s e v são os estados da fonte de dados S e da visão V, respectivamente. 's é o novo estado de S após uma atualização. U são as atualizações necessárias para manter a visão V e que reflete na atualização feita na fonte S. ''v é o novo estado da visão V após a execução das atualizações U. É dito que a visão V foi corretamente mantida se os estados ''v e 'v são iguais, sendo que 'v é o estado de V obtido diretamente por 's através do mapeamento Mv (pelo processo de re-materialização).

19 19 Figura 1.1 Problema da manutenção de visões Diversos trabalhos, como (HERT; REIF; GALL, 2010), utilizaram ontologias como visões sobre a fonte de dados relacionais. Nestes trabalhos a estrutura da ontologia e do esquema do banco de dados é similar, ou seja, o mapeamento utilizado entre a ontologia e a fonte de dados é direto. De forma resumida, um mapeamento é classificado como direto (PRUD'HOMMEAUX; SEABORNE, 2013) quando utilizam correspondências intuitivas como, por exemplo, uma classe da ontologia é mapeada para uma tabela de uma fonte de dados relacional e uma propriedade da ontologia é mapeada para um atributo de uma tabela em uma fonte de dados relacional. Entretanto, diversas aplicações utilizam ontologias para descrever formalmente a semântica de seus dados não são necessariamente similares a estrutura da fonte de dados. Com isso, torna-se necessário lidar com diferentes estruturas entre os dois modelos, o que demanda a utilização de mapeamentos mais complexos que os mapeamentos diretos. Este trabalho lida principalmente com o problema relacionado à manutenção de uma visão RDF sobre uma fonte de dados relacional mediante a utilização de mapeamentos complexos. 1.2 Proposta O presente trabalho propõe uma estratégia de manutenção incremental, baseado em regras para automaticamente atualizar as visões materializadas. Essas regras têm associadas condições de disparo que quando satisfeitas causam a execução de uma ação, a

20 20 qual atualizará a visão RDF. A estratégia tem dois passos principais: 1) geração dos mapeamentos, e 2) geração das regras de manutenção da visão. A Figura 1.2 ilustra esses passos. A geração dos mapeamentos depende do designer para especificar um mapeamento entre o esquema relacional e a ontologia alvo, e resulta em uma especificação de como representar os conceitos do esquema relacional em termos das classes e propriedades RDF escolhidas pelo designer. O mapeamento induz uma visão RDF que é exportada da fonte de dados. A geração das regras de manutenção da visão automaticamente constrói as regras requeridas para a manutenção incremental da visão RDF a partir dos mapeamentos. Nossa solução tem os seguintes pontos principais. Nós propomos Assertivas de Correspondência (ACs) como uma maneira conveniente para especificar mapeamentos customizados entre vocabulários RDF alvo e esquemas dos bancos de dados. Os benefícios da utilização de formalismos declarativos para mapeamentos de esquemas são bem conhecidos (VIDAL; ARAUJO; CASANOVA, 2005). Os conceitos de ACs foram apresentados em (VIDAL et al. 2008) num contexto de visões XML. Entretanto, tem-se provado que é mais simples aplicar as ACs no contexto discutido nesta dissertação. É importante assinalar que o problema de geração dos mapeamentos está fora do escopo deste trabalho. As visões que nós endereçamos são focadas na publicação de esquemas RDF. Como tal, as ACs induzem os mapeamentos de esquema definidos pela classe de consultas as quais suportam a maioria dos tipos de dados reestruturados que são comuns na publicação de dados. Nós restringimos a expressividade dos mapeamentos a fim de obter um algoritmo muito eficiente. Além disso, as visões são auto-manuteníveis. Visões auto-manuteníveis não necessitam de informação externa para serem mantidas, ou seja, não é necessário consultar novamente a fonte na hora da atualização da visão.

21 21 Figura 1.2 Passos principais da estratégia de manutenção da visão. Nossas regras podem ser implementadas usando triggers já que a fonte de dados é relacional. Assim, nenhum sistema de middleware é requerido, uma vez que triggers são responsáveis pela propagação direta das atualizações para a visão materializada. A maioria das etapas do processo de manutenção da visão é feita em tempo de definição da visão. Baseada nos mapeamentos, em tempo de definição da visão, nós podemos: (i) identificar todas as atualizações da fonte que são relevantes para a visão; e (ii) definir os procedimentos de manutenção da visão requeridos para manter a visão atualizada a partir de uma dada atualização relevante na fonte. Enfatizamos que os procedimentos de manutenção da visão são definidos com base exclusivamente nas atualizações da fonte e seu estado atual, portanto, não é necessário nenhum acesso à visão materializada. Também os procedimentos de manutenção da visão propagada pelas regras não requerem nenhuma consulta adicional sobre a fonte de dados para manter a visão. Essas duas últimas características são importantes quando a visão é mantida externamente (ZHUGE; GARCIA-MOLINA, 1998), porque o acesso a uma fonte de dados remota pode ser muito lento. O uso de regras é uma solução eficiente para manutenção incremental de visões externas. No entanto, criar regras que mantém corretamente uma visão RDF pode ser um processo complexo, que exige ferramentas para automatizar o processo de geração das regras. Nesta dissertação, mostramos que, baseado em um conjunto de ACs (VIDAL et al. 2008),

22 22 pode-se gerar, de forma automática e eficiente, todas as regras requeridas para manter a visão materializada. Nosso formalismo permite justificar formalmente que as regras geradas pela nossa abordagem mantêm corretamente a visão. 1.3 Objetivos da Dissertação Este trabalho tem como objetivo geral a especificação de um ambiente que possibilite o processo de atualização de visões RDF de forma incremental sobre fonte de dados relacionais à medida que esta fonte sofre atualizações. As principais contribuições desta dissertação são: (i) Definição de um processo para a manutenção incremental de uma visão RDF a partir de uma fonte de dados relacional. Em nossa abordagem, propomos a geração de procedimentos que automatizem a manutenção incremental à medida que a fonte de dados sofre atualizações. Para a geração desses procedimentos apresentamos algoritmos que, dado um conjunto de ACs entre a ontologia de domínio e a fonte de dados relacional, gera todos os procedimentos para as operações de inserção, remoção e atualização. (ii) Desenvolvimento de uma ferramenta para gerar os mapeamentos de forma semiautomática a partir de uma ontologia e um esquema de banco de dados. (iii) Desenvolvimento de uma ferramenta para a geração dos procedimentos (em java) e triggers SQL a partir dos mapeamentos entre fonte relacional e visão RDF. Os triggers são utilizados para que, ao ocorrer uma atualização na fonte relacional (inserção, remoção e atualização), o procedimento relativo àquela operação seja invocado automaticamente.

23 Organização da Dissertação O restante desta dissertação está organizado da seguinte forma: O Capítulo 2 contém a fundamentação teórica, apresentando uma revisão sobre os tópicos relevantes para o desenvolvimento desta dissertação, bem como os principais trabalhos relacionados. O Capítulo 3 especifica as assertivas de correspondência e o processo de geração de regras utilizadas na manutenção incremental da visão. O Capítulo 4 descreve a abordagem proposta para a manutenção incremental de visões RDF materializadas entre uma ontologia e as fontes de dados relacionais. O Capítulo 5 apresenta as ferramentas desenvolvidas, discorrendo sobre suas principais funcionalidades, aspectos de implementação e resultados experimentais. Finalmente, o Capítulo 6 expõe as conclusões e perspectivas de trabalhos futuros. 2 FUNDAMENTAÇÃO TEÓRICA 2.1Introdução Neste capítulo trataremos de alguns conceitos cujo entendimento é essencial para a compreensão do contexto em que esta dissertação está inserida, bem como da fundamentação necessária ao entendimento dos capítulos seguintes.

24 24 A seção 2.2 dá uma visão geral da Web Semântica desde a sua origem até as camadas da sua arquitetura. A seção 2.3 explica os conceitos, a sintaxe, e exemplifica o uso do framework RDF. A seção 2.4 apresenta a linguagem OWL (do inglês Web Ontology Language) e suas sub-linguagens. A seção 2.5 introduz a linguagem SPARQL para consultas em grafos RDF. Na seção 2.6 a linguagem SPARQL Update é apresentada e detalhada através de exemplos. Na seção 2.7, os principais componentes da infraestrutura de Linked Data são apresentados. A seção 2.8 apresenta o framework Fuseki, que executa as atualizações SPARQL Update na visão RDF. Por fim, a seção 2.9 apresenta a conclusão do capítulo. 2.2 Web Semântica A visão da Web Semântica é a de fazer com que as informações na Web possam ser processadas por máquinas e não somente compreendida por humanos. Esta visão criou muitas analogias com a área de Inteligência Artificial. No entanto, é necessário fazer uma separação entre os diferentes objetivos e aplicações da Web Semântica. Obviamente, é impossível desenvolver agentes de software que decidam como humanos (nenhuma aplicação da Web Semântica passou no teste de Turing). Entretanto, hoje a comunidade de pesquisadores relacionados à Web Semântica desenvolveu fortes conceitos e padrões que podem ser usados para melhorar significativamente a qualidade de softwares e aplicações centrados em dados. Estes conceitos serão apresentados nas seções subsequentes A Origem da Web Semântica Embora a origem da Web Semântica esteja tipicamente ligada ao artigo publicado por Tim Berners Lee, James Hendler e Ora Lassila em Maio de 2001 (BERNERS-LEE; HENDLER; LASSILA, 2001), sua história iniciou nos anos 90 quando Tim Berners-Lee começava a desenvolver a WWW (do inglês: World Wide Web). A ideia de adicionar semântica às páginas Web e links já fazia parte de seus planos e projetos originais. Porém, a

25 25 ideia de combinar RDF com lógicas descritivas para implementar a Web Semântica só foi formulada dez anos mais tarde. A partir de 2001, os conceitos básicos da Web Semântica como RDF, RDF Schema, OWL e SPARQL foram padronizados pela W3C. Uma extensão da SPARQL para permitir atualizações nas triplas RDF (chamada SPARQL Update) foi submetida em Julho de Arquitetura em Camadas da Web Semântica As camadas da arquitetura da Web Semântica (HORROCKS et al., 2005) estão ilustradas na Figura 2.1 e são comumente organizadas na forma de uma pilha para ilustrar os diferentes conceitos que compõem o núcleo da Web Semântica. A camada base é constituída por dois conceitos básicos: As URIs e o padrão UNICODE de codificação de caracteres (para garantir compatibilidade com todas as línguas mundialmente conhecidas). Devemos notar que existe uma abreviação mais recente para URI chamada IRI (do inglês: Internationalized Unicode-encoded URI). A camada XML (do inglês: extensible Markup Language) faz parte da arquitetura, pois RDF é originalmente serializado em XML. Isto ocorre principalmente porque XML tornou-se um padrão amplamente difundido para troca de dados. Mais tarde, foram propostos formatos de serialização mais compactos para representar grafos RDF como, por exemplo, Turtle, Notation 3 e N-Triples. Na seção mostraremos exemplos de serialização de grafos RDF nas notações Turtle e RDF/XML.

26 26 Figura 2.1 Camadas da Web Semântica 1 Acima da camada RDF está a camada RDF Schema (RDFS). O RDFS pode ser usado para declarar classes pré-definidas. Estas classes podem ser utilizadas para adicionar restrições de tipo a recursos RDF. RDFS será descrito na seção Acima da camada RDFS estão ás camadas OWL e RIF/SWRL. Enquanto RDFS trata da tipagem dos recursos, OWL pode ser usada para classificar recursos por meio de lógicas descritivas. OWL é o sucessor do DAML+OIL e tem três variantes com diferentes níveis de expressividade: OWL Light, OWL-DL e OWL Full. Mais detalhes sobre a OWL serão apresentados na seção 2.4. Como restrições em OWL são baseadas em lógica descritiva, não é possível criar restrições que envolvam várias classes. Por exemplo, com OWL não podemos expressar: um ônibus pode transportar uma quantidade dez vezes maior de passageiros que um carro de passeio. A camada RIF/SWRL foi proposta para suportar esse tipo de regra (HORROCKS et al., 2004). 1 Imagem extraída de

27 27 Além do framework para lidar com ontologias, existe a linguagem de consultas SPARQL (será apresentada na seção 2.5) que está empilhada acima da camada RDF. SPARQL é a linguagem padrão da Web Semântica para recuperação de informações contidas em grafos RDF. A camada Unifying Logic é destinada a prover os padrões necessários para a definição de linguagens lógicas com poder de expressividade suficiente para a implementação de novos mecanismos de inferência na Web Semântica. A camada Proof mostra que deve haver meios de detectar e explicar os processos lógicos utilizados pelos reasoners semânticos. A camada Cryptography é apresentada na Figura 2.1 na vertical englobando as camadas da base até a camada proof. Ela é responsável pela segurança e privacidade das informações fornecidas em todas as camadas. O framework Trust está situado quase no topo da pilha. Geralmente, a confiabilidade pode ser assegurada pelo uso de uma infraestrutura de chaves públicas. Em geral, dados RDF podem ser assinados e encriptados por meio do uso de certificados digitais emitidos por autoridades certificadoras. Por fim, A camada User Interface é formada pelos sistemas que utilizam a Web Semântica como plataforma de execução. 2.3 Resource Description Framework (RDF) RDF é um framework para representar informações na Web de uma forma flexível, com o mínimo de restrições e cujo vocabulário é conhecido como RDF Core. RDF pode ser utilizado em aplicações isoladas com formato de dados proprietários. No entanto, seu modelo de dados genérico agrega mais valor quando utilizado para compartilhamento de informações. Dessa forma, o valor da informação cresce à medida que ela se torna acessível a um maior número de aplicações na Web. RDF é o principal modelo de dados utilizado nas aplicações da Web Semântica. Toda informação adicionada por componentes de mais alto nível como RDF Schema e OWL é modelada em RDF. Dentre os documentos que especificam o RDF, o mais importante deles é o RDF Primer (MANOLA; MILLER, 2004), pois este

28 28 introduz os conceitos básicos do framework RDF. RDF Primer é um resumo dos demais documentos que especificam o RDF e contém as informações básicas que são necessárias para o uso efetivo do RDF. O RDF Primer também explica como definir vocabulários usando a linguagem RDF Schema. Nas seções que seguem, discutimos os conceitos básicos do RDF, os principais formatos de serialização e a linguagem RDF Schema Conceitos e Sintaxe Grafos como Modelo de dados A estrutura por trás de qualquer expressão RDF é uma coleção de triplas, onde cada tripla consiste de sujeito, predicado (ou propriedade) e objeto (s, p, o). Um conjunto de triplas é denominado grafo RDF. O poder do RDF está na simplicidade desse modelo de dados. Uma sentença do tipo: A página Web foi criada por Diego Cardoso pode ser representada pelo grafo RDF mostrado na Figura 2.2. Neste exemplo, o sujeito é a URI < o predicado é dc:creator (propriedade definida no vocabulário Dublin Core) e o literal Diego Cardoso é o objeto. Este exemplo mostra como uma tripla RDF pode ser ilustrada na forma nó-arconó. O sujeito e o objeto são os nós e o predicado é o arco que os liga. A direção do arco é muito significante, pois sempre parte do sujeito e aponta para o objeto. Figura 2.2 Grafo RDF com uma única tripla

29 29 Vocabulário baseado em URIs e Identificadores de Nós URI é uma sequência compacta de caracteres que identifica um recurso físico ou abstrato. A utilização de URIs (BERNERS-LEE, T.; FIELDING, R.; MASINTER, 2006) é um dos princípios básicos do Linked Data: tudo que pode ser descrito por alguém na Web deve ter uma URI e, para possibilitar a recuperação da informação sobre um recurso, clientes HTTP devem ser capazes de resolverem tais URIs. Um nó pode ser uma URI, um literal ou blank (sem identificação). Predicados são sempre URIs. Uma URI ou um literal usados como nós identificam o que o nó representa. Uma URI usada como predicado identifica um relacionamento entre os nós conectados. Um blank é um nó que não é uma URI e também não é um literal, ou seja, é um nó que pode ser utilizado em sentenças RDF mas não possui nenhum nome associado. Tipos de Dados Um tipo de dados é usado em RDF na representação de valores como inteiros, numéricos de ponto flutuante e datas. Os tipos de dados pré-definidos no XML Schema (xsd) e identificados através de URIs são utilizados pelo RDF, pois este pré-define somente o tipo de dado rdf:xmlliteral. No entanto, novos tipos de dados podem ser definidos usando XML Schema como, por exemplo, xsd:integer para definir o tipo inteiro. Literais São utilizados para identificar valores como números e datas por meio de suas representações léxicas. Tudo que pode ser representado como um literal também pode ser representado como uma URI, porém em alguns casos é mais conveniente ou intuitivo usar literais. Um literal pode ser um objeto de uma tripla RDF, mas não pode ser o sujeito ou o predicado. Seu valor pode ser um texto livre ou tipado Serialização de RDF Existem muitos formatos de serialização para representar grafos RDF. O primeiro formato definido pela W3C foi o RDF/XML. Ele ainda é a sintaxe padrão para publicação de

30 30 vocabulários RDF e para troca de dados na Web. Como a sintaxe XML é muito volumosa e difícil de ser lida por pessoas, sintaxes alternativas foram propostas. Podemos citar como exemplo a Notation 3 (N3) 2 e dos seus subconjuntos, dos quais a sintaxe Turtle 3 tornou-se a mais popular. A sintaxe Turtle é mais legível, intuitiva e compacta quando comparada a sintaxe RDF/XML. Turtle é usada nos exemplos do estudo de caso desta dissertação. O grafo da Figura 2.2 pode ser representado usando a sintaxe Turtle da seguinte dc: < < dc:creator Diego Cardoso. O mesmo grafo quando representado usando a sintaxe RDF/XML pode ser descrito da seguinte forma: <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" xmlns:dc=" <rdf:description rdf:about=" <dc:creator>diego Cardoso</dc:creator> </rdf:description> </rdf:rdf> RDF Schema (RDFS) RDF Schema estende o vocabulário RDF Core. Surgem vários conceitos prédefinidos, como por exemplo: classes (rdfs:class) e propriedades (rdfs:property). Classes no RDF Schema são grupos abstratos, conjuntos ou coleções de objetos. As classes podem conter indivíduos, outras classes, ou uma combinação de ambos. Cada classe pode conter propriedades que tem pelo menos um nome e um valor. Propriedades são utilizadas para armazenar informação que é específica para a classe ligada a ela. Classes e Propriedades No RDF, basicamente todo recurso pode ser utilizado como um predicado ou como uma classe (usando a propriedade rdf:type). Por exemplo:

31 31 < rdf:type foaf:person. < dc:creator < Entretanto, para entendermos a semântica de foaf:person e dc:creator, estes recursos precisam estar descritos em algum lugar. A definição de foaf:person é parte do vocabulário Friend-of-a-Friend 4 (BRICKLEY; MILLER 2014). Para criar uma nova classe RDF basta declará-la como membro da classe rdfs:class. Similarmente à classe foaf:person, a definição da propriedade RDF dc:creator é parte do vocabulário Dublin Core 5 (POWELL et al., 2006). Neste vocabulário, dc:creator é definido como sendo do tipo rdfs:property. Domínio e Imagem de Propriedades Dada uma propriedade específica p, o conjunto de triplas RDF (s, p, o) pode ser interpretado como uma relação binária p(s, o) que associa um objeto o a um sujeito s. Usando esta notação, o domínio D p é o conjunto de todos os possíveis valores de s e a imagem I p é o conjunto de todos os possíveis valores de o. RDFS define duas propriedades rdfs:domain e rdfs:range usadas, respectivamente, para definir o domínio e a imagem de uma propriedade RDF. As propriedades RDF são definidas globalmente. Dessa forma, se uma propriedade não define domínio e imagem então ela pode ser usada com qualquer recurso, independente da classe deste recurso. Esta é a maior diferença do esquema RDF para um esquema relacional, onde atributos precisam ser definidos dentro do contexto de uma relação específica. 2.4 Web Ontology Language (OWL) A W3C recomenda a utilização da linguagem OWL por aplicações que precisam processar o conteúdo de documentos, e não somente disponibilizar este conteúdo para que pessoas possam lê-lo. OWL pode ser usada para tornar explícito o significado de termos de vocabulários e os relacionamentos entre esses termos. Esta representação de termos e seus relacionamentos é chamada de ontologia

32 32 OWL é mais abrangente que XML, RDF e RDF-S, pois provê vocabulários adicionais com uma semântica formal. De forma resumida, RDF define como escrever e OWL define o que escrever. OWL pode ser considerada uma versão revisada da linguagem DAM+OIL e possui três sublinguagens apresentadas a seguir, em ordem crescente de expressividade: OWL Lite: suporta classificação hierárquica e restrições simples. Por exemplo, embora suporte restrições de cardinalidade, somente são permitidos os valores de cardinalidade 0 e 1. Sua formalização é menos complexa que a da OWL DL. OWL DL: suporta o máximo de expressividade que possa ser computado e decidido em um tempo finito. Inclui todas as estruturas da linguagem OWL, porém elas devem ser utilizadas respeitando certas restrições (por exemplo, embora uma classe possa ser subclasse de mais de uma classe, uma classe não pode ser instância de uma outra classe). A sigla DL significa Description Logics, uma área de pesquisa dedicada a estudar as lógicas utilizadas na formalização da OWL. OWL Full: suporta o máximo de expressividade com a liberdade sintática do RDF, porém sem garantias computacionais. Por exemplo, em OWL Full uma classe pode ser tratada simultaneamente como uma coleção de indivíduos ou como um único indivíduo dentro do seu contexto. Com OWL Full, uma ontologia pode aumentar o vocabulário (RDF ou OWL) pré-definido. 2.5 SPARQL Consultas em grafos RDF podem ser realizadas utilizando a linguagem SPARQL (PRUD HOMMEAUX; SEABORNE, 2013), que é a linguagem padrão de consultas da Web Semântica. Entretanto, SPARQL não é somente uma linguagem declarativa, mas também um protocolo que envia consultas e recupera os resultados via HTTP. Tipicamente, os dados RDF são disponibilizados na Web por meio da criação de um SPARQL endpoint, um serviço Web com suporte ao protocolo SPARQL. Este serviço é acessado através de uma URI específica, a qual é criada para receber requisições HTTP com consultas SPARQL passadas como parâmetro e retorna os resultados de forma estruturada. Estes resultados podem vir em diferentes formatos dependendo dos comandos SPARQL

33 33 enviados. Por exemplo, consultas usando os comandos SELECT e ASK geralmente terão retornos nos formatos XML, JSON ou texto plano. Já quando utilizamos o comando CONSTRUCT, os resultados normalmente usam os formatos RDF/XML, Turtle ou N3. Um exemplo de uma consulta SPARQL é apresentado na Figura 2.3. PREFIX foaf: **especifica os prefixos utilizados na consulta SELECT?name **Parâmetros a serem encontrados WHERE { **Padrão de busca da query?person foaf:name?name. Figura 2.3 Exemplo de uma consulta SPARQL 2.6 SPARQL Update A primeira versão do SPARQL fornece suporte somente para a consulta de dados em RDF. A comunidade da Web Semântica identificou a necessidade de não somente consultar dados em RDF, como também de possibilitar a atualização desses dados. A comunidade então fez um esforço para solucionar este problema, o que levou a especificação do SPARQL Update, proposto para ser uma linguagem de manipulação de dados RDF. As principais operações suportadas pelo SPARQL Update são: INSERT DATA (para inserir novas triplas), DELETE DATA (para remover triplas) e MODIFY (para deletar e/ou inserir dados baseados na cláusula WHERE. A estrutura das atualizações é ilustrada na Figura 2.4.

34 34 Figura 2.4 Inserção, deleção e modificação com SPARQL Update Insert Data e Delete Data A operação Insert Data no SPARQL Update consiste de um conjunto de triplas que são inseridas aos dados existentes. O padrão básico é formado por três partes:1) a definição de URI para o recurso a ser adicionado; 2) o tipo do recurso (que normalmente é o nome da classe); 3) as propriedades com seus respectivos valores, como pode ser visto na Figura 2.5. Figura 2.5 Inserção em SPARQL Update

35 35 A Figura 2.6 ilustra um exemplo de uma inserção referente a um Estudante. A primeira tripla é a URI < O rdf:type neste exemplo é a classe Estudante. Em seguida temos as propriedades e seus respectivos valores. Figura 2.6 Exemplo de inserção em SPARQL Update A operação Delete Data no SPARQL Update consiste de uma operação para excluir triplas RDF. O padrão básico é mostrado na Figura 2.7. O primeiro bloco consiste das propriedades que serão deletadas e o segundo bloco especifica as condições para a deleção. Na operação DELETE DATA, diferentemente do SQL, podemos deletar tanto todas as propriedades de uma instância de uma classe, como também apenas um subconjunto de propriedades (funcionando como um UPDATE em SQL que define como NULL algumas colunas). Figura 2.7 Deleção em SPARQL Update A Figura 2.8 ilustra um exemplo de uma deleção SPARQL Update. No primeiro bloco da deleção à esquerda, temos as propriedades que serão deletadas. O?x representa a URI do recurso que será deletado e o?x?y?z refere-se a todas as outras propriedades que o Estudante possui (neste caso o Nome). Poderíamos suprimir a expressão?x?y?z para deletar somente a propriedade (deleção à direita da figura). Na clausura WHERE temos o rdf:type que especifica o tipo a ser deletado.

36 36 Figura 2.8 Exemplos de deleções em SPARQL Update Modify data A operação MODIFY em SPARQL Update consiste em uma operação para modificar um grafo RDF e contém a estrutura ilustrada na Figura 2.9. Figura 2.9 Modificação em SPARQL Update MODIFY é uma combinação atômica de operações de inserir e deletar que, em geral, não se limita a substituir triplas, mas também pode adicionar/remover triplas. Um exemplo é ilustrado na Figura 2.10 onde o diegovss@ufc.br é alterado para diegovss@lia.ufc.br.

37 37 Figura 2.10 Exemplo de uma operação MODIFY em SPARQL Update 2.7 Linked Data Em Julho de 2006, Tim Berners-Lee publicou um artigo na Web sobre a ideia de Linked Data (BERNERS-LEE, 2006). A idéia central do Linked Data é que, enquanto a WWW consiste em documentos HTML conectados por hiperlinks (ligados de forma sintática), a Web Semântica consiste em recursos de diversos tipos conectados por propriedades (ligados de forma semântica). A web Semântica é uma rede de dados ligados de forma semântica e a sua representação é através de grafos RDF. Para que possamos acessar e navegar em grafos RDF de uma forma mais intuitiva, Berners-Lee propôs quatro regras de design: 1. URIs devem ser usadas para identificar coisas. 2. Especificamente, URIs HTTP devem ser usadas para que pessoas possam localizar coisas. 3. Se alguém busca uma URI, informações úteis devem ser fornecidas usando os padrões (RDF e SPARQL). 4. Links semânticos devem apontar para outras URIs para que as pessoas possam descobrir mais coisas. Em 2007, muitos projetos foram lançados para dar suporte a esta ideia e promover a adoção dos paradigmas de Linked Data (AUER et al., 2007). Uma grande quantidade de

38 38 dados disponíveis publicamente (dados gerados por usuários, e dados abertos governamentais) foi publicada desde então. Por outro lado, existe a ideia de uma Web de Dados pública para adicioná-la à tradicional WWW. Os princípios de Linked Data também podem ser adaptados em soluções empresariais para integração de dados corporativos. Na Figura 2.11 temos a infraestrutura atual da Web de Dados. A figura mostra no centro uma aplicação cliente que normalmente será um navegador comum ou um navegador especializado em Linked Data, como por exemplo, o Tabulator (BERNERS-LEE et al., 2006). A aplicação cliente dispõe dos seguintes componentes: a) alguns recursos RDF distribuídos na Web, b) alguns datasets RDF com um SPARQL endpoint e uma interface Linked Data, c) um motor de buscas da Web Semântica, d) um localizador de serviços, como por exemplo, o Sindice (TUMMARELLO; DELBRU: OREN, 2007), e e) um mediador, como por exemplo, o SemWIQ (LANGEGGER, 2010). Todos estes componentes são descritos em seguida. Figura Infraestrutura atual de Linked Data 6 Aplicações Cliente Atualmente, os clientes mais populares são navegadores Linked Data. Eles interpretam dados RDF e disponibilizam visões estruturadas e bem definidas destes dados, normalmente na forma de grupos de sujeitos, propriedades e valores (literais ou links para recursos). 6 Imagem extraída de

39 39 Recursos RDF De acordo com a W3C Technical Architecture Group (TAG), um recurso RDF é um documento Web contendo dados RDF. Ele é identificado por uma URI HTTP completa e pode ser dinamicamente gerado a partir de um banco de dados. Entretanto, sua aparência é de um simples documento Web. Um recurso RDF contém um conjunto de sentenças RDF descrevendo vários recursos, onde alguns deles podem ser referências a links RDF externos. SPARQL Endpoints SPARQL Endpoints fornecem acesso a datasets RDF maiores através do uso da linguagem de consultas declarativa SPARQL e de um protocolo baseado em HTTP-REST. Para evitar ataques do tipo deny of service (DoS), alguns endpoints possuem restrições sobre o tamanho dos conjuntos de dados retornados. Podemos assumir que uma boa quantidade dos dados disponíveis será provida através de endpoints SPARQL. Linked Data Interfaces Como os SPARQL endpoints fornecem apenas acesso declarativo, não é possível navegar sobre os recursos encapsulados pelo endpoint sem ter que empacotar a informação executando, por exemplo, consultas do tipo DESCRIBE. Uma Linked Data interface é um wrapper RDF-para-HTML anexado ao endpoint, por exemplo, Pubby (CYGANIAK; BIZER 2011). Ela resolve URIs de recursos, executa as consultas, e retorna uma resposta HTTP em tempo de execução. Semantic Web Search Engine (SWSE) SWSEs utilizam rastreadores especializados que procuram por dados RDF na Web, os quais usualmente são identificados no campo Content-type do cabeçalho de resposta HTTP. Eles também possuem uma interface Web e/ou uma API com várias opções de busca. Em geral, um SWSE possui busca por palavras chave que retorna uma lista de recursos RDF. Em um segundo momento, o usuário pode restringir os recursos RDF exibidos criando filtros por tipos de recursos conhecidos. Sindice, um localizador de Serviços

40 40 Enquanto os motores de busca guardam todos os dados (especialmente arquivos RDF e OWL), a ideia do Sindice é usar índices específicos para armazenar somente a informação que for mais relevante. Por exemplo, atualmente ele só armazena um índice para as URIs, as propriedades que são inversa funcional e seus valores, e as palavras chave. Sindice também pode se integrar a navegadores Linked Data ou outros clientes semelhantes. Existe uma API que retorna uma lista de propriedades rdf:seealso cujos valores são URIs. Mediadores Um mediador pode ser utilizado para consulta a datasets RDF distribuídos a partir de um único ponto de acesso. Ele pode ser visto como um novo serviço que é parte da Web de Dados e que pode ser usado por outros clientes e aplicações. 2.8 FUSEKI Fuseki é um servidor que suporta o protocolo SPARQL HTTP, a linguagem SPARQL Query e a linguagem SPARQL Update. O objetivo dele é permitir a publicação, o gerenciamento e o consumo de dados RDF de forma simples. O Fuseki já tem embutidas as seguintes ferramentas: Jena, ARQ (SPARQL query engine) e TDB (RDF Store). Ao inicializarmos o servidor, temos uma interface Web capaz de realizar consultas, atualizações e upload de arquivos RDF diretamente para o dataset usado. As consultas podem ser federadas, ou seja, acessar mais de uma fonte de dados através do uso da operação SERVICE. Também permite o uso de vários grafos RDF que podem ser configurados para serem acessados como se fizessem parte do grafo default. Algumas limitações que serão tratadas em futuras versões são: Cada instância do servidor Fuseki somente gerencia um único dataset. Ainda não há como definir restrições de segurança de dados. Não permite o armazenamento em banco de dados relacional através do SDB, mas somente em memória (in-memory) ou em RDF Store (TDB).

41 Neste trabalho propomos realizar a manutenção incremental de uma visão RDF (em um RDF Store) executando as atualizações SPARQL Update via HTTP Conclusões Este capítulo apresentou uma síntese dos assuntos mais relevantes que servem de fundamentação para o entendimento dos demais capítulos desta dissertação. Foram expostos os principais conceitos da Web Semântica, do modelo RDF, do RDF schema, das linguagens OWL e SPARQL, SPARQL Update, de Linked Data e o framework Fuseki.

42 42 3 TRABALHOS RELACIONADOS 3.1Introdução Esta seção aborda as principais ferramentas e tecnologias dedicadas a mapear dados relacionais em triplas RDF. Algumas delas, além de realizar a conversão dos dados entre os dois modelos (Relacional e RDF Schema), também possibilitam: a publicação das triplas utilizando Linked Data interfaces ou SPARQL endpoints; e a persistência das triplas em memória ou em RDF stores. A Seção 3.2 apresenta o Triplify com algumas de suas limitações. Na Seção 3.3, é apresentado o Virtuoso e suas tecnologias. Na Seção 3.4, é apresentado o Jena e suas principais características. Na seção 3.5, é apresentado o Sesame e seus principais plugins. Na Seção 3.6, é apresentado o D2RQ e seus principais componentes. Na Seção 3.7, é apresentada a ferramenta R3M e sua funcionalidade de manter uma visão RDF a partir de bases de dados também em RDF. Na Seção 3.8, é apresentado o framework LDIF e como ele realiza a integração dos dados. Por fim, a Seção 3.9 apresenta a conclusão do capítulo. 3.2 Triplify O Triplify (AUER et al., 2009) é um plugin para ser instalado em aplicações Web. Converte o conteúdo de bancos de dados relacionais para os formatos RDF, JSON ou Linked Data. Esta ferramenta é muito leve, consistindo de pouco menos de 500 linhas de código. É de fácil configuração (em média leva-se uma hora para ser configurada) e, se a aplicação precisar ser implantada várias vezes, esta configuração pode ser reutilizada sem modificações. Os mapeamentos são simples e criados através de consultas SQL (visões). O trabalho do Triplify é converter os resultados destas consultas em RDF, JSON ou Linked Data. No momento da escrita desta dissertação, o Triplify possuía as seguintes limitações: 1. Apenas disponível na versão beta.

43 43 2. O desempenho só é garantido para aplicações web com uma base de dados de no máximo 100 megabytes. 3. Não há garantia de confidencialidade dos dados. Assim, dados confidenciais devem ser omitidos das consultas SQL dos mapeamentos. 3.3Virtuoso A plataforma Virtuoso (ERLING; MIKHAILOV, 2006) é bastante abrangente. Sua proposta é trabalhar com vários modelos (servidor de dados multimodal) e realizar o gerenciamento, acesso, integração e conversão de seus conteúdos. Os modelos de dados utilizados são XML, SQL, RDF e texto livre. Além disso, também se propõe a ser: um servidor Web de Documentos, um servidor Linked Data, um servidor de aplicações Web e um repositório de serviços Web (SOAP ou REST). 3.4 Jena O Jena Semantic Web Framework for Java (CARROLL et al., 2004) fornece APIs para que aplicações da Web Semântica possam manipular grafos RDF. Jena foi originalmente desenvolvido no HP Labs em Bristol entre os anos de 2000 e 2009, mas tornou-se um projeto de código aberto em meados de 2009 fazendo parte do projeto Apache até hoje. As principais características do Jena são: Suporte aos formatos XML, N3 e N-Triples para leitura e escrita de dados RDF tanto em memória (Jena SDB) como em disco (Jena TDB); Suporte a RDF, RDFa, RDFS e OWL; Uma API para consultas federadas utilizando a linguagem SPARQL (Jena ARQ); Disponibilização de SPARQL endpoint (Joseki ou Fuseki);

44 44 Possui motores de inferência embutidos e interfaces para motores de inferência externos. O Jena é utilizado neste trabalho para a comunicação com o servidor Fuseki, utilizado como RDF Store dos dados da visão RDF. 3.5 Sesame Similar ao Jena, o Sesame (BROEKSTRA; KAMPMAN; HARMELEN 2002) é um framework da Web Semântica para armazenamento e consulta de dados e esquemas RDF. Quando concebido em 2001, representou um enorme avanço por ter sido a primeira ferramenta pública que realizava estas consultas utilizando a linguagem SeRQL. Também pode ser configurado com relação à forma de armazenamento (em memória ou RDF store), possui mecanismos de inferência e suporta diferentes formatos de arquivo RDF. Por ser extensível, foram desenvolvidos alguns plug-ins e extensões. Como por exemplo: Virtuoso Sesame Provider: com ele é possível consultar dados armazenados no banco de dados do Virtuoso utilizando a API do Sesame. Adaptador do Sesame para o Oracle: integra a API do Sesame com as tecnologias da Web Semântica desenvolvidas para os bancos de dados Oracle. Mecanismo D2RQ: possibilita a integração do D2RQ com a API do Sesame. 3.6 Plataforma D2RQ O D2RQ é uma plataforma para acessar bancos de dados relacionais na forma de grafos RDF. O acesso aos dados relacionais é virtual e somente para leitura. Assim, não é necessário replicar estes dados dentro de uma base RDF. Também é possível criar dumps dos dados relacionais em formato RDF e carregar estes dumps em bases RDF. A plataforma é formada pelos seguintes componentes:

45 45 Linguagem D2RM (BIZER, 2003): uma linguagem de mapeamentos declarativa para criação de correspondências entre conceitos do modelo relacional em termos do modelo RDF. Mapeamentos nesta linguagem são documentos RDF escritos usando a sintaxe N3. Servidor D2R (BIZER; CYGANIAK, 2006): é um servidor HTTP que disponibiliza uma interface Linked Data e um SPARQL endpoint sobre o banco de dados relacional. Motor de Regras D2RQ: é o responsável por interpretar os mapeamentos D2RM. Utilizado pelo Servidor D2R para transformar consultas SPARQL em consultas SQL. No entanto, também pode ser usado como um plug-in para os frameworks Jena e Sesame. Neste caso os mapeamentos D2RM são utilizados para converter chamadas às APIs desses frameworks em consultas SQL no banco de dados relacional. A Figura 3.1 apresenta a arquitetura geral da plataforma D2RQ com os componentes descritos aqui e como eles estão integrados uns com os outros. Figura Arquitetura geral da plataforma D2RQ 7 7 Imagem extraída de

46 R3M No que diz respeito à manutenção de visões RDF, (HUNG; DENG; SUBRAHMANIAN, 2004) define uma ferramenta R3M, cuja funcionalidade é manter visões RDF a partir de bases de dados em RDF. Esta abordagem trata de visões RDF em que não há diferenças entre a estrutura da fonte e a estrutura da visão, ou seja, a visão contém apenas um subconjunto de classes e atributos da fonte de dados. Quando a estrutura da fonte e da visão é muito semelhante, é utilizado mapeamentos diretos e o processo para a geração das atualizações utilizadas para manter a visão é simples. Nossa ideia é a manutenção incremental de visões RDF materializadas onde existem estruturas possivelmente diferentes e que exigem mapeamentos mais complexos, como é o caso de mapeamentos heterogêneos. Nestes casos, é necessário, a partir das regras de mapeamento, definir abordagens mais complexas para traduzir atualizações na fonte de dados em atualizações no destino. 3.8 LDIF O LDIF (SCHULTZ et al., 2011) consiste em um framework para construir aplicações sobre Linked Data com os seguintes passos: Collect Data: Módulos de importação que replica localmente conjuntos de dados por meio de download de arquivos, ou crawnling com SPARQL. Map to Schema: Uma linguagem expressiva para mapeamento que permite traduzir os dados dos vários vocabulários que são usados na Web para um vocabulário de destino local e consistente. Resolve Identities: Um componente de resolução de identidade que descobre aliases de URI's nos dados de entrada e os substitui por uma única URI baseada em heurística de correspondência fornecida pelo usuário.

47 47 Quality Assessment and Data Fusion: Que prevê a fusão dos dados de acordo com diferentes métodos de resolução de conflitos. Output: LDIF provê como saída os dados integrados e que podem ser gravados em um arquivo ou para um QuadStore. De forma resumida o LDIF realiza a integração dos dados de um ou mais datasets e realiza a fusão dos dados. Nosso trabalho não contempla a integração de dados e considera apenas fontes de banco de dados relacionais (diferente do LDIF que considera como fonte de dados as ontologias). O LDIF não considera o problema de manutenção das triplas RDF, apenas sua integração e em nossa abordagem tratamos exatamente do problema de manutenção das triplas RDF. 3.9 Conclusões Este capítulo apresentou algumas das principais ferramentas destinadas a lidar com os problemas de como publicar dados relacionais na forma de grafos RDF e como consultar, persistir e atualizar estes grafos. Foram destacadas as principais funcionalidades de cada uma destas ferramentas bem como a integração que pode existir entre elas. Pretendemos com esse estudo, obter subsídios para formular contribuições relevantes ao contexto de mapeamentos relacional para RDF, bem como a Materialização e manutenção de visões RDF. Essas contribuições serão apresentadas nos capítulos seguintes deste trabalho.

48 48 4 ASSERTIVAS DE CORRESPONDÊNCIA 4.1 Introdução Nesta seção, apresentamos o formalismo para especificação de visões RDF de dados relacionais. As definições aqui descritas são base para a solução do problema de manutenção incremental de uma visão RDF. Na Seção 4.2, mostramos um estudo de caso que será utilizado durante todo este trabalho. Na Seção 4.3, descrevemos os conceitos básicos e notações adotadas. Na Seção 4.4, definimos as Assertivas de Correspondências (AC). Na Seção 4.5, apresentamos as regras de transformação geradas pelas ACs. Na Seção 4.6, apresentamos exemplos de ACs e regras de transformação. Na Seção 4.7, mostramos como as regras de transformação podem ser usadas para gerar o grafo RDF. Por fim, na Seção 4.8, concluimos o capítulo. 4.2 Estudo de Caso Nesta seção, apresentamos um estudo de caso que será utilizado ao longo deste trabalho. Para este estudo de caso, utilizaremos um esquema relacional fonte denominado ISWC_REL, apresentado na Figura 4.1, e uma ontologia de domínio denominada CONF_OWL, apresentada na Figura 4.2.

49 49 Figura Esquema do banco de dados ISWC_REL Na Figura 4.1, cada relação do esquema relacional possui uma chave primária sequencial cujo nome termina com o literal ID. Persons e Papers são as relações principais do esquema. Elas representam, respectivamente, autores e seus artigos. O atributo conferences da relação Papers é uma chave estrangeira para a relação Conferences e indica a conferência onde o artigo foi publicado. O relacionamento N:M entre Persons e Papers é realizado pela relação intermediária Rel_Person_Paper. A relação Topics guarda os tópicos abordados nos artigos. Rel_Paper_Topic faz o relacionamento entre Topics e Papers e o atributo parentid da relação Topics é um autorelacionamento. A relação Organizations se refere às organizações onde os autores podem ter algum vínculo. Este vínculo é estabelecido pela relação intermediária Rel_Person_Organization. Os rótulos nos arcos de relacionamento, como Fk_Papers, são os nomes das chaves estrangeiras. Na Figura 4.2, a ontologia CONF_OWL reusa termos de quatro vocabulários conhecidos: FOAF 8 (Friend of a Friend), SKOS 9 (Knowledge Organization System), VCARD 10 e DC 11 (Dublin Core). Foi utilizado o prefixo conf para os novos termos definidos em CONF_OWL. As classes que representam os conceitos principais da ontologia são foaf:person e foaf:document. Os arcos entre as classes são rotulados com o nome da propriedade de objeto que as relaciona e a direção do arco parte do domínio para a imagem desta propriedade. Por exemplo, o arco entre foaf:document e foaf:person está e

50 50 rotulado com a propriedade dc:creator que relaciona documentos com seus criadores. O domínio de dc:creator é foaf:document e sua imagem é foaf:person. As classes conf:conference, skos:concept, conf:organization e conf:postaladdress representam, respectivamente, as conferências onde os documentos são publicados, os assuntos que são citados em documentos ou são temas de pesquisa de pessoas, as organizações onde pessoas atuam, e os endereços dessas organizações. Figura Ontologia de domínio CONF_OWL 4.3 Conceitos Básicos e Notação Adotada Ao longo deste trabalho usamos a notação R[A 1,..., A n ] para representar um esquema de relação, e adotamos as restrições relacionais: atributos obrigatórios (ou not null), chaves, chaves primárias e chaves estrangeiras. Em particular, usamos F(R:L, S:K) para denotar uma chave estrangeira F, onde L e K são as listas de atributos das relações R e S, respectivamente. L e K possuem o mesmo tamanho. Dessa forma, F relaciona R e S. Um esquema relacional é um par S= (R, ), onde R é um conjunto de esquemas de relação e é um conjunto de restrições relacionais tais que: possui uma restrição de chave primária para cada esquema de relação em R; tem uma restrição de atributo obrigatório para cada atributo que é parte de uma chave única ou de uma chave primária;

51 51 Se tem uma chave estrangeira na forma F(R:L, S:K), então também tem uma restrição indicando que K é a chave primária de S. O vocabulário de S é um conjunto de nomes de relação, nomes de atributos, etc. usados em S. Dado um esquema de relação R[A 1,..., A n ] e uma tupla t de R, usamos t.a k para indicar a projeção de t sobre A k. Usamos seleções sobre esquemas de relação como usal. Seja S=(R, ) um esquema relacional e sejam R e T esquemas de relação de S. Uma lista = [F 1,..., F n-1 ] de nomes de chaves estrangeiras de S é um caminho de R para T se, e somente se, existe uma lista R 1,..., R n de esquemas de relação de S tal que R 1 =R, R n =T e F i relaciona R i e R i+1. Dizemos que as tuplas de R referenciam tuplas de T através de φ. Um caminho φ é um caminho associativo se, e somente se, φ=[f 1, F 2 ], onde as chaves estrangeiras são das formas F 1 (R 1 :K 1, R 2 :L 2 ) e F 2 (R 2 :M 2, R 3 :K 3 ). Por exemplo, considere o esquema relacional ISWC_REL da Figura 4.1. A lista de nomes de chaves [Fk_Publications, Fk_Authors] é um caminho associativo de Papers para Persons, mas [Fk_Publications, Fk_Persons] nem sequer é um caminho. Relembramos nesta seção alguns conceitos básicos relacionados a ontologias. Um vocabulário V é um conjunto de classes, propriedades de objeto e propriedades de dados. Uma ontologia é um par O=(V, ) tal que V é um vocabulário e é um conjunto finito de fórmulas em V, as restrições de O. Dentre as restrições, consideramos aquelas que definem o domínio e a imagem de uma propriedade, além das restrições de cardinalidade, definidas de forma usual. 4.4 Definição de Assertivas de Correspondência Nesta seção introduzimos a noção de assertiva de correspondência (VIDAL; ARAUJO; CASANOVA, 2005). Seja S = (R, ) um esquema relacional e O = (V, ) uma ontologia. Assuma que possui restrições definindo o domínio e a imagem de cada propriedade em V. Definição 4.1: Uma Assertiva de Correspondência de Classe (ACC) é uma declaração em um dos seguintes formatos: 1. Ψ: C R[A 1,..., A n ] 2. Ψ: C R[A 1,..., A n ]

52 52 onde Ψ é o nome da ACC, C é uma classe do vocabulário V, R é o nome de uma relação do esquema S, A 1,..., A n são os atributos que compõem a chave primária de R, e é um filtro de seleção aplicado sobre R. Nós dizemos então que Ψ correlaciona C com R. A Tabela 4.1 mostra alguns exemplos de ACCs entre ISWC_REL e CONF_OWL. Tabela 4.1 Exemplos de Assertivas de Correspondência de Classe (ACCs) Ψ 1 :foaf:person Persons[perID] Ψ 2 :foaf:document Papers[paperID] (year > 2002) Na Tabela 4.1, Ψ 1 é uma ACC entre a classe foaf:person de CONF_OWL e a relação Person de ISWC_REL e perid é o atributo de Person utilizado para gerar a URI de foaf:person. Ψ 2 é uma ACC entre a classe foaf:document de CONF_OWL e a relação Papers de ISWC_REL, paperid é o atributo de Papers utilizado para gerar a URI de foaf:document e year > 2000 é um filtro de seleção aplicado sobre Papers Definição 4.2: Uma Assertiva de Correspondência de Objeto (ACO) é uma declaração em um dos seguintes formatos: 1. Ψ: P R 2. Ψ: P R / onde Ψ é o nome da ACO, P é uma propriedade de objeto do vocabulário V, R é o nome de uma relação do esquema S e é um caminho a partir de R. A Tabela 4.2 mostra alguns exemplos de ACO entre ISWC_REL e CONF_OWL. Tabela 4.2 Exemplos de Assertivas de Correspondência de Objetos (ACOs) Ψ 3 :vcard:adr Organizations Ψ 4 :skos:subject Papers / [Fk_Papers, Fk_Topics] Na Tabela 4.2, Ψ 3 é uma ACO da classe conf:organizations de CONF_OWL e vcard:adr é uma propriedade de conf:organizations. Ψ2 é uma ACO da classe foaf:document e a relação Papers e [Fk_Papers, Fk_Topics] é o caminho a partir de Papers.

53 53 Definição 4.3: Uma Assertiva de Correspondência de Dados (ACD) é uma declaração em um dos seguintes formatos: 1. Ψ: P R / A 2. Ψ: P R / {A 1,...,A n 3. Ψ: P R / / B 4. Ψ: P R / / {B 1,...,B n onde Ψ é o nome da ACD, P é uma propriedade de dados do vocabulário V, R é o nome de uma relação do esquema S, A é um atributo de R, A 1,...,A n são atributos de R, é um caminho de R para uma relação T do esquema S, B é um atributo de T, e B 1,...,B n são atributos de T. A Tabela 4.3 mostra alguns exemplos de ACDs entre ISWC_REL e CONF_OWL. Tabela 4.3 Exemplos de Assertivas de Correspondência de Dados (ACDs) Ψ 5: foaf:mbox Persons / Ψ6:foaf:name Persons / { firstname, lastname Na Tabela 4.3, Ψ5 é uma ACD da classe foaf:person de CONF_OWL e foaf:mbox é uma propriedade de foaf:person. Ψ6 é uma ACD da classe foaf:person e foaf:name é uma propriedade de foaf:person. A expressão { firstname, lastname representa a concatenação dos dois atributos da tabela Persons. Nós fechamos esta seção com a definição de um esquema de visão RDF induzido por um mapeamento e com uma definição auxiliar usada na construção das regras de manutenção da visão. Definição 4.4: Um mapeamento entre S e O é um conjunto M de ACs tal que: 1. Se M tem uma ACO na forma P R, então M deve ter também uma ACC que mapeia o domínio de P com R, e uma ACC que mapeia a imagem de P também com R. 2. Se M tem uma ACO na forma P R /, onde é um caminho de R para T, então M deve ter uma ACC que mapeia o domínio de P com R e uma ACC que mapeia a imagem de P com T. 3. Se M tem uma ACD que mapeia uma propriedade de dados P do vocabulário V com uma relação R do esquema S, então M deve ter uma ACC que mapeia o domínio de P com R.

54 54 Definição 4.5: Seja M um mapeamento entre S e O. O esquema induzido da visão RDF por M é o vocabulário V M, o qual consiste de todas as classes e nomes de propriedades que ocorrem no lado esquerdo de uma AC em M. Nós dizemos que M é um conjunto de ACs de V M. Definição 4.6: Seja M um mapeamento entre S e O. Seja V M o esquema induzido da visão RDF por M. Seja R um nome de relação no vocabulário de S e Ψ um AC em M. Ψ é relevante para R se e somente se R ocorrer no lado direito de Ψ. R é relevante para V M se R ocorrer no lado direito de uma AC em M. Nós usamos M[R] para denotar o conjunto de ACs em M que são relevantes para R. Por exemplo, as seguintes ACs são relevantes para R: Ψ: P R / A Ψ: P R1 / / B onde R ocorre em 4.5 Regras de Transformação geradas pelas ACs Nesta seção introduzimos a noção de regra de transformação e mostramos como interpretar AC na forma de regras de transformação. Sejam O=(V, ) uma ontologia e S=(R, ) um esquema relacional, com vocabulário W. Sejam X um conjunto de variáveis escalares e T um conjunto de variáveis de tupla, disjuntos entre si e disjuntos de W e U. Um literal é uma expressão na forma R(t), onde R é um nome de uma relação em U e t é uma variável de tupla em T, ou um predicado embutido de uma das formas mostradas na Tabela 4.4. Um corpo de regra B é uma lista de literais. Quando necessário, usamos B[x 1,, x k ] para dizer que a tupla ou as variáveis escalares x 1,, x k ocorrem em B. Também usamos R(t), B[t,x 1,, x k ] para dizer que o corpo de regra tem um literal na forma R(t).

55 Uma regra de transformação, ou simplesmente uma regra, é uma expressão em uma das seguintes formas: 55 C(x) B[x], onde C é uma classe em V e B[x] é um corpo de regra. P(x,y) B[x,y], onde P é uma propriedade em V e B[x, y] é um corpo de regra. Seja M um mapeamento entre S = (R, ) e O = (V, ), ou seja, M satisfaz as condições declaradas na Definição 4.4. Assuma que toda classe C em V está associada a um prefixo de um namespace. A Tabela 4.5 mostra as regras de transformação induzidas pelas ACs de M. Por exemplo, na Tabela 4.5, a regra de mapeamento da Linha 5 (coluna à direita) indica que, para cada tupla t de R tal que A é um atributo de R e t.a não é nulo, é possível: Gerar a URI s do domínio D de P correspondente a t, usando a ACC Ψ D : D(s) R(t), B D [t, s], onde B D [t, s] significa: 1) TemURI[Ψ](t, s) (um dos predicados embutidos da Tabela 4.4), se a ACC para D for a da Linha 1 da Tabela 4.1; ou 2) TemURI[Ψ](t, s), (t), se a ACC para D for a da Linha 2 da Tabela 4.1; Traduzir o valor de A na tupla t, gerando o literal v; Associar v com o valor da propriedade P de s. Tabela 4.4 Predicados embutidos Predicado embutido Definição intuitiva naonulo(v) naonulo(v) é verdadeiro sse o valor de v não é nulo RDFLiteral(u, A, R, v) Dado um valor u, um atributo A de R, uma relação R, e um literal v, RDFLiteral(u, A, R, v) é válido sse v é a representação literal de u, considerando o tipo de A em R TemTuplasReferenciadas[ ](t, u) Dada uma tupla t de R e uma tupla u de T, onde é um caminho de R para T TemTuplasReferenciadas[ ](t,u) é verdadeiro sse u é referenciado por t através do caminho TemURI[Ψ](t, s) onde Ψ é uma ACC para a classe C de V, usando os atributos A 1,..., A n de R concat([v 1,..., v n ], v) Dada uma tupla t de R, TemURI[Ψ](t, s) é verdadeiro sse s é a URI obtida pela concatenação do prefixo para o namespace de C com os valores de t.a 1,..., t.a n Dada a lista [v 1,..., v n ] de valores string, concat([v 1,..., v n ], v é válido sse v é a string obtida concatenando v 1,..., v n

56 56 Assertiva de Correspondência Tabela 4.5 Regras de Transformação 1 Ψ: C R[A 1,..., A n ] C(s) R(t), TemURI[Ψ](t, s) Regra de Transformação 2 Ψ: C R[A 1,..., A n ] C(s) R(t), TemURI[Ψ](t, s), (t) 3 Ψ: O R onde: - A tem uma ACC Ψ D que relaciona o domínio D de O com R e Ψ D tem uma regra D(s) R(t), B D [t, s] - A tem uma ACC Ψ N que relaciona a imagem N de O com R e Ψ N tem uma regra N(o) R(t),B N [t, o] P(s,o) R(t), B D [t, s], B N [t, o] 4 Ψ: O R / onde: - é um caminho de R para T - A tem uma ACC Ψ D que relaciona o domínio D de O com R e Ψ D tem uma regra D(s) R(t), B D [t, s] - A tem uma ACC Ψ N que relaciona a imagem N de O com T e Ψ N tem uma regra N(o) T(u),B N [u, o] P(s,o) R(t), B D [t, s], TemTuplasReferenciadas[ ](t, u), T(u), B N [u, o] 5 Ψ: P R / A onde: - A tem uma ACC Ψ D que relaciona o domínio D de P com R e Ψ D tem uma regra D(s) R(t),B D [t, s] - A é um atributo de R P(s,v) R(t), B D [t, s], naonulo(t.a), RDFLiteral(t.A, A, R, v) 6 Ψ: P R / / A onde: - é um caminho de R para T - A tem uma ACC Ψ D que relaciona o domínio D de P com R e Ψ D tem uma regra D(s) R(t),B D [t, s] - A é um atributo de T 7 Ψ: P R / {A 1,..., A m onde: - A tem uma ACC Ψ D que relaciona o domínio D de P com R e Ψ D tem uma regra D(s) R(t),B D [t, s] - A 1,..., A m são atributos de R 8 Ψ: P R / / {A 1,..., A m onde: - é um caminho de R para T - A tem uma ACC Ψ D que relaciona o domínio D de P com R e Ψ D tem uma regra D(s) R(t),B D [t, s] - A 1,..., A m são atributos de T P(s,v) R(t), B D [t, s], TemTuplasReferenciadas[ ](t, u), naonulo(u.a), RDFLiteral(u.A, A, T, v) P(s,v) R(t), B D [t, s], naonulo(t.a 1 ),,naonulo(t.a m ), RDFLiteral(t.A 1, A 1, R, v 1 ),, RDFLiteral(t.A m, A m, R,v m ), concat([v 1,...,v m ], v) P(s,v) D(t), B D [t, s], TemTuplasReferenciadas[ ](t, u), naonulo(u.a 1 ),, naonulo(u.a m ) RDFLiteral(u.A 1, A 1, T, v 1 ),, RDFLiteral(u.A m, A m, T, v m ), concat([v 1,.., v m ], v)

57 Exemplos de ACs e Regras de Transformação A Tabela 4.6 mostra um conjunto de ACs que especificam um mapeamento entre CONF_OWL e ISWC_REL, obtidas com o auxílio da ferramenta descrita no Capítulo 6. A Tabela 4.7 contém as regras de transformação induzidas pelas ACs da Tabela 4.6, onde a regra RACi foi gerada a partir da AC ACi. Por exemplo, as regras induzidas pelas ACs ACC1, ACD1, ACO2, ACC3, ACC4 e ACO3 são, respectivamente, RACC1, RACD1, RACO2, RACC3, RACC4 e RACO3 e tem o seguinte significado: RACC1 especifica que cada tupla t em Person produz uma tripla RDF: < rdf:type foaf:person. O atributo perid, que é chave primária da relação Person, é utilizado para compor a URI dos indivíduos da classe foaf:person. RACD1 especifica que cada tupla t em Person produz uma tripla RDF: < foaf:name concat(t.firstname, t.lastname). Desta forma, o valor da propriedade foaf:name é obtido pela concatenação dos atributos firstname e lastname. RACO2 especifica que, para cada tupla t em Person, para cada tupla t em Topics tal que t é referenciado por t através do caminho [Fk_Authors, Fk_Publications, Fk_Papers, Fk_Topics], é gerada uma tripla RDF: < conf:researchinterests < Como não há uma relação intermediária ligando diretamente as relações Person e Topics é preciso percorrer um caminho de chaves estrangeiras partindo de Person e terminando em Topics. RACC3 e RACC4 especificam que cada tupla t em Organizations produz, respectivamente, as triplas RDF:

58 58 < rdf:type conf:organization < t.country> rdf:type conf:postaladdress Neste caso, a relação Organizations é mapeada em duas classes: conf:organization e conf:postaladdress. A diferença entre elas consiste nos atributos selecionados para compor a URI. Para a classe conf:organization foi escolhido o atributo orgid que é chave primária da relação, ao passo que para a classe conf:postaladdress foram escolhidos os atributos address, location, postcode e country que juntos compõem uma chave candidata. RACO3 especifica que cada tupla t em Organizations produz uma tripla RDF: < vcard:adr < example.com/organization/t.address/t.location/t.postcode/t.country> Neste caso, como a relação Organizations é mapeada em duas classes: conf:organization e conf:postaladdress, uma propriedade de ligação, vcard:adr, é criada entre as classes. Tabela 4.6 ACs entre ISWC_REL e CONF_OWL ACC 1 foaf:person Persons[perID] ACC 2 foaf:document Papers[paperID], (year > 2002) ACC 3 conf:organization Organizations[orgID] ACC 4 conf:postaladdress Organizations[address, location, postcode, country] ACC 5 conf:conference Conferences[confID] ACC 6 skos:concept Topics[topicID] ACO 1 conf:hasaffiliation Persons / [Fk_Persons, Fk_Organizations] ACO 2 conf:researchinterests Persons / [Fk_Authors, Fk_Publications, Fk_Papers, Fk_Topics ] ACO 3 vcard:adr Organizations ACO 4 skos:subject Papers / [Fk_Papers, Fk_Topics] ACO 5 conf:conference Papers / Fk_Conferences ACO 6 skos:broader Topics / Fk_Parent ACD 1 foaf:name Persons / { firstname, lastname ACD 2 foaf:mbox Persons / ACD 3 rdfs:label Organization / name ACD 4 foaf:homepage Organization / homepage ACD 5 vcard:street Organizations / address ACD 6 vcard:locality Organizations / location ACD 7 vcard:pcode Organizations / postcode ACD 8 vcard:country Organizations /country ACD 9 dc:title Papers / title ACD 10 dcterms:abstract Papers / abstract

59 59 ACD 11 dc:date Papers / year ACD 12 skos:preflabel Topics / topicname ACD 13 rdfs:label Conferences / name ACD 14 dc:date Conferences / date ACD 15 conf:location Conferences / location Tabela Regras de transformação relacionadas às ACs da Tabela 4.6 RACC 1 RACC 2 RACC 3 RACC 4 RACC 5 RACC 6 RACO 1 RACO 2 RACO 3 RACO 4 RACO 5 RACO 6 RACD 1 RACD 2 RACD 3 RACD 4 RACD 5 RACD 6 RACD 7 RACD 8 RACD 9 foaf:person(s) Persons(t), TemURI[ACC 1 ](t,s) foaf:document(s) Papers(t), TemURI[ACC 2 ](t,s) conf:organization(s) Organizations (t), TemURI[ACC 3 ](t,s) conf:postaladdress(s) Organizations (t), TemURI[ACC 4 ](t,s) conf:conference(s) Conferences(t), TemURI[ACC 5 ](t,s) skos:concept(s) Topics(t), TemURI[ACC 6 ](t,s) conf:hasaffiliation(s,o) Persons(p), TemURI[ACC 1 ](p,s), TemTuplasReferenciadas[Fk_Persons, Fk_Organizations](p,t), Organizations(t), TemURI[ACC 3 ](t,o) conf:researchinterests(s,o) Persons(p), TemURI[CCA1](p,s), TemTuplasReferenciadas[Fk_Authors, Fk_Publications, Fk_Papers, Fk_Topics](p,t), Topics(t), TemURI[ACC 6 ](t,o) vcard:adr(s,o) Organizations(t), TemURI[ACC 3 ](t,s), Organizations (t), TemURI[ACC 4 ](t,o) skos:subject(s,o) Papers(p), TemURI[ACC 2 ](p,s), TemTuplasReferenciadas[Fk_Papers, Fk_Topics](p,t), Topics(t), TemURI[ACC 6 ](t,o) conf:conference(s,o) Papers(p), TemURI[ACC 2 ](p,s), TemTuplasReferenciadas[Fk_Conferences](p,t), Conferences(t), TemURI[ACC 5 ](t,o) skos:broader(s,o) Topics(t), TemURI[ACC 6 ](t,s), TemTuplasReferenciadas[Fk_Parent](t,u), Topics(u), TemURI[ACC 6 ](u, o) foaf:name(s, v) Persons(p), TemURI[ACC 1 ](p, s), naonulo(p.firstname), naonulo(p.lastname), RDFLiteral(p.firstName, firstname, Persons, v1), RDFLiteral(p.lastName, lastname, Persons, v2), concat([v1, v2], v) foaf:mbox(s, v) Persons(p), TemURI[ACC 1 ](p, s), naonulo(p. ), RDFLiteral(p. , , Persons, v) rdfs:label(s, v) Organizations(o), TemURI[ACC 3 ](o, s), naonulo(o.name), RDFLiteral(o.name, name, Organizations, v) foaf:homepage(s, v) Organizations(o), TemURI[ACC 3 ](o, s), naonulo(o.homepage), RDFLiteral(o.homepage, homepage, Organizations, v) vcard:street(s, v) Organizations(o), TemURI[ACC 4 ](o, s), naonulo(o.address), RDFLiteral(o.address, address, Organizations, v) vcard:locality (s, v) Organizations(o), TemURI[ACC 4 ](o, s), naonulo(o.location), RDFLiteral(o.location, location, Organizations, v) vcard:pcode (s, v) Organizations(o), TemURI[ACC 4 ](o, s), naonulo(o.postcode), RDFLiteral(o.postcode, postcode, Organizations, v) vcard:country (s, v) Organizations(o), TemURI[ACC 4 ](o, s), naonulo(o.country), RDFLiteral(o.country, country, Organizations, v) dc:title(s, v) Papers(p), TemURI[ACC 2 ](p, s), naonulo(p.title), RDFLiteral(p.title, title, Papers, v) RACD 10 dcterms:abstract(s, v) Papers(p), TemURI[ACC 2 ](p, s), naonulo(p.abstract), RDFLiteral(p.abstract, abstract, Papers, v) RACD 11 dc:date(s, v) Papers(p), TemURI[ACC 2 ](p, s), naonulo(p.year), RDFLiteral(p.year, year, Papers, v) RACD 12 skos:preflabel(s, v) Topics(t), TemURI[ACC 6 ](t, s), naonulo(t.topicname), RDFLiteral(t.topicName, topicname, Topics, v) RACD 13 rdfs:label(s, v) Conferences(t), TemURI[ACC 5 ](t, s), naonulo(t.name), RDFLiteral(t.name, name, Conferences, v)

60 60 RACD 14 dc:date(s, v) Conferences(t), TemURI[ACC 5 ](t, s), naonulo(t.date), RDFLiteral(t.date, date, Conferences, v) RACD 15 conf:location(s, v) Conferences(t), TemURI[ACC 5 ](t, s), naonulo(t.location), RDFLiteral(t.location, location, Conferences, v) 4.7 Usando as regras de transformação para gerar o grafo RDF Suponha que o estado atual do banco de dados ISWC_REL é o descrito na Figura 4.3. A Tabela 4.8 mostra as triplas geradas a partir da aplicação das regras de transformação da Tabela 4.7 no estado da Figura 4.3. Estas triplas compõem o grafo gerado pelo mapeamento definido pelas ACs da Tabela 4.6. Figura Estado do banco de dados ISWC_REL

61 Tabela Triplas geradas por aplicar as regras de transformação da Tabela 4.7 no estado da Figura 4.3 ACC 1 rdf:type foaf:person rdf:type foaf:person rdf:type foaf:person ACC 2 rdf:type foaf:document rdf:type foaf:document ACC 3 rdf:type conf:organization ACC 4 rdf:type conf:postaladdress Tabela continuação ACC 5 rdf:type conf:conference ACC 6 rdf:type skos:concept rdf:type skos:concept rdf:type skos:concept ACO 1 conf:hasaffiliation conf:hasaffiliation conf:hasaffiliation ACO 2 conf:researchinterests conf:researchinterests conf:researchinterests conf:researchinterests conf:researchinterests conf:researchinterests ACO 3 vcard:adr ACO 4 skos:subject skos:subject skos:subject skos:subject ACO 5 conf:conference conf:conference ACO 6 skos:broader skos:broader ACD 1 foaf:name " Yolanda Gil" foaf:name " Varun Ratnakar" foaf:name "Jim Blythe" ACD 2 foaf:mbox " gil@isi.edu" foaf:mbox " varunr@isi.edu" foaf:mbox " blythe@isi.edu" ACD 3 rdfs:label " Hewlett-Packard Laboratories, Bristol" ACD 4 foaf:homepage " ACD 5 vcard:street " Filton Road" ACD 6 vcard:locality " Bristol" ACD 7 vcard:pcode " BS348QZ" ACD 8 vcard:country " UK" ACD 9 dc:title " Trusting Information Sources One Citize " dc:title " Automatic Generation of Java/SQL base " ACD 10 dcterms:abstract " This paper describes an appro " dcterms:abstract " This paper describes two appr " ACD 11 dc:date dc:date 2002 ACD 12 skos:preflabel " Artificial Intelligence" skos:preflabel " Semantic Web" 61

62 62 skos:preflabel " Knowledge Management" ACD 13 rdfs:label " International Semantic Web Conference 2002" ACD 14 dc:date " June 9-12, 2002" ACD 15 conf:location "Sardinia" 4.8 Conclusões Neste capítulo, foram apresentadas as definições relacionadas às ACs, as regras de transformação geradas a partir das ACs e um exemplo prático de utilização deste formalismo. O esquema relacional e a ontologia de domínio apresentados serão utilizados ao longo deste trabalho como estudo de caso.

63 5. MANUTENÇÃO INCREMENTAL BASEADA EM ASSERTIVAS DE CORRESPONDÊNCIA Introdução Apresentamos neste capítulo nossa abordagem para a manutenção incremental do esquema de visão RDF. Na seção 5.2, explicamos o processo para a manutenção incremental com seus respectivos passos. Na seção 5.3, detalhamos o algoritmo Generate_InsertOnR" com um exemplo prático de seu funcionamento. Na seção 5.4, detalhamos o algoritmo Generate_DeleteOnR" com um exemplo prático de seu funcionamento. Por fim, na seção 5.5, apresentaremos nossas conclusões. 5.2 Processo para Manutenção Incremental Neste capítulo considere: O = (V, ), a ontologia alvo, onde V é o vocabulário de O e é o conjunto de constraints de O; S = (R, ), o esquema relacional que é mapeado para O, onde R é um conjunto de relações e é um conjunto de relações e constraints; M, o mapeamento entre S e O, definidas por um conjunto de ACs. V M é o esquema da visão RDF exportada, induzido por M. Nesta seção, apresentamos como usar as ACs para gerar o conjunto de regras requeridas para a manutenção incremental de visões RDF de V M. Em nossa abordagem, o processo de geração de regras de manutenção para V M consiste em dois passos: 1. A geração de V M ; 2. A geração de um conjunto de regras necessárias para a manutenção incremental da V M materializada. Cada um desses passos é descrito como segue.

64 Geração do Esquema da Visão RDF exportado VM Este passo envolve a geração de V M, o esquema da visão RDF induzido por M. Na nossa abordagem, o esquema da visão RDF é uma ontologia exportada cujo vocabulário é um subconjunto do vocabulário da ontologia de domínio e pode ser automaticamente gerada tendo como base as ACs em M. Os detalhes da geração de V M está fora do escopo desta dissertação, entretanto pode ser encontrado em (CASANOVA et al., 2011). É importante lembrar que este trabalho trata apenas dos constraints, sob certas condições Para o nosso estudo de caso, a Figura 5.1 apresenta o esquema da visão RDF exportada ISWC_RDF induzida por ACs na tabela 4.6. O vocabulário ISWC_RDF contém todos os elementos da ontologia CONF_OWL que são relacionados aos elementos de ISWC_REL. Figura 5.1 Esquema da visão exportada ISWC_RDF.

65 Geração das Regras de Manutenção Incremental de V O processo para a geração do conjunto de regras requeridas para a manutenção incremental da visão materializada V M consiste em dois sub-passos: 1. Obter o conjunto de todas as relações em S que são relevantes para V M. 2. Para cada relação R que é relevante para V M, gerar as regras para manter V M. Em nossa abordagem, o conjunto de nomes das relações que são relevantes para V M pode ser facilmente computado, baseado nos mapeamentos V M (ver Definição 4.6 do capítulo 4). Por exemplo, em nosso estudo de caso, todas as relações de ISWC_REL são relevantes para a visão ISWC_RDF. Para cada update µ sobre a relação R, as regras de manutenção da visão que vamos descrever neste capítulo cria uma atualização U para ser aplicada sobre V M. Três regras são geradas, consoante o tipo de atualização (ver Figura 5.2): Regra (a) é disparada pela inserção em R; Regra (b) é disparada pela deleção em R; Regra (c) é disparada pelo update em R (Um update é tratado como uma deleção seguida de uma inserção) When INSERT 0N R Then U:= GVU_INSERTonR (rnew); ApplyUpdates( V, U); (a) When DELETE 0N R Then U:=GVU_DELETEonR (rold); ApplyUpdates( V, U); (b) When UPDATE 0N R Then U:=GVU_DELETEonR (rold); ApplyUpdates( V, U); U:= GVU_INSERTonR (rnew); ApplyUpdates( V, U); (c) Figura 5.2 Regras para a manutenção da visão V com seus updates sobre a relação relevante R. Nas regras da Figura 5.2, o procedimento GVU_INSERTonR recebe como entrada uma tupla r new inserida em R e retorna o update μ necessário para manter V M. De modo semelhante, o procedimento GVU_DELETEonR recebe como entrada uma tupla r old deletada de Rn e retorna o update μ necessário para manter V M. Estes procedimentos são gerados automaticamente, em tempo de definição da visão, baseado nas ACs de V M que são relevantes para Rn. A seguir, iremos discutir os algoritmos para compilar GVU_INSERTonR e GVU_DELETEonR a partir dos ACs de V M.

66 Algoritmo para compilar GVU_INSERTonR A Figura 5.3 apresenta o algoritmo Generate_GVU_INSERTonR, cuja a entrada é M[R], o conjunto de CAs de V M que são relevantes para R, e compila o procedimento GVU_INSERTonR, cujo parâmetro é r new. Entrada: M[R], o conjunto de ACs relevantes para a relação R Saída: Procedimento GVU INSERTonR com o parâmetro r new τ := { U := ; ; For all ΨC: :C R[A1,, An] in M[R] do GVUI[CA1]; //computa os procedimentos de manutenção para ΨC: :C R[A1,, An] For all ΨC: :C R[A1,, An] in M[R] do GVUI[CA2]; For all ΨC: :P R in M[R] do GVUI[CA3]; //computa os procedimentos de manutenção para ΨC: :C R[A1,, An] //computa os procedimentos de manutenção para ΨC: :P R For all ΨC: :P R/ in M[R] do GVUI[CA4]; //computa os procedimentos de manutenção para ΨC: :P R/ For all ΨC: :P R/ in M[R] do GVUI[CA5]; //computa os procedimentos de manutenção para ΨC: :P R/ For all ΨC: :P R/{A1,, An in M[R] do GVUI[CA6]; //computa os procedimentos de manutenção para ΨC: :P R/{A1,, An For all ΨC: :P R/ /B in M[R] do GVUI[CA7]; //computa os procedimentos de manutenção para ΨC: :P R/ /B For all ΨC: :P R/ {B1,, Bnin M[R] do GVUI[CA8]; //computa os procedimentos de manutenção para ΨC: :P R/ {B1,, Bn For all ΨC: :P R1/ in M[R] do GVUI[CA9]; //computa os procedimentos de manutenção para ΨC: :P R1/ For all ΨC: :P R1/ /B in M[R] do GVUI[CA10]; //computa os procedimentos de manutenção para ΨC: :P R1/ /B For all ΨC: :P R1/ {B1,, Bnin M[R] do GVUI[CA11]; //computa os procedimentos de manutenção para ΨC: :P R1/ {B1,, Bn Return(τ). Figura 5.3 Algoritmo Generate_GVU_INSERTonR. Para cada AC em M[R], o algoritmo executa o procedimento correspondente GVUI. GVUI gera um conjunto de procedimentos o qual computa, em tempo de atualização

67 67 do banco de dados, um conjunto de updates requeridas para a manutenção de V M com relação a e a inserção de r new na relação R. Como exemplo, a Figura 5.4 apresenta o procedimento GVUI[CA1] que contém os procedimentos induzidos pelas ACs do tipo C = R[A1,..., An] quando ocorrem inserções em R. Os Procedimentos GVUI[CA] para todos os tipos de ACs são apresentados no Apêndice A. // Computa os procedimentos para: C = R [A1,...,An] τ := + s:= GenerateURI[ ](rnew);" + U := U u { InsertTriple(s, rdf:type", C");";"; end Figura 5.4 Procedimento GVUI[CA1]. Na Figura 5.4, GVUI[CA1] tem os seguintes procedimentos: A instrução s:= GenerateURI[ r new ); para computar as URIs da instância de domínio de C; A instrução U := U + { InsertTripla(s, rdf:type, C ); ; que é usada para incrementar o valor da variável U com a função InsertTriple. O presente trabalho desenvolveu algumas funções embutidas que são utilizadas pelos procedimentos GVUI[CA]. A Tabela 5.1 apresenta as funções embutidas usadas pelos procedimentos GVUI[CA] (GenerateURI, ObtainReferencedTuples e GenerateRDFLiteral). Tabela 5.1 Funções embutidas Funções Embutidas Definição GenerateRDFLiteral(u, A, R, v) v = GenerateRDFLiteral(u, A, R) iff RDFLiteral(u, A, R, v) ObtainsReferencedTuples[ ](t) onde é um caminho de R para T GenerateURI[Ψ](t) onde Ψ é uma CCA para a classe C. GenerateConcat([v 1,.., v n ],v) { u / HasReferencedTuples[ ](t,u) s = GenerateURI[Ψ](t) iff HasURI[Ψ](t, s) v = GenerateConcat(u, A, R) iff concat([v 1,.., v n ],v)

68 68 Ressaltamos que as atualizações da visão, as quais são geradas pelo procedimento GVU_INSERTonR em tempo de atualização do banco de dados, são computadas com base unicamente na atualização do banco de dados e no estado do banco de dados atual e, portanto, não necessitam de acesso à visão materializada. Também é importante notar que a aplicação de em V M opera exclusivamente no estado de visão atual, ou seja, elas não acessam o banco de dados atual. Essas características são importantes quando a visão é mantida externamente porque o acesso a um banco de dados remoto pode tornar o processo de manutenção lento. Por exemplo, a Figura 5.6 mostra o procedimento GVU_INSERTonPapers, que calcula as atualizações necessárias para manter a visão ISWC_RDF no que diz respeito às inserções na relação Papers. Pela definição 4.6 do capítulo 4, temos que o conjunto de ACs relevantes para Papers é M[Papers] = {CCA2, DCA9, OCA5 (ver Tabela 4.4). Assim, o procedimento de manutenção GVU_INSERTonPapers é computado pela união de cada bloco de procedimentos de manutenção gerados pelos procedimentos GVUI[CA1], GVUI[CA4] e GVUI [CA5], respectivamente. Nossa estratégia para provar que as regras U são criadas corretamente consiste em demonstrar que o novo estado da visão obtida pela aplicação de U em VM é consistente com o novo estado de banco de dados, um conceito definido da seguinte forma: Definição 5.1 U mantém corretamente VM a partir de update se e somente se, para cada par de estados S1 e S2 de S, temos que S1 e S2 são estados que correspondem, respectivamente, ao antes e depois da atualização, e V1 e V2 são os estados de V M em S1 e S2, respectivamente, onde U(V1) = V2 (ver diagrama na Figura 5.5). Figura 5.5 Problema de manter incrementalmente uma visão. O procedimento GVU_INSERTOnPapers são apresentados na Figura 5.6.

69 69 U := ; // Updates requeridos pela CCA2 (generados pela GVUI[CA1]) s:= GenerateURI[CCA2](r new ); U:= U u { InsertTriple(s, rdf:type", foaf: Document");"; // Updates requeridos pela OCA5 (generados pela GVUI[CA4]) s:= GenerateURI[CCA2](r new ); Q := ObtainReferencedTuples[FK_Conferences] (r new ); for all t in Q do o := GenerateURI[CCA5](t); U := U u { If conf:conference(o) then InsertTriple(s, conf:conference", o);"; end for // Updates requeridos pela DCA9 (gerados pela GVUI[CA5]) s:= GenerateURI[CCA2](r new ); if nonnull(r new.title) then v = GenerateRDFliteral(r new.title, title", Papers"); U := U u { InsertTriple(s, dc:title", v);"; end if Return(U); end Figura 5.6 Procedimento GVU_INSERTOnPapers Considere, como exemplo, a inserção da tupla em Papers: t = (3, Framework for..., This Paper propose a framework..., 2002, 23541) Supondo que o corrente estado S1 do banco de dados ISWC_REL é mostrado na Figura 4.3. A Figura 5.7 apresenta o conjunto de procedimentos de atualização U retornados pelo procedimento GVU_INSERTonPapers(t).

70 70 InsertTriple(uri/document/3, rdf:type, foaf:document ); if conf:conference(uri/conference/23541) then InsertTriple(uri/document/3, conf:conference, uri/conference/23541 ); InsertTriple(uri/document/3, dc:title, Framework for... ); end if Figura 5.7 View update U retornados pelo procedimento GVU_INSERTOnPapers. novo estado da visão: Aplicando U ao estado da visão V1 apresentado na Tabela 4.8, nós obtemos o v2 = v1 u [ uri/document/3, rdf:type, foaf:document; uri/document/3, conf:conference, uri/conference/23541; uri/document/3, dc:title, Framework for... ; O novo estado do banco de dados é S2 = S1 u {t. A partir de M nós temos M(S2) = M(S1) u M[Papers](t). Também, a partir de M temos: v2 = v1 u [ uri/document/3, rdf:type, foaf:document; uri/document/3, conf:conference, uri/conference/23541; uri/document/3, dc:title, Framework for... ; Portanto, U(V1) = V2. Assim pela Definição 5.1, temos que U mantém corretamente a visão V (visão ISWC_RDF apresentada na Figura 5.1).

71 Algoritmo para compilar GVU_DELETEonR O algoritmo para compilar o procedimento GVU_DELETEonR é ilustrado na Figura 5.8. Este algoritmo é muito similar ao algoritmo GVU_InsertonR (ilustrado na Figura 5.3). GVU_DELETEonR recebe como entrada M[R], o conjunto de ACs de V M que são relevantes para R, e compila o procedimento GVU_DELETEonR, com o parâmetro rold. Para cada AC em M[R], o algoritmo executa o correspondente procedimento GVUD. GVUD gera um conjunto de procedimentos o qual computa, em tempo de atualização do banco de dados, um conjunto de updates requeridos para a manutenção de V M com relação a e a deleção de r old de R. Entrada: M[R], o conjunto de ACs relevantes para a relação R Saída: Procedimento GVU DELETEonR com o parâmetro r old τ := { U := ; ; For all ΨC: :C R[A1,, An] in M[R] do GVUD[CA1]; For all ΨC: :C R[A1,, An] in M[R] do GVUD[CA2]; For all ΨC: :P R in M[R] do GVUD[CA3]; For all ΨC: :P R/ in M[R] do GVUD[CA4]; For all ΨC: :P R/ in M[R] do GVUD[CA5]; For all ΨC: :P R/{A1,, An in M[R] do GVUDCA6]; For all ΨC: :P R/ /B in M[R] do GVUD[CA7]; For all ΨC: :P R/ {B1,, Bnin M[R] do GVUD[CA8]; For all ΨC: :P R1/ in M[R] do GVUD[CA9]; For all ΨC: :P R1/ /B in M[R] do GVUD[CA10]; For all ΨC: :P R1/ {B1,, Bnin M[R] do GVUD[CA11]; Return(τ). Figura 5.8 Algoritmo Generate GVU_DELETEOnR

72 72 Por exemplo, a Figura 5.9 ilustra o procedimento GVUD[CA1] que contém os procedimentos induzidos pelas ACs do tipo C = R[A1,...,An] quando ocorrem deleções em R. Os procedimentos GVUD[CA] para todos os tipos de ACs são apresentados no Apêndice B, com o intuito de facilitar a leitura. // Computa os procedimentos de manutenção C = R[A1,...,An] τ := + s:= GenerateURI[ ](r old ); U := U u { DeleteTriple(s, rdf:type", C");";" end Figura 5.9 Procedimento GVUD[CA1] A Figura 5.10 apresenta o procedimento GVU_DELETEonOrganizations, que computa os updates necessários para manter a visão ISWC_RDF com respeito as deleções na relação Organizations. Pela definição 4.6, temos que o conjunto de ACs relevantes para a relação Organizations é M[Organizations] = {CCA3, CCA4, OCA3, DCA3, DCA4, DCA5, DCA6, DCA7, DCA8. Para Cada AC é gerado um conjunto de procedimentos referentes ao GVUD[CA] correspondente, conforme podemos ver na Figura Considere, como exemplo, a deleção da tupla em Organizations: t = (7, Hewllett,..., Supondo que o corrente estado S1 da fonte de dados ISWC_REL é mostrado na Figura 4.3. A Figura 5.11 apresenta o conjunto de procedimentos de atualização U retornados pelo procedimento GVU_DELETEOnOrganizations(t).

73 73 U := ; // Updates requeridos pela CCA3 (gerados pela GVUD[CA1]) s:= GenerateURI[CCA3](r old ); U:= U u { DeleteTriple(s, rdf:type", conf:postaladdress");"; // Updates requeridos pela CCA4 (gerados pela GVUD[CA1]) s:= GenerateURI[CCA4](r old ); U:= U u { DeleteTriple(s, rdf:type", conf:organization");"; // Updates requeridos pela OCA3 (gerados pela GVUD[CA3]) s:= GenerateURI[OCA3](r old ); U:= U u { DeleteTriple(s, vcard: ADR",?o);"; // Updates requeridos pela DCA3 (gerados pela GVUD[CA5]) s:= GenerateURI[DCA3](r old ); U:= U u { DeleteTriple(s, rdfs:label",?v);"; // Updates requeridos pela DCA4 (gerados pela GVUD[CA5]) s:= GenerateURI[DCA4](r old ); U:= U u { DeleteTriple(s, foaf:homepage",?v);"; // Updates requeridos pela DCA5 (gerados pela GVUD[CA5]) s:= GenerateURI[DCA5](r old ); U:= U u { DeleteTriple(s, vcard:street",?v);"; // Updates requeridos pela DCA6 (gerados pela GVUD[CA5]) s:= GenerateURI[DCA6](r old ); U:= U u { DeleteTriple(s, vcard:locality",?v);"; // Updates requeridos pela DCA7 (gerados pela GVUD[CA5]) s:= GenerateURI[DCA7](r old ); U:= U u { DeleteTriple(s, vcard:pcode",?v);"; // Updates requeridos pela DCA8 (gerados pela GVUD[CA5]) s:= GenerateURI[DCA8](r old ); U:= U u { DeleteTriple(s, vcard:country",?v);"; Return(U); end Figura 5.10 procedimento GVU_DELETEonOrganizations

74 74 DeleteTriple(uri/uri2, rdf:type", conf:postaladdress"); DeleteTriple(uri/organization/7, rdf:type", conf:organization"); DeleteTriple(uri/organization/7, vcard:adr",?o); DeleteTriple(uri/organization/7, rdfs:label",?v); DeleteTriple(uri/organization/7, foaf:homepage",?v); DeleteTriple(uri/uri2, vcard:street",?o); DeleteTriple(uri/uri2, vcard:locality",?o); DeleteTriple(uri/uri2, vcard:pcode",?o); DeleteTriple(uri/uri2, vcard:country",?o); end Figura 5.11 View update U retornados pelo procedimento GVU_DELETEOnOrganizations. Aplicando U no estado da visão V 1 apresentado na Tabela 4.6, nós obtemos o novo estado V 2, apresentado na Figura 5.12, (onde uri2 significa postaladdress/filton/20/road/bristol/bs438qz/uk ): v2 = v1 {uri/uri2, rdf : type, conf : PostalAddress i; uri/organization/7, rdf:type, conf:organization i; uri/organization/7, vcard : ADR,?oi; uri/organization/7, rdfs : label,?vi; uri/organization/7, foaf : homepage,?vi; uri/uri2, vcard : Street,?vi; uri/uri2, vcard : locality,?vi; uri/uri2, vcard : pcode,?vi; uri/uri2, vcard : country,?vi; Figura 5.12 Novo estado V 2 da visão. O novo estado do banco de dados é s2 = s1 - {t. A partir de M, nós temos M(s2) = M(s1) - M[Organizations](t). Porém, nós também temos:

75 75 M(s2) = v1 { uri/uri2, rdf : type, conf : PostalAddress i; uri/organization/7, rdf:type, conf:organization i; uri/organization/7, vcard : ADR,?oi; uri/organization/7, rdfs : label,?vi; uri/organization/7, foaf : homepage,?vi; uri/uri2, vcard : Street,?vi; uri/uri2, vcard : locality,?vi; uri/uri2, vcard : Pcode,?vi; uri/uri2, vcard : country,?vi; Portanto, U(V1) = V2. Assim Definição 5.1, nós temos que U mantém corretamente a visão V (visão ISWC_RDF apresentada na Figura 5.1). 5.5 Conclusões Neste capítulo, foi apresentada uma visão geral dos passos usados no processo de Manutenção incremental. Também foram apresentados os algoritmos que são utilizados para gerar as regras que mantém incrementalmente a visão RDF.

76 76 6 RUBYA RULES BY ASSERTIONS 6.1 Introdução Neste capítulo mostraremos a ferramenta RUBYA (Vania et. al. 2014) que, de forma resumida, contém as seguintes funcionalidades: 1) geração dos mapeamentos entre a Ontologia alvo e o banco de dados relacional, e 2) publicação e materialização dos dados relacionais em um RDF-STORE usando mapeamentos definidos por assertivas de correspondência. A seção 6.2 apresenta os principais componentes da RUBYA. A seção 6.3 aborda a utilização da ferramenta RUBYA no estudo de caso adotado neste trabalho. Por fim, na seção 6.4, apresentaremos nossas conclusões. 6.2 Principais Componentes A Figura 6.1 apresenta os principais componentes da ferramenta RUBYA. Figura Principais Componentes da Ferramenta RUBYA

77 77 RUBYA possui quatro componentes principais: a interface gráfica (GUI), o gerador do esquema da visão RDF (GRVS), o gerador de Regras e procedimentos JAVA (GVMR) e o view Controller, que é responsável por atualizar a visão RDF. Cada componente é responsável pela implementação de uma etapa ou parte de uma etapa do processo apresentado na Seção 5.2. A saída de um componente é entrada para o próximo componente a ser executado, pois são interligados por meio do processo. Para melhor entendimento apresentaremos a seguir os componentes na ordem em que são utilizados no processo, ou seja, desde a geração das ACs até a criação das regras que são a saída final do processo GUI (Graphical User Interface) Uma sessão da ferramenta inicia com o usuário configurando a conexão com o banco de dados fonte e escolhendo a ontologia alvo. A Figura 6.4 apresenta a janela de configuração para a realização dessas tarefas. No separador Ontology Schema (número 1 da Figura 6.2) podemos colocar os dados referentes a ontologia alvo e no separador Database configuration (número 2 da Figura 6.2) podemos colocar os dados referentes ao acesso ao banco de dados fonte. Figura Configuração para acesso à base ISWC_REL

78 78 Uma vez que os esquemas e ontologias foram configurados, o usuário pode carregar os dois esquemas em duas árvores de nós e criar as ACs associando os nós do esquema da ontologia com os nós do esquema do banco de dados. Esta tarefa é feita de forma gráfica pelo uso do componente GUI (como pode ser visto na Figura 6.6 da página 83). As associações criadas na GUI especificam o mapeamento entre o esquema RDF alvo e o esquema relacional fonte. A GUI facilita a geração das ACs, uma vez que as cria a partir das correspondências gráficas que o usuário especifica. Essas ACs serão usadas como entrada para o próximo componente GRVS (Generate RDF view schema) Este módulo é responsável pela geração do esquema da visão RDF a partir das ACs. O componente GRVS irá percorrer a lista de ACs e criar uma ontologia que contenha somente os termos mapeados. Esta ontologia é então exibida na forma de uma árvore na aba RDF VIEW SCHEMA GVMR (Generate Rules) Este componente implementa os algoritmos apresentados no Capítulo 5, os quais geram as regras para cada uma das relações relevantes com a finalidade de fazer a manutenção do esquema da visão RDF. O processo para a geração das regras consiste nos seguintes passos: a) A partir das ACs obtidas, é gerado uma lista das relações relevantes para o esquema da visão RDF. b) Para cada relação relevante V, três regras são geradas: uma para inserções na fonte, outra para deleções na fonte e outra para updates na fonte. Em nossa abordagem, como pode ser visto na Figura 6.3, as regras são geradas na forma de Triggers, store Procedures e métodos Java.

79 79 Figura 6.3 Estrutura de triggers, store procedures e métodos JAVA. A estrutura apresentada na Figura 6.3 segue a seguinte sequência: Para cada relação relevante são gerados três Triggers, um para cada tipo de atualização. Cada Trigger realiza a chamada a um Store Procedure. São criados dois Store Procedures para cada relação relevante: addtable e removetable, que por sua vez fazem a chamada aos métodos GVU_INSERTOnR e GVU_DELETOnR, respectivamente (veja cap. 5, seções 5.3 e 5.4) View Controller O módulo View Controller realiza a materialização inicial a partir das ACs geradas. Isto consiste em triplificar os dados do banco de dados fonte que são relevantes para a visão RDF. Como pode ser visto na Figura 6.4, o View Controller atualiza a visão RDF à medida que os

80 80 Triggers são disparados na fonte de dados relacional. O processo consiste nos seguintes passos: 1. O Trigger é disparado e faz uma chamada ao Store Procedure. 2. O Store Procedure por sua vez invoca o método JAVA correspondente. 3. O método JAVA gera, a partir da tupla de entrada (r new no caso da inserção, r old no caso da deleção e ambas no caso de um update), um conjunto de comandos U e invoca uma chamada ao View Controller. 4. O View Controller por sua vez, gera um conjunto de triplas RDF U a partir de U e executa a atualização U na visão RDF. Esses passos serão descritos em forma de exemplos na seção O View Controller utiliza o servidor Fuseki (servidor de gerenciamento e atualização de grafos RDF, capaz de apresentar e atualizar modelos de grafos RDF pela web usando o SPARQL e o protocolo HTTP). Figura Framework Rubya

81 Implementação do Estudo de Caso Abordaremos nesta seção a aplicação da ferramenta RUBYA ao estudo de caso introduzido na Seção 4.5 deste trabalho. Apresentaremos passo a passo a interação do usuário com a ferramenta, incluindo a configuração para acesso à base de dados fonte, a publicação dos dados RDF gerados pelo mapeamento entre ontologia e base de dados relacional e a manutenção incremental atrávés de alguns exemplos Criação de um Mapeamento entre ontologia e base de dados relacional O usuário inicia uma nova sessão na ferramenta utilizando o componente GUI para configurar o acesso à base de dados relacional e escolher a ontologia exportada. No nosso exemplo, a fonte de dados é o esquema da conferência ISWC (apresentada na Figura 4.1), o qual foi definido neste estudo de caso usando o banco de dados Oracle. A Figura 6.2 mostra a configuração de acesso à base que corresponde aos parâmetros de conexão com o banco de dados. A ontologia alvo utilizada é a ontologia de domínio CONF_OWL que foi apresentada na Figura 4.2. No nosso estudo de caso, essa ontologia foi descrita usando a linguagem Turtle e armazenada em um arquivo local na máquina do usuário. É de salientar que apesar desta escolha para o nosso estudo de caso, a ferramenta também permite que seja escolhida uma URL (como pode ser visto na Figura 6.5). Figura Configuração da Ontologia de Domínio

82 82 Com a conclusão desta etapa inicial, o componente GUI apresenta na Grid (veja Figura 6.6), à esquerda da Tela Principal, uma nova linha com os nomes da ontologia alvo (RDF Target) e do banco de dados relacional fonte (RDB Source). Ao executar um duplo clique nesta linha, as árvores dos dois esquemas são carregadas na aba CA_Editor da tela principal. À esquerda fica a árvore do esquema alvo (Target Schema T) e à direita fica a árvore do esquema fonte (Source Schema S). As demais abas estão inicialmente desabilitadas e vão sendo habilitadas à medida que vamos executando na ferramenta os passos do processo descrito no Capítulo 5. Figura 6.6 Tela principal para criação das ACs 6.3.2Criação das Assertivas de Correspondência Veremos nesta seção como RUBYA torna fácil a tarefa de criar as ACs. Basicamente, o usuário deverá selecionar elementos das duas árvores (Target Schema e Source Schema) que sejam correspondentes e a ferramenta cria a declaração da AC na caixa de texto que fica na parte de baixo da aba CA_Editor. Em seguida, o usuário clica em Salvar e a AC é incluída na lista da aba Mappings (habilitada após a criação da primeira AC).

83 83 A Figura 6.7 mostra a criação de uma AC para o estudo de caso apresentado na seção 4.2, capítulo 4. Na Figura, é mostrada a criação de uma AC de objeto para a propriedade dc:creator que relaciona indivíduos da classe foaf:document com indivíduos da classe foaf:person. Primeiro o usuário navega na árvore T até localizar a propriedade de objetos dc:creator e selecioná-la. Em seguida ele navega na árvore S a partir da tabela Papers passando por um caminho com duas chaves estrangeiras para chegar à tabela Persons. Por fim, ele seleciona a opção Salvar (Save) e a nova AC é incluída na lista conforme podemos observar na Figura 6.8. Figura Criação de uma ACO para a propriedade dc:creator Figura Lista com as ACs criadas até o momento

84 84 Opcionalmente, é possível criar um filtro de seleção em uma ACC. Esta opção para adicionar um Filtro (Add Filter) fica localizada no canto inferior direito da tela (veja Figura 6.7). Quando o usuário seleciona esta opção, o componente GUI apresenta uma nova tela para construção do filtro de seleção (veja Figura 6.9). Figura Exemplo de criação de um filtro de seleção No nosso exemplo, criamos um filtro para selecionar somente os papers publicados após Ao selecionarmos a opção Salvar (Save) o filtro é incluído na ACC foaf:document gerando o seguinte resultado: foaf : Document papers [PaperID], FILTER [papers.year > 2002] Desta forma, vemos que é possível criar facilmente todas as ACs listadas na Tabela 4.3 do nosso exemplo. A Figura 6.10 mostra a lista destas ACs criadas pela ferramenta RUBYA.

85 Geração do esquema da visão RDF A geração do esquema da visão RDF ocorre de forma automática quando o usuário seleciona a opção Create RDF VIEW (pode ser visto na Figura 6.10, canto inferior direito). A figura 6.11 mostra o esquema da visão RDF do nosso estudo de caso. Observe que o esquema contém apenas os elementos que foram mapeados, ou seja, as seis classes com suas respectivas propriedades que possuem ACs associadas.

86 86 Figura Esquema da visão RDF a partir das ACs do estudo de caso Geração das Regras A partir do esquema da visão RDF e das ACs, o componente GVMR executa os passos apresentados na Figura 6.3 gerando todas as regras necessárias para manter a visão RDF. O algoritmo gerou um total de 24 Triggers que correspondem às tabelas relevantes: Person, Paper, Organizations, Conferences, Topics, Rel_Paper_Topics, Rel_Person_Paper, Rel_Person_Organization. O Conjunto de todos os triggers gerados por nossa ferramenta para o estudo de caso pode ser vistos no apêndice C. A figura 6.12 apresenta a aba RULES que mostra as Triggers geradas pela ferramenta RUBYA para a relação Topics. Figura 6.12 Triggers, Store Procedures e botão 'Create Procedures' Geração dos Procedimentos JAVA Após a criação das regras, o usuário pode, então, selecionar a opção criar procedimentos (na ferramenta: Create Procedures), localizado na Figura 6.12, canto inferior

87 87 direito. Neste passo, o componente GVRM executa os algoritmos da seção 5.3 e 5.4 do capítulo 5, gerando os procedimentos JAVA. A Figura 6.13 apresenta a tela onde é mostrado os métodos JAVA gerados pela ferramenta RUBYA. Figura 6.13 Tela de apresentação dos métodos JAVA Para cada Relação relevante é criado um método GVU_InsertOnR e GVU_DeleteOnR. A Figura 6.14 apresenta os métodos JAVA gerados para a relação Topics. O conjunto de todos os procedimentos Java gerado por nossa ferramenta para este estudo de caso pode ser visto no Apêndice D. Métodos GVU_InsertOnTopics public static String GVU_InsertOnTOPICS(Tuple_Topics rnew ){ String S,S1,U=""; Object V,O; S = GenerateURI_Concept_TOPICS(rnew); public static String GVU_InsertOnTOPICS(Tuple_Topics rnew ){ U = U + "InsertTriple("+S+",rdf:type,skos:Concept);"; if (nonnull(rnew.topicname)== true){ V = GenerateRDFliteral(rnew.TOPICNAME,"TOPICNAME","TOPICS"); U = U + "InsertTriple("+S+",skos:prefLabel,"+V+");"; try{ Tuple_TOPICS [ ] Q; Q = ObtainReferencedTuples_FK_BROADER(rnew); if(q!= null) { for(int i=0;i<q.length;i++){ Tuple_TOPICS t = Q[i]; O = GenerateURI_Concept_TOPICS(t); U = U + "if Concept("+O+") then " + "InsertTriple("+S+", skos:broader, "+O+");"; catch (SQLException e) { return U;

88 88 Métodos GVU_DeleteOnTopics public static String GVU_DeleteOnTOPICS( Tuple_Topics rold){ String S,S1,U=""; Object V,O; S = GenerateURI_Concept_TOPICS(rold); U = U + "DeleteTriple("+S+",rdf:type,skos:Concept);"; if (nonnull(rold.topicname)== true){ V = GenerateRDFliteral(rold.TOPICNAME,"TOPICNAME","TOPICS"); U = U + "DeleteTriple("+S+",skos:prefLabel,"+V+");"; try{ Tuple_TOPICS [ ] Q; Q = ObtainReferencedTuples_FK_BROADER(rold); if(q!= null) { for(int i=0;i<q.length;i++){ Tuple_TOPICS t = Q[i]; O = GenerateURI_Concept_TOPICS(t); U = U + "if Concept("+O+") then " + "DeleteTriple("+S+", skos:broader, "+O+");"; catch (SQLException e) { return U; Figura 6.14 Métodos JAVA gerados para a relação Topics Métodos gerados pela ferramenta no Banco de dados e materialização da visão As Triggers, Store Procedures e métodos JAVA só serão executados e criados no banco de dados fonte após o usuário clicar no botão Apply, ilustrado na Figura A Materialização dos dados em triplas RDF irá ocorrer quando o usuário selecionar a opção Materialize View (na Figura 6.13, canto inferior direito) após a execução dos Triggers e métodos JAVA no banco de dados relacional fonte. Neste momento, a ferramenta fará a materialização inicial utilizando o módulo view Controller (ilustrado na Figura 6.4). Após a materialização inicial dos dados da base relacional é possível consultá-los através da URL localhost://3030 que o servidor Fuseki utiliza para o acesso a página do RDF-Store, como ilustrado na Figura 6.15.

89 89 Figura 6.15 Servidor Fuseki na URL localhost:// Gerando o SPARQL Update a partir de atualizações na base de dados relacional. Mostraremos agora dois exemplos de casos de atualizações na fonte de dados relacional. Exemplo : Considere a seguinte Inserção na tabela Organizations: INSERT INTO ORGANIZATIONS(ORGID,NAME,ADDRESS,LOCATION,POSTCODE, URI,HOMEPAGE,COUNTRY) VALUES (8,'UFC','Humberto Monte', 'Fortaleza',' ,'UFC.BR',' Na Figura 6.16 é mostrado o método GVU_InsertOnORGANIZATIONS utilizado para gerar os procedimentos para o view Controller.

90 90 public static String GVU_InsertOnORGANIZATIONS(Tuple_Organizations rnew){ String S,S1,U=""; Object V,O; S = GenerateURI_PostalAddress_ORGANIZATIONS(rnew); U = U + "InsertTriple("+S+",rdf:type,conf:PostalAddress);"; if (nonnull(rnew.country)== true){ V = GenerateRDFliteral(rnew.COUNTRY,"COUNTRY","ORGANIZATIONS"); U = U + "InsertTriple("+S+",vcard:country,"+V+");"; if (nonnull(rnew.address)== true){ V = GenerateRDFliteral(rnew.ADDRESS,"ADDRESS","ORGANIZATIONS"); U = U + "InsertTriple("+S+",vcard:street,"+V+");"; if (nonnull(rnew.location)== true){ V = GenerateRDFliteral(rnew.LOCATION,"LOCATION","ORGANIZATIONS"); U = U + "InsertTriple("+S+",vcard:locality,"+V+");"; if (nonnull(rnew.postcode)== true){ V = GenerateRDFliteral(rnew.POSTCODE,"POSTCODE","ORGANIZATIONS"); U = U + "InsertTriple("+S+",vcard:pcode,"+V+");"; S = GenerateURI_Organization_ORGANIZATIONS(rnew); U = U + "InsertTriple("+S+",rdf:type,conf:Organization);"; if (nonnull(rnew.homepage)== true){ V = GenerateRDFliteral(rnew.HOMEPAGE,"HOMEPAGE","ORGANIZATIONS"); U = U + "InsertTriple("+S+",foaf:homepage,"+V+");"; if (nonnull(rnew.name)== true){ V = GenerateRDFliteral(rnew.NAME,"NAME","ORGANIZATIONS"); U = U + "InsertTriple("+S+",rdfs:label,"+V+");"; String S2= ""; S2 = GenerateURI_PostalAddress_ORGANIZATIONS(rnew); U = U + "InsertTriple("+S+",vcard:ADR, "+S2+");"; return U; Figura 6.16 GVU_INSERTonOrganizations(t) A Figura 6.17 contém os comandos U gerados pelo procedimento GVU_InsertOnORGANIZATIONS. InsertTriple( < InsertTriple( < InsertTriple( < Monte') InsertTriple( <

91 91 InsertTriple( < InsertTriple(< InsertTriple(< foaf:homepage,'htt:// InsertTriple(< InsertTriple(< < Figura 6.17 View update U retornado pelo procedimento GVU_INSERTonOrganizations(t) A partir dos comandos U, o view Controller converte os comandos e gera a atualização SPARQL Update, que é apresentada na Figura PREFIX dc: < PREFIX skos: < PREFIX conf: < PREFIX rdfs: < PREFIX owl: < PREFIX xsd: < PREFIX rdf: < PREFIX foaf: < PREFIX vcard: < PREFIX dcterms: < INSERT DATA { < rdf:type conf:postaladdress. < vcard:country 'BRAZIL'. < vcard:street 'Humberto Monte'. < vcard:locality 'Fortaleza'. < vcard:pcode < rdf:type conf:organization. < foaf:homepage 'htt:// < rdfs:label 'UFC'. < < Figura 6.18 SPARQL Update U executado pelo View Controller no RDF-Store.

92 Por fim, é apresentado na Figura 6.19, o estado da visão RDF após o Insert em Organizations. 92 Figura 6.19 Estado da visão RDF após o insert em Organizations. Exemplo 2: Considere a deleção na tabela Rel_Paper_Topics: DELETE FRM REL_PAPER_TOPICS(PAPERID,TOPICID) VALUES(2,5) Na Figura 6.20 é apresentado o método GVU_DeleteOnRel_Paper_Topics utilizado para gerar os comandos para o view Controller.

93 93 public static String GVU_DeleteOnREL_PAPER_TOPICS(Tuple_Rel_Paper_Topic r old ){ String S,S1,U=""; Object V,O; try { Tuple_PERSON [] Q1 = null; Q1 = ObtainReferencedTuples_FK_PAPER_FK_PUBLICATION_FK_AUTOR(rold); if(q1!= null) { for(int j=0;j<q1.length;j++) { Tuple_PERSON t = Q1[j]; S = GenerateURI_Person_PERSON (t); U = U + "DeleteTriple("+S+", conf:research_interests,?o);"; Tuple_TOPICS [] Q2 = null; Q2 = ObtainReferencedTuples_FK_AUTOR_FK_PUBLICATION_FK_PAPER_FK_TOPIC(t); if(q2!= null) { for(int i=0;i<q2.length;i++){ Tuple_TOPICS t2 = Q2[i]; O = GenerateURI_Concept_TOPICS(t2); U = U + "if Concept("+O+") then " + "InsertTriple("+S+", conf:research_interests, "+O+");"; catch (SQLException e) { try { Tuple_PAPER [] Q1 = null; Q1 = ObtainReferencedTuples_FK_PAPER(rold); if(q1!= null) { for(int j=0;j<q1.length;j++) { Tuple_PAPER t = Q1[j]; S = GenerateURI_Document_PAPER (t); U = U + "DeleteTriple("+S+", skos:subject,?o);"; Tuple_TOPICS [] Q2 = null; Q2 = ObtainReferencedTuples_FK_PAPER_FK_TOPIC(t); if(q2!= null) { for(int i=0;i<q2.length;i++){ Tuple_TOPICS t2 = Q2[i]; O = GenerateURI_Concept_TOPICS(t2); U = U + "if Concept("+O+") then " + "InsertTriple("+S+", skos:subject, "+O+");"; catch (SQLException e) { return U; Figura 6.20 GVU_DELETEonRel_Paper_Topics(t)

94 A Figura 6.21 contém os comandos U gerados pelo procedimento GVU_DeleteOnRel_Paper_Topics. 94 DeleteTriple(< conf:research_interests,?o) if Concept(< then { InsertTriple(< conf:research_interests, < DeleteTriple(< skos:subject,?o) if Concept(< then { InsertTriple(< skos:subject, < Figura 6.21 View update U retornado pelo procedimento GVU_DELETEonRel_Paper_Topics(t) A partir dos comandos U, o view Controller converte os comandos e gera a atualização SPARQL Update, que é apresentada na Figura PREFIX dc: < PREFIX skos: < PREFIX conf: < PREFIX rdfs: < PREFIX owl: < PREFIX xsd: < PREFIX rdf: < PREFIX foaf: < PREFIX vcard: < PREFIX dcterms:< DELETE DATA { < conf:research_interests < < conf:research_interests < < skos:subject < < skos:subject < INSERT DATA { < conf:research_interests < < skos:subject < Figura 6.22 SPARQL Update U executado pelo view Controle no RDF-Store

95 Por fim, é apresentado na Figura 6.23, o estado da visão RDF após a deleção em Rel_Paper_Topics. 95 Figura 6.23 Estado da visão RDF após o Delete em REL_Paper_Topics. 6.4 Conclusões Este capítulo apresentou as principais funcionalidades da ferramenta RUBYA, explicou sua arquitetura, o funcionamento de cada um dos seus componentes e aplicou sua utilização ao estudo de caso adotado. Por fim, foram apresentados alguns exemplos onde se comprovou a exatidão dos resultados obtidos.