UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
APTO: API PARA TRADUÇÃO DE METADADOS EM XML
Área de Inteligência Artificial
Por
Felipe de Oliveira Flôr
Rafael de Santiago, Bel.
Orientador
André Luís Alice Raabe, Dr.
Co-orientador
Itajaí (SC), julho de 2009
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
APTO: API PARA TRADUÇÃO DE ONTOLOGIAS EM XML
Área de Inteligência Artificial
por
Felipe de Oliveira Flôr
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientador: Rafael de Santiago, Bel.
Itajaí (SC), julho de 2009
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................iv
LISTA DE FIGURAS................................................................................. v
LISTA DE TABELAS ...............................................................................vi
RESUMO...................................................................................................vii
ABSTRACT..............................................................................................viii
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO ..................................................................................... 3
1.1.1 Formulação do Problema ................................................................................. 3
1.1.2 Solução Proposta ............................................................................................... 3
1.2 OBJETIVOS ........................................................................................................ 4
1.2.1 Objetivo Geral ................................................................................................... 4
1.2.2 Objetivos Específicos ........................................................................................ 4
1.3 METODOLOGIA................................................................................................ 4
1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 7
2.1 INTEROPERABILIDADE................................................................................. 7
2.1.1 INTEROPERABILIDADE EM REPOSITÓRIO DE OBJETOS DE
APRENDIZAGEM...................................................................................................... 8
2.2 ONTOLOGIA .................................................................................................... 10
2.2.1 Padrões de Representação de Ontologias ..................................................... 12
2.2.2 Metadados........................................................................................................ 13
2.3 MAPEAMENTO DE ONTOLOGIAS ............................................................ 17
2.4 TRABALHOS SIMILARES............................................................................. 22
2.4.1 Ontology Builder (OntBuild) ......................................................................... 22
2.4.2 Protégé.............................................................................................................. 23
2.4.3 Glue................................................................................................................... 25
2.4.4 Discussão sobre Trabalhos Similares............................................................ 26
3 PROJETO ............................................................................................. 28
3.1 REQUISITOS .................................................................................................... 28
3.1.1 Requisitos Funcionais ..................................................................................... 28
3.1.2 Requisitos Não Funcionais ............................................................................. 28
3.1.3 Regras de Negócios ......................................................................................... 28
3.2 DIAGRAMA DE CASOS DE USO ................................................................. 29
3.3 DIAGRAMA DE CLASSES............................................................................. 29
3.4 DIAGRAMA DE SEQUÊNCIA....................................................................... 30
4 Desenvolvimento................................................................................... 33
4.1 TECNOLOGIAS UTILIZADAS NO DESENVOLVIMENTO.................... 33
ii
4.1.1 XSLT ................................................................................................................ 33
4.1.2 JDOM............................................................................................................... 36
4.1.3 JAXP................................................................................................................. 37
4.2 MAPEAMENTO UTILIZADO ....................................................................... 39
4.3 UTILIZAÇÃO DO APTO ................................................................................ 44
4.4 VALIDAÇÃO DA API...................................................................................... 45
4.4.1 LOM para Dublin Core.................................................................................. 45
4.4.2 Dublin Core para LOM.................................................................................. 47
5 CONSIDERAÇÕES FINAIS .............................................................. 49
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 51
iii
LISTA DE ABREVIATURAS
API
APTO
DC
JAXP
LOM
OWL
RDF
SBC
TCC
UNIVALI
XML
XSL
XSLT
W3C
WAN
Application Program Interface
API para Tradução de Ontologias
Dublin Core5
Java API for XML Processing
Learning Object Metadata
Web Ontology Language
Resource Description Framework
Sistemas de Base em Conhecimento
Trabalho de Conclusão de Curso
Universidade do Vale do Itajaí
Extensible Markup Language
Extensible Stylesheet Language
Extensible Stylesheet Language Transformations
World Wide Web Consortium
Wide Area Network
iv
LISTA DE FIGURAS
Figura 1. Tradução de ontologia X para Y utilizando a API APTO ....................................................4
Figura 2. Ontologia representada de forma gráfica............................................................................12
Figura 3. Dublin Core no formato RDF .............................................................................................15
Figura 4. Representação esquemática da hierarquia de elementos do modelo LOM ........................16
Figura 5. Exemplo de LOM ...............................................................................................................17
Figura 6. Mapeamento de Ontologias ................................................................................................18
Figura 7. Combinação de ontologias..................................................................................................19
Figura 8. Alinhamento de ontologias .................................................................................................20
Figura 9. Interação de ontologias .......................................................................................................20
Figura 10. OntBuild............................................................................................................................23
Figura 11. Ontologia no Protégé ........................................................................................................25
Figura 12. Diagrama de Casos de Uso demonstrando o processo usabilidade do APTO..................29
Figura 13. Diagrama de classe demonstrando as classes que o APTO irá implementar....................30
Figura 14. Diagrama de seqüência demonstrando o processo de tradução que o APTO pretende
adotar..........................................................................................................................................31
Figura 15. Exemplo de um mapeamento simplificado entre as ontologias Dublin Core e LOM ......32
Figura 16. Exemplo de XSLT ............................................................................................................35
Figura 17. Exemplo de XML .............................................................................................................35
Figura 18. Exemplo de Arquivo Resultante da Tradução do XSLT ..................................................36
Figura 19. Exemplo do JAXP Realizando a Transformação .............................................................38
Figura 20. Mapeamento desenvolvido primeira parte........................................................................42
Figura 21. Mapeamento desenvolvido segunda parte ........................................................................43
Figura 22. Exemplo de utilização do APTO ......................................................................................44
Figura 23. Ontologia Origem em LOM .............................................................................................46
Figura 24. Ontologia Alvo resultante em Dublin Core ......................................................................47
Figura 25. Ontologia Origem em Dublin Core ..................................................................................47
Figura 26. Ontologia Alvo em LOM..................................................................................................48
v
LISTA DE TABELAS
Tabela 1. Ferramentas similares.........................................................................................................26
Tabela 2. Mapeamento entre Dublin Core e LOM.............................................................................40
vi
RESUMO
FLÔR, Felipe de Oliveira. APTO: API para tradução de ontologias em XML. Itajaí, 2008. 53 f.
Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências
Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2008.
Muitos softwares necessitam se comunicar com outros sistemas. Para que a comunicação ocorra de
forma transparente e sem nenhuma falha na entrega da informação, é necessária a utilização de
padrões para representar as informações. Estes padrões podem ser expressos através de uma
representação formal, através de uma determinada ontologia. As ontologias podem ser
representadas em diversos formatos, como por exemplo: desenhos (grafos) e descrição textual
(XML). Um dos problemas na troca de informações entre diferentes aplicações são os diferentes
padrões, como por exemplo: um sistema X pode estar utilizando uma ontologia no formato OWL, e
outro sistema Y estarem utilizando ontologia no formato LOM, mesmo os sistemas X e Y estarem
tratando dos mesmos assuntos, serão incompatíveis, não conseguindo se comunicar, pois o formato
das ontologias é divergente. Para que os softwares consigam se comunicar é necessário que eles
possuam os mesmos formatos de ontologias. Com o intuito de auxiliar na resolução deste problema,
resultou no desenvolvimento de uma API. A API APTO utiliza-se da técnica de Mapeamento de
Ontologias, pois esta técnica permite um “relacionamento” entre duas ontologias de padrões
diferentes e de domínios semelhantes. A API APTO conta com uma única classe, que realiza a
tradução através de uma Ontologia de Mapeamento e uma Ontologia de Origem, resultando na
Ontologia Alvo. A API desenvolvida pode ser utilizada para resolver o problema de
interoperabilidade. A motivação para o desenvolvimento foi à incompatibilidade encontrada entre
os tipos de metadados que descrevem Objetos de Aprendizagem, o que dificulta as buscas
realizadas em repositórios com estes materiais digitais. Devido a isso, para a validação da API
APTO foi utilizado dois padrões de ontologias bem difundidos na descrição de Objetos de
Aprendizagem: LOM e Dublin Core.
Palavras-chave: Interoperabilidade. Ontologia. Mapeamento de Ontologia.
vii
ABSTRACT
Several software need to communicate with another systems. To this communication occurs without
issues, it’s necessary to use a standard information representation . These standards are easily
expressed by ontology. An ontology can be represented in several formats, e.g. draws (graphs) and
textual description (XML). The main issue is that the ontology can be expressed in several formats,
e.g. a “X” Ontology can be represented in the OWL format and another “Y” Ontology can be
represented in the LOM format, even if both represents the same subject, but they are incompatibles
because are represented in different formats. To exists communication in a software group is
necessary that these software have the same standard ontology. To help the solution of this
problem, this study aims to specify an API, called APTO, that allows to translate several ontology,
allowing the construction of software mechanisms that do the communication between different
systems. To establish how the API works was made a research and the selected technique was the
Ontology Mapping because allow mapping between two ontology with different standards and
similar domains, where is possible, from a origin ontology and a standard mapping, translate an
ontology in another one. The APTO project was specified allowing that the translation occurs using
a single class. This class makes the translation through a mapping ontology, where is necessary
input two parameters in XML format, expressed in text form: a origin ontology and your respective
mapping for a destiny ontology (translated result), facilitating the use of the application. The main
motivation to do this work was the incompatibility found between the types of metadata that
describe the Learning Objects, what turns the search for digital material in repositories harder. To
validate the APTO will be used broadcasted ontology in the Learning Objects description: LOM
and Dublin Core.
Keywords: Interoperability. Ontology. Ontology Mapping.
viii
1 INTRODUÇÃO
Com o advento da informática, as pessoas passaram a atribuir ao computador atividades do
cotidiano. Os computadores possuem um papel importante na sociedade, servindo como ferramenta
de apoio para o trabalho e aprimoramento do conhecimento, com isto armazenam e processam
informações, para se representar uma determinada informação em computadores é utilizada os
chamados domínios do conhecimento. Estes domínios são versões resumidas do conhecimento de
uma determinada área (RUSSEL; NORVIG, 2004). Por exemplo, na área de matemática, um
domínio do conhecimento pode ser conceitos relacionados à Álgebra Linear; na computação um
domínio do conhecimento poderia ser Inteligência Artificial.
Em domínios complexos e mutáveis como compras na Internet, controle de robôs e temas de
aprendizado, há a necessidade de representações flexíveis, para que se consiga relacionar o
conhecimento, conseguindo assim adaptar-se aos mais diversos cenários possíveis. Uma possível
representação destes conceitos pode ser realizada através de ontologias (RUSSEL; NORVIG,
2004).
Ontologia é a forma de representar as informações de um determinado assunto. Nessa
representação são definidas diversas particularidades, adotando um padrão para reconhecer o
assunto específico (RUSSEL; NORVIG, 2004). Existem diversas áreas que aplicam ontologias, tais
como Inteligência Artificial, Web Semântica, Engenharia de Software e Arquitetura da Informação.
Exemplos disto são os agentes móveis que utilizam padrões e serviços da Web Semântica
representados em ontologias, possibilitando cooperação de maneira flexível com os domínios de
negócio (SANTANA et al., 2007; SILVA et al., 2006).
Com o uso considerável das ontologias, os padrões começaram a ser criados por iniciativas
de facilitar a representação computacional das mesmas. Estes padrões geralmente são destinados a
domínios específicos do conhecimento. Mesmo em domínios semelhantes, duas ontologias de
padrões divergentes se tornam incompatíveis, pois são interpretadas de formas diferentes: um
exemplo disto é o elemento Creator do Dublin Core e o elemento Description do LOM, eles são
diferentes, mas representam o mesmo elemento.
A partir deste problema, pesquisas na comunidade científica foram realizadas com o intuito
de permitir diferentes ontologias de domínio semelhantes possam ser compatíveis, ou seja,
interoperáveis: combinação de ontologias, alinhamento de ontologias, interação de ontologias e
mapeamento de ontologias (GAŠEVIĆ; HATALA, 2006).
O mapeamento de ontologias é a forma de expressar formalmente quais termos de uma
determinada ontologia tem relação com termos de outra. Um exemplo disto pode ser verificado em
duas ontologias: uma que expressa conceitos sobre Livro e outra sobre CD, nessas poderia haver um
mapeamento, expressando a compatibilidade entre outra ontologia (GAŠEVIĆ; HATALA, 2006).
Um exemplo de ontologia são o metadados e eles servem para representar uma determinada
informação sobre um dado.
A proposta deste Trabalho de Conclusão de Curso é de realizar levantamento científico
sobre ontologias e mapeamento de ontologias, que permitiu a criação de mecanismos de software
que traduz metadados expressas em padrões diferentes, através de ontologias que mapeiem as
semelhanças entre duas ontologias. Para isso se utiliza duas ontologias: a que deve ser traduzida e o
resultado desta tradução. O trabalho é justificado pela pesquisa na área da tecnologia, para prover a
interoperabilidade entre sistemas, foi desenvolvido uma API que auxiliará a interoperabilidade entre
aplicações com metadados em XML com padrões divergentes, mas de domínio semelhante.
A motivação principal para a criação desta API surgiu da necessidade do trabalho de
Santiago e Raabe (2008), onde uma rede de interoperabilidade para compartilhamento de Objetos
de Aprendizagem é especificada. Um dos mecanismos essenciais para garantir a interoperabilidade
da rede é o de tradução de ontologias, que permitirá que Objetos de Aprendizagem de diferentes
metadados possam ser identificados de forma equivalente. Devido a motivação para o projeto ter
partido de interoperabilidade entre metadados de Objetos de Aprendizagem, para avaliar a API para
Tradução de Ontologias em XML (APTO) serão utilizados os metadados Dublin Core e Learning
Object Metadata, comumente utilizados para a descrição de Objetos de Aprendizagem.
Também foram criadas nomenclaturas para facilitar a descrição do projeto. Abaixo se
encontra a listagem das mesmas:
•
Ontologia Origem: metadado base que sofrerá a tradução;
•
Ontologia de Mapeamento: este metadado contém o relacionamento de outros dois
metadados com formatos distintos, com o intuito de viabilizar a tradução de uma para
outra; e
•
Ontologia Alvo: metadado resultante da tradução.
Será apresentada a pesquisa necessária para o desenvolvimento da API, a modelagem da
ferramenta e a forma que foi desenvolvido e os testes relacionados à validação do APTO.
2
1.1 PROBLEMATIZAÇÃO
1.1.1
Formulação do Problema
Atualmente se tem o uso considerável de metadados por parte de sistemas, independente da
área que o software está relacionado. Por isto padrões foram criados para estabelecer regras para
representação computacional da informação (BREITMAN, 2005).
Hoje em dia existem muitos padrões para se representar metadados, e quando os softwares
utilizam padrões diferentes mesmo sendo em domínios semelhantes, torna os sistemas
incompatíveis, ou seja, faz com que softwares não consigam se comunicar. O problema abordado
pode ser visualizado no trabalho de Santiago e Raabe (2008), onde uma rede de compartilhamento
de Objetos de Aprendizagem necessita de mecanismo para tornar os metadados que descrevem
estes objetos equivalentes, para pesquisas e comparações.
1.1.2
Solução Proposta
Para solucionar o problema identificado, a proposta deste trabalho é desenvolver uma API
para tradução de metadados em XML. Através desta API os sistemas poderão traduzir as ontologias
divergentes para o formato de ontologia que seja compreensível, assim permitindo que as aplicações
tenham uma interoperabilidade, sem necessidade de alterar seus padrões de comunicação.
A API terá como parâmetros de entrada a Ontologia Origem (metadado que deve ser
traduzida) e a Ontologia de Mapeamento (metadado que vai conter as informações de quais termos
devem ser traduzidos e de que forma), através das duas ontologias de entrada será gerada uma
terceira ontologia a Ontologia Alvo (metadado resultante da tradução).
A Figura 1 demonstra o funcionamento da solução proposta: um “Sistema X”, que utiliza
uma Ontologia de Origem deseja se comunicar com o “Sistema Y” que utiliza uma Ontologia Alvo.
O “Software de Interoperabilidade” recebe a informação no padrão da Ontologia Origem,
juntamente com o Mapeamento de Ontologia, e através das duas ontologias de entrada é realizado a
tradução, utilizando-se da API APTO, e após o término da tradução é enviado resultado desta
tradução (Ontologia Alvo) para o “Software Y”.
3
Figura 1. Tradução de ontologia X para Y utilizando a API APTO
1.2 OBJETIVOS
1.2.1
Objetivo Geral
Desenvolver uma API que realiza a tradução de um metadados em XML em outro
metadado, a partir de uma Ontologia Origem e uma Ontologia de Mapeamento.
1.2.2
Objetivos Específicos
•
Realizar levantamento bibliográfico sobre ontologias;
•
Pesquisar sobre mapeamento de ontologias;
•
Pesquisar tecnologias XML aplicáveis a mapeamento de ontologias;
•
Pesquisar sobre trabalhos similares a proposta;
•
Modelar a API APTO;
•
Validação da API APTO; e
•
Redigir o Texto do TCCII.
1.3 Metodologia
Na primeira etapa foi realizado pesquisa sobre Interoperabilidade, com o foco em
Interoperabilidade em Repositórios de Objetos de Aprendizagem possibilitando o compreendimento
4
e justificando a real necessidade em se ter um trabalho de conclusão com o foco de resolver
problemas de interoperabilidade.
Como segunda etapa, foram realizadas pesquisas sobre ontologia, procurando-se por padrões
de ontologias e aplicações de ontologias para se obter embasamento necessário para realizar a
construção da API.
Já na terceira etapa foi realizada pesquisa referente a técnicas para resolver problemas de
ontologias divergentes, que serviu para verificar se realmente a técnica de mapeamento de ontologia
era a melhor técnica a ser utilizada.
Na quarta etapa verificou-se e equiparou-se os trabalhos similares a API desenvolvida com o
intuito de se obter mais informações e embasamento para implementação do APTO.
Como quinta etapa, foi desenvolvida a modelagem do projeto: levantamento de requisitos,
diagrama de seqüência e diagrama de classe. A modelagem possibilitou o melhor compreendimento
sobre o comportamento da API desenvolvida neste projeto, e detalhando ela.
Por último, foi relatado o processo de desenvolvimento e as tecnologias utilizadas. Além
disso, foram efetuados e relatados os testes envolvendo o projeto, para detectar possíveis falhas na
implementação da API.
1.4 Estrutura do trabalho
Esse trabalho de conclusão está estruturado em quatro capítulos: Introdução, Fundamentação
Teórica, Projeto e Considerações Finais.
O primeiro capítulo deste trabalho aborda uma visão geral sobre o projeto. Neste pode-se ter
uma descrição do problema proposto e a solução proposta, metodologia utilizada, os objetivos a
atingir e a motivação do trabalho.
No segundo capítulo é apresentada a revisão bibliográfica, sendo assim tendo uma análise
mais aprofundada sobre os assuntos envolvidos no projeto. O primeiro assunto é sobre
interoperabilidade, com o foco em interoperabilidade em repositório de objetos de aprendizagem. A
seguir é apresentada fundamentação sobre ontologia, como os padrões de representação e
aplicações de ontologias. Serão apresentado metadados, entre eles estarão sendo abordado o LOM e
Dublin Core, que serão os padrões utilizados para implementar os testes do APTO. Na etapa
5
seguinte é abordado o tema mapeamento de ontologia, suas vantagens, técnicas entre outros. E por
último os trabalhos similares, com ênfase nas diferenças e similaridades.
No terceiro capítulo são elaboradas a análise e a modelagem necessária para
desenvolvimento da API APTO, tais como: os requisitos funcionais, os requisitos não-funcionais e
as regras de negócio. Ainda neste capítulo são apresentados o diagrama de sequência e diagrama de
classes.
O quarto capítulo serve para relatar o desenvolvimento da API, tais como ás tecnologias
utilizadas no desenvolvimento, mapeamento utilizado e relatar os testes efetuados para validação da
API.
Já no quinto capítulo, são apresentadas as considerações finais sobre o trabalho
desenvolvido, bem como trabalhos futuros.
6
2 FUNDAMENTAÇÃO TEÓRICA
Na seção de fundamentação teórica são abordados conceitos e trabalhos similares com
intuito de gerar embasamento necessário para atingir os objetivos propostos. Dentre os tópicos
abordados, serão discutidos principalmente: Ontologias, Padrões de Representação de Ontologias,
Aplicações de Ontologias, Mapeamento de Ontologias, Trabalhos Similares.
2.1 INTEROPERABILIDADE
De acordo com Suleman (2001), interoperabilidade é a forma em que sistemas
computacionais distintos consigam interagir entre si, através de: troca de mensagens,
compartilhamento de arquivos ou interação em conjunto com o objetivo de resolver uma
determinada tarefa. Quanto menor a falha na comunicação, melhor é sua capacidade de
interoperabilidade.
Nunes (2004) afirma que quanto maior a capacidade do software conseguir transferir e
receber dados, além de compartilhar serviços, melhor sua interoperabilidade. Nunes (2004)
classifica sistemas interoperáveis em cinco categorias:
•
Isolado: o sistema não se comunica com outros sistemas;
•
Ligado: os sistemas trocam arquivos textos, e-mails, arquivos de imagem;
•
Funcional: os sistemas cooperam entre si, para exerce atividades complexas, um
exemplo são os sistemas distribuídos;
•
Domínio: os sistemas são integrados, se conectam através de uma WAN (Wide Area
Network), apenas compartilhando informações; e
•
Ambiente: os sistemas operam de forma conjunta utilizando informações globais em
muitos domínios.
Segundo Wileden e Kaplan (1997), interoperabilidade pode ser definida de várias maneiras,
dependendo do contexto que está sendo inserida. De acordo com Advanced Distributed Learning
(2006) no contexto de softwares educacionais, a interoperabilidade está relacionada à habilidade de
utilizar componentes instrucionais desenvolvidos em um local para um grupo de ferramentas ou
plataforma, e conseguir utilizá-los em outro local para outros grupos de ferramentas ou plataforma.
2.1.1
INTEROPERABILIDADE EM REPOSITÓRIO DE OBJETOS DE
APRENDIZAGEM
A principal motivação deste projeto surgiu do problema destacado por Santiago e Raabe
(2008), onde a integração de diferentes Repositórios de Objetos de Aprendizagem estaria sujeita a
transposição da barreira da utilização de divergentes padrões empregados aos objetos. Esta seção
tem por objetivo apresentar Objetos de Aprendizagem, repositórios destes materiais, com o intuito
de introduzir o domínio do problema abordado neste trabalho.
Objetos de Aprendizagem
Os Objetos de Aprendizagem são utilizados como elementos de motivação ao ensino, e são
considerados quaisquer recursos utilizados ao apoio ao processo de aprendizagem. Um filme ou
figura podem ser considerados um Objeto de Aprendizagem, quando são utilizados para fins
pedagógicos. Eles devem possuir uma sugestão para contexto abordado, pois um objeto pode estar
inserido entre várias áreas do ensino, por exemplo, um filme que fale sobre as formas geométricas
que são compostas as arquiteturas de prédios e monumentos, pode ser utilizado para ensinar
geometria (Hatala et al., 2004).
Para o Learning Technology Standards Committee (LTSC) da IEEE, Objetos de
Aprendizagem são quaisquer entidades, digitais ou não, que podem ser usados, reusados e
referenciados no apoio tecnológico com o intuito do aprendizado (LTSC IEEE, 2007).
Pode se empacotar conteúdos eletrônicos, como imagens, vídeos entre outros, em Objetos de
Aprendizagem, assim permitindo compartilhar todos os materiais de ensino de forma mais fácil e
ágil, possíveis de serem compartilhados em diferentes Repositórios de Objetos de Aprendizagem
(IMS, 2001).
De acordo com Picciano (1998), a classificação é extremamente importante para Objetos de
Aprendizagem, pois é através dele que se podem identificar como, onde e para quem podem ser
aplicado. Um Objeto de Aprendizagem sem classificação é como se fosse uma pessoa sem
identidade, seria muito difícil de identificá-la. A melhor maneira de classificar o Objeto de
Aprendizagem é através dos metadados, pois estes descrevem os Objetos de Aprendizagem.
Segundo Hatala et al. (2004), o Ambiente de Execução é utilizado para controlar as
sequência que as requisições chegam para o Repositórios de Objetos de Aprendizagem e para
8
permitir a interoperabilidade entre todos os conteúdos deste repositórios, através do modelo de
navegação que existe no ambiente.
Segundo Mohan (2007) para que Objetos de Aprendizagens sejam reutilizados é necessário
que eles estejam disponíveis na Internet. Os sistemas responsáveis por disponibilizar estes objetos
na Web são os Repositórios de Objetos de Aprendizagem, pois os repositórios são capazes de
armazenar e principalmente distribuir materiais de ensino. Esta distribuição está ligada diretamente
com o reuso dos objetos, pois quanto mais eficiente for este mecanismo, mais fácil será identificar e
recuperar os Objetos de Aprendizagem desejados. Existem padrões como, por exemplo, o Digital
Repository Interoperability (DRI), que facilitam a compatibilidade de diferentes repositórios.
Repositórios de Objetos de Aprendizagem
Hatala et al. (2004) colocam que a larga aceitação de padrões para a Web Semântica (como
o XML e o RDF) foi crucial para a criação de sistemas que podem descobrir e compartilhar
informações para a área educacional. Grande parte desses sistemas diz respeito aos Repositórios de
Objetos de Aprendizagem que são alvos de esforços para sua criação. Recentemente, a comunidade
e-learning tem se focado na habilidade de conectar e usar recursos existentes em repositórios
distribuídos. O aparecimento de padrões como o Learning Object Metadata (IEEE LTSC), estão
facilitando esta abordagem.
De acordo com Hatala et al. (2004), as maiores iniciativas para possibilitar a
interoperabilidade em Repositório de Objetos de Aprendizagem são:
•
Open Archive Initiative: desenvolve e promove padrões de interoperabilidade para a
disseminação de conteúdos. Uma das tecnologias desenvolvidas foi o Protocol for
Metadata Harvesting, permitindo que repositórios criem coleções e coletem metadados
de outras fontes (SOMPEL; LAGOZE, 2002 apud HATALA et al., 2004);
•
National Science Digital Library: fundado pela National Science Foundation, fornece
bibliotecas para criação de Objetos de Aprendizagem para educação em ciência,
matemática, engenharia e tecnologia. (ARMS et al., 2002 apud HATALA et al., 2004); e
•
IMS Digital Repository Interoperability: especifica uma arquitetura funcional para
interoperabilidade entre repositórios de conteúdos instrucionais (IMS DRI, 2003 apud
HATALA et al., 2004).
9
Picciano (1998) afirma que a maneira mais eficiente de se construir um Objetos de
Aprendizagem é através do uso de ontologias, pois permite conhecer vários atributos e informações
sobre os conteúdos dos mesmos.
A interoperabilidade é muito importante entre Repositórios de Objetos de Aprendizagem,
pois a interoperabilidade facilita a busca de Objetos de Aprendizagem. A API para Tradução de
Metadados em XML desenvolvida neste trabalho permitirá maior interoperabilidade entre os
repositórios, independente do formato que os objetos estejam representados.
2.2 ONTOLOGIA
De acordo com Russel e Norvig (2004), para que sistemas consigam reconhecer uma
determinada informação é necessário representar através de uma ontologia. Na ontologia se define
várias particularidades com o intuito de representar uma determinada informação sobre um domínio
específico.
Fonseca, Engenhofer e Borges (2000) afirmam que ontologias são teorias que especificam
um vocabulário relativo a um assunto especifico, e que este vocabulário define entidades, classes,
propriedades e as relações entre estes componentes.
Embora os conceitos dos autores não sejam iguais, há um consenso ao afirmar que
ontologias é a forma de representar um determinado assunto dentro de um contexto específico.
De acordo com Pérez (1999), o uso de ontologia tem diferentes tipos de classificação:
•
Ontologias de Representações: definem as representações de forma declarativa, tais
como atributos e propriedades;
•
Ontologias Gerais: definem as representações de forma abstratas. São representados os
aspectos do âmbito do mundo, tais como seres, tempo, entre outros;
•
Ontologias Centrais ou Genéricas: é a representação das informações gerais de uma
determinada área de estudo, ou seja, o assunto não é específico, como por exemplo, área
de Computação;
•
Ontologias de Domínios: se refere a um assunto mais específico de uma área de estudo,
como, por exemplo, em Computação, o estudo de Inteligência Artificial. O foco é
geralmente nos conceitos e objetos do conteúdo; e
10
•
Ontologias de Aplicações: para um domínio específico procura-se solucionar problemas.
Por exemplo, em Inteligência Artificial procura-se descobrir como fazer com que os
agentes comuniquem-se entre si independente da estrutura de comunicação utilizada.
Embora uma ontologia tenha diversas classificações dependendo do grau de generalidade,
neste projeto se utilizará o conceito de Ontologia de Domínio. Todas as ontologias podem ser
representadas através de vários formatos. Dois destes são:
•
Representação Gráfica: É a representação através de uma estrutura em árvore; e
•
Representação Textual: É a representação através de textos.
Para representação computacional de ontologias, geralmente utiliza-se Extensible Markup
Language (XML) que é expressa de forma estruturada e textual, pois possui muitos padrões de
ontologias representação neste formato. São exemplos de formatos que se pode ter representado
uma ontologia expressa em XML: LOM (Learning Object Metadata) (LTSC IEEE, 2005), RDF
(Resource Description Framework) (W3C, 2007a), OWL (Web Ontology Language) (W3C,
2007b).
Segundo Smith et al. (2005), a ontologia é representada por conceitos. O conceito pode ser
composto por classes, instâncias e termos. As classes são os componentes de um objeto, como por
exemplo, em um domínio de biblioteca a classe pode ser representada por livro. Já as instâncias são
partes de uma classe. Ainda se utilizando do exemplo de domínio de uma biblioteca e de uma classe
representada por um livro a instancia poderia ser o livro “Glossário de Termos Técnicos
Computação”. Os termos são partes das classes como, por exemplo, autor.
Na Figura 2 pode ser visualizado um exemplo de ontologia de domínio sobre obras. Os
conceitos estão representados em uma hierarquia, demonstrando os relacionamentos entre eles. Por
exemplo, uma obra é um livro nesta ontologia e o livro tem uma editora e um escritor. Deste modo,
um escritor não é uma obra, pois a mesmo está inserida é pertencente ao livro. Estes
relacionamentos entre conceitos e a hierarquias são exemplos de ontologia. Quatro classes estão
representadas, tais como:
•
Obra: é o que será representado, neste exemplo um livro.
•
Livro: se refere ao nome do livro, um exemplo de livro é o “Glossário de Termos
Técnicos Computação”;
11
•
Editora: é a entidade responsável por reproduzir o livro, um exemplo é a “UNIVALI”; e
•
Escritor: representa quem escreveu o livro, como exemplo “Tânia Azevedo Leite”.
Figura 2. Ontologia representada de forma gráfica
A ontologia é importante para comunicação entre sistemas, pois através dela é possível
representar vocabulários, e desta forma os sistemas conseguem trocar informações, tornando-se
interoperáveis. Exemplos de aplicações que utilizam ontologias são agentes, web-services e
metadados.
Nas sub-seções a seguir serão abordados assuntos como padrões de representação,
aplicações de ontologias, mapeamento de ontologias, metadados, comparações entre as trabalhos
similares e a modelagem do projeto, com o intuito de relacionar o conceito de ontologia com os
objetivos do trabalho. Os metadados foram estudados de forma mais aprofundada como aplicações
de ontologias, pois pretende-se validar a API proposta através destas estruturas.
2.2.1
Padrões de Representação de Ontologias
Para representar ontologias é utilizado formatos que contém especificação já estruturada, o
que facilita a criação de ontologia e permite a interoperabilidade entre sistemas que empregam os
mesmos padrões de representação ontológicas.
12
O XML se tornou uma das representações estruturadas mais adotadas para intercâmbio e
representação de informações na Internet, e existe uma grande quantidade de dados codificados no
formato XML (CHAVES; VIEIRA; RIGO, 2001).
O RDF e o OWL são dois exemplos de ontologias representadas em XML. O RDF serve
como base para processamento de metadados. Os padrões estão baseados no conceito de ontologias
e são utilizados para estruturar documentos de modo a explorar definições de orientação a objeto
que possibilita a aplicação de herança, reuso, modularização, entre outros. O RDF pode auxiliar em
uma variedade de aplicações, desde catálogos de bibliotecas até coleções pessoais de fotos. Já o
XML é utilizado para representar a troca de informações entre sistemas. As especificações RDF
provêem um suporte a sistemas de ontologias simples para auxiliar a troca de conhecimento na Web
(W3C, 2007a).
A OWL é uma linguagem para definir e criar ontologias na Web. Através dela podem-se
representar as classes e seus respectivos relacionamentos e propriedades. A OWL foi desenvolvida
para ser utilizada em aplicações que tenham a necessidade de processar o conteúdo da informação
ao invés de apenas apresentar informações para os seres humanos. Ela apresenta maior facilidade de
interpretação dos computadores sobre o conteúdo da Web do que XML, RDF e RDFS (RDF
Schema), por fornecer vocabulário adicional com uma semântica formal (W3C, 2008b).
Brietman (2005) cita que a OWL foi concebida pelo World Wide Web Consortium (W3C)
devido à necessidade das aplicações de Web Semântica empregarem construções e racionalização
de ontologias, e explicitar fatos sobre um determinado domínio. A OWL se divide em três sublinguagens:
•
OWL Lite: suporta necessidades para classificação hierárquica e restrições simples;
•
OWL DL: suporta o máximo de expressividade garantindo que as conclusões sejam
computáveis, é a versão do OWL mais utilizada; e
•
OWL Full: usada para sistemas que necessitam o máximo de expressividade e liberdade
sintática do RDF sem garantias computacionais.
2.2.2
Metadados
De acordo com o Breitman (2005), os metadados são dados sobre dados, ou seja,
informações sobre um determinado documento, como por exemplo, autor e editora. Bibliotecários,
13
museólogos, arquivistas e editores já utilizam metadados, para catalogar e organizar livros,
arquivos, materiais e documentos.
Breitman (2005) ainda cita alguns aspectos importantes dos metadados:
•
metadados não precisam ser digitais;
•
metadados podem ser utilizados para processamento e relacionamento de condição física
de um determinado objeto, não somente especificando características sobre seu
conteúdo;
•
metadados podem ser obtidos através de seres humanos, fontes na Internet, grandes
bases de dados, entre outros; e
•
metadados evoluem durante o ciclo de vida do objeto a que se referem, pois podem ser
modificados e até mesmo descartados.
Entre os padrões de metadados selecionados como aplicações de ontologias que irão ser
utilizados para avaliar o APTO estão: Dublin Core e Learning Object Metadata. Pois estes dois
padrões são os mais utilizados para descrever Objetos de Aprendizagem. Nas subseções seguintes o
Dublin Core e o Learning Object Metadata serão apresentados.
Dublin Core
Dublin Core é uma especificação que tem como resultado um XML para descrição de
Objetos de Aprendizagem, contêm semântica para descrição de recursos disponibilizados pela
Internet. Dublin Core contêm vários elementos que compõem o padrão e são eles (BREITMAN,
2005):
•
Assunto (subject): tema do trabalho que está se descrevendo;
•
Título (title): título do conteúdo;
•
Criador (creator): responsável pelo conteúdo intelectual;
•
Descrição (description): descrição do conteúdo;
•
Editor (publisher): responsável pela disponibilização do Objeto de Aprendizagem;
•
Outro agente (contributor): pessoas que contribuíram de alguma forma para o projeto;
14
•
Data (date): data de publicação;
•
Tipo do Objeto (type): tipo do conteúdo (dicionário, poema, ficção, entre outros);
•
Formato (format): formato do objeto (como, por exemplo, executável WIN32, PDF);
•
Identificador (identifier): identificação única do conteúdo (um código);
•
Relacionamento (relation): relacionamento com outros Objetos de Aprendizagem;
•
Fonte (source): objetos dos quais o conteúdo atual foi derivado;
•
Linguagem (language): linguagem do conteúdo (por exemplo, Português, Japonês, entre
outras);
•
Cobertura (coverage): escopo do que é abordado no Objeto de Aprendizagem; e
•
Direitos (rights): informações sobre os direitos reservados do Objeto de Aprendizagem.
Um exemplo de um metadado Dublin Core pode ser visualizado na Figura 3. Na mesma,
está se utilizando o padrão RDF no intuito de descrever um recurso encontrado na Web.
<?xml version=”1.0”?>
<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:dc=”http://purl.org/dc/elements/1.1/”>
<rdf:Description
rdf:about=”http://www.inf.puc-rio.br/~ka
rin/index.html”>
<rdf:creator>Karin Breitman</rdf:creator>
<dc:title>Home Page da Profa. Karin</dc:title>
<dc:date>30 de outubro de 2007</dc:date>
</rdf:description>
</rdf:RDF>
Figura 3. Dublin Core no formato RDF
Fonte: Adaptado de BRIETMAN (2005).
LOM
Leaning Objects Metadata (LOM) foi criado através de outros padrões de metadado como
Dublin Core e o IMS Learning Resource Meta-Data. Pode-se utilizar XML ou RDF para representar
um metadado LOM. O RDF é utilizado para inserir o padrão LOM em outros padrões de descrição
de recurso, geralmente no formato XML e que estendem as funcionalidades do RDF (LTSC IEEE,
2005).
15
LOM se estrutura através de um conjunto de elementos, incluindo tipos de dados,
multiplicidades e relacionamentos entre componentes. Todos os elementos que compõe o LOM são
opcionais, portanto, o XML Schema que represente a estrutura do padrão não deve obrigar o uso de
qualquer elemento, de acordo com LTSC IEEE (2005).
Na Figura 4 são demonstrados os elementos e as hierarquias do modelo LOM.
Figura 4. Representação esquemática da hierarquia de elementos do modelo LOM
Fonte: IMS (2004).
De acordo com LTSC IEEE (2005), as categorias do metadado LOM que se destacam são:
•
General: descreve informações de identificação do Objeto de Aprendizagem, como:
título, identificador, linguagem, descrição, dentre outros;
•
Life Cycle: informações relativas ao ciclo de vida do Objeto de Aprendizagem, tais
como: pessoas que fizeram contribuições, estado atual, versão, entre outros;
•
Meta-Metadata: informações sobre o próprio metadado utilizado;
16
•
Technical: especificações sobre requerimentos e características técnicas do Objeto de
Aprendizagem;
•
Educational: características educacionais e pedagógicas;
•
Rights: propriedade intelectual e direitos de uso do Objeto de Aprendizagem;
•
Relation: configurações de grupo que determinam as relações de um Objeto de
Aprendizagem com outro;
•
Annotation: provê comentários sobre uso educacional do objeto; e
•
Classification: categoria que descreve o objeto de acordo com um sistema particular de
classificação.
Pode ser visualizar um exemplo de uma descrição simples de um Objeto de Aprendizagem,
utilizando o padrão LOM na Figura 5.
<lom>
<general>
<title>
Design Patterns: Elements of Reusable ObjectOriented Software
</title>
<catalogentry>
<catalog>ISBN</catalog>
<entry>0-201-63361-2</entry>
</catalogentry>
<language>en</language>
<keyword>Object-Oriented</keyword>
<keyword>Programming</keyword>
<keyword>Computer Software</keyword>
<keyword>Reusability</keyword>
</general>
</lom>
Figura 5. Exemplo de LOM
Fonte: Mohan (2007).
2.3 MAPEAMENTO DE ONTOLOGIAS
O Mapeamento de Ontologias é uma técnica que visa representar quais termos de uma
ontologia se relaciona com outra. Com isto identificam-se os termos com o mesmo significado em
duas ontologias, mas representados de formas distintas, permitindo que os sistemas tenham
capacidade de comunicar-se de forma transparente entre si (interoperabilidade) (GAŠEVIĆ;
HATALA, 2006; KALFOGLOU; SCHORLEMMER, 2003; MAEDCHE; STAAB, 2002).
17
De acordo com Noy (2004), Kalfoglou e Schorlemmer (2004), para que os sistemas
consigam ter uma maior interoperabilidade é fundamental a construção de mecanismos de
mapeamento, desta forma eliminando as diferenças entre as ontologias e possibilitando a troca de
informações entre aplicações através dos relacionamentos gerados pelo mapeamento.
A Figura 6 representa o mapeamento de uma ontologia representado por Ontologia Origem
através de uma outra ontologia representada por Ontologia de Mapeamento, as relações de
mapeamento são representadas por r1, r2 e r3 . Pode-se observar também que o mapeamento da
ontologia independe do nó da árvore, ou seja, um termo da Ontologia Origem pode se relacionar
com outra de um nó mais abaixo ou mais acima da árvore. Outra observação é que os termos da
Ontologia de Mapeamento estabelecem uma conexão entre os termos da Ontologia Origem com a
Ontologia Alvo.
Figura 6. Mapeamento de Ontologias
Fonte: Adaptado de Gašević e Hatala (2006).
Uma aplicação de Mapeamento de Ontologias é citada por Librelotto, Ramalho e Henriques
(2003), onde o uso do conceito é utilizado quando o usuário deseja encontrar informações
importantes a respeito de um determinado domínio e a relevância deste conteúdo não pode ser
caracterizada através de pesquisa convencional em uma ferramenta de busca.
18
A técnica de mapeamento de ontologias é extremamente importante para este trabalho, pois
é através dela que o APTO vai saber qual termo de uma ontologia se relaciona com a outra,
tornando possível tradução das ontologias. API APTO utiliza a técnica de mapeamento para fazer a
tradução de uma Ontologia Origem em outra Ontologia Alvo.
Segundo Felicíssimo e Breitman (2004), além do mapeamento outras três alternativas para
interligar ontologias distintas existem, são eles:
•
Combinação de Ontologias: une duas Ontologias Origem em uma só Ontologia
Resultante. Através dela não é possível fazer tradução e sim criar uma terceira ontologia
mais completa. A Figura 7 é um exemplo gráfico de combinação de ontologias;
Figura 7. Combinação de ontologias
Fonte: Hinz e Polazzo (2007).
•
Alinhamento de Ontologias: A Ontologia Origem e a Ontologia Alvo não sofrem
alterações, é criada uma nova ontologia que vai conter as ligações entre à Ontologia
Origem e a Ontologia Alvo. A Figura 8 é um exemplo gráfico de alinhamento de
ontologias; e
19
Figura 8. Alinhamento de ontologias
Fonte: Hinz e Polazzo (2007).
•
Interação de Ontologias: na interação de ontologia podem-se ter várias Ontologias
Origem, a partir das Ontologias Origem será construída uma nova ontologia que englobe
todos os termos das ontologias envolvidas. Este método não permite fazer tradução de
ontologias, pois ele serve para criar uma nova ontologia que vai conter todos os termos
comuns entre as Ontologias Origens. A Figura 9 é um exemplo gráfico de interação de
ontologias.
Figura 9. Interação de ontologias
Fonte: Hinz e Polazzo (2007).
O mapeamento de ontologias pode ser realizado de forma automática, semi-automático ou
até mesmo manual. Manualmente, o risco de se cometer uma falha é grande, pode-se acabar
cometendo erros fazendo como que o mapeamento fique defeituoso, além disto é considerado um
processo difícil e demorado (NOY; MUSEN, 1999 apud CHAVES; LIMA, 2003).
20
Já o mapeamento de forma automática é extremamente difícil de ser implementado, é um
tema que envolve muitas pesquisas e é um grande problema nesta área (USCHOLD, 2001 apud
CHAVES; LIMA, 2003).
A melhor forma de ligar conhecimentos que tenham similaridades representadas por
ontologias ou interligar sistemas que utilizem-se de ontologias pra prover comunicação, é através de
mapeamento (CHAVES; LIMA, 2003). Segundo Chaves e Lima (2003) através da abordagem
Heurística e de Probabilidade pode-se prover o mapeamento de ontologias de forma automática:
•
Heurística: considera como porcentagem de similaridade a diferença entre o total de
termo de uma ontologia A e o número de termos que podem ser relacionados com uma
ontologia B. Uma ontologia A contem dez termos, e destes, oito termos conseguem ser
mapeados para uma ontologia B, sendo assim a ontologia A tem 80% de similaridade
com a B; e
•
Probabilidade: o grau de similaridade é feito através de conceitos que identificam
similaridade.
Segundo Chaves e Lima (2003), similaridade é uma medida que serve para avaliar se a
mudança de uma cadeia de caracteres ocorre ou não. Como por exemplo, “moto” para
“motocicleta”, para transformar uma na outra é necessário alterar quatro caracteres. Existem dois
tipos de análise de similaridade, a análise léxica e análise semântica, elas vêm sendo muito
pesquisadas (2001 apud NOLL; SACOLL; EDELWEISS, 2007):
•
Normalização: os termos semânticos que tenham o mesmo significado em diferentes
ontologias irão receber nomes em comuns. Na ontologia A se tem um termo denominado
como carro e na ontologia B como moto, com a formalização eles passariam a se chamar
automóvel;
•
Categorização: são separados em grupos os termos que mais se parecem, desta forma os
termos de um grupo só serão comparado com os termos que ser refere ao grupo
relacionado da outra classe. Em uma ontologia A se tem termo carro e o termo
caminhão. Aplicando a categorização será inserido os termos carro e caminhão dentro
um grupo veículo, por exemplo; e
•
Comparação: é atribuído para os elementos um grau de similaridade dentro das suas
categorias.
21
Segundo Hinz e Palazzo (2007) para que o mapeamento de ontologias seja feito de forma
eficaz, permitindo que sistemas consigam se comunicar, é necessário que o mapeamento utilize um
bom algoritmo de identificação de termos correlacionados. Dois algoritmos para análise de
similaridade léxica são:
•
Edit Distance: avalia duas seqüências de caracteres pelo número mínimo de operações
necessárias para transformar uma cadeia em outra (LEVENSHTEIN, 1966 apud NOLL,
SACOLL; EDELWEISS, 2007); e
•
Stemmer: avaliação de seqüência de caractere pela redução de uma palavra ao seu
radical (STEMMER, 2007 apud NOLL; SACOLL; EDELWEISS, 2007).
Já na análise de similaridade léxica, é feita verificação ente os termos e durante o processo
de normalização é recomendável a utilização de uma lista com os termos para relacionar os
conceitos para que possa ser feita a avaliação (NOLL; SACOLL; EDELWEISS, 2007).
2.4 TRABALHOS SIMILARES
Ferramentas que eliminem as diferenças entre ontologias e que possibilitem a troca de
mensagens entre aplicações são fundamentais para que os sistemas consigam ter uma maior
interoperabilidade (KALFOGLOU; SCHORLEMMER, 2004). Atualmente, existem soluções que
utilizam ontologias, seja construindo ontologias ou interligando duas ontologias distintas. Neste
trabalho foram estudados três aplicativos: Ontology Builder (OntBuild), Protégé e Glue.
2.4.1
Ontology Builder (OntBuild)
A Ontology Builder é uma ferramenta que serve para criar ontologias a partir de documentos
com representações em XML, utiliza-se de uma especificação para saber quais termos dos
documentos devem ser aproveitados e como que eles se associam entre si (LIBRELOTTO;
RAMALHO; HENRIQUES, 2003).
A ferramenta utiliza-se de um XML padrão criado para descrever quais informações deverão
ser extraídas dos documentos XML dos quais se devem criar a ontologia. As ontologias são criadas
no padrão XML (ibidem).
Na Figura 10 se tem representado a arquitetura proposta do Ontology Builder:
22
•
Extrator de Topic Map: gera uma ontologia que vem de uma base de documento XML;
•
XSTM-P: é a representação de uma base de documentos no formato XML;
•
XML FONTE: através deste arquivo o Extrator Topic Map gera a ontologia resultante;
•
XSTM: XSTM é a representação de um formato de arquivo em XML; e
•
Topic Map: é o arquivo gerado pelo Extrator de Topic Map.
Figura 10. OntBuild
Fonte: Librelotto, Ramalho e Henriques (2003)
A similaridade entre o Ontology Builder e a APTO está na geração de uma ontologia
resultante, além disto, elas necessitam de um documento para saber quais termos serão utilizados
para criar a Ontologia Alvo, ou seja, as duas se utilizam de mapeamento.
A ferramenta Ontology Builder gera uma ontologia a partir de um documento em XML, já o
APTO por ser uma API, auxilia programadores na hora do desenvolvimento dos sistemas que
utilizam metadados divergentes.
2.4.2
Protégé
A ferramenta Protégé foi desenvolvida na Universidade de Stanford pelo departamento de
informática médica. No início ela era uma ferramenta de aquisição de conhecimento para apenas
um sistema especialista para ontologias. Ela foi desenvolvida em Java e de código aberto. Devido a
23
isso possui vários componentes (PROTÉGÉ, 2008). Três exemplos de componentes para o Protégé
são:
•
Plugin OKBC: para acesso remoto de ontologias;
•
Ontoviz: componente gráfico para construção de ontologias; e
•
Jambalaya: componente gráfico para construção de ontologias.
Aos poucos Protégé foi se aperfeiçoando com a evolução dos Sistemas de Base em
Conhecimento (SBC), hoje está ferramenta permite criar ontologias de domínios, personalizar
formulários de dados, inserir e editar dados, possibilitando a construção de SBC guiado por uma
ontologia. Através do Protege é possível criar ontologias em diversos formatos, como por exemplo:
XML, RDF e OWL (PROTÉGÉ, 2008).
Na Figura 11 pode-se observar a ferramenta Protégé. Nela está sendo mostrada uma
ontologia representada de forma gráfica em OWL.
24
Figura 11. Ontologia no Protégé
Fonte: Protege (2008)
Em comparação do Protégé com o APTO, é possível afirmar que as duas ferramentas se
diferem quase por completamente, pois a ferramenta Protégé se propõe a criação de ontologias. Já o
APTO se propõe em traduzir uma ontologia em outra. O que elas têm em comum é que ambas
utilizam ontologias, uma traduzindo e outra criando.
2.4.3
Glue
O Glue é uma ferramenta para geração de mapeamento de ontologias. Esta ferramenta
utiliza de técnicas de similaridade para conseguir realizar a tradução de ontologias com eficácia. O
foco desta aplicação é mapear ontologias de domínio. Através do Glue não é possível realizar
tradução de ontologias, pois esta ferramenta apenas mapeia a ontologia e não as traduz (DOAN et
al., 2002).
25
As duas são extremamente distintas, pois a ferramenta Glue se propõe a mapear duas
ontologias distintas. Já o APTO se propõe em traduzir metadados em outro, através de
mapeamentos de ontologias. Outra distinção entre elas é que o APTO se dispõe a ser uma API ao
invés de uma aplicação, como Glue. No entanto há uma similaridade entre elas, ambas tem o foco
em resolver problema de interoperabilidade de sistemas.
A ferramenta Glue poderia se aproveitar da API APTO para gerar a tradução de ontologias
depois ter sido elaborado o mapeamento pelo Glue.
2.4.4
Discussão sobre Trabalhos Similares
Através dos trabalhos similares pesquisados foi possível constatar que nenhuma técnica ou
ferramenta sozinha consegue resolver totalmente o problema de interoperabilidade entre sistemas,
como exemplo pode-se citar o Glue que faz mapeamento só que não faz tradução de ontologias.
Na Tabela 1 apresentam-se as diferenças e similaridades entre os trabalhos estudados e a
API APTO.
Tabela 1. Ferramentas similares
Ferramentas
Utiliza mapeamento de ontologia?
OntBuild
SIM
Protégé
NÃO
Glue
NÃO
APTO
SIM
Gera o mapeamento de ontologia de forma manual?
NÃO
NÃO
NÃO
NÃO
Gera o mapeamento de ontologia de forma semiautomático?
NÃO
NÃO
SIM
NÃO
Gera o mapeamento de ontologia de forma
automática?
NÃO
NÃO
NÃO
NÃO
Permite a criação de ontologia de forma manual?
NÃO
SIM
NÃO
NÃO
Permite a criação de ontologia de forma automática?
SIM
SIM
NÃO
NÃO
Realiza tradução de ontologias?
NÃO
NÃO
NÃO
SIM
Fornece API para desenvolvimento de aplicações ?
NÃO
NÃO
NÃO
SIM
26
Na Tabela 1 pode-se observar que nenhuma das ferramentas analisadas se propõe a fazer a
tradução de ontologias como API APTO, e isso realmente comprova o quanto a proposta deste
trabalho é importante para área de pesquisa de interoperabilidade. O fato mais marcante nesta
analise é que a técnica de mapeamento de ontologias é a mais utilizada para o tratamento de
formatos divergentes e foi também possível compreender que nenhuma ferramenta sozinha
consegue resolver totalmente o problema de interoperabilidade.
27
3 PROJETO
Neste capítulo é abordado o projeto da API para tradução de ontologias o APTO que foi
desenvolvido no decorrer do TCC II. São abordados como tópicos: requisitos do projeto, descrição
das classes (seguindo o paradigma de Orientação a Objetos), descrição dos diagramas de seqüência,
discussão sobre tecnologias a serem utilizadas.
3.1 REQUISITOS
Nesta seção serão abordados os requisitos do projeto. Tais requisitos servem para especificar
o que a API deve fazer e o que ela não contempla. Para facilitar a leitura os requisitos foram
divididos em: funcionais (representados pela sigla RF), não funcionais (representados pela sigla
RNF) e regras de negócio (representados pela sigla RN).
3.1.1
Requisitos Funcionais
Requisitos funcionais são as especificações das funções que API deve contemplar e como
ela deve agir a determinadas ações. O requisito funcional do projeto APTO é:
•
RF01: a API deve realizar a tradução da Ontologia Origem com base na Ontologia de
Mapeamento gerando uma Ontologia Alvo.
3.1.2
Requisitos Não Funcionais
Requisitos não funcionais definem as restrições e características da API. Os requisitos não
funcionais do projeto APTO são:
3.1.3
•
RNF01: a API deve ser implementada utilizando a linguagem de programação JAVA; e
•
RNF02: a API só deve traduzir ontologias baseados em XML.
Regras de Negócios
As Regras de negócios especificam como o negócio deve funcionar. Elas estão ligada a
forma que a API deverá tratar suas regras em nível de implementação. As regras de negócio do
projeto APTO são:
28
•
RN01: a API deve traduzir a Ontologia de Origem de acordo com uma Ontologia de
Mapeamento, ambas fornecida por parâmetro;
•
RN02: a API deverá retornar uma estrutura de dados serializada em formato do tipo
String contendo a Ontologia Alvo;
•
RN03: o parâmetro Ontologia Origem deverá ser no formato de String, exigindo a
serialização do XML de entrada; e
•
RN04: o parâmetro Ontologia de Mapeamento deverá ser no formato de String, exigindo
a serialização do XML de entrada.
3.2 DIAGRAMA DE CASOS DE USO
Na Figura 12 pode-se visualizar o caso de uso da API APTO, só será necessário um caso de
uso, pois a maior complexidade deste Trabalho de Conclusão de Curso está em traduzir a ontologia.
A Figura 12 mostra a interação entre o Ontologia Origem (ator) e o UC01- Traduz Ontologia (caso
de uso) que constitue a API e gera a Ontologia Alvo (ator). O sistema que estiver utilizando API
poderá traduzir ontologia desejada.
Figura 12. Diagrama de Casos de Uso demonstrando o processo usabilidade do APTO
3.3 DIAGRAMA DE CLASSES
Na Figura 13 estão representadas as classes da API proposta no projeto:
29
•
TradutorOntologia: é nesta classe que vão estar as regras de tradução a partir do
mapeamento de ontologia; e
•
Document: é a classe responsável por representar a estrutura de dados que é utilizada na
representação do XML que é manipulado pelo APTO. O XML esta sendo representado
pela API JDOM.
Figura 13. Diagrama de classe demonstrando as classes que o APTO irá implementar
3.4 DIAGRAMA DE SEQUÊNCIA
Para demonstrar o funcionamento das atividades do projeto APTO foi elaborado o diagrama
de sequência presente na Figura 14. As entidades que fazem parte do diagrama são:
•
Sistema: o sistema é qualquer ferramenta ou programa que utilize o APTO, para
tradução de ontologias;
•
TradutorOntologia: é o objeto responsável por traduzir a Ontologia de Origem na
Ontologia Alvo através da Ontologia de Mapeamento;
•
Origem: Document: este objeto é a Ontologia Origem no formato de XML representado
através da API JDOM;
•
Mapemaento: Document: este objeto é a Ontologia de Mapeamento no formato de XML
representado através da API JDOM; e
•
Alvo: Document: este objeto é a Ontologia Alvo no formato XML representado através
da API JDOM.
30
O diagrama demonstra que um Sistema cria um objeto TradutorOntologia e que ele faz a
solicitação da tradução de ontologia para API informando a Ontologia Origem e a Ontologia de
Mapeamento, através do objeto TradutorOntologia instanciada. Após a solicitação da tradução o
TradutorOntologia solicita a transformação das ontologias de entrada que estão no formato String
para a estrutura de dados através da classe XML. Depois que as ontologias de entradas já estão no
formato do modelo XML, é feita a tradução da Ontologia Origem para Ontologia Alvo. Após a
tradução a Ontologia Alvo é transformada para o formato de String pelo objeto Alvo:Document.
Por último a Ontologia Alvo é retornada para o Sistema no formato de String.
Figura 14. Diagrama de seqüência demonstrando o processo de tradução que o APTO pretende
adotar
NA Figura 15 pode-se ver um exemplo sintético do que poderia ser um mapeamento entre as
ontologias Dublin Core e Learning Object Metadata. A Ontologia de Mapeamento (árvore do centro
da figura) estabelece quais são as equivalências entre Dublin Core e Learning Object Metadata.
Esse “mapeamento” de equivalências é o que permitirá uma tradução de Dublin Core para Learning
Object Metadata e vice-versa.
31
Ontologia de Mapeamento
Dublin Core x LOM
LOM
Dublin Core
Figura 15. Exemplo de um mapeamento simplificado entre as ontologias Dublin Core e LOM
32
4 DESENVOLVIMENTO
Após apresentação dos tópicos de modelagem do projeto desenvolvido, foram efetuadas as
implementações com o intuito de construir a API modelada. Neste capítulo serão abordos aspectos
técnicos sobre a implementação da API para Tradução de Metadados em XML. Os tópicos
abordados são: tecnologias utilizadas no desenvolvimento, mapeamento utilizado, utilização do
APTO e validação da API.
4.1 Tecnologias utilizadas no desenvolvimento
Para que o projeto fosse concluído com sucesso, foi necessário estudar algumas API para
manipulação do XML. As tecnologias utilizadas estão dividido nos sub-tópicos XSLT, JDOM e
JAXP.
4.1.1
XSLT
A Extensible Stylesheet Language (XSL) determina a apresentação de um determinado
elemento XML. Ela fornece informações de padronização ou layout sobre o documento XML. O
XSL está para o arquivo XML, assim como o CSS está para HTML (W3C, 1999).
O XSL está dividido em três partes, são eles (W3C, 1999):
•
XSLT: linguagem para transformação de XML;
•
XPath: linguagem para navegar em arquivos XML; e
•
XSL-FO: linguagem para formatar arquivos XML.
A Extensible Stylesheet Language Transformations (XSLT) é uma linguagem em XML com
um formato pré-definido para ser utilizado na transformação de um documento XML em outro
arquivo qualquer. Ele é o formato recomendado pela W3C. Através do deste arquivo de
transformação é possível inserir e remover elementos, tomar decisões e até mesmo ordenar os
conteúdos, em um arquivo no formato XML. O XSLT é considerado a parte mais importante do
XSL. Neste trabalho também, pois o intuito é fazer uma tradução e não a representação de um
XML (W3C, 1999).
33
Para conseguir efetuar a transformação o XSLT utiliza-se do XPath para navegar no
documento XML, buscando os elementos que possuem correlação entre os documentos
correspondentes, estabelecidos no XSLT. Depois de encontrar os elementos equivalentes, ele copia
ou transforma dependendo da necessidade especificada, e monta o arquivo resultante (W3C, 1999).
XSLT tem vários elementos, com diversas funcionalidades, abaixo pode-se ver algumas
delas, estas estão sendo utilizadas na API do projeto (W3C, 1999):
•
Value-of: serve para pegar o valor de um nó especificado em outro XML;
•
If: serve para que seja possível aplicar condições, com o intuito de se utilizar de outras
funcionalidades do XSLT somente se satisfazer a condição expressa;
•
Element: é utilizado para criar um nó no documento de saída;
•
For-each: pega todos os nós de um determinado elemento, ou seja ele faz um loop
percorrendo todos os nós especificados em um documento XML;
•
Atribute: é utilizado para substituir o nome do elemento especificado; e
•
Param: serve para criar uma variável, ela pode ser utilizada para testes em condições If
ou até mesmo para exibidas em um elemento Value-of, ou em um elemento Atribute.
Pode ser visualizar um exemplo de XSLT na Figura 16, onde esta representado a
transformação de um arquivo XML para HTML.
34
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="agenda">
<html>
<head>
<title>Exemplo de XSLT</title>
</head>
<body>
<b>Clientes</b>
<table border="1">
<tr>
<th>Nome</th>
<th>Telefone</th>
</tr>
<xsl:for-each select="cliente">
<tr>
<td><xsl:value-of select="nome"/></td>
<td><xsl:value-of select="fone"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Figura 16. Exemplo de XSLT
Pode ser visualizado um exemplo de XML utilizado para exemplificar a transformação neste
trabalho na Figura 17, neste arquivo XML se tem representado uma agenda telefônica.
<?xml version="1.0" encoding="ISO-8859-1"?>
<agenda>
<cliente>
<nome>Felipe</nome>
<fone>3347-7777</fone>
</cliente>
<cliente>
<nome>Thiago</nome>
<fone>3348-8888</fone>
</cliente>
<cliente>
<nome>João</nome>
<fone>3349-9999</fone>
</cliente>
</agenda>
Figura 17. Exemplo de XML
Pode ser visualizado um exemplo do resultado da transformação entre o XML e o XSLT na
Figura 18.
35
<html>
<head>
<title>Exemplo de XSLT</title>
</head>
<body>
<b>Clientes</b>
<table border="1">
<tr>
<th>Nome</th>
<th>Telefone</th>
</tr>
<tr>
<td>Felipe</td>
<td>3347-7777td>
</tr>
<tr>
<td>Thiago</td>
<td>3348-8888td>
</tr>
<tr>
<td>João</td>
<td>3349-9999<td>
</tr>
</table>
</body>
</html>
Figura 18. Exemplo de Arquivo Resultante da Tradução do XSLT
O arquivo XSLT representado na Figura 16 entra no elemento raiz de um arquivo XML,
percorrendo todos os elementos denominados por cliente, após achar o elemento procurado através
do Xpath, vai entrar nos elementos filhos, nome e fone, pegando os seus respectivos conteúdos e o
substituindo no arquivo resultante. Pode-se observar que todas tags reservadas pelo arquivo XSLT
começa xsl, as outras tags que não contém xsl simplesmente são copiadas para o arquivo resultante.
Os arquivos XML que foi utilizado na transformação pode ser visto na Figuras 17 e o resultado da
transformação pode ser visualizado na Figuras 18. Como mencionado anteriormente a
transformação pode ser para vários formatos de arquivos, como XML, HTML entre outros.
4.1.2
JDOM
O JDOM foi utilizado na API implementada para representar o XML enviado pelo sistema
usuário, e para montar o XML resultante. Ela é uma API com o código aberto desenvolvida em
Java, com o intuito de facilitar a criação, leitura e manipulação de documentos XML. A sua
estrutura é baseada na árvore do DOM. A principal diferença entre DOM e JDOM é que o DOM foi
criado com o intuito de ser utilizado em Java Script para manipular páginas HTML, já o JDOM foi
criado especificamente para Java assim aproveitando todos os recursos oferecidos por essa
36
linguagem de programação, tais como: métodos de sobrecarga, coleções, reflexão e expressões de
idiomas (JDOM, 2002).
O JDOM pode ser utilizado para transferir dados entre SAX e DOM, e ele é mais amigável
do que os dois. Ele trata tudo como classe e não como interface, ou seja, toda tag é representada
pela classe org.jdom.Element e os documentos XML são representados pela classe
org.jdom.Document (JDOM, 2002).
É importante ressaltar que as principais características do JDOM são:
•
Facilitador no desenvolvimento de aplicações por parte dos programadores Java;
•
As modificações de um documento XML são mais eficientes e fáceis de serem
realizadas;
•
Abstração das complexidades de se trabalhar com arquivos XML;
•
A API se integra com DOM e SAX;
•
É uma API utiliza-se de pouca memória e rápido em seu processamento considerando
outras API para manipulação de XML;
•
Não pode manipular documentos maiores que a memória disponível no computador; e
•
O XML não esta representado de forma física, fica representado apenas logicamente na
memória.
4.1.3
JAXP
O JAXP (Java API for XML Processing) é uma API em JAVA para processar documentos
XML, permitindo que o documento seja interpretado, analisado, e transformado em outro
documento. Um sistema que utiliza esta API pode trabalhar o documento independente da
tecnologia DOM ou SAX, pois esta API permite que se trabalhe com as duas (JAXP-SUN, 2003).
Para que o JAXP consiga fazer a transformação é necessário um documento XSLT, pois é
neste arquivo que vão conter todas as regras de transformação, e também um arquivo XML a ser
transformado para outro arquivo. Na Figura 19 pode-se visualizar um exemplo do JAXP sendo
utilizado para processar um arquivo XSLT e um XML. Após o processamento ele gera um terceiro
arquivo, o arquivo resultado, no caso do exemplo um arquivo em HTML (JAXP-SUN, 2003).
37
Figura 19. Exemplo do JAXP Realizando a Transformação
A biblioteca JAXP contém diversos pacotes, abaixo estão listados os principais (JAXPSUN, 2003):
•
javax.xml.Parsers: definição de uma interface comum para diferentes fornecedores de
parsers SAX e DOM. Este pacote também define as classes de exceção para tratamento
de erros;
•
javax.xml.Transform: serve para transformações dos documentos XML para diversos
formatos, utilizando-se de um XSLT;
•
org.xml.Sax: definição das interfaces para SAX: ContentHandler, ErrorHandler,
DTDHandler e EntityResolver;
38
•
org.xml.sax.Ext: definição das extensões do SAX que são usadas quando um
processamento mais sofisticado é requerido (como o processamento de um DTD, por
exemplo);
•
org.xml.sax.Helpers: definição de classes de ajuda para tornar a implementação da
interface SAX mais amigável; e
•
org.w3c.Dom:
definição da classe para o documento DOM e todos os seus
componentes.
A API desenvolvida neste projeto utiliza-se do pacote javax.xml.Transform da biblioteca
JAXP para conseguir realizar a tradução de um Document em outro.
4.2 Mapeamento Utilizado
Para que fosse possível a avaliação da API APTO foi criado um mapeamento que permita a
tradução de uma ontologia expressa em Learning Object Metadata para Dublin Core e vice-versa.
Para realizar o mapeamento entre LOM e Dublin Core foi utilizado como referência o trabalho de
(LTSC IEEE, 2005). O mapeamento pode ser visualizado na Tabela 2.
39
Tabela 2. Mapeamento entre Dublin Core e LOM
Dublin Core
Identifier
Title
Language
Description
Subject
Coverage
Type
Date
LOM
General.Identifier.Entry
General.Title
General.Language
General.Description
General.Keyword OU Classification SE Classification.Purpose =
"Discipline" OU "Idea"
General.Coverage
Educational.LearningResourceType
LifeCycle.Contribute.Date SE LifeCycle.Contribute.Role = "Publisher"
Creator
LifeCycle.Contribute.Entity SE LifeCycle.Contribute.Role = "Author"
OtherContributor
LifeCycle.Contribute.Entity SE LifeCycle.Contribute.Role != ""
Publisher
LifeCycle.Contribute.Entity SE LifeCycle.Contribute.Role = "Publisher"
Format
Technical.Format
Rights
Rights.Description
Relation
Relation.Resource.Description
Source
Relation.Resource.Indentifier.Entry SE Relation.Kind = "IsBasedOn"
Fonte: Adaptado de LTSC IEEE (2005).
Na Tabela 2 pode-se verificar os relacionamentos de cada elemento efetuados entre Dublin
Core e LOM. O elemento Identifier do Dublin Core esta para LOM no elemento General subelemento Identifier até chegar na folha Entry. Outro exemplo é onde o Subject do Dublin Core pode
estar sendo relacionado com General.Keyword ou como Classication, ou até mesmo ter condições
para saber se o elemento esta relacionado ou não.
Com o mapeamento criado identificou-se a necessidade de representá-lo em um formato
XML. Abaixo se tem a lista das tags necessárias para se criar o mapeamento identificado:
•
Translation: elemento root do mapeamento, este elemento é obrigatório;
•
Root: é o nó pai que serve para especificar o mapeamento de quem para quem esta se
traduzindo;
•
Map: é o nó pai que serve para identificar quais elementos se relacionam;
•
Rela1: serve para identificar qual nó do 1º XML representado tem relação nó do outro
XML;
40
•
Rela2: serve para identificar qual nó do 2º XML representado tem relação nó do outro
XML;
•
Cond1_if: serve para que seja possível criar condições, ou seja, para que a tradução
ocorra
do 1º XML para o outro XML é necessário atender uma determinada
condição expressa neste elemento;
•
Cond2_if: serve para que seja possível criar condições, ou seja, para que a tradução
ocorra
do 2º XML para o outro XML é necessário atender uma determinada
condição expressa neste elemento;
•
Rela1_cond: identifica qual nó do 1º XML tem relação com nó do 2° XML, mais a
relação só acontecerá se atender a condição determinada e expressa na cond1_if; e
•
Rela2_cond: serve para identificar qual nó do 2º XML tem relação com nó do 1° XML,
mais a relação só acontecerá se atender a condição determinada e expressa na cond2_if.
O mapeamento entre LOM e Dublin Core criado pode ser visualizado a primeira parte na
Figuras 20 e a segunda na Figura 21. No mapeamento criado cda nó “map” vai conter uma relação
entre os padrões a serem traduzidos,onde se tem “rela1” ou “rela1_cond” ou “cond1_if” representa
o LOM e onde se tem “rela2” ou “rela2_cond” ou “cond2_if” significa que é do Dublin Core.
Quando o usuário da API for criar o mapeamento entre dois padrões ele deve estabelecer qual
padrão será o 1° padrão e qual será o 2° padrão e isto é informado através do “root”.
41
<?xml version=\"1.0\"?>
<translation>
<root>
<rela1>lom</rela1>
<rela2>dc</rela2>
</root>
<map>
<rela1>General_Identifier_Entry</rela1>
<rela2>Identifier</rela2>
</map>
<map>
<rela1>General_Title</rela1>
<rela2>Title</rela2>
</map>
<map>
<rela1>General_Language</rela1>
<rela2>Language</rela2>
</map>
<map>
<rela1>General_Description</rela1>
<rela2>Description</rela2>
</map>
Figura 20. Mapeamento desenvolvido primeira parte
42
<map>
<cond1_if>Classification_Purpose = 'Idea' or Classification_Purpose
'Discipline' and General_Keyword = ''</cond1_if>
<rela1>General_Keyword</rela1>
<rela1_cond>Classification_Description</rela1_cond>
<rela2>Subject</rela2>
</map>
<map>
<rela1>General_Coverage</rela1>
<rela2>Coverage</rela2>
</map>
<map>
<rela1>Educational_LearningResourceType</rela1>
<rela2>Type</rela2>
</map>
<map>
<cond1_if>LifeCycle_Contribute_Role = 'Publisher'</cond1_if>
<rela1_cond>LifeCycle_Contribute_Date</rela1_cond>
<rela2>Date</rela2>
</map>
<map>
<cond1_if>LifeCycle_Contribute_Role = 'Author'</cond1_if>
<rela1_cond>LifeCycle_Contribute_Entity</rela1_cond>
<rela2>Creator</rela2>
</map>
<map>
<cond1_if>LifeCycle_Contribute_Role != ''</cond1_if>
<rela1_cond>LifeCycle_Contribute_Entity</rela1_cond>
<cond2_if>Creator = ''</cond2_if>
<rela2_cond>OtherContributor</rela2_cond>
</map>
<map>
<cond1_if>LifeCycle_Contribute_Role = 'Publisher'</cond1_if>
<rela1_cond>LifeCycle_Contribute_Entity</rela1_cond>
<cond2_if>Creator = '' and OtherContributor = ''</cond2_if>
<rela2_cond>Publisher</rela2_cond>
</map>
<map>
<rela1>Technical_Format</rela1>
<rela2>Format</rela2>
</map>
<map>
<rela1>Rights_Description</rela1>
<rela2>Rights</rela2>
</map>
<map>
<rela1>Relation_Resource_Description</rela1>
<rela2>Relation</rela2>
</map>
<map>
<cond1_if>Relation_Kind = 'IsBasedOn'</cond1_if>
<rela1_cond>Relation_Resource_Indentifier_Entry</rela1_cond>
<rela2>Source</rela2>
</map>
</translation>
Figura 21. Mapeamento desenvolvido segunda parte
43
=
4.3 Utilização do APTO
Como o APTO é uma API, ou seja serve como uma camada de software para que os
progamdores utilzem para conseguir prover uma interoperabilidade entre os sistemas, o mesmo não
contém interface para usuário.
A utilização da API APTO pode ser visualizada na Figura 22.
/*
* Exemplo de utilização do APTO
* @author Felipe
*/
//Importar a API APTO
import APTO.APTO;
public class Exemplo_utilizacao_APTO {
public static void main(String[] args) throws Exception {
//Declaração do APTO
APTO apto = new APTO();
String ontologia_origem = "";
String ontologi_mapeamento="";
String ontologi_alvo="";
int direcao = 1;
//XML Origem em LOM
ontologia_origem = "<?xml version=\"1.0\"?>"
+"<lom>"
+"<General>"
+"<Identifier>"
+"<Entry>Felipe</Entry>"
+"</Identifier>"
+"</General>"
+"</lom>";
//XML de Mapeamento
ontologi_mapeamento= "<?xml version=\"1.0\"?>"
+"<translation>"
+"<root>"
+"<rela1>lom</rela1>"
+"<rela2>dc</rela2>"
+"</root>"
+"<map>"
+"<rela1>General_Identifier_Entry</rela1>"
+"<rela2>Identifier</rela2>"
+"</map>"
+"</translation>";
System.out.println(ontologi_alvo
=
apto.Tradutor(ontologia_origem,
ontologi_mapeamento,direcao));
}
}
Figura 22. Exemplo de utilização do APTO
Para conseguir utilizar a API primeiramente é necessário fazer a declaração da mesma, para
isto é utilizado o comando “import APTO.APTO;”. Após a declaração é necessário criar uma
instância da ferramenta, através do código “APTO apto = new APTO();”. Como etapa final deve-se
44
passar uma Ontologia Origem e uma Ontologia de Mapeamento e a direção que se deseja traduzir
“apto.Tradutor(ontologia_origem, ontologi_mapeamento,direcao)” e por final a API retorna no
formato String a Ontologia Alvo. No exemplo demonstrado na Figura 22 é utilizado como
“direcao” o “1” pois a Ontologia Origem esta expressa nas primeiras relações.
4.4 Validação da API
Para avaliar a API APTO foram utilizados os metadados que são geralmente utilizados para
descrever Objetos de Aprendizagem (conforme descrito na Introdução e na Problematização deste
trabalho): Dublin Core e Learning Object Metadata. Foram efetuadas duas avaliações para
validação da API, a primeira de LOM para Dublin Core e a segunda de Dublin Core para LOM.
4.4.1
LOM para Dublin Core
O processo de avaliação que foi utilizado para verificar o funcionamento da API foi da
seguinte forma: a API recebeu uma Ontologia Origem em Learning Object Metadata e uma
Ontologia de Mapeamento entre Dublin Core e Learning Object Metadata expresso através de texto,
e retornou uma ontologia (Ontologia Alvo) equivalente em Dublin Core. A Figura 20 e Figura 21
representam a Ontologia de Mapeamento recebida pela API, na Figura 23 se tem a Ontologia
Origem e na Figura 24 a Ontologia Alvo que é o resultado da tradução.
45
<?xml version="1.0"?>
<lom>
<General>
<Identifier>
<Entry>Felipe01</Entry>
</Identifier>
<Title>Objeto do Felipe</Title>
<Language>Portugues</Language>
<Description>Este objeto foi criado para teste da API</Description>
<Keyword></Keyword>
<Coverage>API</Coverage>
</General>
<LifeCycle>
<Contribute>
<Role>Author</Role>
<Entity>Felipe Flor</Entity>
<Date>05/05/2009</Date>
</Contribute>
</LifeCycle>
<Technical>
<Format>XML</Format>
</Technical>
<Educational>
<LearningResourceType>Objeto de Aprendizagem</LearningResourceType>
</Educational>
<Rights>
<Description>Codigo Aberto</Description>
</Rights>
<Relation>
<Kind>IsBasedOn</Kind>
<Resource>
<Identifier>
<Entry>http://www.w3.org/2004/OWL</Entry>
</Identifier>
<Description>Web Ontology Language (OWL)</Description>
</Resource>
</Relation>
<Classification>
<Purpose>Discipline</Purpose>
<Description>Teste da API</Description>
</Classification>
</lom>
Figura 23. Ontologia Origem em LOM
A Figura 23 representa um metadado em LOM utilizado como parâmetro de entrada na API
APTO, ou seja, ela é a Ontologia Origem. Neste metadado se tem representado todos os elementos
que contém ligações entre LOM e Dublin Core, que esta representado na Tabela 2. Já na Figura 24
se tem o resultado da tradução.
46
<?xml version="1.0"?>
<dc>
<Identifier>Felipe01</Identifier>
<Title>Objeto do Felipe</Title>
<Language>Portugues</Language>
<Description>Este objeto foi criado para teste da API</Description>
<Subject>Teste da API</Subject>
<Coverage>API</Coverage>
<Type>Objeto de Aprendizagem</Type>
<Date></Date>
<Creator>Felipe Flor</Creator>
<OtherContributor>Felipe Flor</OtherContributor>
<Publisher></Publisher>
<Format>XML</Format>
<Rights>Codigo Aberto</Rights>
<Relation>Web Ontology Language (OWL)</Relation>
<Source>http://www.w3.org/2004/OWL</Source>
</dc>
Figura 24. Ontologia Alvo resultante em Dublin Core
A Figura 24 representa um metadado em Dublin Core retornado pela API APTO, ou seja,
ela é a Ontologia Alvo, o resultado da tradução. O resultado do teste da tradução de LOM para
Dublin Core foi considerado bem sucedido.
4.4.2
Dublin Core para LOM
Nesta etapa de teste o processo de avaliação utilizado para validar a API foi da seguinte
forma: a API recebeu uma Ontologia Origem em Dublin Core e uma Ontologia de Mapeamento
entre Dublin Core e Learning Object Metadata expresso através de texto, e retorna uma ontologia
(Ontologia Alvo) equivalente em LOM. A Figura 20 e Figura 21 representam a Ontologia de
Mapeamento recebida pela API, na Figura 25 se tem a Ontologia Origem e na Figura 26 a
Ontologia Alvo que é o resultado da tradução.
<?xml version=\"1.0\"?>
<dc>
<Identifier>Felipe01</Identifier>
<Title>Objeto do Felipe</Title>
<Language>Portugues</Language>
<Description>Este objeto foi criado para teste da API</Description>
<Subject>Teste da API</Subject>
<Coverage>API</Coverage>
<Type>Objeto de Aprendizagem</Type>
<Date>08/10/2009</Date>
</dc>
Figura 25. Ontologia Origem em Dublin Core
47
A Figura 25 representa um metadado em LOM utilizado como parâmetro de entrada na API
APTO, ou seja, ela é a Ontologia Origem. Já na Figura 26 se tem o resultado da tradução.
<?xml version=\"1.0\"?>
<dc>
<Identifier>Felipe01</Identifier>
<Title>Objeto do Felipe</Title>
<Language>Portugues</Language>
<Description>Este objeto foi criado para teste da API</Description>
<Subject>Teste da API</Subject>
<Coverage>API</Coverage>
<Type>Objeto de Aprendizagem</Type>
<Date>08/10/2009</Date>
</dc>
Figura 26. Ontologia Alvo em LOM
A Figura 26 representa um metadado em LOM retornado pela API APTO, ou seja, ela é a
Ontologia Alvo, o resultado da tradução. O resultado nessa etapa de validação da tradução de
Dublin Core para LOM foi considerado o esperado.
48
5 CONSIDERAÇÕES FINAIS
O desenvolvimento de uma ferramenta para promover interoperabilidade entre metadados é
uma tarefa que exigiu uma grande compreensão dos conceitos. Com a pesquisa bibliográfica foi
possível compreender a importância dos metadados para os Objetos de Aprendizagem, tais como
seus repositórios.
A etapa de pesquisa de Mapeamento de Ontologias foi fundamental para ter uma base sólida
para firmar a técnica a ser utiliza pelo APTO. Assim mostrando que a técnica mais plausível para se
utilizar na API proposta é o mapeamento de ontologia, pois é através dela que é possível realizar a
tradução de ontologias. Também serviu para compreender e verificar que a construção de um
mapeamento entre duas ontologias não seria tarefa nem um pouco fácil.
Na pesquisa das ferramentas similares encontraram-se métodos para promover a
comunicação entre sistemas que utilizam diferentes padrões de comunicação, que visou entender os
conceitos e métodos relevantes ao projeto. Através das referências estudadas, foi possível
compreender os padrões de comportamento das ferramentas que trabalham com metadados. E com
a pesquisa foi constatado que nenhuma técnica ou ferramenta sozinha consegue resolver totalmente
o problema de interoperabilidade entre sistemas, e que nenhuma ferramenta é capaz de trabalhar
com todos os padrões ontológicos existente.
A modelagem do sistema ajudou a projetar e compreender todas as funções do APTO,
atentando para os objetivos do projeto. Na fase de desenvolvimento foram levantadas as tecnologias
a serem utilizadas. Depois, foi iniciado o processo de implementação que inicialmente foi utilizado
a API JDOM, sem qualquer complicação. Na seqüência do desenvolvimento foi utilizado à
biblioteca Transformer da API JAXP para transforma XSLT em texto.
Através da fase de teste foi possível detectar algumas dificuldades, a API desenvolvida não
estava conseguindo traduzir do padrão Dublin Core pra LOM. A API não conseguia traduzir
quando algum nó “map” do mapeamento não continha o elemento “rela1”. Outra dificuldade que
foi encontrada é quando alguns elementos estavam sendo repetidos, quando deveriam aparecer
somente uma vez. É importante ressaltar que esta fase também foi importante para conseguir
analisar e tentar encontrar soluções para dificuldades encontradas para o desenvolvimento da API.
Para resolver foi necessário alterações no motor para capturar a informação do elemento
“rela1_cond”, quando não existir o elemento “rela1” e para inserir dentro do elemento pai ao invés
de toda vida criar um novo elemento, assim a ferramenta teve o funcionamento esperado.
Este trabalho traz grandes contribuições no que tange a interoperabilidade Repositórios de
Objetos de Aprendizagem permitindo com que o repositório consiga realizar buscas e comparações,
independente do formato do metadado do Objeto de Aprendizagem.
Os próximos passos para este trabalho de conclusão de curso é conseguir fazer a integração
da API com Repositórios de Objetos de Aprendizagem, Web-service e com trabalho de Santiago e
Raabe (2008), onde uma rede de interoperabilidade para compartilhamento de Objetos de
Aprendizagem é especificada.
50
REFERÊNCIAS BIBLIOGRÁFICAS
ADVANCED DISTRIBUTED LEARNING. Sharable Content Object Reference Model 2004:
overview. 3. ed. [S.l.], 2006.
BREITMAN, Karin Koogan. Web Semântica: a internet do futuro. 2. ed. Rio de Janeiro: LTC,
2005. ISBN 85-216-1466-7
CHAVES, Marcirio Silveira, LIMA, Vera Lúcia Strube de. Similaridade entre Estruturas
Ontológicas. In: WORKSHOP EM TECNOLOGIA DA INFORMAÇÃO E DA LINGUAGEM
HUMANA, 10°, São Carlos, 2003. Anais... [S.l.:s.n.], 2003.
CHAVES, Marcirio Silveira; VIEIRA, Renata; RIGO, Sandro. Uso de Ontologias para
Gerenciamento e Acesso a Documentos na Web. In: OFICINA DE INTELIGÊNCIA ARTIFICIAL,
5°, 2001, Pelotas. Anais... [S.l.:s.n.], p.75-87.
DALTIO, Jaudete; MEDEIROS, Claudia M. Bauzer. Um Servidor de Ontologias para Apoio a
Sistemas de Biodiversidade. In: WORKSHOP DE TESES E DISSERTAÇÕES - SBBD (Proc XXI
SBBD), 5°, 2006, Florianópolis. Anais..., 2006. p. 71-76.
DOAN, AnHai; MADHAVAN, Jayant; DOMINGOS, Pedro; HALEVY, Alon. Learning to Map
between Ontologies on the Semantic Web. In: WWW2002 - THE ELEVENTH INTERNATIONAL
WORLD WIDE WEB CONFERENCE, Honolulu, 2002. Proceedings…, [S.l.]: ACM Press, 2002.
FELICÍSSIMO, Carolina Howard ; BREITMAN, Karin Koogan . Uma Estratégia para o
Alinhamento Taxonômico de Ontologias. In: Workshop de Web Semântica do XVIII Simpósio
Brasileiro de Engenharia de Software (WWS'2004), 1°, 2004, Brasília. Anais..., [S.l.:s.n.], 2004.
FONSECA, Frederico; ENGENHOFER, Max; BORGES, Karla A. V. Ontologias e
Interoperabilidade Semântica entre SIGs. In: WORKSHOP BRASILEIRO EM
GEOINFORMÁTICA, 3°, 2000, São Paulo. Anais…, São Paulo: [s.n.], 2000.
GAŠEVIĆ, Dragan, HATALA, Marek. Ontology mappings to improve learning resource search.
British Journal of Educational Technology, [S.l.]. v. 37,n. 3, p.375-389, 2006. ISSN 0007-1013.
HATALA, Marek; RICHARDS, Griff; EAP, Timmy; WILLMS, Jordan. The Interoperability of
Learning Object Repositories and Services: Standards, Implementations and Lessons Learned. In:
13TH WORLD WIDE WEB CONFERENCE., 2004, New York. Proceedings… New York: ACM
Press, 2004. ISBN: 1-58113-844-X.
HINZ, Verlani Timm; PALAZZO, Luiz Antônio Moro. Colaboração em Sistemas Multiagentes
Modelados por Ontologias. In: WORKSHOP – ESCOLA DE SISTEMAS DE AGENTES PARA
AMBIENTES COLABORATIVOS, Pelotas, 2007. Anais..., [S.l.:s.n.], 2007.
IMS. Global Learning Consortium IMS. Adoption [S.l.], 2001. Disponível em:
<http://reusability.org/read/chapters/wiley.doc/>. Acesso em: 9 fevereiro 2009.
IMS. IMS Meta-data Best Practice Guide for IEEE 1484.12.1-2002 Standard for Learning
Object Metadata. [S.l.], 2004.
51
JAXP SUN Microsystems. Java API for XML Processing (JAXP). [S.l.], 2003. Disponível em:
<http://java.sun.com/xml/jaxp/>. Acesso em: 20 fevereiro 2009.
JDOM. JDOM and XML Parsing, Part 1. [S.l.], 2002. Disponível em:
<http://www.jdom.org/docs/oracle/jdom-part1.pdf>. Acesso em: 10 abril 2009.
KALFOGLOU, Yannis.; SCHORLEMMER, Marco. Ontology Mapping: the state of the art.
Knowledge Engineering Review, p.1-31, 2003. ISSN: 0269-8889
KALFOGLOU, Yannis. e SCHORLEMMER, Marco. Formal Support for Representing and
Automating Semantic Interoperability. In: EUROPEAN SEMANTIC WEB SYMPOSIUM,
Heraklion, 1º, 2004. Proceedings…, [S.l.]: Springer , 2004. ISBN 3-540-21999-4
LIBRELOTTO, Giovani Rubert; RAMALHO, José Carlos; HENRIQUES, Pedro. Rangel. TMBuilder: um construtor de ontologias baseado em Topic Maps. In: CONFERÊNCIA
LATINOAMERICANA DE INFORMÁTICA – CLEI, La Paz, 29°, 2003. Anais..., [S.l.:s.n.], 2003.
LTSC IEEE. Extensible Markup Language (XML) Schema Definition Language Binding for
Learning Object Metadata. New York, 2005.
LTSC IEEE. Learning Object Metadata Standard. Disponível em:
<http://www.ieeeltsc.org/working-groups/wg12LOM/lomDescription/>. Acesso em: 01 fev. 2009.
MAEDCHE, A.; STAAB, S. Measuring Similarity Between Ontologies. In: European Conference
on Knowledge Acquisition and Management (EKAW), 2002. Proceedings…, [S.l.:s.n.], 2002.
MOHAN, Permanand. Learning Objects Repositories. In: KOOHANG, Alex; HARMAN, Keith.
Learning Objects: theory, praxis, issues, and trends. Santa Rosa: Informing Science Press, 2007.
p.527-548. ISBN 83-922337-6-X.
NOLL, Rodrigo Perozzo; SACCOL, Deise de Brum; EDELWEISS, Nina. Uma Proposta para
Análise de Similaridade entre Documentos XML e Ontologias em OWL. In: Simpósio Brasileiro de
Banco de Dados (SBBD), João Pessoa, 2007. Anais..., [S.l:s.n.], 2007.
NOY, Natalya F. Semantic Integration: a survey of ontology-based approaches. ACM SIGMOD
Record, New York, v.33, n.4, p.65-70, 2004. ISSN 0163-5808.
NUNES, S. S. Alternativas para a Interoperabilidade entre Sistemas de InformaçãoUniversitários.
163 f. Dissertação de Mestrado. Departamento de Engenharia Eletrotécnica e Computação.
Faculdade de Engenharia da Universidade do Porto, 2004.
PÉREZ, Asunción Gómez Ontological Engineering: Theoretical Foundations. In: Internacional
Joint Conference on Artificial Intelligence (IJCAI), 1999. Proceedings…, [S.l.:s.n.], 1999.
PICCIANO, Anthony G. Developing an Asynchronous Course Model at a Large, Urban University.
Journal of Asynchronous Learning Networks, [S.l.], v.2, n.1, p.3-19, 1998. ISSN 1092-8235.
PROTÉGÉ. What is Protege? Disponível em: <http://protege.stanford.edu/overview/>. Acesso em:
1 nov. 2008.
52
QUINTON, Stephen R. Contextualisation of Learning Objects to Derive a Meaning. In:
KOOHANG, Alex; HARMAN, Keith. Learning Objects: theory, praxis, issues, and trends. Santa
Rosa: Informing Science Press, 2007. p. 113-180. ISBN 83-922337-6-X
RUSSEL, S.; NORVIG, P. Inteligência artificial: referência completa para cursos de computação.
2. ed. Rio de Janeiro: Elsevier, 2004. ISBN 8-535-21177-2
SANTANA, Luiz Henrique Zambom; PRADO, Antonio Francisco; SOUZA, Wanderley Lopes;
BIAJIZ, Mauro. Usando Ontologias, Serviços Web Semânticos e Agentes Móveis no
Desenvolvimento Baseado em Componentes. In: SIMPÓSIO BRASILEIRO DE COMPONENTES,
ARQUITETURAS E REUTILIZAÇÃO DE SOFTWARE, 2007, Campinas. Anais... , [S.l.:s.n.],
2007. ISBN 978-85-268-0797-6
SANTIAGO, Rafael de; RAABE, André Luís Alice. Camada de Integração entre Learning
Management System e Múltiplos Repositórios de Objetos de Aprendizagem. In: CONGRESO
BRASILEIRO DE ENSINO SUPERIOR A DISTÂNCIA, 5º, 2008, Gramado. Anais... [S.l.: s.n.],
2008.
SILVA, Alan Pedro; OLIVEIRA, Rômulo Nunes de ; BITENCOURT, Ig Ibert ; COSTA, Evandro
de Barros ; ALMEIDA, Hyggo Oliveira de . Um Ambiente Baseado em Agentes para Suporte a
Negociações Eletrônicas Automatizadas Utilizando Ontologias e Regras de Produção. In:
SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 20., 2006, Florianópolis.
Anais… [S.l:s.n.], 2006. p. 49-59.
SMITH, Michael K.; WELTY, Chris; MCGUINNESS, Deborah L.. OWL Web Ontology
Language, 2005. Disponível em: <http://www.w3.org/TR/2004/REC-owl-guide-20040210/>.
Acesso em: 10 fev. 2009.
SULEMAN, Hussein. Enforcing Interoperability with the Open Archives Initiative Repository
Explorer. In: ACM-IEEE Joint Conference on Digital Libraries, 2001, Roanoke. Anais… [S.l:s.n.],
2001. p. 63-64. ISBN 1-58331-354-6
W3C. Resource Description Framework (RDF). [S.l.], 2007a. Disponível em: <http://www.w3
.org/RDF/>. Acesso em: 9 agosto 2008.
W3C. Web Ontology Language (OWL). [S.l.], 2007b. Disponível em: <http://www.w3.org/2004/
OWL/>. Acesso em: 9 agosto 2008.
W3C. XSL Transformations (XSLT)Version 1.0. [S.l.], 1999. Disponível em:
<http://www.w3.org/TR/xslt>. Acesso em: 15 junho 2009.
WILEDEN, Jack C.; KAPLAN, Alan. Software Interoperability: Principles and Practice. In:
International Conference on Volume, 1999, Issue. Proceedings…, [S.l.:s.n.], 1997.
53