Web semântica aplicada ao serviço da Consultadoria jurídica - Lei de arrendamento

Transcrição

1 Nelson Rodrigues Web semântica aplicada ao serviço da Consultadoria jurídica - Lei de arrendamento Engenharia Informática Setembro 2010

2

3 Web semântica aplicada ao serviço da Consultadoria jurídica - Lei de arrendamento Relatório da Disciplina de Projecto Engenharia Informática Escola Superior de Tecnologia e de Gestão Nelson Rodrigues Setembro iii -

4 A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas neste relatório. - iv -

5 Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto. Prof. Doutor Paulo Matos Co-Orientador Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto. Prof. Doutor Nina Aguiar - Co-Orientador Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da disciplina de Projecto. Prof. Doutor Pedro João - Arguente Aceite para avaliação da unidade curricular de Projecto - v -

6 - vi -

7 Prefácio A Web tem vindo a crescer de forma exponencial, não só em número de utilizadores, mas também em conteúdos, resultado da facilidade com que qualquer utilizador pode criar e colocar conteúdos na Web. Surgem novas realidades, novas formas de comunicação, novas formas de relacionamento. Todos nós, de uma forma ou outra, participamos e contribuímos para o crescimento deste universo. Nem o mais ousado visionário foi capaz de antever esta realidade e o impacto da Internet na nossa sociedade. Já poucos ousarão questionar que isto é apenas o início. Esta realidade revolucionou a nossa sociedade, alterou comportamentos, deu-nos outra visão do mundo, abriu horizontes, fez do nosso mundo maior mas mais pequeno. As oportunidades são mais do que nunca e a Internet potenciou novas necessidades. É inegável a sua utilidade como fonte de saber, como forma de partilha de conhecimento, como forma de debater novas ideias. No entanto, toda essa sabedoria está diluída no mesmo informalismo que tem permitido à Web o seu crescimento exponencial. Informalismo esse que nos é inato, a nós enquanto pessoas, na nossa forma de comunicar e transmitir saber. Mas de todo inadequado à utilização de soluções computacionais, as únicas que nos permitirão lidar com tão grande dimensão de conhecimento a inteligência colectiva formada pela contribuição do conhecimento de todos. Criaram-se soluções que de alguma forma contornaram estas limitações. Algumas das quais ficarão para a história da Web e, quem sabe, da própria humanidade, como é o caso do Google. Já quase todos tivemos a oportunidade fazer uma pesquisa, que nos devolve milhares de resultados, mas que é completamente incapaz de obter resultados no contexto por nós desejado. Ou pesquisar determinado assunto e os resultados reportarem a realidades geográficas para nós irrelevantes, mas que se impõem pela dimensão da sua população na Web. Ou ainda, produzir resultados que estão completamente desfasados temporalmente, alguns mesmo caducos. Por estas limitações, pelas crescentes exigências e expectativas e pela constatação que há muito conhecimento inexplorado, que as soluções existentes não conseguem alcançar, levanos a querer reformular, diria mesmo corrigir, este universo. A Web Semântica surge neste sentido propondo a classificação e adjectivação dos conteúdos a nível semântico, possibilitando assim uma Web mais inteligente, que permite a - vii -

8 automatização do seu processamento através de agente inteligentes, criando assim um modelo de conhecimento. Estas bases de conhecimento são a base da Web Semântica. A forma como estão interligadas, permite a inferência de novos conhecimentos, novos factos, de informação mais complexa e valiosa. Este projecto visa contribuir para esta nova realidade, dita de 3ª geração, formalizando computacionalmente o conhecimento existente sobre as anteriores e actual lei do arrendamento urbano. Formalização essa utilizável como base de conhecimento para processamento computacional, que no âmbito deste projecto é testada e aplicada na construção de um sistema de aconselhamento jurídico on-line, onde os utilizadores possam expor os seus casos e interrogar o sistema no sentido de obter automaticamente respostas para as suas dúvidas. A formalização está efectuada em RDF, RDFS e OWL. E a linguagem utilizada para interrogar a base de conhecimento, vulgarmente designada por ontologia, é o SPARQL. Palavras-chave: Web Semântica; Jena; Ontologias; RDF; RDFS; OWL; Inferência. - viii -

9 Agradecimentos Durante o último ano em que estive envolvido na investigação, análise e aprendizagem da tecnologia Web Semântica tive a oportunidade de contar com o apoio de diversas pessoas que directa ou indirectamente contribuíram para a realização deste projecto. No topo quero agradecer ao meu orientador, Professor Paulo Matos, pela ajuda permanente, o seu espírito crítico e determinante em todos os momentos, e o poder contar com a experiência e o estímulo para a realização deste projecto. Não posso deixar de referenciar os diversos professores que me ajudaram, mas principalmente iluminaram ao longo do meu percurso académico, pois sem eles não teria este gosto em aprender. À Professora Nina Aguiar, pela disponibilidade prestada e pela ajuda na parte de índole legal no projecto, pois sem ela, os esclarecimentos da Lei para o desenvolvimento do trabalho seriam decerto uma grande incógnita. À minha família que esteve sempre perto de mim e que me apoiou moralmente e reforçou a motivação durante o meu percurso académico. Aos meus amigos pela ajuda e principalmente pela paciência para comigo em todos os momentos de desespero, prestando sempre boa disposição. O meu profundo apreço também ao Instituto Politécnico de Bragança, por me ter acolhido e fornecido todas as condições de trabalho, durante este percurso. A todos, o meu sincero agradecimento. - ix -

10 - x -

11 Conteúdo 1 Introdução Enquadramento Objectivos Estrutura Introdução da arquitectura Modelo Breve introdução à arquitectura Breve introdução às tecnologias Tecnologias Web Semântica Arquitectura da Web Semântica Ontologias Metadados Modelo RDF Terminologia Tripla Representação RDF Representação gráfica e sintáxica Resource com diversos statements Resources Anónimos Resources como objecto de um statement Tipos de dados RDF Representação de dados com rdf:value Representação de contentores de recursos RDF Schema Conceito Classes e Propriedades Modelo xi -

12 5.4 Propriedades rdf:property e rdfs:datatype rdfs:domain e rdfs:range rdfs:subclassof rdfs:subpropertyof RDF e RDFS OWL Especificação de inferência do OWL OWL Lite OWL DL OWL Full OWL vs RDF e RDFS Operações com Classes Classes Disjuntas Classes Equivalentes União e intersecção Propriedade Propriedades Inversas Propriedade Funcional Propriedade Transitiva Restrições allvaluesfrom hasvalue Cardinalidade Jena Conceitos Arquitectura Criação de Modelo RDF Mecanismos de Inferência Modelação RDF e Schema Mecanismos de Consulta Tipos de Query Sintaxe do SPARQL SPARQL no JENA Domínio do Problema Arquitectura ideal Introdução ao domínio Descrição do domínio Representação do Schema xii -

13 8.5 Estrutura de desenvolvimento Arquitectura de inferência de dados Modo de leitura e escrita da ontologia Representação do Schema GUI Desenvolvimento da Aplicação Escolhas de implementação Implementação da Aplicação Conclusões Avaliação dos Resultados Trabalhos Futuros Bibliografia A Representação do Schema Lei A.1 Modelo gráfico do Schema A.2 Representação das Classes e Propriedades A.3 Código do modelo do Schema A.4 Código do modelo do Schema GUI xiii -

14 Lista de Tabelas Tabela 1 - Elementos RDF Tabela 2 - Classes do RDFS Tabela 3 - Propriedades do RDFS Tabela 4 - Descrição de exemplos de DataType Tabela 5 Alguns tipos de ontologias com o Jena Tabela 6 - Exemplo de Ontologia RDF Schema com o reasoner Tabela 7- Modelo RDF, instanciação do Schema Tabela 8 - Exemplo de código Java para o uso do SPARQL Tabela 9 - Representação do output da query da tabela Tabela 10 - Exemplos de predicados presente no modelo Tabela 11 - Tabela com as propriedades do Schema GUI Tabela 12 - Definição das propriedades e restrições das Classes Tabela 13 - Definição de restrições e propriedades que possuem as propriedades xiv -

15 Lista de Figuras Figura 1 - Representação da arquitectura geral Figura 2 - Simples exemplo de um modelo RDF... 6 Figura 3 - Exemplo de uma query Figura 4 - Resposta a uma query Figura 5 - Representação do modelo em termos de tecnologias Figura 6 Arquitectura da solução Web Figura 7 - Arquitectura da Web Semântica Figura 8 - Acção de um agente perante a adição de duas ontologias Figura 9 - Exemplo simbólico da utilidade de metadados Figura 10 - Exemplo de RDF sentença/tripla" Figura 11 - Representação de diversos statements Figura 12- Representação de resource anónimo Figura 13 - Representação do tipo de resource anónimo Figura 14 - Adicionar um sujeito a um objecto de outro statement Figura 15 - Representação de um container Bag Figura 16- Representação do object property Figura 17 - Representação do DataType property Figura 18 - Exemplo de um domínio associado a um Object Property Figura 19 - Exemplo de um domínio associado a um DataType Property Figura 20 - Exemplo de Rdfs:subClassOf Figura 21 - Exemplo de um modelo ontológico completo RDF+RDFS Figura 22 - Evolução das ontologias, até à chegada do OWL xv -

16 Figura 23 - Modelo das várias variações do OWL Figura 24 - Exemplo propriedade Inversa Figura 25 - Exemplo propriedade funcional Figura 26 - Exemplo de uma propriedade transitiva Figura 27 - Exemplo da restrição allvaluesfrom Figura 28 - Exemplo da restrição hasvalue Figura 29 - Exemplo da restrição de cardinalidade Figura 30 - Arquitectura da Framework Jena Figura 31 - Diagrama de Classes do domínio de Contrato de Arrendamento Figura 32 - Arquitectura de inferência de dados Figura 33 - Exemplo da instanciação de uma Classe do Schema Figura 34 - Exemplo da instanciação de Classes do Schema, com a construção de triplas Figura 35 - Exemplo da comunicação de dados entre a solução Web e o servidor Figura 36 - Schemas utilizados Figura 37 - Exemplo de listas das propriedades Figura 38- Modelo de Schemas Figura 39 - Exemplo da sequência da leitura à instanciação Figura 40- Exemplo de inferência no layout Figura 41 - Exemplo do layout da solução Web Figura 42 Diagrama completo do Schema da Lei com as classes definidas xvi -

17 Lista de Abreviaturas AJAX - Asynchronous Javascript And XML API - Application Programming Interface CSS - Cascading Style Sheets DAML - DARPA Agent Markup Language GUI - Graphical User Interface JSP Java Server Pages MVC Model View Controller OWL - Web Ontology Language POO Programação Orientada a Objectos RDF- Resource Description Framework RDFS - RDF Schema RDQL - RDF Data Query Language RQL RDF Query Language SGML - Standard Generalized Markup Language SPARQL Protocol and RDF Query Language SQL - Structured Query Language URI - Uniform Resource Identifier W3C - World Wide Web Consortium XHTML - Extensible Hypertext Markup Language XML - Extensible Markup Language - xvii -

18 - xviii -

19 Capítulo 1 1 Introdução 1.1 Enquadramento Este projecto enquadra-se na 3ª geração da Web, mais concretamente na Web Semântica, e tem como principal objectivo apreender as tecnologias e princípios que sustentam esta área do saber, com o objectivo de desenvolver soluções que permitam a construção e integração de fontes de conhecimento processáveis computacionalmente. O domínio de intervenção deste projecto é a lei do arrendamento urbano, que é pertinente para uma grande maioria da sociedade Portuguesa e contribuirá para uma maior divulgação e compreensão dos direitos e deveres de cada português. O desejável seria modelar todas as leis em vigor em Portugal, mas tal tarefa não só é de enorme complexidade, como de dimensão insustentável para um projecto de fim de curso. Direccionou-se assim este projecto para um domínio mais restrito, a lei do arrendamento urbano. Disponibilizar uma base de conhecimento processável computacionalmente sobre a Lei de arrendamento urbano é já de si um desafio considerável, no entanto para testar essa base de conhecimento, validar a solução idealizada e dar uma aplicação de cariz prático ao trabalho, que seja visível e útil, entendeu-se aplicar esta base na construção de um sistema de consultadoria jurídica on-line sobre questões de arrendamento. 1.2 Objectivos O desenvolvimento do projecto teve como propósito a investigação de tecnologias relacionadas com a Web Semântica, no sentido de construir sistemas inteligentes (inteligência artificial)

20 Pág. 2 de Introdução Como a área de aplicação é a da Lei do arrendamento urbano, estabeleceu-se como um dos objectivos, o estudo e a análise dessa lei na perspectiva de construir uma base de conhecimento que fosse o mais fidedigna e abrangente possível, capaz de sustentar a solução que foi idealizada. Para especificar a base de conhecimento, sabia-se de antemão ser necessário aprender uma linguagem formal capaz de sustentar a descrição deste tipo de conhecimento e que fosse processável computacionalmente. A escolha incidiu no RDF, mas devido à complexidade do problema, rapidamente se percebeu que seria necessário ir mais longe e foi inevitável incluir nos objectivos a aprendizagem do RDFS e do OWL. Fazia também parte dos objectivos a escolha e adopção de uma ferramenta que permitisse ler e interrogar a base de conhecimentos, no sentido de inferir novos factos. A escolha recaiu sobre o SPARQL para linguagem de interrogação, e na framework Jena para a codificação e inferência de novos factos. O objectivo principal era especificar formalmente, com recurso a RDF, RDFS e OWL, a estrutura da base de conhecimento para a lei de arrendamento urbano e preencher essa base com a informação necessária à correcta aplicação da lei. No sentido de permitir obter respostas a questões sobre casos concretos, havia a necessidade de criar uma forma de anexar à base de conhecimento os factos sobre esses casos e, posteriormente, definir as questões. Assim, o segundo maior objectivo deste projecto era conceber e desenvolver uma solução que permitisse a um utilizador comum inserir factos e questões e, posteriormente, obter respostas inteligíveis, sem que para tal tivesse que possuir conhecimentos de linguagens formais utilizadas na especificação deste tipo de conhecimento. Solução essa que deveria assim ter uma interface através da qual o utilizador pudesse descrever os factos do caso em concreto sobre o qual pretende colocar as questões. Factos esses que apenas traduzem a perspectiva do utilizador sobre o caso em questão e não necessariamente conhecimentos de índole legal. A interface deveria ainda permitir a introdução das questões que o utilizador queira colocar sobre o caso que descreveu. O sistema deverá inferir a resposta final e apresentá-la de forma inteligível ao utilizador acompanhada do conhecimento de índole legal utilizado na sua dedução. Estabeleceu-se também como objectivo garantir o acesso à solução, ao maior número de utilizadores possível. Para tal, a solução deveria ser concebida para funcionar sobre Web, conseguindo assim atingir uma maior amplitude de indivíduos. 1.3 Estrutura A estrutura deste trabalho foi criada com o intuito que o leitor perceba o que se pretende, o que se tem, e o que se fez para tal. O primeiro capítulo visa enquadrar o leitor no tema do projecto, dando a conhecer os objectivos propostos; o segundo capítulo apresenta a arquitectura idealizada e faz uma breve introdução à terminologia e às tecnologias adoptadas; o terceiro capítulo contém uma descrição mais detalhada das tecnologias utilizadas; os conceitos base para a rápida compreensão das ferramentas utilizadas para descrever o modelo

21 Pág. 3 de Introdução de conhecimento estão representados nos capítulos quatro (RDF), cinco (RDFS) e seis (OWL); no sétimo capítulo é efectuada uma introdução à framework Jena, expondo os conceitos, arquitectura, os mecanismos de consulta e a API; no oitavo capítulo descreve-se como foi interpretado o domínio de estudo, explicando a arquitectura, e decisões tomadas na construção do modelo de conhecimento; no nono capítulo estão descritas as ferramentas em qual se desenvolveu todo este trabalho, desde simples validadores de documentos ontológicos, até ferramentas que ajudaram ao desenvolvimento; e por fim, o capítulo de conclusão com o resumo do trabalho, objectivos alcançados, ponderações finais e trabalho futuro.

22 Pág. 4 de Introdução

23 Capítulo 2 2 Introdução da arquitectura 2.1 Modelo A arquitectura do modelo construído possui quatro componentes, tal como é representado na Figura 1. A ontologia 1 definida sobre a Lei de arrendamento, que é uma interpretação o mais fiel possível do que consta no decreto-lei e transversal a qualquer caso em concreto, os factos sobre o caso concreto (que são fornecidos pelo utilizador do sistema), a questão/questões que são igualmente facultadas pelo utilizador, e por último o motor de inferência que irá ser responsável pela obtenção das respostas tendo em conta a ontologia e os factos. Figura 1 - Representação da arquitectura geral. 1 No âmbito da Web Semântica, ontologia é o termo técnico utilizado para designar base de conhecimento

24 Pág. 6 de Introdução da arquitectura O motor de inferência conjuga o conhecimento descrito na ontologia, com os factos descritos pelo utilizador, produzindo mais conhecimento nomeadamente conhecimento sobre a aplicação da Lei ao caso em concreto, até conseguir (se possível) obter as respostas para as questões colocadas. <rdf:description rdf:about=" "> <Senhorio> <rdf:description rdf:about= Nelson > <nome> Nelson </nome> </rdf:description> </Senhorio > </rdf:description> Figura 2 - Simples exemplo de um modelo RDF A representação de uma base de conhecimento, seja da lei ou do caso real, não é fácil de especificar a um utilizador comum, pode-se verificar na Figura 2 a representação formal (RDF/RDFS/OWL) para a seguinte interpretação: Nelson é o nome do Senhorio que pertence ao contrato de arrendamento. PREFIX rdfs:< PREFIX rdf:< SELECT?x WHERE{ {?x rdf:type?aux} UNION {?aux rdf:value?x} FILTER (Regex(?x,"ricardo")) } A especificação das perguntas também não é de fácil compreensão, tal como se verifica na Figura 3, mesmo que a linguagem utilizada, o SPARQL, tenha semelhanças com o SQL. As respostas a estas queries 2, mesmo no formato textual e tabular, como o utilizado na Figura 4, são bastante rudimentares nome Obrigacao ================ "Miguel" "III" Figura 3 - Exemplo de uma query. Figura 4 - Resposta a uma query. 2 Query é o termo técnico para designar questões, em especial questões devidamente formalizadas.

25 Pág. 7 de Introdução da arquitectura Figura 5 - Representação do modelo em termos de tecnologias. A representação do conhecimento bem como a gestão do mesmo torna-se assim uma tarefa árdua em termos de análise e escrita do modelo, pois tal como mostra a Figura 5 a representação do conhecimento será através do modelo RDF, e as perguntas são especificadas através do SPARQL. 2.2 Breve introdução à arquitectura Existe uma enorme dificuldade em especificar conhecimento segundo as notações formais, o que é particularmente grave para o utilizador comum que não tem necessariamente conhecimentos sobre o domínio do problema (lei de arrendamento), nem das tecnologias utilizadas nas especificações, mas em especial da experiência de formalizar e desenhar ontologias. Este problema leva à necessidade da criação de um interface que permita, aos utilizadores que não têm formação específica em ontologias, a introdução de conhecimento (respeitante ao caso concreto) e de queries. Atendendo que um dos objectivos do projecto era que a solução a desenvolver estive-se ao alcance do maior número de utilizadores possível, optou-se por criar uma solução Web. Figura 6 Arquitectura da solução Web.

26 Pág. 8 de Introdução da arquitectura A Figura 6 exibe a arquitectura da solução, onde se pode identificar as bases de conhecimento, o motor de inferência e mecanismo de interrogação (SPARQL), e a solução utilizada para integrar todos estes elementos a framework Jena. Pelo facto do Jena estar desenvolvido em Java, isto é, toda sua API é em Java, a escolha da solução para a geração das páginas recaiu naturalmente nas Servlets do Java Enterprise Edition. Daí a inclusão na arquitectura da solução de um contentor Web e de um servidor capaz de executar as servlets, que no caso deste projecto foi o Glassfish. No browser correm as páginas produzidas a partir das servlets, construídas com XHTML, CSS para definir estilos e Javascript com recurso à framework JQuery para produzir alguns efeitos visuais, bem como efectuar os acessos via AJAX. Para que tudo isto funcione houve um conjunto de pequenos problemas que tiveram que ser resolvidos, nomeadamente relacionados com o elevado número de vocábulos existentes na linguagem natural, com compatibilização de notação e a introdução de erros de escrita (ver Capítulo 8.6). De forma resumida a solução passou por permitir que os utilizadores construam as frases que descrevem os seus factos recorrendo a um conjunto de termos pré-definidos. Termos esses obtidos dinamicamente a partir da ontologia. O utilizador escolhe o termo (predicado) e completa a frase definindo o sujeito (recurso) e o complemento (recurso/valor). Em função do predicado escolhido e do evoluir da descrição do caso, poderá acontecer que as frases surjam parcialmente preenchidas (para lá do predicado). No sentido de optimizar o processo de descrição do caso, concebeu-se uma solução que vai condicionando os predicados disponíveis a cada instante. Para tal criou-se uma metaontologia que entre outras coisas, estabelece a ordem pela qual os predicados devem ser eventualmente preenchidos. Essa ordem corresponde à sequência que um especialista da área (advogado) utilizaria para apurar os factos. Assim, inicialmente surgem alguns predicados e conforme o utilizador vai construindo as suas frases, são inferidos novos conhecimentos e determinados novos predicados a utilizar. Outros há, que vão deixando de estar disponíveis (pelo facto de já estarem preenchidos). De notar no entanto que isto não obriga à utilização de todos os predicados e nem sequer é relevante para efeitos de obtenção das respostas. Apenas tenta-se levar o utilizador a facultar a informação que é efectivamente relevante e na sequência que provavelmente lhe é mais natural, utilizando uma notação compatível e à prova de erros. Grande parte disto desta tarefa é feita com recurso a AJAX, que passa o facto introduzido para o servidor, este converte esse facto na notação correcta, acrescenta-o à ontologia (parte que contém os factos), infere novos conhecimentos, apura os predicados aplicáveis e devolveos ao browser. Este actualiza o resumo dos factos já introduzidos e a lista de predicados disponíveis para a descrição de novos factos. A qualquer instante o utilizador pode dar por concluída a introdução dos factos e formular a pergunta com base em todos os predicados, sujeitos e complementos existentes na ontologia (resultantes da ontologia de base e dos factos introduzidos). A pergunta é remetida para o servidor, convertida em SPARQL e executada. O resultado traduz todos os passos utilizados

27 Pág. 9 de Introdução da arquitectura na inferência para se alcançar a resposta (ou respostas). Esse resultado é processado no sentido de produzir uma resposta legível para utilizadores comuns, o que é feito produzindo frases do tipo causa consequência, recorrendo aos predicados, sujeitos e complementos existentes na ontologia. Cada frase do resultado é sustentada pelo(s) artigo(s) do decreto-lei que justifica a relação de causalidade. Convém acrescentar que apesar da arquitectura estar completamente definida e de ter havido o cuidado de construir protótipos que validassem as várias funcionalidades, não foi no entanto possível concluir no prazo previsto para este projecto um protótipo que integrasse numa única aplicação todas as funcionalidades descritas, bem como outras que serão imprescindíveis para utilizar esta solução como um consultor real (registo de utilizadores, gestão de casos, etc). 2.3 Breve introdução às tecnologias Ontologias O termo já desde há muito tempo é utilizado na área da filosofia, representa o estudo da existência. Foi adoptado mais recentemente no campo da inteligência artificial, como forma de designar uma descrição bem definida (formal) sobre um conjunto de entidades e as suas relações. No domínio da partilha do conhecimento, o termo refere-se a especificação de uma conceituação, representação de um conhecimento. RDF O RDF é, como o nome indica, uma framework que permite a representação de recursos da Web. O conceito usado pelo RDF é bastante simples, pois consegue-se abstrair do problema, onde tudo são recursos, como por exemplo livros, endereços, pessoas. Recursos esses que podem ter predicados, como nome, idade ou pai, para os quais se podem definir valores ao associar com outros recursos. O RDF contempla um conjunto de predicados generalistas mas muito abrangentes e adequado a um grande número de problemas e de um vasto conjunto de tipos de literais. A notação mais utilizada para o RDF tem por base o XML, no entanto o RDF por si só não impõe que seja esta notação, isto é, podem ser usadas outras notações. O RDF não se prende assim com a notação, mas apenas com os conceitos e com a existência de determinados predicados e tipos de valores. É a solução de base para a descrição de ontologias recomendada pelo W3C. Exemplo de descrição de um modelo Rdf: <rdf:description rdf:about=" <Autor> <rdf:description rdf:about= alunos/nelson > <nome> Nelson </nome> </rdf:description>

28 Pág. 10 de Introdução da arquitectura </Autor> </rdf:description> RDF Schema O RDFS é uma notação mais evoluída do que o RDF, que está para este último como o XML Schema está para o XML. Define um conjunto de predicados com uma semântica bem estabelecida e interpretável pelos motores de inferência compatíveis, que visam especialmente descrever a estrutura das ontologias. OWL A expressividade do RDF e do RDFS nem sempre é suficientemente clara e poderosa para descrever todo o tipo de ontologias. O OWL é um acrónimo para Web Ontology Language, foi proposto pelo W3C, com objectivo de complementar o RDF/RDFS fornecendo uma maior expressividade e um maior leque de relações úteis para a construção de ontologias mais exigentes. Na realidade o OWL, não é uma única linguagem, mas sim um conjunto de três linguagens que se diferenciam pelo nível de expressividade (número de predicados disponíveis), cabe ao utilizador a escolha da linguagem mais favorável e produtiva para a sua ontologia. JENA A framework Jena disponibiliza um ambiente de programação em Java para desenvolvimento de ontologias. Através desta framework, de código aberto, é possível desenvolver desde descrições ontológicas descritas em RDF até ao OWL. Possui variadíssimas ferramentas, modelos de inferência de regras, capacidade de processar linguagens de interrogação (RQL/SPARQL) no sentido de interrogar os modelos construídos, bem como a importação e persistência de modelos. Reúne assim um leque completo de soluções necessárias ao desenvolvimento de aplicações para a Web Semântica.

29 Capítulo 3 3 Tecnologias 3.1 Web Semântica Arquitectura da Web Semântica A Web Semântica tem vindo a desenvolver as ferramentas para aumentar as potencialidades da Web e da comunicação entre o ser Humano e os Computadores. Para a descrição de recursos, da lógica, da própria semântica dos recursos, foi criada uma arquitectura (ver Figura 7) inicialmente por Tim Berners-Lee (Berners-Lee, Hendler, 2001), e pelo W3C, (XML bem como RDF são duas tecnologias desenhas e criadas pelo W3C), um conjunto de várias camadas para a descrição da divisão da arquitectura da Web Semântica. A existência de cada camada não depende das camadas superiores, podendo depender de si própria ou de camadas inferiores. Por exemplo, a camada de RDF juntamente com RDF Schema (RDFS) é mais abstracta, e não tão especializada como a camada XML. Uma ontologia na Web Semântica é descrita num nível superior do RDF e RDFS. URI e Unicode Universal Resource Identifier, fornece uma string bem formatada que descreve unicamente um recurso, por exemplo o código ISBN de um livro, identifica univocamente este livro, ou um endereço Web, etc. XML- é um standard usado na troca de informação na Web, permitindo a estruturação dos dados sem a descrição do seu significado

30 Pág. 12 de Tecnologias RDF- descreve a informação, possibilitando a sua estruturação, mas consegue descrever o seu significado, bem como meta-dados. RDF Schema - é uma extensão do RDF, mas possui a capacidade de construir objectos de modelo dos dados, descrevendo o significado dos mesmos. Ontologias Conjunto de conceitos e termos interligados para descrever uma determinada área do conhecimento, ou a representação para o conhecimento nesse domínio [Swartout e Tate, 1999]. Lógica - proporciona a descrição de regras, de modo a enriquecer as ontologias. Prova e Confiança - suporta a execução de regras, bem como a avaliação e confiança das mesmas, por exemplo Jena Reasoner (usado no trabalho), SWI-Prolog, Jess, etc. SPARQL Figura 7 - Arquitectura da Web Semântica Ontologias Uma Ontologia é um modelo acordado, dentro de um domínio de interesse, este vocabulário representa uma linguagem mais rica para a sua descrição, possibilita restrições nos seus recursos e propriedades. Comparando com a taxonomia 4, as ontologias representam num nível mais elevado e mais flexível, podendo definir a semântica dos termos dos vocabulários, as relações e conceitos dos termos interligados [Cardoso, 2007]. 3 Fonte : Tim Berners-Lee (2005), comentada pelo autor 4 Uma taxonomia é uma terminologia na qual os termos são organizados de forma hierárquica. Cada termo pode compartilhar um relacionamento de um nó pai e um nó filho (especialização/generalização) com um ou mais elementos da taxonomia.

31 Pág. 13 de Tecnologias O termo ontologias tem vindo a ser cada vez mais usado, devido à necessidade de representar conhecimento numa área em ascensão como a Web Semântica. As ontologias são uma forma de descrever conhecimento processável computacionalmente, mas também para aumentar a comunicação entre computadores e humanos. Existem três principais razões para usar Ontologias [Jasper e Hschold, 1999], elas são: Ajudar na comunicação entre os humanos e os computadores Alcançar a interoperabilidade entre sistemas de softwares Ajudar a melhorar o design e a qualidade da arquitectura do sistema de software Tecnicamente é possível fazer a analogia do modelo Ontológico com o modelo de Programação Orientada a Objectos, ambos partilham os conceitos de classes, heranças e propriedades [Fensel, 2001]. Figura 8 - Acção de um agente perante a adição de duas ontologias. Descrição: Inferência feita por um agente perante a adição de duas ontologias, adicionando os recursos numa ontologia final, com mais recursos, deixando assim a ontologia final mais rica. Tal como acontece nas linguagens de POO, a vantagem de possuir classes que definem um pequeno domínio, e a reutilização dessa mesma classe para diversas actividades, é semelhante ao que acontece com as ontologias. Os agentes acedem a esses domínios, para realizar diversas tarefas. É possível fazer a união de classes, contendo as suas propriedades. Na Web Semântica procura-se a mesma perspectiva, criar o mesmo efeito com as Ontologias, contendo assim mais informação no seu modelo final (ver Figura 8). Ideologicamente conforme se descrevem novas ontologias, agentes de software devem entende-las e processa-las. A sua mutação deve ser realizada tão eficazmente que qualquer nova query é sobre uma nova base de conhecimento actualizada. Tendo assim sempre a informação imediata, explorando um modelo mais inteligente. Actualmente existem várias linguagens para descrever ontologias, mas a que denota mais crescimento é OWL, a sua descrição será feita posteriormente.

32 Pág. 14 de Tecnologias Metadados Existe uma enorme tendência do ser humano de inferir conhecimento para os computadores, tendo já uma larga história de linguagem de marcação (SGML, XHTML, XML), para estandardizar dados segundo um modelo. O problema encontra-se no significado, pois os dados são interpretados como simples tags, não existe um significado semântico para descrever a semântica da estrutura. Pode-se entender como meta-dados, os dados que definem os próprios dados (ver Figura 9). Um catálogo de uma livraria é um meta-dado pois, possui informação que descreve publicações de livros (dados). Figura 9 - Exemplo simbólico da utilidade de metadados. Vejamos o seguinte exemplo: <h1>centro de Apoio ao Cidadão </h1> Bem vindo ao nosso portal Portal de Apoio ao Cidadão Temos ao seu serviço aplicações para simular, a fidelidade do seu Contrato de Arrendamento. Caso queria falar com um especialista contacte o nosso pessoal, o nosso advogado Nelson. Se tiver algum problema na aplicação contacte o administrador do site Ricardo Rodrigues. <h2>horas para contactar/h2> Seg. 11h 17h A interpretação deste código em XHTML, computacionalmente não passa de simples tags. O objectivo é ensinar a semântica das palavras ao computador, pois Ricardo Rodrigues e Nelson, não têm significado nenhum, o primeiro passo da Web Semântica é dar a estes recursos algum significado. Vamos construir então um modelo meta-dados. <empresa> <nome> Centro de Apoio ao Cidadão </ nome> <serviços> Contrato de Arrendamento </serviços> <pessoal> <advogado> Nelson </advogado> <administradorsistema> Ricardo Rodrigues </administradorsistema> </pessoal> </empresa >

33 Pág. 15 de Tecnologias A simples etiquetagem dos conteúdos já possibilita executar procedimentos computacionais mais avançados, por exemplo, já é possível determinar com toda a facilidade o nome da empresa, o tipo de serviços prestados ou identificar as pessoas que trabalham nessa empresa. Pode-se verificar que o XML foi um pequeno passo, para a larga caminhada de tentar criar um modelo ontológico perfeito para a compreensão do significado dos dados. Mas o XML, não permite que o computador entenda o significado dos meta-dados (Schema). Consegue identificar esses meta-dados, mas não que eles possam significar. Sendo esta a principal razão que limita a utilização do XML na especificação de ontologias. É necessário assim partir para uma camada superior na arquitectura da Web Semântica, para o RDF juntamente com o RDFS, ou mesmo para o OWL. Como se demonstra no capítulo seguinte, o modelo RDF consegue fazer isto automaticamente dando sentido aos recursos.

34 Pág. 16 de Tecnologias

35 Capítulo 4 4 Modelo RDF Desenvolvido pelo, o RDF é uma plataforma que permite estandardizar definições de metadados, sendo como uma nova representação de recursos da Web. Esta representação possui fortes ligações ao XML, juntos, tornam-se a base da descrição da Web Semântica, pois possuem a competência da construção de ontologias. É bastante versátil ao ponto de se conseguir moldar a informação de uma forma bastante consistente (devido à última camada confiança da Figura 7), para que seja processada uniformemente por máquinas. A capacidade da descrição do modelo RDF, assenta na descrição de modelos URI, e uma sintaxe com muitas parecenças com XML, para a descrição de um modelo de dados, em que descreva dados e meta-dados é necessário: Descrever os tipos de recursos que existam Descrever a concepção estrutural de conjuntos de recursos Descrever a relação entre os recursos Na descrição do modelo de dados inicia-se no topo o recurso Things 5, tudo o resto é derivado deste. Existem assim recursos, com propriedades associadas a eles. As propriedades têm e podem ter tipos de propriedades ligados através de um valor, podendo ser outro recurso. As propriedades também têm o objectivo de estabelecer o tipo de relação associado ao recurso. 4.1 Terminologia O modelo básico consiste em três tipos de objectos: Resources - são identificados por um URI, podem ser a descrição de qualquer recurso, físico, uma pessoa, um livro ou um objecto conceptual, uma página Web como uma música, uma cor ou mesmo uma classe de things que contenha cores. Podem ser usados para especificar domínios mais específicos como por exemplo, a asa de um 5 Things no contexto do RDF, representa um tipo, um resource, todos os resources, derivam de thing

36 Pág. 18 de Modelo RDF pássaro ou um parágrafo de um documento, qualquer objecto de informação que represente algo, e que possua algum significado acerca de um conceito. Por exemplo: ou Nelson. o Resources Anónimos (reconhecidos também por blank nodes), o RDF não necessita que todas as suas frases tenham resources identificados por referências URI. Utiliza-se porque é-se forçado a produzir um Resource próprio para casos em que a complexidade da ontologia assim o exige, por exemplo, para descrever um carro como aquele carro, ou o Nelson naquele carro, não é usual o utilizador criar casos destes, não se trata de um erro mas sim da maneira como está construída a plataforma. Usualmente são criados internamente pelo programa de inferência, mas não tem que ser passados para o utilizador (ver Figura 12). Property é uma característica que descreve o recurso, cada propriedade tem um significado, para definir valores, descrever recursos, ou mesmo tipos de relações com outras propriedades. A ideia é utilizar things ou URI para identificar relações. Por exemplo: neste caso são considerados verbos: autor, idade, nome. Statement A especificação de um recurso, com o nome da propriedade, mais o respectivo valor, representa um Statement. O valor da propriedade pode ser um Literal ou mesmo um recurso ou outra propriedade. O Statement funciona como uma junção destes três elementos Tripla Forma de representar uma sentença, composta pelos três objectos seguintes: {Sujeito, Predicado, Objecto}, ou podendo ter várias ramificações. { Sujeito, [Predicado], Objecto } /Nelson Autor Nelson Recurso Propriedade Valor da Propriedade Figura 10 - Exemplo de RDF sentença/tripla".

37 Pág. 19 de Modelo RDF A Figura 10 mostra a representação de uma tripla, sendo lida como Nelson é o autor do recurso Apenas são possíveis construções sintácticas, produzidas através de triplas. A estrutura é muito simples, (certos cépticos acreditam que é uma limitação esta ideia das triplas) mas podendo-se tornar bastante complexa com o aumento da ontologia. Sujeito: usualmente identificado por um endereço URL, pois como se destina à Web, descrevendo com URI. Predicado: reconhecido pelo termo propriedade, é o tipo de meta-dados identificados pelo sujeito. Objecto: é o valor do tipo do meta-dados. Este valor pode ser um literal, ou até mesmo um próprio Objecto que representa um sujeito. 4.2 Representação RDF Representação gráfica e sintáxica Gráfica As triplas, além de se poderem interpretar textualmente, podem ser representadas graficamente. A sua realização é feita através de grafos, segundo o modelo convencionado pelo W3C. Como se pode ver na Figura 10, a representação gráfica de uma tripla é obtida através de um círculo oval, que representa um recurso, de setas direccionais que representam as propriedades e de um rectângulo onde se define o valor da propriedade. Sintaxicamente Existem diversas formas para descrever o mesmo grafo. Das notações possíveis, (RDF/XML, N3, N-triples), a que se encontra uniformizada oficialmente pela W3C, é a RDF/XML. Cada descrição de um recurso é representada pela tag <rdf:description> com o atributo <rdf:about>, <rdf:id> ou anónimo. A propriedade como visto anteriormente pode ser definida por um URI, ou um recurso, ou o caso mais simples, um literal. Exemplo 1, o literal é um valor da propriedade: <rdf:description rdf:about=" <Autor> <rdf:description rdf:about= alunos/nelson >

38 Pág. 20 de Modelo RDF <nome> Nelson </nome> </rdf:description> </Autor> </rdf:description> Exemplo 2, a propriedade é um recurso de outra sentença: <rdf:description rdf:about=" <Autor rdf:resource= alunos/nelson /> </rdf:description> <rdf:description rdf:about=" alunos/nelson "> <nome> Nelson </nome> </rdf:description> Exemplo 3, descrição como valor de propriedade: <rdf:description rdf:about=" <Autor rdf:resource= alunos/nelson /> </rdf:description> <rdf:description rdf:about=" alunos/nelson " nome= Nelson /> Exemplo 4, blank nodes, neste caso autor é um recurso anónimo: <rdf:description rdf:about=" <Autor> <rdf:description> <nome> Nelson </nome> </rdf:description> </Autor> </rdf:description> Resource com diversos statements Como é possível confirmar através dos exemplos da secção anterior, é possível construir um recurso com diversos predicados/propriedades, construindo assim um modelo ontológico com vários statements (ver Figura 11)

39 Pág. 21 de Modelo RDF Nelson nome Pessoa País Portugal cidade Lisboa Modelo Rdf/xml Figura 11 - Representação de diversos statements. <rdf:description rdf:about="pessoa"> < >nelson@ipb.pt</ > <nome>nelson</nome> <País>Portugal</País> <cidade>lisboa</cidade> </rdf:description> Resources Anónimos Tal como explicado, a criação de blank nodes, na secção (4.1 Terminologia), torna-se assim mais clara a sua compreensão na Figura 12. Nelson nome nelson@ipb.pt Pessoa País Portugal Morada Cidade resource anónimo Lisboa Figura 12- Representação de resource anónimo.

40 Pág. 22 de Modelo RDF No modelo RDF/XML, é criado um nó fictício para fazer a ligação, neste caso j.0 representa esse resource. <rdf:description rdf:about="pessoa"> <j.0:nome>nelson</j.0:nome> <j.0:morada rdf:nodeid="a0"/> </rdf:description> <rdf:description rdf:nodeid="a0"> <j.0:cidade>lisboa</j.0:cidade> <j.0:país>portugal</j.0:país> </rdf:description> Torna-se comum na construção de ontologias especificar o tipo de resource. Constrói-se assim um modelo mais expressivo, que facilita a inferência de novo conhecimento (ver Figura 13). Nelson nome nelson@ipb.pt Pessoa País Portugal Morada Cidade Morada type Lisboa Figura 13 - Representação do tipo de resource anónimo. Modelo RDF/XML, referenciando o tipo através da tag rdf:type <rdf:description rdf:about="pessoa"> <j.0:nome>nelson</j.0:nome> <j.0:morada rdf:nodeid="a0"/> </rdf:description> <rdf:description rdf:nodeid="a0"> <rdf:type rdf:resource= Morada /> <j.0:cidade>lisboa</j.0:cidade> <j.0:país>portugal</j.0:país> </rdf:description>

41 Pág. 23 de Modelo RDF Resources como objecto de um statement Tal como foi visto anteriormente, o objecto pode ser definido como um Literal, ou como um resource, mas neste caso sem ser anónimo, com um significado, descrevendo um URI, então, o objecto de um statement passa a ser um sujeito de uma sub-frase. Tal como mostra a Figura 14. Nelson nome Conta Conta_ 13 dominio endereço ipb.pt nelson@ipb.pt Pessoa País Portugal Morada Cidade Morada type Lisboa Modelo RDF/XML, é adicionado mais um Resource para Conta_ 13 <rdf:description rdf:about="pessoa"> <j.0:nome>nelson</j.0:nome> <j.0:morada rdf:nodeid="a0"/> < rdf:resource="conta_ 13"/> </rdf:description> <rdf:description rdf:nodeid="a0"> <rdf:type rdf:resource= Morada /> <j.0:cidade>lisboa</j.0:cidade> <j.0:país>portugal</j.0:país> </rdf:description> <rdf:description rdf:about="conta_ 13"> <dominio>ipb.pt</dominio> <endereço>nelson@ipb.pt</endereço> </rdf:description> 4.3 Tipos de dados RDF Figura 14 - Adicionar um sujeito a um objecto de outro statement. Para a descrição dos modelos ontológicos, estão disponíveis diversos tipos de dados definidos no próprio standard do RDF. Nas secções seguintes irão ser explicados alguns desses tipos. A Tabela 1, contem os elementos que são utilizados com mais frequência.

42 Pág. 24 de Modelo RDF RDF rdf:type rdf:property rdf:xmlliteral rdf:value rdf:alt, rdf:bag, rdf:seq Tabela 1 - Elementos RDF Descrição Define o tipo de um recurso, através de outro recurso. Elemento que representa um predicado, para descrever a relação binária existente numa tripla. Elemento que representa o objecto, como sendo literal. Serve para descrever o fim de recurso com um valor. Conjunto de contentores para recursos. Tipos de dados mais usados no modelo RDF simples, possui o prefixo rdf: que define sintacticamente vocabulários pertencentes a Representação de dados com rdf:value Nem todos os dados são descritos com a simples sentença {sujeito, [predicado], objecto}, por vezes e como visto anteriormente há a necessidade de expandir o nosso modelo e criar outros tipos de recursos, para definirem uma sentença, tal como na Figura 14, existem tipos para recursos. Existem variadíssimos tipos para atribuir a recursos, contudo o rdf:value sendo também um tipo de valor, pode variar de ontologia para ontologia. É necessário perceber até que ponto é vantajoso utilizar este tipo, para representar o tipo do resource. Por exemplo: o tipo date que irá ser demostrado mais tarde, é utilizado para definir a data, seja em qualquer domínio em que esteja definido, mas se descrever um o tipo value para um recurso e noutro domínio descrever exactamente com o mesmo id/nome um recurso com significado completamente diferente, podem possuir sentidos iguais para a máquina de inferência. É por isso que se deve usar na prática com alguma abstracção e não no contexto, pois esse mesmo sentido pode ser perdido quando o motor de inferência conjuga dois domínios diferentes, resultados mesclados Representação de contentores 6 de recursos Por vezes na ontologia é necessário utilizar contentores para guardar vários elementos do mesmo tipo. Por exemplo, para referenciar os alunos do IPB. 6 O termo resulta da tradução de containers, Poder-se-ia utilizar colecções

43 Pág. 25 de Modelo RDF No modelo do RDF, existem três tipos distintos de contentores: rdf:bag pretende guardar recursos ou literais onde a ordem e a repetição dos valores não é relevante (ver Figura 15). rdf:seq ao contrário do anterior, este tipo de contentor tem o conceito de ordenação. rdf:alt representa um conjunto de recursos ou literais, mas a propriedade associada, só pode estar afecta a um elemento. Modelo RDF/XML do container Bag <rdf:description about=" <estudantes> <rdf:bag> <rdf:li rdf:resource=" /alunos/nelson "/> <rdf:li rdf:resource=" /alunos/ricardo "/> <rdf:li rdf:resource=" /alunos/rodrigues "/> </rdf:bag> </estudantes > </rdf:description> m estudantes rdf: type rdf:_1 rdf:_2 rdf:_3 /alunos/nelso /alunos/ricardo /alunos/maria rdf:_bag Figura 15 - Representação de um container Bag A descrição dos restantes contentores assenta na mesma nomenclatura rdf seguido do tipo de contentor, para as colecções basta usar a tag <rdf:parsetype= Collection >, e colocar os recursos dentro da colecção, como mostra o seguinte exemplo: <rdf:description rdf:about=" <menu rdf:parsetype="collection"> <rdf:description rdf:about="/artigos.htm" /> <rdf:description rdf:about="/livros.htm" /> <rdf:description rdf:about="/revistas.htm" /> </menu> </rdf:description>

44 Pág. 26 de Modelo RDF

45 Capítulo 5 5 RDF Schema 5.1 Conceito Através do RDF conseguimos descrever o nosso vocabulário, usando recursos, mas não conseguimos definir sentenças de um domínio particular, nem semânticas desse domínio. RDF Schema, (RDFS, 2004) fornece esse tipo de sistema para a descrição do RDF. Comparando ambos, o RDFS é mais evoluído tecnologicamente, sendo uma extensão semântica do RDF, consegue construir objectos de modelo, dos actuais dados que está a referenciar, exprimindo assim o significado. 5.2 Classes e Propriedades Classes Para descrever um domínio particular, podemos utilizar recursos simples, como visto anteriormente. Supondo que queremos descrever um domínio: cadeira leccionado no IPB, por exemplo POO aluno, Nelson Rodrigues este tipo de descrição já era possível, com simples vocabulário RDF. Mas descrever uma classe que defina um meta-dado do próprio recurso, só é possível com o RDFS. As classes definem um termo mais abstracto, sendo este o resultado que se pretende, definir classes que definem tipos de objectos. Por exemplo, a classe Aluno define as propriedades existentes num objecto/instância que seja do tipo Aluno. Sendo o aluno Nelson Rodrigues um desses objectos

46 Pág. 28 de RDF Schema Propriedades Tal como no modelo RDF, as propriedades são utilizadas na construção de triplas. Pretendem definir o tipo de relação entre o sujeito e o objecto. A distinção das propriedades no RDF para o RDF Schema é que pode herdar, propriedades de outras propriedades, definidas no modelo. Em termos de modelação em POO, as instâncias desta classe Propriedades, podem ser pensadas como atributos de uma classe. 5.3 Modelo Como podemos ver na Tabela 2, a classe rdfs:resource, é a classe genérica. Podendo assim modelar casos muito genéricos de um determinado domínio, que caso contrário não seria possível. Tabela 2 - Classes do RDFS 7 Classe rdfs:resource rdfs:literal rdfs:class rdfs:datatype rdfs:container rdfs:containermembershipproperty Explicação Classe resource, pode definir tudo Classe de valores de literal, por exemplo strings e inteiros Classe que define a própria Classe Classe que define tipos de RDF (RDF datatypes) Classe que define colecções RDF Classe que define propriedades de membros de colecções rdf:_1, rdf:_2,..., todas as que são sub-propriedades de membro Propriedades disponibilizadas pelo RDFS, dando especial atenção ao rdfs:subclassof, rdfs:subpropertyof, rdfs:domain e rdfs:range. Tabela 3 - Propriedades do RDFS 8 Propriedade Explicação domain Range rdf:type O recurso é uma instância de uma classe rdfs:resource rdfs:class rdfs:subclassof O recurso é uma instância de uma subclassof rdfs:class rdfs:class rdfs:subpropertyof O recurso é uma subpropriedade de uma propriedade rdf:property rdf:property rdfs:domain Refere um domain de uma propriedade rdf:property rdfs:class rdfs:range O alcance de um recurso propriedade rdf:property rdfs:class rdfs:label Um recurso de fácil leitura para o humano rdfs:resource rdfs:literal rdfs:comment A descrição de um recurso rdfs:resource rdfs:literal rdfs:member A descrição de um recurso rdfs:resource rdfs:resource rdf:first O primeiro item de um recurso numa lista RDF rdf:list rdfs:resource rdf:rest O resto dos recursos na lista, depois do primeiro rdf:list rdf:list rdfs:seealso Mais informação sobre o recurso rdfs:resource rdfs:resource rdfs:isdefinedby A definição do recurso rdfs:resource rdfs:resource rdf:value Idiomática propriedade usada para os valores rdfs:resource rdfs:resource estruturados rdf:subject O sujeito de um recurso (representando também um rdf:statement rdfs:resource recurso) rdf:predicate O predicado de uma tripla, podendo este ser um recurso rdf:statement rdfs:resource rdf:object O objecto de uma tripla, podendo este ser um recurso rdf:statement rdfs:resource 7 Fonte: 8 Fonte:

47 Pág. 29 de RDF Schema 5.4 Propriedades Na construção de um modelo ontológico, torna-se importante definir novos tipos de propriedades, sobre as quais cai a lógica do modelo, existindo para o tornar mais rico, em termos de vocabulário e mais claro na sua explicação. De seguida mostram-se as propriedades que merecem mais atenção, por razões óbvias rdf:property e rdfs:datatype Das classes que disponibiliza o RDFS, vamos realçar as seguintes: rdf:property rdfs:datatype Neste momento, faz sentido comparar todos os tipos de propriedades, algumas já vistas anteriormente, com o intuito de tornar mais claro a explicação do rdfs:datatype A representação do recurso ligado a um literal, está representado graficamente na Figura 10. Representação de um object property ligado a outro recurso ver Figura 16. Nelson irmão de Tiago Figura 16- Representação do object property Representação de DataType property, ligado a um tipo de dado definido no próprio Schema xml. Contrato Data de vigência " "^^< Figura 17 - Representação do DataType property.

48 Pág. 30 de RDF Schema Lista de alguns tipos na Tabela 4: Tabela Descrição de exemplos de DataType. DataType string gyear boolean gmonthday float gday double gmonth decimal hexbinary duration base64binary datetime anyuri time gyearmonth date NOTATION Como se pode verificar na Figura 17 está ligada a instância de contrato, ao valor , que é um xml:date. Existem dois tipos de DataTypes: Primitivos, são aqueles que são definidos por si mesmos. Derivados, tal como o próprio nome indica, são datatypes herdados por outros datatypes rdfs:domain e rdfs:range Quando usamos o Schema para criar um modelo, também se pode restringir os valores que cada instância de uma classe irá ter, sendo referido à propriedade que se está a usar, inferindo nessa propriedade os tipos de valores que vai ter e o domínio. Por exemplo, as seguintes triplas: 1. Uma das partes rescindiu contrato 2. Inquilino rescindiu do bónus - Figura Ricardo rescindiu a Figura 19 É importante notar que o domínio na frase 1, é uma instância referida como parte, sendo a classe de uma das partes que constitui o contrato bilateral, e na terceira tripla Ricardo é uma instância de Pessoa. É boa programação de uma ontologia restringir as propriedades, para não serem tomadas como valores absolutos. O mesmo princípio deve ser seguido para o tipo de valor que irá ter a propriedade, na continuação do exemplo, o alcance da propriedade na primeira sentença é contrato, no segundo caso é o recurso bónus. Como se pode ver na terceira frase, o alcance é uma instância do XML date. 9 Fonte:

49 Pág. 31 de RDF Schema domain Inquilino rescindiu Object Property range Bónus Figura 18 - Exemplo de um domínio associado a um Object Property. domain Pessoa rescindiu Datatype Property range XMLSchema#date Figura 19 - Exemplo de um domínio associado a um DataType Property rdfs:subclassof O RDFS permite definir instâncias de uma classe, mas permite também definir subclasses de classes. Uma instância pode tirar partido de receber várias características, tal como na programação orientada a objectos, quando herdamos uma classe, esta irá ter o significado da sua classe e das classes das quais herda. Na Figura 20 vemos que a classe Carro é uma subclasse de Veiculo. Veiculo Rdfs:subClassOf Carro Figura 20 - Exemplo de Rdfs:subClassOf.

50 Pág. 32 de RDF Schema rdfs:subpropertyof Tal como o rdfs:subclassof, o subpropertyof baseia-se no mesmo contexto, só que relacionado com propriedades, uma propriedade pode conter propriedades com restrições (rdfs:domain) de domínios diferentes. 5.5 RDF e RDFS Como se tem vindo a mostrar, entre as diferenças do RDF e do RDF Schema, podemos notar que se completam. Trabalhando a níveis diferentes, mas formando juntamente um único vocabulário capaz de descrever completamente uma ontologia. O RDFS num nível mais abstracto permite definir o esquema que se vai usar, especificando as classes e o relacionamento entre elas, bem como as propriedades. Neste momento a atitude perante o RDF muda, pois serve para definir as instâncias das classes que estão no RDF Schema, tal como mostra a Figura 21. range XMLSchema#string nome domain Pessoa domain rdfs:subclass rdfs:subclass range Contrato tem rdfs: subpropertyof assinou RDFS (Schema) rdfs:subclass Inquilino Senhorio Contrato Arrendamento type type assino Ricardo Contrato nº 21 RDF Figura 21 - Exemplo de um modelo ontológico completo RDF+RDFS.

51 Capítulo 6 6 OWL Com aumento do interesse ao nível semântico de representar dados possuindo uma melhor interoperabilidade com o computador, as potencialidades criadas com o RDF+RDFS foram-se tornando cada vez mais limitadas, desenvolvendo e aperfeiçoando novas soluções. Este tipo de aperfeiçoamento levou a subir mais um patamar na arquitectura da Web Semântica (ver Figura 7), desenvolvendo um novo nível de linguagem para a especificação de ontologias. 6.1 Especificação de inferência do OWL O OWL foi criado com uma extensão do RDF, e também do DAML+OIL (ver Figura 22), com o objectivo de melhorar a comunicação com significados da Web. Esta derivação do DAML não é assim tão estranha, pois o DAML foi concebido como um agente de marcação de linguagem do OIL. Este último começou a ser desenvolvido com o intuito de suportar conhecimento de comércio electrónico, com as vantagens inerentes do RDF. Nasce daqui o OWL, também como uma extensão do RDF Schema. Figura 22 - Evolução das ontologias, até à chegada do OWL

52 Pág. 34 de OWL O OWL foi dividido em três especificações, cada um delas suporta diferentes tipos de propriedades, a saber: OWL lite - contém menos predicados e por esse facto foi mais facilmente assimilado pelos motores de inferência OWL DL - garante a compatibilidade com a versão base, mas estende essa versão com mais atributos OWL full versão compatível com a anterior, mas mais completa. O facto de estarem divididos em vários níveis, resulta só e simplesmente de se ter identificado logo à partida que não seria simples e/ou eficiente implementar motores de inferência capazes de perceberem e processarem determinados predicados. A opção foi assim dividir a especificação do OWL em três níveis de concretização diferentes. O OWL full pela sua complexidade acaba por ser a especificação menos suportada pelos motores de inferência. Figura Modelo das várias variações do OWL OWL Lite É dos três casos aquele que possui a sintaxe menos rica e utilizada na especificação das ontologias mais simples. Permite obter soluções mais simples, o que é uma vantagem para quem analisa, pois é a mais fácil de perceber. Por outro lado, não comporta a descrição de situações mais complexas, como por exemplo, a disjunção de classes, cardinalidade, etc. 10 Fonte: OWL: Representing Information Using the Web Ontology language, Lee W. Lacy ano, p.242

53 Pág. 35 de OWL OWL DL OWL DL (description logic), será a escolha para quem pretende mais expressividade do que o OWL Lite, sendo considerada uma sub-linguagem do OWL FULL, permitindo restringir como são usados os construtores do OWL e RDF OWL Full É usada quando se pretende a máxima expressividade, onde haja domínios complexos e exista a necessidade de tal nível. É usado todo o tipo de combinações, inclusive com RDF+RDFS. Se o modelo final for construído no OWL Full, não é possível passar para os anteriores, por exemplo, um modelo descrito em OWL Lite é compatível com OWL DL, e um modelo ontológico no OWL DL é compatível com o OWL Full, mas nunca o caso contrário, sendo somente estas as hipóteses, como se pode ver Figura OWL vs RDF e RDFS A principal transitividade do RDF/RDFS para o OWL é a expressividade. O OWL consegue fornecer um maior e mais potente vocabulário. O RDF Schema possui certas limitações que foram ultrapassadas com o aparecimento do OWL. O OWL possibilita assim novos conceitos, baseados na negação na diferença lógica que é possível definir e descrever. O RDFS não permite fazer, por exemplo: Disjunção de classes - por vezes tem-se a necessidade de fazer esta separação, de classes. Por exemplo, não convém que um inquilino no mesmo contrato seja um senhorio. União/intersecção de classes - na Web Semântica estas são características importantes, pois permitem obter novas classes pela combinação das existentes sem criar classes de raiz, contribuindo assim para construir ontologias mais ricas. Cardinalidade restringir propriedades em termos de cardinalidade, isto é, condicionar o número de instâncias diferentes que podem estar ligadas a uma determinada propriedade, é outra das funcionalidades não suportada pelo RDFS, mas suportada pelo OWL. Por exemplo, o contrato de arrendamento, tem obrigatoriamente duas classes derivadas da classe Pessoa ou conjunto destas (Inquilino e Senhorio).

54 Pág. 36 de OWL Propriedades inversas - quando se define uma propriedade, perante duas classes diferentes, existe a lógica inversa, que o OWL consegue definir. Equivalências - o RDFS não consegue descrever equivalências entre conceitos, sendo também um dos pontos importantes no desenvolvimento de uma ferramenta ontológica que esta consiga expressar a equivalência de conceitos ontológicos de grupos diferentes. Estas são algumas das limitações do RDFS comparativamente ao OWL. De seguida, ir-se-á esmiuçar cada uma destas propriedades, bem como outras. 6.3 Operações com Classes Classes Disjuntas Por vezes tem-se a necessidade de fazer esta separação de classes. Pois o motor de inferência poderá inferir vários tipos de significados numa mesma instância dessas classes. Por exemplo, não convém que no mesmo contrato o inquilino seja também ele o senhorio, faz-se assim então essa disjunção: <owl:class rdf:id="contrato"/> <owl:class rdf:id= Inquilino > <owl:disjoinwith rdf:resource: Senhorio /> </owl:class> <owl:class rdf:id= Senhorio > <owl:disjoinwith rdf:resource: Inquilino /> </owl:class> <owl:objectproperty rdf:id="tem"> <rdfs:domain> <owl:class> <owl:unionof rdf:parsetype="collection"> <owl:class rdf:about="#inquilino"/> <owl:class rdf:about="#senhorio"/> </owl:unionof> </owl:class> </rdfs:domain> <rdfs:range rdf:resource="#contrato"/> </owl:objectproperty> Classes Equivalentes O OWL consegue descrever duas classes como equivalentes. Isto tem enormes vantagens em termos conceptuais no modelo, pois permite juntar várias instâncias de classes diferentes.

55 Pág. 37 de OWL Num nível mais abstracto traz uma vantagem mais poderosa, torna possível afirmar que uma classe de uma ontologia é equivalente a uma outra classe de uma outra ontologia. <owl:class rdf:id= Inquilino > <owl:equivalentclass rdf:resource: Arrendatário /> </owl:class> Isto não só permite compatibilizar ontologias, como criar um vocabulário mais rico União e intersecção O exemplo que se segue ilustra uma situação, que por si só, mostra as vantagens da linguagem comportar mecanismos para a união e a intersecção. <owl:object rdf:id="woman"> <owl:intersectionof rdf:parsetype="collection"> <owl:class rdf:about="#female"/> <owl:class rdf:about="#human"/> </owl:intersectionof> </owl:class/> 6.4 Propriedade 6.5 Propriedades Inversas Esta propriedade serve para definir a relação inversa de uma propriedade. Por exemplo, se uma propriedade Senhorio liga a instância Ricardo à instância Tiago, então existe uma propriedade inversa Inquilino que liga Tiago a Ricardo, ver Figura 24.

56 Pág. 38 de OWL Pessoa rdfs:subclassof rdfs:subclassof Inquilino_de o inversof Inquilino Senhorio domain Senhorio_de range type type Ricardo Senhorio_de Tiago Inquilino_de Figura 24 - Exemplo propriedade Inversa O código OWL que define este exemplo será: <owl:class rdf:id="pessoa"/> <owl:class rdf:id="inquilino"> <rdfs:subclassof rdf:resource="#pessoa"/> </owl:class> <owl:class rdf:id="senhorio"> <rdfs:subclassof rdf:resource="#pessoa"/> </owl:class> <owl:objectproperty rdf:id="inquilino_de"> <owl:inverseof rdf:resource="#senhorio_de"/> </owl:objectproperty> <owl:objectproperty rdf:id="senhorio_de"> <rdfs:domain rdf:resource="#senhorio"/> <owl:inverseof rdf:resource="#inquilino_de"/> <rdfs:range rdf:resource="#inquilino"/> </owl:objectproperty> <Senhorio rdf:id="ricardo"> <Senhorio_de rdf:resource="#tiago"/> </Senhorio> <Inquilino rdf:id="tiago"> <Inquilino_de rdf:resource="#ricardo"/> </Inquilino>

57 Pág. 39 de OWL Propriedade Funcional A propriedade funcional permite identificar univocamente cada instância por propriedade, podendo só aquela propriedade não ter mais que uma instância, restringindo assim o valor. Um exemplo deste tipo de propriedade é a data de nascimento de uma pessoa, em que associado a uma pessoa só pode existir uma única instância da propriedade data de nascimento, caso exista mais que uma, ambas representam a mesma instância. (ver Figura 25). domain tem professor range type Pessoa domain Data de nascimento range type FunctionalProperty XMLSchema#date type type Implica que Nelson e Ricardo São a mesma Pessoa tem aluno P. Matos Data de nascimento Nelson tem aluno Data de nascimento Ricardo Figura 25 - Exemplo propriedade funcional <owl:datatypeproperty rdf:id="data_de_nascimento"> <rdf:type rdf:resource="&owl;functionalproperty"/> <rdfs:domain rdf:resource="#pessoa"/> <rdfs:range rdf:resource="&xsd;date"/> </owl:datatypeproperty> <Pessoa rdf:id="nelson"> <data_de_nascimento rdf:datatype="&xsd;date"> </data_de_nascimento> <tem_professor rdf:resource="#prof_paulo_matos"/> </Pessoa> <owl:class rdf:id="pessoa"/> <Pessoa rdf:id="prof_paulo_matos"> <data_de_nascimento rdf:datatype="&xsd;date"> </data_de_nascimento> <tem_aluno rdf:resource="#nelson"/> </Pessoa>

58 Pág. 40 de OWL Pessoa rdf:id="ricardo"> <tem_professor rdf:resource="#prof_paulo_matos"/> </Pessoa> <owl:objectproperty rdf:id="tem_aluno"> <rdf:type rdf:resource="&owl;functionalproperty"/> <rdfs:domain rdf:resource="#pessoa"/> <rdfs:range rdf:resource="#pessoa"/> </owl:objectproperty> <owl:objectproperty rdf:id="tem_professor"> <rdf:type rdf:resource="&owl;functionalproperty"/> <rdfs:domain rdf:resource="#pessoa"/> <rdfs:range rdf:resource="#pessoa"/> </owl:objectproperty> Como a instância Nelson, representa a mesma instância Ricardo, a pesquisa por exemplo da data de nascimento, pode ser efectuada à instância Ricardo, mesmo não estando implicitamente definido, a data a Ricardo, cabe esta responsabilidade ao motor de inferência Propriedade Transitiva Com o OWL é possível definir propriedades transitivas e usar a transitividade na inferência de novos conhecimentos. Neste contexto, a transitividade pode ser definida da seguinte forma: se T é uma propriedade transitiva que relaciona a com b e b com c, então a e c também estão relacionados via T. A Figura 26 ilustra um caso da aplicação da transitividade à propriedade há transporte, que permite ao motor de inferência obter a instância Lisboa há transporte Bragança. Há transporte Bragança Há transporte Porto Lisboa Há transporte Figura 26 - Exemplo de uma propriedade transitiva <Cidade rdf:id="bragança"/> <owl:class rdf:id="cidade"/> <owl:objectproperty rdf:id="ha_transporte"> <rdf:type rdf:resource="&owl;transitiveproperty"/> <rdfs:domain rdf:resource="#cidade"/> <rdfs:range rdf:resource="#cidade"/> </owl:objectproperty> <Cidade rdf:id="lisboa">

59 Pág. 41 de OWL <ha_transporte rdf:resource="#porto"/> </Cidade> <Cidade rdf:id="porto"> <ha_transporte rdf:resource="# Bragança "/> </Cidade> 6.6 Restrições As restrições podem ser atribuídas a propriedades, bem como a classes. Ambas servem, para restringir, um certo domínio. As restrições de propriedade, permitem especificar uma instância que satisfaz a restrição de uma certa classe allvaluesfrom Permite restringir a um conjunto completo de valores de uma propriedade. Se, por exemplo apenas se quiser instanciar um certo tipo de instâncias, da classe A, que possuam propriedade, tem contrato, mas que sejam todos os valores da classe B. Por exemplo, pretende-se instanciar, todas as pessoas que possuam contrato, ver Figura 27 tem Instância tem Inquilinos tem Direitos Inquilino Figura 27 - Exemplo da restrição allvaluesfrom <owl:class rdf:id="direitos_de_inquilino"/> <owl:class rdf:id="inquilinos"> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#tem"/> <owl:allvaluesfrom rdf:resource="#direitos_de_inquilino"/> </owl:restriction> </rdfs:subclassof> </owl:class>

60 Pág. 42 de OWL hasvalue É possível definir restrições a uma instância, que possuam uma propriedade com um determinado valor, descrevendo assim um tipo de instância com pelo menos uma relação a uma propriedade que liga a uma instância. Por exemplo, como mostra a Figura 28, instanciar uma classe que defina as pessoas residentes em Lisboa. Código Postal Código Postal Figura 28 - Exemplo da restrição hasvalue <owl:class rdf:id="lisboa"> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#codigo_postal"/> <owl:hasvalue rdf:datatype="&xsd;string"> </owl:hasvalue> </owl:restriction> </rdfs:subclassof> </owl:class> Cardinalidade O OWL permite restringir o número de instâncias, especificando a sua cardinalidade. Decompondo esta propriedade, encontramos três funções diferentes. Cardinalidade máxima especifica o número máximo de instâncias ( ) Cardinalidade mínima especifica o número mínimo de instâncias ( ) Cardinalidade especifica um número exacto de instâncias (=) Como se pode pela ver na Figura 29, o número máximo que uma instância de um departamento pode ter é exactamente dois professores. tem Instância tem Departamento tem tem Professores Figura 29 - Exemplo da restrição de cardinalidade.

61 Pág. 43 de OWL <owl:class rdf:id=" Departamento informatica"> <rdfs:subclassof> <owl:restriction> <owl:onproperty rdf:resource="#tem"/> <owl: exactly rdf:datatype="&xsd;nonnegativeinteger">2</owl: exactly > </owl:restriction> </rdfs:subclassof> </owl:class>

62 Pág. 44 de OWL

63 Capítulo 7 7 Jena 7.1 Conceitos Com o aumentar do interesse nos modelos de Web Semântica, existiu uma necessidade de automatizar o processo de desenvolver modelos em código puro em RDF. Brian McBride, um funcionário da HP (Hewlett-Packard) foi o principal responsável pelo desenvolvimento de uma framework de código aberto, a Jena, contendo algumas derivações do projecto SIRPAC. A Jena é uma framework, com API em Java, que contém um conjunto de classes com funcionalidades que possibilitam a criação, gestão e interrogação de ontologias. Tem por base os conceitos do RDF; disponibiliza motores de inferência capazes de processarem todo o tipo de predicados do RDF, RDFS e OWL; permite importar e exportar as ontologias de e para vários formatos; disponibiliza mecanismos de persistência (para ficheiro e/ou base de dados); e é capaz de processar linguagens de interrogação de ontologias como o SPARQL e RQL. Como framework que é, permite que muitos dos conceitos, concretizados através de várias interfaces e classes abstractas, possam ser expandidos e especializados. Por exemplo, o utilizador pode implementar o seu próprio motor de inferência ou especializar o seu modelo ontológico. É ainda de realçar que, provavelmente, é a solução mais utilizada para o desenvolvimento de aplicações para a Web Semântica, com uma comunidade bastante activa e com vários projectos complementares que visam alargar o leque de funcionalidades disponíveis. 7.2 Arquitectura Tal como mostra a Figura 30, a arquitectura da framework Jena é composta no seu núcleo por três camadas principais. A camada denominada por Ontologia API, que oferece um suporte de todas as classes necessárias para trabalhar com os três tipos de representação de ontologias que disponibiliza. O segundo modelo Core Model API, possui as bases para poder manipular todas as características de uma ontologia. E o Inference API (reasoning) que efectua,

64 Pág. 46 de Jena consoante o motor de inferência escolhido, a derivação de novos factos. Possuindo uma plataforma de interrogação dependendo do modelo escolhido. A serialização pode ser efectuada em N3, N-triple, bem como RDF/XML sendo esta última a mais usada. A nível de persistência do modelo, possui o suporte necessário para salvaguardar os modelos em ficheiro ou mesmo em base de dados. Toda esta comunicação entre as várias camadas que constituem o núcleo do modelo é realizável através do Jena Graph Interface. Figura 30 - Arquitectura da Framework Jena É considerada uma mais-valia este tipo de abordagem, transformando internamente o modelo em grafos para melhor interoperabilidade entre as camadas. Possuindo a capacidade de construir um grafo para a representação textual da tripla, tal como foi mostrado nos capítulos anteriores. Todos os objectos criados, derivam de RDFnode, (resources, properties, literals, etc), bem como o ponto de inicio do modelo. 7.3 Criação de Modelo RDF A API do Jena disponibiliza variadíssimas classes. Para a construção do modelo, a class Model trata de toda a manipulação do modelo ontológico; criação de propriedades; criação e adição de novos modelos; características de inferência; etc. É possível criar de raiz um modelo, bem como fazer a leitura de um modelo previamente criado. Pretende-se criar um modelo vazio por defeito, para a implementação da tripla representada na Figura 10: Model mymodel = ModelFactory.createDefaultModel();

65 Pág. 47 de Jena de seguida é necessário adicionar os recursos e, respectivas, propriedades, especificando previamente o espaço de nomes (URI) a que pertence a ontologia. Quando é construído um objecto, torna-se obrigatório passar o URI como argumento, juntamente com o nome do objecto. //Criação do modelo ontológico Model mymodel = ModelFactory.createDefaultModel(); //espaço de nomes String URI = " mymodel.setnsprefix("ipb", URI); //criação do recurso Resource dono = mymodel.createresource(uri +"Nelson"); //criação da proriedade Property autor = mymodel.createproperty(uri +"autor"); //criação de um literal Literal autorvalue = mymodel.createliteral("nelson"); //adição do literal à propriedade dono.addproperty(autor, autorvalue); mymodel.write(system.out,"rdf/xml"); mymodel autor Nelson O Jena permite a representação textual do modelo criado anteriormente, pode-se visualizar vários tipos de formato: N-TRIPLE < < "Nelson" ipb: < ipb:nelson ipb:autor "Nelson" RDF/XML <rdf:rdf xmlns:rdf=" xmlns:ipb=" > <rdf:description rdf:about=" <ipb:autor>nelson</ipb:autor> </rdf:description> </rdf:rdf> Este último modelo de output será o modelo usado no desenrolar do relatório. O enriquecimento e desenvolvimento de uma ontologia baseia-se na criação de novos recursos e propriedades.

66 Pág. 48 de Jena 7.4 Mecanismos de Inferência O Jena disponibiliza vários motores de inferência (reasoners), que à semelhança de motores mais convencionais (como por exemplo, os utilizados em muitas plataformas de Prolog), podem processar regras de inferência especificadas explicitamente pelos utilizadores. Diferem no entanto destes pelo facto de saberem o que fazer com determinados predicados (os definidos pelo RDFS/OWL), sem que para tal o utilizador tenha que fornecer explicitamente as regras que definem o comportamento desses predicados. Assim, tendo por base os factos descritos na ontologia (normalmente com recurso ao RDF), o motor de inferência é capaz de aplicar as regras de derivação, sejam elas explicitamente ou implicitamente fornecidas, para derivar novos factos que podem ser adicionados ao modelo. Para além de permitir a utilização de motores de inferência exteriores à framework (depois de devidamente adaptados), o Jena faculta de base dois motores que diferem entre si na forma de aplicar as regras de inferência, são eles os seguintes: forward Chaning Engine backward Chaning Engine. Como foi visto na secção anterior, existem diferentes tipos de Reasoners, é possível escolher motores mais simples, bem como os mais complexos, inferindo um largo leque de regras. Para especificar esta característica, é necessário chamar o método createontologymodel da classe ModelFactory com o tipo de parâmetro OntModelSpec. Por exemplo, para o caso do OWL Lite com gravação em memória e sem suporte para inferência: OntModel model = ModelFactory.createOntologyModel ( OntModelSpec.OWL_LITE_MEM); Na Tabela 5 abaixo estão representadas diferentes tipos de ontologias, podendo-se combinar. DAML_MEM DAML_MEM_RDFS_INF OWL_LITE_MEM OWL_MEM_RULE_INF RDFS_MEM Tabela 5 11 Alguns tipos de ontologias com o Jena Simples modelo DAML gravado em memória sem suporte para reasoning. A DAML modelo gravado em memória com suporte para a inferência em RSDS. Simples modelo OWL Lite gravado em memória sem suporte para reasoning. Modelo OWL Lite gravado em memória com suporte para inferência. Um simples modelo gravado na memória em OWL Lite Modelação RDF e Schema 11 Chapter 14, PROGRAMMING THE SEMANTIC WEB, Jorge Cardoso

67 Pág. 49 de Jena Por uma questão de organização e de garantir a qualidade do software a desenvolver, deve-se separar conceptualmente os dados (informação concreta) do schema (estrutura da informação). Nas tabelas em baixo estão, representados dois modelos, Schema (Tabela 6) e o model_data (Tabela 7), ambos no mesmo ficheiro, mas é possível carregar separadamente e fazer a inferência para um terceiro ficheiro. Tabela 6 - Exemplo de Ontologia RDF Schema com o reasoner. //------Schema String uri = " OntModel schema = ModelFactory.createOntologyModel( OntModelSpec.OWL_DL_MEM_RDFS_INF); schema.setnsprefix("co", uri); //CLASSES OntClass Contrato = schema.createclass(uri+"contrato"); OntClass ContratoArrendamento = schema.createclass(uri+"contratoarrendameto"); Contrato.addSubClass(ContratoArrendamento); OntClass Pessoa = schema.createclass(uri+"pessoa"); OntClass Inquilino = schema.createclass(uri+"inquilino"); OntClass Senhorio = schema.createclass(uri+"senhorio"); Pessoa.addSubClass(Inquilino); Pessoa.addSubClass(Senhorio); //PROPRIEDADES OntProperty name = schema.createdatatypeproperty(uri+"nome"); name.adddomain(pessoa); name.addrange(xsd.xstring); OntProperty tem = schema.createdatatypeproperty(uri+"tem"); tem.adddomain(pessoa); tem.addrange(contrato); OntProperty assinou = schema.createdatatypeproperty(uri+"assinou"); assinou.addsuperproperty(tem); A construção do Schema, pode assim estar representada num modelo separado do modelo de dados. De seguida estão representadas as instâncias do Schema, bem como a definição do reasoner, que irá inferir os novos factos. Estes factos resultantes da inferência do Schema mais o RDF, podem estar num modelo à parte, ou no mesmo modelo. Tabela 7- Modelo RDF, instanciação do Schema //------Dados Model model_data = ModelFactory.createDefaultModel(); model_data.setnsprefix("data", uri); //INSTANCIAS Individual iiquilino = Inquilino.createIndividual(uri+"Ricardo"); Individual iconarr = ContratoArrendamento.createIndividual(uri+"Contrato_n_21"); Statement sta1 = model_data.createstatement(iiquilino, assinou, iconarr); Statement sta2 = model_data.createstatement(iiquilino, name, "Ricardo"); model_data.add(sta1); model_data.add(sta2); //INFERENCIA RDFS+RDF Reasoner reasoner = ReasonerRegistry.getOWLReasoner(); InfModel infmodel = ModelFactory.createInfModel(reasoner,schema,model_data);

68 Pág. 50 de Jena 7.5 Mecanismos de Consulta A utilidade da ontologia começa a ser útil, a partir, do momento em que começamos a tirar partido do conhecimento nela descrito. A ontologia pode ser interrogada através de métodos que são disponibilizados pela API do JENA, através de queries feitas em SPARQL ou num modelo mais arcaico, o RDQL. O SPARQL, foi padronizado pelo grupo do W3C, sendo uma grande parte do desenvolvimento do projecto vocacionada para a consulta de documentos ontológicos. Possui características que permitem consultar a semântica, triplas, conjunções, disjunções, incluindo propriedades do RDF, bem como do RDFS. Uma das grandes vantagens da consulta em RDF, é que pode efectuar-se consultas em modelos OWL, desde que a sua representação seja em RDF Tipos de Query Consoante o valor do output, o SPARQL, possibilita diferentes tipos de construção do modelo da query, cada um com diferentes concepções: Select Construct Ask Describe Select Retorna todos, ou um subconjunto, dos valores que corresponderão ao padrão da tripla presente na query Construct constrói um gráfico por substituição das variáveis da tripla ASK esta primitiva é utilizada para testar se existe ou não um padrão de consulta. Não retorna soluções possíveis da consulta, unicamente a existência de solução ou não. Describe - esta forma descreve, num único grafo RDF, o resultado da query em questão Sintaxe do SPARQL A sintaxe é bastante semelhante à linguagem SQL, contendo a mesma base de conceito de queries, bem como a sua estrutura.

69 Pág. 51 de Jena SELECT Variáveis FROM documentos rdf WHERE padrões AND expressões de filtros USING prefixos O padrão da consulta assenta na descrição de uma tripla (sujeito, predicado, objecto). No SELECT definem-se as variáveis através do prefixo? ou $ antes do nome da variável. É possível restringir os valores das queries através de variadíssimas primitivas, por exemplo, ORDER BY, OPTIONAL, FILTER, AND, OR, etc SPARQL no JENA As queries podem ser executadas sem estar no modelo ontológico completo (como se pretende que fique no modelo final), podem-se efectuar queries ao Schema da Lei, sem ainda o utilizador ter inferido conhecimento. Em resposta obtém-se um resultando pouco elegante. É possível ainda no ambiente de programação construir queries, sem ter necessidade de recorrer a linguagem própria do SPARQL, basta para isso instanciar algumas classes do Jena, este tipo de interrogação tem a vantagem de iterar os valores da query. Tabela 8 - Exemplo de código Java para o uso do SPARQL //Criação de uma string, que terá a descrição da query String querystring = " PREFIX rdfs:< " PREFIX rdf:< " PREFIX uri:< "SELECT?inquilino?contrato "+ "WHERE{" + "?va uri:nome?inquilino."+ "?va uri:assinou?contrato"+ "}"; //Criação da instancia da query Query query = QueryFactory.create(queryString); //Representa a execução da query QueryExecution qe = QueryExecutionFactory.create(query,infmodel); //Contém a solução, sendo o mesmo um iterador ResultSet results = qe.execselect(); //ouput dos resultados ResultSetFormatter.out(System.out,results,query); qe.close(); Na Tabela 8 acima, pressupõe-se que já esteja carregado o modelo infomodel. Estão representados uma série de prefixos, no início do código, que correspondem ao URI do modelo ontológico, para clarificar, tanto a escrita como a leitura dos URI, e caminhos enormes que se teriam que colocar.

70 Pág. 52 de Jena O output deste exemplo será o seguinte: inquilino contrato ======================= "Ricardo" uri:contrato_n_ Tabela 9 - Representação do output da query da tabela 7.

71 Capítulo 8 8 Domínio do Problema Arquitectura ideal Com o constante aumento da informação presente na Web, bem como a falta de controlo do seu conteúdo, leva a um crescimento de informação que pode deteriorar-se a si mesma. Possibilitando unicamente a pesquisa de informação por motor de busca, este tipo de motores (crawler) fazem a busca por palavras-chave, contendo uma enorme quantidade de resultados, em que nem todos fazem parte do domínio desejado. Torna-se então necessário catalogar a enorme informação existente na Web para este tipo de motores poder efectuar uma pesquisa mais inteligente, efectuando uma pesquisa semântica. Este tipo de procura será efectuado através de agentes, que conseguirão entender o significado dos dados e retornar uma semântica ao utilizador. Estes agentes têm a finalidade de moldar a Web (ideologicamente a Web 3.0), tratando os dados semanticamente através das suas relações, devidamente estruturados e catalogados, alimentando assim este ciclo. 8.2 Introdução ao domínio Com o aumento da Web Semântica, tem vindo a crescer a modelação de ontologias em vários domínios, no caso da Lei, existem diversas características a considerar. Esmiuçando estas características pode-se concordar que um domínio de índole legal abrange bastantes dúvidas por parte de quem o solícita, bem como a própria lei que pode sofrer transformações. Computacionalmente torna-se um excelente caso para se moldar numa ontologia. Posteriormente, a serem definidas as características que vão explicar este domínio podem-se obter diversas respostas, bastando efectuar as interrogações correctas para tal, bem como a transformação do próprio domínio que se torna mais simples com esta tecnologia, podendo aproveitar subdomínios construídos, se caso se provar que continuam credíveis. Porém a Lei geral em si é bastante abrangente, pode ser interpretada de diversas maneiras tal como a lei do arrendamento, para tal, o domínio do problema foi restringido, submetido a diversas limitações, restando assim um caso mais pequeno do domínio da lei do Contrato de Arrendamento

72 Pág. 54 de Domínio do Problema 8.3 Descrição do domínio Para um melhor desenvolvimento e análise do domínio é necessário compreender os primórdios de um caso desta natureza. Que perguntas similares serão feitas por vários advogados, para o início de um caso. Por exemplo é imprescindível saber se o queixoso é inquilino ou senhorio do locado para o desenvolvimento do processo, tornando consequente o seu final. O levantamento destas questões é importante para moldar um caso mais próximo da realidade. Com base na lei é possível que existam duas entidades sendo elas distintas, mas ambas interligadas a um Contrato, ambas contendo a mesma relação a um domínio (contrato). Para o cumprimento do contrato, ambas as partes têm que satisfazer uma série de obrigações, respeitando-se assim mutuamente. O não cumprimento pode ter diversas consequências, sendo esta área outro caso de estudo diferente uma vez que requer a análise de outras componentes que não estão directamente relacionadas com a lei de arrendamento, por exemplo: questões sociais, existência de cadastro criminal, etc. Construindo assim um schema, que irá possibilitar criar um ambiente comum/padrão, tendo especial atenção à sua construção pois, pretende-se um caso abrangente que possa cobrir todos os casos, expansível no sentido de ser fácil adicionar novos elementos (por exemplo: obrigações ou mesmo novas leis) e generalista no sentido de utilizar termos e conceitos comuns a outros domínios (nomeadamente legislativos). 8.4 Representação do Schema Tendo em atenção os seguintes pontos: Existe um contrato com duas partes Cada parte pode ser constituída por um indivíduo ou um conjunto deles Cada parte tem uma lista de obrigações a cumprir Algumas obrigações são condicionadas, isto é, dependem da ocorrência de determinados factores Como foi visto em capítulos anteriores, existem semelhanças entre diagramas de classes e a descrição de ontologias. A representação do Schema da Lei completo encontra-se no apêndice A -Representação do Schema Lei.

73 Pág. 55 de Domínio do Problema Figura 31 - Diagrama de Classes do domínio de Contrato de Arrendamento Este diagrama faz referência aos casos em que cada parte só possui um contrato, a ideologia para mais que um será a mesma mas o diagrama não a refere A Figura 31 modela uma ontologia que contém uma parte comum a muitas áreas do direito (que contém conceitos como Contrato e Parte); e uma parte específica do arrendamento, que contém os conceitos de Senhorio, Inquilino, Obrigação Inquilino, etc. É possível efectuar a sua decomposição, a existência de obrigações Condicionais e Directas deve-se ao facto de existirem casos muito particulares, onde a obrigação não é uma aplicação directa, por exemplo: O senhorio pode obrigar o inquilino a deixar a casa, por vários motivos, I- O contrato foi celebrado com prazo certo (artigo 1097.º do Código Civil) II- O inquilino deixa de cumprir as suas obrigações (artigo 1101.º do Código Civil) III- Etc. Analisando cada caso: I. Contrato Celebrado com prazo certo Depende dos seguintes requisitos:

74 Pág. 56 de Domínio do Problema a) O senhorio pode exigir que o inquilino deixe a casa bastando uma comunicação ao inquilino com uma antecedência não inferior a um ano do termo do contrato. II. O inquilino deixa de cumprir as suas obrigações (resolução por incumprimento por parte do inquilino) O inquilino deixa de cumprir as suas obrigações quando: a) Usa o prédio de forma contrária à lei, aos bons costumes ou à ordem pública b) Usa o prédio para fim diverso daquele a que se destina c) Não dá uso à casa por mais de um ano, salvo: Em caso de força maior ou de doença Se a ausência, não perdurando há mais de dois anos, for devida ao cumprimento de deveres militares ou profissionais do próprio, do cônjuge ou de quem viva com o arrendatário em união de facto Se a utilização for mantida por quem, tendo direito a usar o locado, o fizesse há mais de um ano d) Se atrasa em mais de três meses no pagamento da renda, encargos ou despesas e) Etc. Tanto no ponto I, como na alínea a), e b) do ponto II, são obrigações directas que ambos têm que cumprir, estando assim implementadas na classe de Obrigação Directa directas. No segundo caso, alínea c), podem existir algumas obrigações condicionadas, por exemplo no caso da alínea c) o inquilino pode não dar uso em caso de doença, cumprimento militar, etc. A modelação do problema vai em conta ao motor de inferência e o mecanismo de queries. O sujeito ou inquilino deixa de cumprir se não satisfazer todas as obrigações, ou seja, o motor de inferência conclui que não cumpre se não possuir todos os factos que estão presentes na lista de obrigações. 8.5 Estrutura de desenvolvimento Arquitectura de inferência de dados Após ter o Schema construído, prossegue-se à instanciação de dados. É necessário estar em constante comunicação com o servidor, pois a inclusão de instâncias no modelo é realizada pelo utilizador, tornando para o servidor, e completando assim a tripla, aumentando assim o nível de conhecimento da ontologia.

75 Pág. 57 de Domínio do Problema Figura 32 - Arquitectura de inferência de dados Contudo a escolha deste tipo de arquitectura vai em conformidade com o modo escolhido para ler a semântica do caso concreto, que irá ser explicado de seguida. Tal como está representada na Figura 32, existe um Schema (que representa a Lei) já fabricado, o utilizador através do browser irá instanciar agora as classes que se encontram nesse modelo, completando assim o modelo RDF (Caso Concreto). Seria possível instanciar as classes no modelo (RDF), no início do processo, seria bastante mais simples (deixando unicamente as necessárias), mas o mecanismo de instanciar com o valor correcto que o utilizador insere é uma solução bastante mais inteligente. Veremos de seguida essa instanciação da Figura 33. <rdfs:class rdf:id="pessoa"/> <rdfs:class rdf:id="inquilino"> <rdfs:subclassof rdf:resource="#pessoa"/> </rdfs:class> <rdfs:class rdf:id="senhorio"> <rdfs:subclassof rdf:resource="#pessoa"/> </rdfs:class> Instanciar a classe Senhorio como Ricardo <rdfs:class rdf:id="pessoa"/> <rdfs:class rdf:id="inquilino"> <rdfs:subclassof rdf:resource="#pessoa"/> </rdfs:class> <rdfs:class rdf:id="senhorio"> <rdfs:subclassof rdf:resource="#pessoa"/> </rdfs:class> <Senhorio rdf:id="ricardo"/> Figura 33 - Exemplo da instanciação de uma Classe do Schema