UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA CURSO DE CIÊNCIA DA COMPUTAÇÃO FREDDY BRASILEIRO SILVA

UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA CURSO DE CIÊNCIA DA COMPUTAÇÃO FREDDY BRASILEIRO SILVA UMA TRANSFORMAÇÃO AUTOMÁTICA ENTRE LINGUAGENS DE REPRESENTAÇÃO DE REGRAS EM ONTOLOGIAS: DE OCL PARA OWL E SWRL VITÓRIA 2014

FREDDY BRASILEIRO SILVA UMA TRANSFORMAÇÃO AUTOMÁTICA ENTRE LINGUAGENS DE REPRESENTAÇÃO DE REGRAS EM ONTOLOGIAS: DE OCL PARA OWL E SWRL Monografia apresentada ao Curso de Ciência da Computação do Departamento de Informática da Universidade Federal do Espírito Santo, como requisito parcial para obtenção do Grau de Bacharel em Ciência da Computação. Orientador: M. Sc. Pedro Paulo Favato Barcelos Coorientador: Prof. Dr. Giancarlo Guizzardi VITÓRIA 2014

FREDDY BRASILEIRO SILVA UMA TRANSFORMAÇÃO AUTOMÁTICA ENTRE LINGUAGENS DE REPRESENTAÇÃO DE REGRAS EM ONTOLOGIAS: DE OCL PARA OWL E SWRL Monografia submetida ao Curso de Ciência da Computação do Departamento de Informática da Universidade Federal do Espírito Santo, como requisito parcial para a obtenção do Grau de Bacharel em Ciência da Computação. Aprovada em 19 de março de 2014. COMISSÃO EXAMINADORA MSc. Pedro Paulo Favato Barcelos - Orientador Universidade Federal do Espírito Santo Prof. Dr. Giancarlo Guizzardi - Co-orientador Universidade Federal do Espírito Santo Prof. Dr. Anilton Sales Garcia Universidade Federal do Espírito Santo Prof. Dr. Maxwell Eduardo Monteiro Instituto Federal do Espírito Santo

DEDICATÓRIA A todos que me apoiaram e me incentivaram nessa longa jornada.

AGRADECIMENTOS Agradeço primeiramente à minha família, que me deu oportunidade de estudo e incentivo para seguir meu caminho. À minha amada namorada, Larissa, pelo companheirismo e apoio em todos os momentos. Ao Pedro Paulo, pela paciência e compreensão durante todo o período de orientação, e ao professor Giancarlo, que confiou e aceitou ser coorientador deste trabalho. Aos professores Anilton e Maxwell, pela oportunidade de trabalho, por todo o conhecimento transmitido durante o período de projeto PADTEC e por aceitarem participar da banca deste trabalho. Aos companheiros de projeto Padtec, por toda a assistência prestada, em especial a Stange, Cabelino, Cássio, Victor Amorim e Fábio. À PADTEC S/A pelo projeto no qual este trabalho se encontra inserido. Ao Stange, novamente, que, quando está no Brasil, toma gol meu toda terça-feira. Aos companheiros do NEMO, pela amizade, conversas exaltadas no horário de trabalho e almoços no RU. Em especial, aos cafés com altíssimo padrão de qualidade proporcionados por Laylla, Ariane e Jordana, às cantorias repentinas e ecléticas do Bassetti, às fotos autografadas do Sobral, e ao tratamento amigável que Cássio e Victor Amorim praticam entre si. Vish! (Specimille, 2014). Aos companheiros de graduação Tiago, Lucas, Viola, Bruno Almeida, Eduardo e Sobral, pelo apoio e desafios superados juntos. Que perrengue, Brasil! Que perrengue! (Arruda, 2008).

RESUMO OntoUML e OWL são linguagens de ontologias para diferentes níveis de representação do conhecimento. Com o objetivo de alcançar melhor representação do conhecimento e capacidade de raciocínio em ontologias OWL, uma Engenharia de Ontologias deve ser usada o que corresponde a uma transformação de um modelo conceitual em uma linguagem de ontologias, como OntoUML, para uma linguagem de ontologia computacional, como OWL. Com o objetivo de aumentar a expressividade das linguagens, melhorando a capacidade de representação de conhecimento, OntoUML e OWL fazem uso de regras OCL e SWRL, respectivamente. Este trabalho define uma transformação MDA automatizada de regras OCL (em um contexto de OntoUML) para ontologias OWL com regras SWRL. Essa transformação, projetada para diminuir a perda de expressividade entre OCL e SWRL e entre OCL e OWL, contribui para: (i) facilitar a criação de regras SWRL a partir de regras OCL, (ii) possibilitar o aumento de expressividade do OWL a partir de regras OCL, (iii) eliminar a possibilidade de erro humano nesse processo (por exemplo, padronizando a adoção de regras de transformação para casos semelhantes) e (iv) melhorar a representação de conhecimento do OWL resultante.

LISTA DE FIGURAS Figura 1 - Padrão de transformação no nível de metadelo. Adaptado de (MILLER; MUKERJI, 2003)... 19 Figura 2 - Fragmento do metamodelo da linguagem OntoUML para o tipo Class. Fonte: (GUIZZARDI, 2005) adaptado... 22 Figura 3 - Fragmento do metamodelo da linguagem OntoUML para o tipo Relationship. Fonte: (GUIZZARDI, 2005) adaptado... 26 Figura 4 - Exemplo do uso das relações SubQuantityOf.... 27 Figura 5 - Exemplo do uso das relações SubCollectionOf e MemberOf.... 28 Figura 6 - Padrões dos casos em que a transitividade do componentof pode ser inferida (casos A, B e C) e dos que não podem ser inferidas (casos D e E). Fonte: (GUIZZARDI, 2009)... 29 Figura 7 - Exemplo do uso das relações ComponentOf.... 29 Figura 8 - Modelo UML e invariante OCL para a classe Person. Fonte: (MILANOVIĆ et al., 2006)... 46 Figura 9 - Um exemplo de modelo OntoUML para o domínio de posse de veículos. 50 Figura 10 - Um exemplo de modelo OntoUML para o domínio de alocação de funcionários e gerenciamento de um departamento... 57 Figura 11 - Um exemplo de modelo OntoUML para o domínio de parentesco de pessoas... 61

LISTA DE TABELAS Tabela 1 - Exemplo de representação de classes em OWL... 31 Tabela 2 - Exemplo de representação de associações em OWL... 33 Tabela 3 - Sintaxe e descrição dos tipos de regras OCL consideradas nesse trabalho... 36 Tabela 4 - Sintaxe e descrição das expressões de OCL consideradas nesse trabalho... 36 Tabela 5 - Sintaxe e descrição dos iteradores de OCL considerados nesse trabalho... 37 Tabela 6 - Sintaxe e descrição das meta-operações sobre objetos de OCL consideradas nesse trabalho... 38 Tabela 7 - Sintaxe e descrição das operações em coleções de OCL consideradas nesse trabalho... 38 Tabela 8 Continuação da sintaxe e descrição das operações em coleções de OCL consideradas nesse trabalho... 39 Tabela 9 - Sintaxe e descrição das operações em tipos primitivos de OCL consideradas nesse trabalho... 39 Tabela 10 Continuação da sintaxe e descrição das operações em tipos primitivos de OCL consideradas nesse trabalho... 40 Tabela 11 - Exemplo de OCL de origem e SWRL resultante da transformação (MILANOVIĆ et al., 2006)... 46 Tabela 12 - Exemplo do processo de criação de variáveis... 50 Tabela 13 - Equivalência para invariantes a partir de lógica de primeira ordem... 52 Tabela 14 - Mapeamento de invariantes e derivações em OCL para SWRL... 52 Tabela 15 - Exemplo do resultado da transformação para o uso do let... 53 Tabela 16 - Mapeamento de expressões em OCL para SWRL... 54 Tabela 17 - Exemplo do resultado da transformação para o uso do isunique... 55 Tabela 18 - Mapeamento de iteradores em OCL para SWRL... 55 Tabela 19 - Mapeamento de metaoperações sobre objetos em OCL para SWRL... 56 Tabela 20 - Exemplo do resultado da transformação para o uso do includes... 58

Tabela 21 - Mapeamento de operações em coleções em OCL para SWRL... 58 Tabela 22 - Mapeamento de operações em tipos primitivos em OCL para SWRL com diferenciação entre operadores negados e não negados... 59 Tabela 23 - Mapeamento de operações em tipos primitivos em OCL para SWRL com operadores não negados... 60 Tabela 24 - Exemplo do resultado da transformação para o uso das tags Symmetric, Irreflexive e Transitive... 61 Tabela 25 - Regras OCL e tags para representação de propriedades de associações OWL... 62 Tabela 26 - Exemplo do resultado da transformação para o uso da tag SubRelationOf... 63

LISTA DE SIGLAS/ACRÔNIMOS CIM Computational Independent Model MDA Model Driven Architecture MOF Meta-Object Facility ATL ATLAS Transformation Language OCL Object Constraint Language OLED Ontology Lightweight Editor OMG Object Management Group OntoUML Ontological Unified Modeling Language OOTOS OntoUML and OCL to OWL and SWRL OWL Web Ontology Language OWL-DL Web Ontology Language Description Logic OWL-Lite Web Ontology Language Lite OWL-Full Web Ontology Language Full PIM Platform Independent Model PSM Platform Specific Model R2ML REWERSE Rule Markup Language RDF Resource Description Framework RuleML Rule Markup Language SWRL Semantic Web Rule Language UFO Unified Foundational Ontology

UML Unified Modelling Language W3C World Wide Web Consortium

SUMÁRIO 1 INTRODUÇÃO... 13 1.1 ESTRUTURA DA MONOGRAFIA... 13 2 BACKGROUND TECNOLÓGICO... 17 2.1 MDA MODEL DRIVEN ARCHITECTURE... 17 2.2 ENGENHARIA DE ONTOLOGIAS... 19 2.3 LINGUAGENS PARA REPRESENTAÇÃO DE ONTOLOGIAS... 20 2.3.1 OntoUML Ontological Unified Modelling Language... 21 2.3.2 OWL Web Ontology Language... 30 2.4 LINGUAGENS PARA REPRESENTAÇÃO DE REGRAS... 34 2.4.1 OCL Object Constraint Language... 34 2.4.2 SWRL Semantic Web Rule Language... 40 3 TRABALHOS RELACIONADOS... 43 3.1 TRANSFORMAÇÕES DE ONTOUML PARA OWL E SWRL... 43 3.1.1 OntoUML2OCL+SWRL Transformation... 44 3.2 TRANSFORMAÇÕES DE OCL PARA OWL E SWRL... 45 3.2.1 Transformação de OCL para SWRL via R2ML... 45 3.2.2 Definição de um subconjunto de OCL para ser mapeado para SWRL... 46 4 A TRANSFORMAÇÃO DE OCL PARA OWL E SWRL... 48 4.1 ESCOPO... 48 4.2 NOMENCLATURA PARA CRIAÇÃO DE VARIÁVEIS... 49 4.3 MAPEAMENTO DE UM SUBCONJUNTO DE OPERADORES OCL PARA SWRL... 51 4.3.1 Invariantes e Derivações... 51 4.3.2 Expressões... 53 4.3.3 Iteradores... 54 4.3.4 Metaoperações sobre Objetos... 56 4.3.5 Operações em Coleções... 56 4.3.6 Operações em Tipos Primitivos... 59

4.4 MAPEAMENTO DE OCL PARA PROPRIEDADES OWL A PARTIR DO USO DE TAGS E PADRÕES... 60 4.5 IMPLEMENTAÇÃO... 64 5 CONCLUSÃO... 66 6 BIBLIOGRAFIA... 68

13 1 INTRODUÇÃO 1.1 CONTEXTUALIZAÇÃO Em (GUIZZARDI, 2007), é proposto o uso de uma Engenharia de Ontologias para a melhoria da representação de conceitos e da capacidade de raciocínio em ontologias computacionais. Na primeira fase dessa Engenharia de Ontologias, chamada modelagem conceitual, é necessário o uso de linguagens altamente expressivas a fim de representar adequadamente o domínio, já que as especificações resultantes têm como objetivo serem usadas por humanos em atividades como comunicação, análise de domínio e solução de problemas (GUIZZARDI, 2007). OntoUML é uma linguagem ontologicamente bem fundamentada, proposta em (GUIZZARDI, 2005) para ser usada nesta fase, cuja aplicação tem sido bem sucedida em domínios como os de eletrofisiologia (GONÇALVES; GUIZZARDI; PEREIRA FILHO, 2007), telecomunicações (BARCELOS, 2011) e petróleo e gás (GUIZZARDI et al., 2010). OntoUML, assim como outras linguagens de representação diagramáticas, possui restrições na capacidade de representação de regras de restrição e de inferência, tornando necessário o uso de uma linguagem associada para este fim. Modelos OntoUML utilizam, então, regras lógicas descritas em Object Constraint Language (OCL), aumentando sua expressividade. O último passo da Engenharia de Ontologias proposta em (GUIZZARDI, 2007) é a criação de versões da ontologia de referência desenvolvida no primeiro passo. Essas versões são chamadas lightweight ontologies e, ao contrário das ontologias de referência, tem foco em propriedades computacionais (GUIZZARDI, 2007). Um exemplo de linguagem para esse tipo de ontologia é o Web Ontology Language (OWL), adotada como padrão na Web Semântica. Assim como OntoUML, OWL também possui restrições quanto a representação de regras do tipo se, então, que devem ser definidas por meio de regras Semantic Web Rule Language (SWRL) (BARCELOS et al., 2013).

14 Uma fase intermediária é necessária para capturar as diferenças ontológicas existentes entre a modelagem conceitual e a implementação das linguagens. Neste caso, entre OntoUML e OWL e entre OCL e SWRL. A preocupação dessa fase é em como tratar possíveis perdas de expressividade entre as linguagens (GUIZZARDI, 2007). 1.2 MOTIVAÇÃO E JUSTIFICATIVA Este trabalho foi realizado no contexto do projeto Assessor Baseado em Ontologias para Gerenciamento de Redes, desenvolvido em parceria entre a Universidade Federal do Espírito Santo (UFES) e a Padtec S/A. A partir dos artefatos produzidos em (BARCELOS, 2011), nesse projeto foram produzidos novos artefatos em OntoUML e OCL para representação do domínio de redes de transporte. Atualmente, caso um usuário deseje realizar uma transformação de OntoUML e OCL para OWL e SWRL, esse deve executá-la de forma manual, além de demandar que o usuário tenha conhecimento prévio da estrutura e possibilidades das linguagens, bem como do processo de mapeamento entre essas. Em especial, conforme apresentado na seção 3.2 deste trabalho (de título Transformações de OCL para OWL e SWRL, do capítulo de 3) mapeamentos anteriores de OCL para SWRL não são disponibilizados em ferramentas computacionais ou, quando são, essas são limitadas ou descontinuadas. Assim, o processo de transformação entre as linguagens se torna difícil e passível de erros. Além disso, considerando-se uma transformação Model Driven Architecture (MDA), transformações manuais em geral ocorrem no nível de modelo (M1) e podem não ser sintaticamente padronizadas. Tudo isso faz com que o entendimento da ontologia resultante seja de difícil entendimento e tenha menor capacidade de representação e menor poder de raciocínio computacional. Uma transformação automatizada poderia ser disponibilizada para a comunidade em geral através de um framework de código aberto. Em (MILANOVIĆ et al., 2006) é proposta uma transformação de OCL para SWRL utilizando os metamodelos dessas linguagens e o metamodelo de REWERSE Rule

15 Markup Language (R2ML), uma linguagem intermediária de regras, como ligação entre os metamodelos de OCL e SWRL. Essa transformação é baseada em regras OCL escritas para modelos Unified Modeling Language (UML), porém não é necessário fazer referência ao modelo de classes UML. A comunicação dessa transformação com seu respectivo modelo UML possibilitaria que aspectos de modelagem fossem capturados, possibilitando que regras OCL fossem adicionadas diretamente à ontologia OWL. Além disso, a transformação proposta em (MILANOVIĆ et al., 2006) não faz diferenciação entre regras OCL dos tipos invariantes e de derivação. 1.3 OBJETIVOS GERAIS A proposta deste trabalho é definir uma transformação automatizada de regras lógicas descritas em OCL para ontologias OWL com regras lógicas descritas em SWRL, funcionando como uma extensão da transformação de OntoUML para OWL e SWRL proposta em (BARCELOS et al., 2013). 1.4 RESULTADOS E CONTRIBUIÇÕES Este trabalho apresenta uma transformação automática de OCL para SWRL e OWL, com o objetivo de estender a transformação apresentada em (BARCELOS et al., 2013), criando então a transformação denominada OntoUML and OCL to OWL and SWRL (OOTOS). Esta transformação é disponibilizada no framework para criação, validação e transformações de ontologia Ontology Lightweight Editor (OLED). A transformação proposta por este trabalho ocorre em um contexto de modelos OntoUML e se comunica com a transformação de OntoUML para OWL e SWRL proposta em (BARCELOS et al., 2013), sendo necessário que as duas ocorram sequencialmente e permitindo que um único arquivo OWL seja gerado. Além disso, a transformação proposta aqui permite que algumas propriedades de OWL sejam definidas por meio de regras OCL.

16 1.5 ESTRUTURA DA MONOGRAFIA O capítulo 2 deste trabalho apresenta o referencial teórico utilizado no desenvolvimento, apresentando o padrão MDA e as linguagens envolvidas na transformação (a saber, OntoUML, OWL, OCL e SWRL). O capítulo 3 apresenta os trabalhos relacionados a mapeamentos ou transformações entre as linguagens, bem como uma comparação entre esses trabalhos e o aqui desenvolvido. O capítulo 4 é referente a contribuição deste trabalho, apresentando a transformação definida, mostrado o mapeamento de OCL para OWL e SWRL, assim como as considerações feitas para definição do escopo e o processo para criação de variáveis em SWRL. Esse capítulo apresenta ainda detalhes da implementação e de aspectos computacionais da transformação. Por fim, o capítulo 5 conclui o trabalho, apresentando considerações finais e propostas de trabalhos futuros.

17 2 BACKGROUND TECNOLÓGICO A transformação aqui apresentada configura-se como uma transformação Model Driven Architecture (MDA), entre linguagens de diferentes níveis de abstração. Ela envolve diretamente as linguagens OCL, SWRL e OWL, dentro do contexto de modelagem em OntoUML. São apresentados, neste capítulo, o padrão MDA e as linguagens envolvidas na transformação. 2.1 MDA MODEL DRIVEN ARCHITECTURE Como uma forma de utilizar modelos no auxílio à criação de software, o padrão Model Driven Architecture (MDA), proposto em (MILLER; MUKERJI, 2003), foi criado pela Object Management Group (OMG), também responsável por padrões como a UML. De acordo com o padrão, um sistema pode ser classificado em diferentes pontos de vista, a partir de um conjunto de conceitos estruturais e de uma estruturação de regras. O MDA considera três tipos de visualização: Computational Independent Model (CIM), Platform Independent Model (PIM) e Platform Specific Model (PSM). Segundo (MILLER; MUKERJI, 2003), o CIM é uma visualização do sistema independente de aspectos computacionais, com foco no domínio e requisitos do sistema. É também chamado de modelo de domínio. No CIM, detalhes estruturais e de processamento ainda não são definidos. O CIM tem um papel importante como intermediador entre um especialista de domínio e um especialista em modelagem de domínios. Ainda segundo (MILLER; MUKERJI, 2003), o PIM foca na operação do sistema, sendo uma parte mais completa da especificação do domínio e com características independentes de plataforma. Assim, o PIM é um modelo dependente de aspectos computacionais, ou seja, é um modelo que pode ser computacionalmente executado (GASEVIC et al., 2006).

18 Por fim, (MILLER; MUKERJI, 2003) define o PSM como a combinação do CIM e do PIM com foco do uso em uma plataforma específica. Assim, detalhes específicos podem ser gerados a partir de diversas ferramentas de transformação automática (GASEVIC et al., 2006). Com os requisitos modelados no nível CIM, é construído um PIM, que pode conter informações computacionais. Uma transformação baseada em MDA é feita de um modelo de origem para um modelo de destino, ou seja, do PIM para o PSM, respectivamente (MILLER; MUKERJI, 2003). Para o processo de transformação entre dois modelos, é necessário que ocorra um mapeamento entre eles, podendo ser feito em diversos níveis, como no nível de instância, de modelo ou no nível de metamodelo. Uma maneira de construir uma transformação única e genérica é considerar o nível de metamodelo das linguagens. O fato de considerar um metamodelo possibilita que regras de mapeamento sejam aplicadas para todas as instâncias de tipos do metamodelo. Em (BARCELOS et al., 2013) são considerados os metamodelos de OntoUML, OWL e SWRL para a implementação de uma transformação entre estas linguagens. Este trabalho, que estende essa primeira transformação, acrescentando a ela a transformação de OCL para SWRL e OWL, também considera os metamodelos das linguagens envolvidas. A Figura 1 mostra como ocorre o padrão de transformação com o mapeamento feito no nível de metamodelo.

19 Figura 1 - Padrão de transformação no nível de metadelo. Adaptado de (MILLER; MUKERJI, 2003) 2.2 ENGENHARIA DE ONTOLOGIAS Nos últimos anos, a utilização de ontologias nas áreas de computação tem crescido consideravelmente, mais especificamente nos contextos de Web Semântica e MDA. Em (GUIZZARDI, 2007) é proposta uma Engenharia de Ontologias com três fases distintas e bem definidas: modelagem conceitual, projeto e implementação. A fase de modelagem conceitual tem como objetivo capturar claramente as características do domínio para, então, ser usada como objeto de comunicação, aprendizado e solução de problemas. Na fase de projeto considerações são feitas a partir do modelo conceitual gerado na fase anterior, a fim de capturar questões arquiteturais e aspectos não funcionais para a fase de implementação. Por fim, a fase de implementação consiste na geração de código passível de execução computacional a partir das considerações da fase de projeto. É possível que diferentes considerações de projeto sejam feitas para um modelo conceitual e que diferentes implementações sejam feitas para cada uma das considerações de projeto. As versões de implementação da ontologia da modelagem conceitual são chamadas lightweight ontologies.

20 Para garantir todas as distinções semânticas dos conceitos de um domínio, (GUIZZARDI, 2007) defende que uma linguagem altamente expressiva seja usada na fase de modelagem conceitual. Esse é o caso da linguagem OntoUML (apresentada na seção 2.3.1) que utiliza regras OCL (apresentada na seção 2.4.1) para representações de restrições e derivações. OCL é a linguagem utilizada como origem na transformação definida neste trabalho. OntoUML utiliza estereótipos para representar as distinções ontológicas dos conceitos, o que restringe a interpretação de cada tipo. Assim, uma transformação MDA cujo modelo de origem é representado em OntoUML, a necessidade de intervenção humana diminui, ou até mesmo pode ser eliminada, possibilitando que a transformação ocorra de forma automatizada somente a partir da entrada de um modelo e do mapeamento feito e, assim, reduzindo chances de erros e de tomadas de decisões diferentes para casos semelhantes. Linguagens de implementação de ontologias têm foco computacional, possuindo assim restrições de tratabilidade e decidibilidade (GUIZZARDI, 2007). Um exemplo de linguagem desse tipo é a OWL (apresentada na seção 2.3.2) e sua linguagem de regras associada, SWRL (apresentada na seção 2.4.2). Ambas são utilizadas como linguagens de destino na transformação final deste trabalho. Uma questão que necessita de atenção é a perda de expressividade ocorrida entre as fases de modelagem conceitual e de implementação, já que a primeira deve ser altamente expressiva e a última deve ter foco computacional. Portanto, na fase de projeto é importante que sejam feitas considerações a fim de se ter o mínimo de perda de expressividade possível. 2.3 LINGUAGENS PARA REPRESENTAÇÃO DE ONTOLOGIAS Esta seção apresenta as quatro linguagens para representação de ontologias relevantes a este trabalho. São elas as linguagens para representação de conceitos, OntoUML e OWL; e as linguagens para a representação de regras, OCL e SWRL.

21 2.3.1 OntoUML Ontological Unified Modelling Language OntoUML é uma linguagem ontologicamente bem fundamentada, proposta em (GUIZZARDI, 2005) como um profile da UML 2.0, para modelagem conceitual de domínios. Tal linguagem é aplicável à fase de Análise da Engenharia de Ontologias proposta em (GUIZZARDI, 2007), pois possui alta expressividade, e é utilizada com sucesso em domínios como eletrofisiologia (GONÇALVES; GUIZZARDI; PEREIRA FILHO, 2007), óleo e gás (GUIZZARDI et al., 2010) e telecomunicações (BARCELOS, 2011). O metamodelo de OntoUML é construído como uma extensão do metamodelo de UML a partir dos elementos Class e Relationship. Essa extensão se dá pela utilização dos conceitos definidos na Unified Foundational Ontology (UFO), uma ontologia de fundamentação proposta em (GUIZZARDI, 2005). A Figura 2 e a Figura 3 apresentam fragmentos do metamodelo de OntoUML. Os elementos folha desses fragmentos apresentados são usados como estereótipos da linguagem. A seguir são apresentadas breves descrições dos estereótipos relevantes a esse trabalho, extraídas e adaptadas de (GUIZZARDI, 2005), (ZAMBORLINI, 2011) e (BARCELOS, 2011).

22 2.3.1.1 Especializações do Elemento UML Class Figura 2 - Fragmento do metamodelo da linguagem OntoUML para o tipo Class. Fonte: (GUIZZARDI, 2005) adaptado Cada estereótipo definido no trecho do metamodelo apresentado na Figura 2 possui características de rigidez, de acordo com sua definição ontológica. Conceitos rígidos são aqueles que, uma vez instanciados, não podem deixar de ser daquele tipo. Conceitos antirrígidos são aqueles que seus indivíduos podem deixar de ser daquilo, de acordo com a necessidade. Conceitos semirrígidos podem agrupar outros conceitos rígidos e antirrígidos ao mesmo tempo e, por isso, instâncias podem ou não de ser daquele tipo quando o conceito agrupado é rígido ou antirrígido, respectivamente. 2.3.1.1.1 Kind

23 Kinds representam conceitos rígidos e que possuem princípio de identidade. Por ser rígido, uma instância de um Kind nunca poderá deixar de ser do mesmo. É comum identificar se um conceito possui princípio de identidade quando é possível contá-lo. Pessoa e árvore são exemplos de Kinds. 2.3.1.1.2 SubKind SubKinds herdam a rigidez e o princípio de identidade do Kind que especializa. Homem e mulher são exemplos de SubKinds que especializam o Kind Pessoa. 2.3.1.1.3 Quantity O estereótipo Quantity representa quantidades maximais de matéria em um recipiente qualquer, de forma que, ao se dividir essa quantidade, o novo conjunto de divisões representam novas instâncias. A quantidade de água em um copo é um exemplo de Quantity que, ao ser dividida, pode se tornar quantidades diferentes de água em copos distintos. 2.3.1.1.4 Collective As instâncias do estereótipo Collective representam coletivos de outros conceitos. Collectives são rígidos. Matilha é um exemplo de Collective do Kind Cão. 2.3.1.1.5 Phase Conceitos antirrígidos que representam, de fato, a mudança de fases, e cuja mudança depende intrinsicamente de suas propriedades, são modelados com o estereótipo Phase. Cada Generalization Set de Phases é, necessariamente, disjunto e completo. Criança, Adolescente e Adulto são exemplos de Phases que dependem do atributo idade do Kind Pessoa.

24 2.3.1.1.6 Role O papel desempenhando por um conceito em um domínio é representado pelo estereótipo Role. Conceitos do tipo Role são antirrígidos e dependem existencialmente de uma relação de cardinalidade mínima 1 com outro conceito. Estudante é um exemplo de Role do Kind Pessoa e que depende existencialmente de uma relação com o conceito Instituição de Ensino. 2.3.1.1.7 Category Categories agrupam conceitos rígidos com diferentes princípios de identidade. Um exemplo de Category é o conceito Item Assegurável, que agrupa os Kinds Pessoa e Carro. 2.3.1.1.8 RoleMixin Ao contrário do Category, o RoleMixin agrupa conceitos antirrígidos com diferentes princípios de identidade. Cliente é um exemplo de RoleMixin que agrupa os Roles Cliente Pessoa Física e Cliente Pessoa Jurídica. 2.3.1.1.9 Mixin Mixins são conceitos semirrígidos que agrupam conceitos rígidos e antirrígidos e, por isso, são sempre aplicáveis aos rígidos e contingentemente aos antirrígidos. O conceito Sentável é um exemplo de Mixin sempre aplicável ao Kind Cadeira e às vezes aplicável ao conceito Caixote. 2.3.1.1.10 Mode

25 Modes são conceitos que representam determinados aspectos de que um indivíduo adquire em determinado contexto. O conceito Dor de Cabeça é um exemplo de Mode. 2.3.1.1.11 Relator Relators são conceitos rígidos que representam um evento que valida uma relação Material. Estes conceitos mediam outros dois conceitos, através de uma relação Mediation, e são representados como uma classe associativa de uma relação Material. O conceito Casamento é um exemplo de Relator que media os Roles Esposo e Esposa e é representado como classe associativa da relação Material casado com.

27 desses órgãos). As relações todo-parte definidas em (GUIZZARDI, 2005) são SubQuantityOf, SubColletionOf, MemberOf e ComponentOf. 2.3.1.2.1 Associação Formal Associações formais são aqueles de dependem exclusivamente de propriedades dos conceitos interligados por elas. Relações que expressem comparações, como mais alto que e mais pesado que, são exemplos de associações formais que dependem das propriedades internas do Kind Pessoa. 2.3.1.2.2 Associação Material Associações materiais dependem de um evento, neste caso o Relator (descrito na seção 2.3.1.1.11), para se tornarem válidas. A relação estuda em é um exemplo de relação material entre os Estudante e Instituição de Ensino e mediada pelo Relator Matrícula. 2.3.1.2.3 SubQuantityOf Relações de sub-quantidade-de interligam conceitos do tipo Quantity, representando uma porção total e porções menores de um total. Essas relações são transitivas devido às suas características ontológicas. Na Figura 4, por exemplo, a quantidade maximal de um drink alcoólico pode ser composta de uma subquantidade de determinada bebida que, por sua vez, pode ser composta de uma subquantidade de álcool. O princípio de transitividade faz com que o drink alcoólico seja composto da subquantidade de álcool. Figura 4 - Exemplo do uso das relações SubQuantityOf.

28 2.3.1.2.4 SubCollectionOf Relações de sub-coleção-de interligam conceitos do tipo Collective, descrevendo uma porção mais específica de um coletivo, e sempre são transitivas. Na Figura 5, o Collective Floresta pode ser composto do Collective Floresta Negra que, por sua vez, pode ser composto do Collective Parte Norte da Floresta Negra. Pela propriedade de transitividade, o Collective Floresta será composto do Collective Parte Norte da Floresta Negra. Figura 5 - Exemplo do uso das relações SubCollectionOf e MemberOf. 2.3.1.2.5 MemberOf Relações de membro-de (memberof) ocorrem entre Collectives e Complexos Funcionais (ex.: Kind, Subkind, Role, Phase) ou entre Collectives. Devido às suas características ontológicas, essas relações não são transitivas. Na Figura 5, uma Árvore Negra da Parte Norte da Floresta Negra é um exemplo de membro da Parte Norte da Floresta Negra. Apesar dessas relações não serem transitivas, a transitividade pode ocorrer entre um conjunto de subcollectionof e um memberof. Ainda na Figura 5, a Árvore Negra da Parte Norte da Floresta Negra é, transitivamente, membro da Floresta Negra e da Floresta. 2.3.1.2.6 ComponentOf Essas relações ocorrem entre Complexos Funcionais e são não-transitivas, ou seja são transitivas em casos específicos (conforme mostrado na Figura 6Erro! Fonte de referência não encontrada.). Além disso, por definição, uma relação desse tipo tem cardinalidade mínima 2 no lado da parte ou a soma das cardinalidades mínimas das partes deve ser maior ou igual a 2.

29 Figura 6 - Padrões dos casos em que a transitividade do componentof pode ser inferida (casos A, B e C) e dos que não podem ser inferidas (casos D e E). Fonte: (GUIZZARDI, 2009) Na Figura 7, o Corpo Humano é composto de Braço que, por sua vez, é composto da Mão. A transitividade ocorre de forma que o Corpo Humano é composto da Mão. Ainda no exemplo abaixo, o Braço deve ser composto por mais partes para que o modelo seja válido. Figura 7 - Exemplo do uso das relações ComponentOf. 2.3.1.2.7 Characterization As relações de caracterização representam características inerentes a um conceito. O Mode Dor de Cabeça é um exemplo de uma característica inerente ao Kind Pessoa. 2.3.1.2.8 Mediation

30 Relações de mediação ocorrem entre um Relator e conceitos que o mesmo valida. O Relator Casamento, por exemplo, media os Roles Esposo e Esposa. 2.3.2 OWL Web Ontology Language A Web Ontology Language (OWL) é uma linguagem para representação de domínios que possui capacidade computacional. A mesma é adotada como padrão do World Wide Web Consortium (W3C) para representação de ontologias na Web Semântica e, para isso, foi feita como uma extensão de Resource Description Framework (RDF), a fim de manter a compatibilidade com a Web e melhorar a expressividade. Apesar de ser mais expressiva que RDF, OWL é menos expressiva que OntoUML, já que é uma linguagem com o foco em implementação. Sendo assim, OWL se enquadra na fase de Implementação da Engenharia de Ontologias proposta em (GUIZZARDI, 2007). A Web Semântica, onde OWL é aplicável, é um ambiente chamado de Mundo Aberto, de forma que uma informação só pode ser considerada verdadeira ou falsa se assim for declarada. De maneira inversa, o Mundo Fechado é tal que caso nada seja dito sobre algo, o mesmo é considerado falso. Por fim, a diferença se dá pela flexibilidade do Mundo Aberto, que permite que a informação seja incompleta, e pelo fato de que no Mundo Fechado as informações devem ser completas (PATEL- SCHNEIDER; HORROCKS, 2006). OWL é uma linguagem com a capacidade de inferência para classes, relações, atributos e indivíduos. O aumento da expressividade na representação do domínio gera preocupações referentes à decidibilidade e tempo computacional de inferência (SMITH; WELTY; MCGUINNESS, 2004). Por isso, OWL é subdividida em 3 versões incrementais entre si: OWL-Lite, que dá suporte a classificações hierárquicas e restrições simples; OWL-DL, que apresenta o melhor equilíbrio entre expressividade e perda de completude e decibilidade; e OWL-Full, que possibilita o máximo de expressividade e não dá garantias quanto ao tempo computacional (SMITH; WELTY;

31 MCGUINNESS, 2004), isto é, pode ser indecidível. A versão que interessa a este trabalho é a OWL-DL. A representação de um domínio em OWL é feita a partir de um de elementos básicos: Classes, Propriedades de Objetos (associações) e Propriedades de Dados (atributos). A seguir serão descritos os elementos básicos de OWL que são relevantes a esse trabalho. Para a apresentação de exemplos será utilizada a interface gráfica do Protégé 4.3, um editor de ontologias gratuito e de código aberto disponível para download em: http://protege.stanford.edu/. 2.3.2.1 Classes Em OWL todos os conceitos são representados por classes e, implicitamente, como subclasses de Thing, a classe mais geral de qualquer domínio OWL. Para classes, é possível definir especializações, disjunções e equivalências. Um conceito é especializado por uma classe definida internamente a ele, com a utilização da propriedade subclassof. A disjunção entre classes é representada com a utilização da propriedade disjointwith, e agrupando os conceitos. Por fim, para definir um conceito como um conjunto de componentes da ontologia, utiliza-se a propriedade equivalentclass. A Tabela 1 apresenta um exemplo visual de um domínio em que: (A) Pessoa é definida como subclasse de Thing, e Homem e Mulher como subclasses de Pessoa; (B) Pessoa é equivalente a qualquer coisa que possua exatamente uma idade; e (C) Homem e Mulher são disjuntos entre si. Idade é um exemplo de DataProperty, descrito na seção 2.3.2.2. Tabela 1 - Exemplo de representação de classes em OWL A) Taxonomia de Classes B) Definição da Classe Pessoa C) Definição da Classe Mulher

32 2.3.2.2 Propriedades (Properties) OWL dá suporte à representação de relações e atributos através de Object Properties e Data Properties, respectivamente. Em ambos, é possível representar especializações a partir da propriedade subpropertyof. Nas relações são definidas as classes origem e destino através do Domain e do Range, respectivamente. Nos atributos são definidas a classe de origem e o tipo de dados por meio do Domain e do Range, respectivamente. Para a representação das restrições de propriedades, são considerados os seguintes axiomas de cardinalidade: mínimo (min), máximo (max), exatamente (exactly) e algum (some). Em OWL, relações são unidirecionais e, por isso, é possível definir uma relação no sentindo contrário e declará-la como inversa através do marcador inverseof. Também é possível definir a disjunção entre relações agrupando as mesmas com o marcador disjointwith. Além disso, (SMITH; WELTY; MCGUINNESS, 2004) e (HITZLER et al., 2012) descrevem características particulares de associações apresentadas a seguir: Funcional (Functional): Seja uma propriedade P, P(x, y)^p(x, z) y = z) Inverso Funcional (Inverse Functional): Seja uma propriedade P, P(y, x)^p(z, x) y = z). Transitivo (Transitive): Seja uma propriedade P, P(x, y)^p(y, z) P(x, z). Um exemplo de transitividade se dá em uma relação que represente que uma Pessoa é ancestral de outra Pessoa. Simétrico (Symmetric): Seja uma propriedade P, P(x, y) P(y, z). Um exemplo de simetria se dá com uma relação que represente que uma Pessoa é irmã de outra Pessoa. Assimétrico (Asymmetric): Seja uma propriedade P, P(x, y) P(y, x).

33 Reflexivo (Reflexive): Representa a associação que conecta um indivíduo nele mesmo. Irreflexivo (Irreflexive): Representa a associação que não conecta um indivíduo nele mesmo. Um exemplo de irreflexividade também se dá pela relação que representa que uma Pessoa é irmã de outra Pessoa e pela relação que representa que uma Pessoa é ancestral de outra Pessoa. A Tabela 2 apresenta um exemplo visual das associações em OWL usadas como exemplo acima. Tabela 2 - Exemplo de representação de associações em OWL A) Taxonomia de ObjectProperty B) Características de ancestralde C) Definição de ancestralde 2.3.2.3 Indivíduos (Individuals) Com foco computacional, OWL dá suporte à criação de indivíduos e à atribuição de propriedades aos mesmos (SMITH; WELTY; MCGUINNESS, 2004). Indivíduos podem ser descritos como de algum tipo, i.e., como pertencentes a uma classe; como mesmo indivíduo que outro indivíduo; ou como diferente de outro indivíduo. Ainda é possível descrevê-los com asserções sobre quais relações o mesmo tem ou não com outro indivíduo ou sobre quais atributos este tem ou não.

34 2.4 LINGUAGENS PARA REPRESENTAÇÃO DE REGRAS As linguagens de ontologias apresentadas neste trabalho não possuem expressividade suficiente para representar todas as características do modelo, como restrições e derivações, sendo necessário o uso conjunto de linguagens de regras a fim de se obter maior expressividade. As linguagens de regras relevantes a este trabalho são apresentadas a seguir. 2.4.1 OCL Object Constraint Language UML é um padrão nas áreas de pesquisa e indústria que provê uma série de recursos para representar modelos através de diagramas. Contudo, diagramas UML nem sempre são suficientes para representar de maneira adequada todos os conceitos de um domínio. O diagrama de classes, por exemplo, que é um dos componentes UML mais utilizados, apresenta inconsistências e redundâncias em seu metamodelo (BERARDI; CALVANESE; DEGIACOMO, 2005). Por isso, o uso de regras Object Constraint Language (OCL) é uma forma de melhorar semanticamente esses diagramas, restringindo o domínio e definindo comportamentos desejáveis. Da mesma maneira que UML, OntoUML também faz uso de regras OCL quando necessário. OCL é um padrão para UML que oferece mecanismos para uma série de propósitos (ex.: como linguagem de consultas, para especificar invariantes, pré e pós condições, etc.). Neste trabalho, o foco da transformação de OCL para SWRL é na especificação de regras de domínio (invariantes e derivações). A justificativa para essa decisão de escopo encontra-se na seção 4.1 deste trabalho. A seguir são apresentados os operadores de OCL relevantes a esse trabalho, juntamente com suas respectivas sintaxes e descrições, conforme (OMG, 2012) e (GOUBET; DELAIGUE, 2009).

35 2.4.1.1 Invariantes e Derivações Em OCL, todas as regras devem especificar um contexto, que é um tipo (classe, associação ou atributo) definido no modelo. Essa restrição significa que não é possível expressar regras gerais sobre o modelo. Tais regras podem ser de dois tipos: (a) as condições invariantes, ou simplesmente invariantes, devem ser obedecidas em todos os estados possíveis do modelo, enquanto (b) as derivações são usadas para inferir relações ou atributos. Invariantes OCL podem representar mais que restrições, pode usar o operador implies para definir uma condição suficiente para se fazer suposições. Quando não expressam restrições, essas regras devem ser interpretadas como uma regra complexa de derivação. Já as regras OCL de derivação são utilizadas para representar como um conceito é inferido a partir de outros, i.e., como um conceito derivado é definido a partir de um conjunto de informações conhecidas. Apesar da diferenciação entre invariantes e derivações em OCL, todas as regras de derivação podem ser escritas como invariantes a partir do operador implies. Por exemplo, se for necessário afirmar de que toda Maçã é redonda, é possível escrever uma regra no formato de derivação, como se x é uma maçã, então x é redonda ou é possível escrever como uma regra de restrição, como é necessário para uma maçã ser redonda. Basicamente, quando um conhecimento só existe a partir de uma inferência ou de um cálculo matemático, o uso de uma regra de derivação é mais adequado (WAGNER, 2002), caso contrário pode ser escrita como restrição. OCL provê sintaxe para construir invariantes e derivações a partir dos construtores inv e derive, respectivamente. Regras complexas de derivação envolvem tipos derivados ou um conjunto de conclusões sobre o estado de uma coisa. A regra OCL a seguir é um exemplo de regra de derivação: context Pessoa inv: not self.oclistypeof(empregado) implies self.oclistypeof(desempregado) A condição acima expressa que, em todos os estados futuros do modelo, todas as Pessoas que não estiverem empregadas serão Desempregadas. Esse é um caso

36 clássico de derivação de tipos que não pode ser expressa usando o construto derive de OCL. Na verdade, sempre que houver regras complexas de derivação, o modelador não poderá usar algo diferente de invariantes. A Tabela 3 abaixo apresenta a sintaxe de regras invariantes e de derivação em OCL, que são as consideradas no desenvolvimento da transformação OCL para SWRL. Tabela 3 - Sintaxe e descrição dos tipos de regras OCL consideradas nesse trabalho Sintaxe context Class inv: OCLExpression context Class inv: OCLExpressionA implies OCLExpressionB context Class::AssociationEnd : Set(Type) derive: OCLExpression context Class::Attribute : Type derive: OCLExpression Descrição Determinada classe é definida como contexto para uma regra descrita em OCL. Determinada classe é definida como contexto para uma regra descrita em OCL que utiliza o operador implies. Determinada associação é definida como contexto para ser derivado a partir de uma regra descrita em OCL. Determinado atributo é definido como contexto para ser derivado a partir de uma regra descrita em OCL. 2.4.1.2 Expressões Apenas algumas dos tipos de expressões de OCL são consideradas neste trabalho, como melhor descrito na seção 4.1. Essas expressões são apresentadas abaixo, na Tabela 4, juntamente com as notações equivalentes em OCL e breves descrições. Tabela 4 - Sintaxe e descrição das expressões de OCL consideradas nesse trabalho Sintaxe Descrição

37 let x: Type = OCLExprA inoclexprb self.attribute self.assocend Atribui o resultado de uma expressão (OCLExprA) a uma variável (x) para ser usada em outra expressão (OCLExprB). O acesso a um atributo (attribute) é feito a partir de uma classe (self) com o próprio atributo por mediação de um ponto. O acesso a associações é feito a partir de uma classe (self) com o Association End (assocend)da associação por mediação de um ponto. 2.4.1.3 Iteradores Apenas alguns dos tipos de iteradores de OCL são considerados neste trabalho, como descrito na seção 4.1. Na Tabela 5 esses iteradores são apresentados juntamente com as notações equivalentes em OCL e breves descrições: Tabela 5 - Sintaxe e descrição dos iteradores de OCL considerados nesse trabalho Sintaxe col->forall(x expr) col->collect(x expr) col->isunique(x x.prop) Descrição Executa uma expressão (expr) para todos os elementos (x) pertencentes a uma coleção (col). Retorna todos os subelementos (x) de uma coleção (col) a partir de uma expressão (expr). Verifica se uma propriedade (prop) de um elemento (x) pertencente a uma coleção (col) é única. 2.4.1.4 Metaoperações sobre objetos Apenas algumas das metaoperações sobre objetos de OCL são consideradas neste trabalho, como descrito em 4.1. Na Tabela 6 essas metaoperações são apresentadas juntamente com as notações equivalentes em OCL e breves descrições:

38 Tabela 6 - Sintaxe e descrição das meta-operações sobre objetos de OCL consideradas nesse trabalho Sintaxe obj.ocliskindof(t) obj.oclistypeof(t) obj.oclastype(t) obj1 = obj2 obj1 <> obj2 Descrição Verifica se um objeto (obj) ou suas generalizações são de determinado tipo (t). Verifica se um objeto (obj) é de determinado tipo (t). Trata um objeto (obj) como sendo de determinado tipo (t). Verifica se dois objetos (obj1 e obj2) são iguais. Verifica se dois objetos (obj1 e obj2) não são iguais. 2.4.1.5 Operações em Coleções Apenas algumas das operações em coleções de OCL são consideradas neste trabalho, como descrito na seção 4.1. A Tabela 7 e a Tabela 8 essas operações são apresentadas juntamente com as notações equivalentes em OCL e breves descrições: Tabela 7 - Sintaxe e descrição das operações em coleções de OCL consideradas nesse trabalho Sintaxe col->includes(obj) col->including(obj) col->includesall(set) col->intersection(set) Descrição Verifica se um objeto (obj) está contido em uma coleção (col). Retorna uma coleção (col) acrescida de um objeto (obj). Verifica se um conjunto de objetos (set) está contido em uma coleção (col). Retorna a interseção entre uma coleção (col) e um conjunto de objetos (set).

39 Tabela 8 Continuação da sintaxe e descrição das operações em coleções de OCL consideradas nesse trabalho Sintaxe col->excludes(obj) col->excluding(obj) col->excludesall(obj) col s Descrição Verifica se um objeto (obj) não está contido em uma coleção (col). Retorna uma coleção (col) decrescida de um objeto (obj). Verifica se um conjunto de objetos (set) não está contido em uma coleção (col). Retorna uma coleção (col) decrescida de um conjunto de objetos (obj). 2.4.1.6 Operações em Tipos Primitivos Apenas algumas das operações em tipos primitivos de OCL são consideradas neste trabalho, como descrito na seção 4.1. Na Tabela 9 essas operações são apresentadas juntamente com as notações equivalentes em OCL e breves descrições: Tabela 9 - Sintaxe e descrição das operações em tipos primitivos de OCL consideradas nesse trabalho a implies b not a a or b a and b Sintaxe Descrição Conclui que uma expressão (b) é verdadeira se outra expressão (a) também é verdadeira. Retorna a negação de uma expressão (a). Compara duas expressões (a e b) e retorna verdadeiro se uma das duas for verdadeira. Compara duas expressões (a e b) e retorna verdadeiro se as duas forem verdadeiras. x > y Verifica se x é maior que y. x >= y Verifica se x é maior ou igual que y. x < y Verifica se x é menor que y. x <= y Verifica se x é menor ou igual que y.

40 Tabela 10 Continuação da sintaxe e descrição das operações em tipos primitivos de OCL consideradas nesse trabalho Sintaxe Descrição x + y Retorna a soma de x e y. x y Retorna a subtração de x e y. x * y Retorna a multiplicação de x e y. x / y Retorna a divisão de x e y. - x Retorna x multiplicado por -1. x.abs() Retorna o valor absoluto de x. true false Valor Booleano equivalente a verdadeiro. Valor Booleano equivalente a falso. 2.4.2 SWRL Semantic Web Rule Language A Semantic Web Rule Language (SWRL) é uma linguagem proposta em (HORROCKS et al., 2004) e adotada pelo W3C para ser uma linguagem de regras para Web Semântica, sendo criada a partir da combinação de Rule Markup Language (RuleML) com as sublinguagens OWL-Lite e OWL-DL da linguagem OWL. A sintaxe concreta de SWRL funciona como uma extensão de OWL e, assim, permite que a representação dos conceitos e regras de um domínio estejam em um mesmo documento. Regras SWRL são construídas a partir de classes, propriedades (associações e atributos), funções (chamadas Built-Ins) nativas ou externas e indivíduos (utilizados como variáveis). Cada assertiva composta por esses elementos é chamada de átomo. Por exemplo, seja C uma classe e P uma propriedade, ambas definidos em OWL, e considerando que indivíduos são representados como? nomedavariavel, um átomo em SWRL pode ser representado da forma: C(? c), P(? p), sameas(? x,? y), differentfrom(? x,? y) ou builtin(? r,? z 1,...,? z n ). Regras SWRL são formadas por uma implicação entre antecedente e consequente (também chamados de body e head, respectivamente). Em SWRL, antecedente e consequente são formados por zero ou mais átomos e considerações são feitas para

41 os casos em os mesmos são vazios: nesses casos, o antecedente é considerado sempre verdadeiro e o consequente é considerado sempre falso. Contudo, alguns editores de ontologias OWL, como o presente no Protégé 4.3, somente dão suporte a regras em que antecedente e consequente tenham no mínimo um átomo. Como o Protégé foi utilizado durante o desenvolvimento deste trabalho para visualização e testes de ontologias e regras, neste trabalho todos os antecedentes e consequentes são ambos gerados com no mínimo um átomo, com adaptações quando necessário. Além de respeitar a sintaxe concreta de OWL, SWRL possui uma sintaxe mais amigável e compreensível para humanos. Nessa sintaxe, uma regra tem o formato antecedente consequente, de maneira que antecedente e consequente são conjunções entre átomos escritas da forma a 1,, a n. Utilizando essa sintaxe, uma regra SWRL que afirme que se aplica a transitividade entre Pessoa e Pessoa, através da relação ancestral de, poderia ser escrita da forma: ancestralde(? x,? y), ancestralde(? y,? z) ancestralde(? x,? z). Quando comparada com OCL, SWRL pode ser considerada uma linguagem de baixa expressividade. Como SWRL possui uma quantidade pequena de operadores, nem sempre é possível o mapeamento direto entre a mesma e OCL. Nesses casos, é necessária a combinação de dois ou mais operadores de SWRL para representar um único operador de OCL e, pela diferença de complexidade, nem toda regra OCL é passível de ser expressa em SWRL. Além disso, o uso de OWL-Lite e OWL-DL não permite que uma regra em SWRL use Built-Ins (descritos a seguir) que tratem de listas e vetores, tornando a linguagem ainda mais restrita. SWRL utiliza dois átomos de OWL para verificar se dois indivíduos representam ou não o mesmo indivíduo, sendo eles sameas e differentfrom, respectivamente. A fim de possibilitar possíveis extensões, todos os outros operadores SWRL são construídos em módulos, chamados Built-Ins. Este trabalho considera apenas alguns dos Built-Ins disponíveis, que são descritos a seguir.

42 2.4.2.1 Built-Ins de Operações de Comparação Todos os Built-Ins de comparação disponíveis em SWRL são considerados neste trabalho. A seguir são listados os mesmos juntamente com as notações equivalentes em SWRL e breves descrições: equal(? x,? y): verifica se x e y são o mesmo indivíduo; notequal(? x,? y): verifica se x e y não são o mesmo indivíduo; lessthan(? x,? y): verifica se x é menor que y; lessthanorequal(? x,? y): verifica se x é menor ou igual a y; greaterthan(? x,? y): verifica se x é maior que y; greaterthanorequal(? x,? y): verifica se x é maior ou igual a y; 2.4.2.2 Built-Ins de Operações de Matemáticos Apenas alguns dos Built-Ins de operações matemáticas são considerados neste trabalho. A seguir os mesmos são listados juntamente com as notações equivalentes em SWRL e breves descrições: add(? x,? y,? z): atribui a x o valor da soma de y e z; subtract(? x,? y,? z): atribui a x o valor da subtração de y e z; multiply(? x,? y,? z): atribui a x o valor da multiplicação de y por z; divide(? x,? y,? z): atribui a x o valor da divisão de y por z; abs(? x,? y): atribui a x o valor absoluto de y.