Download PDF
ads:
i
Laboratório Nacional de Computação Científica
Programa de Pós-Graduação em Modelagem Computacional
AGUIA: UM GERADOR SEMÂNTICO DE INTERFACE
GRÁFICA DO USUÁRIO PARA ENSAIOS CLÍNICOS
Por
Miriã da Silveira Coelho Corrêa
PETRÓPOLIS, RJ - BRASIL
MARÇO DE 2010
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ii
AGUIA – AGUIA: UM GERADOR SEMÂNTICO DE INTERFACE
GRÁFICA DO USUÁRIO PARA ENSAIOS CLÍNICOS
Miriã da Silveira Coelho Corrêa
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DA COORDENAÇÃO DE
FORMAÇÃO DE RECURSOS HUMANOS DO LABORATÓRIO NACIONAL DE
COMPUTAÇÃO CIENTÍFICA COMO PARTE DOS REQUISITOS NECESSÁRIOS
PARA A OBTENÇÃO DO GRAU DE MESTRE EM MODELAGEM
COMPUTACIONAL.
Aprovada por:
____________________________________________________
Ana Tereza Ribeiro de Vasconcelos, D.Sc. – LNCC
____________________________________________________
Ana Maria de Carvalho Moura, D.Sc. – LNCC
____________________________________________________
Fabio Andre Machado Porto, D.Sc. – LNCC
____________________________________________________
Jonas Almeida, Ph.D. – UTMD Anderson Cancer Center
PETRÓPOLIS, RJ - BRASIL
MARÇO DE 2010
ads:
i
Coelho Corrêa, Miriã da Silveira
XXXX AGUIA: Um gerador semântico de interface gráfica do usuário para
ensaios clínicos / Miriã da Silveira Coelho Corrêa -- Petropólis, RJ. : Laboratório
Nacional de Computação Científica, 2010.
x, 117 p.: il.;29 cm
Orientador: Ana Tereza Vasconcelos; Co-orientador: Jonas Almeida
Dissertação (mestrado) - Laboratório Nacional de Computação Científica, 2010.
1. Interface Gráfica Autônoma. 2. Web Semântica. 3. RDF. 4.Câncer
Gastrointestinal. I.Vasconcelos, Ana Tereza II. Almeida, Jonas III. LNCC/MCT.
IV. Título
CDD XXX.XXX
ii
Ao meu marido Charles pela paciência, amor e pelo
apoio incondicional. Aos meus pais, irmãos e
sobrinhos, por aceitarem a minha ausência.
iii
Agradecimentos
Agradeço a Deus pelo dom da vida, renovado nos sonhos que se concretizam, como
este que agora se torna realidade. Por ter me dado forças para enfrentar os obstáculos que
apareceram no meu caminho durante esta jornada e ainda por ter me dado forças para superar
a saudade e a distância da minha família.
Ao meu marido Charles, o meu sincero agradecimento pelo apoio incondicional nos
momentos mais difíceis, disponibilidade e paciência ao longo deste período e compreensão
dos inúmeros momentos dedicados a este trabalho. Por deixar parcialmente os seus sonhos em
prol dos meus e por me ajudar a superar a distância da minha família e amigos.
Aos meus pais Darci e Ivone, por todo esforço em prol da minha formação, pelo
carinho, conforto e orações. Por serem exemplo de vida, amor, carinho e dedicação.
Aos meus orientadores Ana e Jonas por todo apoio prestado, bem como a paciência,
incentivo, empenho, sabedoria, confiança e por terem aberto caminhos para meu crescimento
intelectual.
Aos meus exemplos de vida, meu irmão Ricardo e minha cunhada Janice que sempre
me estimularam a dar este grande passo e acreditaram e mim. Estas duas pessoas com muita
sabedoria, discernimento, bom senso me encorajaram nas horas mais difíceis. Obrigada pelo
apoio incondicional, por todo carinho, amizade e por fazerem parte da minha vida de forma
tão expressiva.
Aos meus sobrinhos Elisa, Ivens, Paloma e Pâmela por serem tão carinhos comigo.
Ao meu cachorrinho Scott por aliviar minha ansiedade e estresse durante os momentos
difíceis.
À Cintia que se tornou minha amiga durante o período que moramos em Houston e
que compartilhou dos momentos felizes e difíceis enquanto realizávamos o trabalho.
À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior – CAPES pelo
auxílio financeiro concedido.
iv
Resumo da Dissertação apresentada ao MCT/LNCC como parte dos requisitos
necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
AGUIA: UM GERADOR SEMÂNTICO DE INTERFACE GRÁFICA DO USUÁRIO
PARA ENSAIOS CLÍNICOS
Miriã da Silveira Coelho Corrêa
Março/2010
Orientador(a): Ana Tereza Vasconcelos - LNCC
Co-orientador: Jonas Almeida, UT MD Anderson Cancer Center
AGUIA é uma aplicação web front-end, desenvolvida para gerenciar dados clínicos,
demográficos e biomoleculares de pacientes coletados durante os ensaios clínicos
gastrointestinais no MD Anderson Cancer Center. A diversidade de metodologias envolvidas
na triagem de pacientes e no processamento da amostra traz uma heterogeneidade dos tipos de
dados correspondentes. Sendo assim, estes devem ser baseados em uma arquitetura orientada
a recurso que transforma dados heterogêneos em dados semânticos, mais especificamente em
RDF (Resource Description Framework - Estrutura para a descrição de recursos). O banco de
dados escolhido foi o S3DB, por este ter cumprido os requisitos necessários de transformação
dos dados heterogêneos de diferentes fontes em RDF, distinguindo explicitamente a descrição
do domínio e sua instanciação, permitindo simultaneamente a contínua edição de ambos.
Além disso, ele usa um protocolo REST, e é de código aberto e domínio público o que facilita
o desenvolvimento e divulgação. Contudo, por mais abrangente e flexível, um formato de web
semântica pode por si só, não abordar a questão de representar o conteúdo de uma forma que
faça sentido para especialistas do domínio. Assim, o objetivo do trabalho aqui descrito foi
identificar um conjunto adicional de descritores que forneceu as especificações para a
interface gráfica do usuário. Esse objetivo foi perseguido através da identificação de um
formalismo que faz uso do esquema RDF para permitir a montagem automática de interfaces
gráficas de uma forma significativa. Um modelo RDF generalizado foi, portanto, definido de
tal forma que as mudanças nos descritores gráficos sejam automaticamente e imediatamente
refletidas na configuração da aplicação web do cliente, que também está disponível neste
trabalho. Embora os padrões de design identificados reflitam e beneficiem os requisitos
específicos de interagir com os dados gerados pelos ensaios clínicos, a expectativa é que eles
contenham pistas para uma solução de propósito geral. Em particular, sugere-se que os
padrões mais úteis identificados pelos utilizadores deste sistema sejam suscetíveis de serem
reutilizáveis para outras fontes de dados, ou pelo menos para outros bancos de dados
semânticos de ensaios clínicos.
vi
Abstract of Thesis presented to MCT/LNCC as a partial fulfillment of the requirements
for the degree of Master of Science (M.Sc.)
AGUIA: UM GERADOR SEMÂNTICO DE INTERFACE GRÁFICA DO USUÁRIO
PARA ENSAIOS CLÍNICOS
Miriã da Silveira Coelho Corrêa
March/2010
Advisor: Ana Tereza Vasconcelos - LNCC
Co-advisor: Jonas Almeida, UT MD Anderson Cancer Center
AGUIA is a web application front-end originally developed to manage clinical,
demographic and biomolecular patient data collected during gastrointestinal clinical trials at
MD Anderson Cancer Center. The diversity of methodologies involved in patient screening
and sample processing, brings corresponding heterogeneity of data types. Thus, this data must
be based on a Resource Oriented Architecture that transforms heterogeneous data in semantic
data, most specifically in RDF (Resource Description Framework). The database chosen was
a S3DB, because it met the necessary requirements of transforming heterogeneous data from
different sources in RDF, explicitly distinguishing the description of the domain from its
instantiation, while allowing for continuous editing of both. Furthermore, it uses a REST
protocol, and is open source and in the public domain which facilitates development and
dissemination. Nevertheless, comprehensive and flexible a semantic web format may be, it
does not by itself address the issue of representing content in a form that makes sense for
domain experts. Accordingly, the goal of the work described here was to identify an
vii
additional set of descriptors that provide specifications for the graphic user interface. That
goal was pursued by identifying a formalism that makes use of the RDF schema to enable
automatic assembly of graphic user interfaces in a meaningful manner. A generalized RDF
model was therefore defined such that changes in the graphic descriptors are automatically
and immediately reflected into the configuration of the client web browser interface
application, which is also made available with this report. Although the design patterns
identified reflect, and benefit, from the specific requirements of interacting with data
generated by clinical trials, the expectation is that they contain clues for a general purpose
solution. In particular, it is suggested that the most useful patterns identified by the users of
this system are susceptible to being reusable for other data sources, or at least for other
clinical trial semantic web data stores.
viii
Lista de Siglas e Abreviaturas
GI – Gastrointestinal
RDF - Resource Description Framework (do inglês)
RDFS – Resource Description Framework Schema (do inglês)
S3DB -Simple Sloppy Semantic Database (do inglês)
S3QL - Simple Sloppy Semantic Query Language (do inglês)
SPARQL - Semantic Protocol and RDF Query Language (do inglês)
HTML - Hyper Text Markup Language (do inglês)
DOM - Document Object Model (do inglês)
IIPS - Intelligent Information Presentation System (do inglês)
XML - eXtensible Markup Language (do inglês)
WebML - Web Modeling Language (do inglês)
OntoWebber - Ontology-Based Web Site (do inglês)
W3C – World Web Consortium (do inglês)
OIL – Ontology Inference Layer (do inglês)
SHOE – Simple HTML Ontology Extension (do inglês)
DAML – Darpa Agent Markup Language (do inglês)
OWL – Web Ontology Language (do inglês)
XMLS – eXtensible Markup Language Schema (do inglês)
DAML-ONT - Darpa Agent Markup Language Ontology (do inglês)
ix
URI – Universal Resource Identifiers (do inglês)
N3 – Notation N3 (do inglês)
REST – Representational State Transfer (do inglês)
GRDDL - Gleaning Resource Descriptions from Dialects of Languages (do inglês)
DHTML – Dynamic Hyper Text Markup Language (do inglês)
CSS - Cascading Style Sheets (do inglês)
APIs – Application Programming Interface (do inglês)
PCR – Polimerase Chain Reaction (do inglês)
AGUIA – Autonomous Graphic User Interface Assembly
TBox – Terminological Component (do inglês)
ABox – Assertion Component (do inglês)
GBox – Graphic Component (do inglês)
Sumário
1. Introdução ........................................................................................................................... 1
1.1 Motivações ................................................................................................................... 2
1.2 Objetivos ...................................................................................................................... 3
1.2.1 Objetivo geral ....................................................................................................... 3
1.2.2 Objetivos específicos ............................................................................................ 3
1.3 Organização da dissertação .......................................................................................... 4
2. Web Semântica e Ontologias .............................................................................................. 5
2.1 Introdução .................................................................................................................... 5
2.2 Web Semântica ............................................................................................................ 5
2.2.1 Ontologias ............................................................................................................ 6
2.1.1.1 Benefícios advindos do uso de ontologias ........................................................ 8
2.1.1.2 Elementos de uma ontologia ............................................................................. 9
2.1.1.3 Tipos de ontologias ........................................................................................... 9
2.1.1.3.1 Quanto ao nível de generalização ............................................................. 10
2.1.1.3.2 Quanto ao grau de formalismo .................................................................. 10
2.1.1.3.3 Quanto ao propósito .................................................................................. 11
2.1.1.4 Construção de ontologias ................................................................................ 11
2.1.1.4.1 Determinar o domínio e o escopo da ontologia ........................................ 11
2.1.1.4.2 Considerar a reutilização de ontologias existentes ................................... 12
2.1.1.4.3 Enumerar os termos importantes na ontologia: ......................................... 12
2.1.1.4.4 Definir as classes e a hierarquia das classes ............................................. 12
2.1.1.4.5 Definir as propriedades das classes: .......................................................... 13
2.1.1.4.6 Definir as propriedades dos atributos: ...................................................... 14
2.1.1.4.7 Criar instâncias: ......................................................................................... 14
2.1.1.5 Aplicações ....................................................................................................... 14
2.1.1.6 Linguagens de representação de ontologias ................................................... 14
xi
2.1.1.6.1 RDF ........................................................................................................... 15
2.1.1.6.1.1 Triplas RDF e grafos .......................................................................... 15
2.1.1.6.1.2 URIs .................................................................................................... 17
2.1.1.6.1.3 Literais ................................................................................................ 17
2.1.1.6.1.4 Linguagens de representação RDF ..................................................... 17
2.1.1.6.2 RDF Schema [15] ...................................................................................... 20
2.1.1.6.3 SHOE ........................................................................................................ 23
2.1.1.6.4 OIL ............................................................................................................ 24
2.1.1.6.5 DAML ....................................................................................................... 24
2.1.1.6.6 DAML + OIL ............................................................................................ 24
2.1.1.6.7 OWL .......................................................................................................... 25
2.3 Considerações finais .................................................................................................. 26
3. AGUIA: Gerador semântico de interfaces ........................................................................ 28
3.1 Motivação .................................................................................................................. 28
3.2 Arquitetura ................................................................................................................. 28
3.2.1 Ontologia de domínio (dados) ............................................................................ 29
3.2.2 Módulo gráfico ................................................................................................... 30
3.2.3 Módulo de consulta ............................................................................................ 31
3.2.4 Aplicação web .................................................................................................... 33
3.3 Implementação ........................................................................................................... 34
3.3.1 Tecnologias utilizadas ........................................................................................ 36
3.3.2 S3DB .................................................................................................................. 37
3.3.2.1 Definição ......................................................................................................... 38
3.3.2.2 Módulo de núcleo (Core Model) do S3DB ..................................................... 39
3.3.2.3 Modelo de consulta ......................................................................................... 40
3.3.2.3.1 S3QL ......................................................................................................... 40
3.3.2.3.2 SPARQL ................................................................................................... 41
3.4 Modelo gráfico ........................................................................................................... 43
xii
3.4.1 Componentes gráficos ........................................................................................ 44
3.4.1.1 Componente de data ....................................................................................... 44
3.4.1.2 Componente de texto ...................................................................................... 44
3.4.1.3 Componente de texto maior ............................................................................ 45
3.4.1.4 Componente de condição ................................................................................ 45
3.4.1.5 Componente de fórmula ................................................................................. 45
3.4.1.6 Componente de restrição ................................................................................ 45
3.4.1.7 Componente de opções ................................................................................... 45
3.4.1.8 Componente de grid ........................................................................................ 46
3.4.1.9 Componente de inativação .............................................................................. 46
3.4.1.10 Componente de concatenação ..................................................................... 46
3.4.1.11 Componente para criação de sub-abas ........................................................ 46
3.4.2 Implementação do modelo gráfico na base de dados ......................................... 46
3.5 Considerações finais .................................................................................................. 55
4. Estudo de caso: AGUIA para ensaios clínicos .................................................................. 56
4.1 Formato, importação dos dados e ontologia de domínio ........................................... 56
4.1.1 Criação da ontologia de domínio (dados) ........................................................... 58
4.1.2 Importação dos dados para o s3db ..................................................................... 63
4.2 Criando o projeto de regras gráficas .......................................................................... 65
4.2.1 Range (Alcance) ................................................................................................. 68
4.2.2 Domain (Domínio) ............................................................................................. 68
4.2.3 Action (Ação) ..................................................................................................... 69
4.2.4 Value (Valor) ...................................................................................................... 70
4.2.5 Trigger (Gatilho) ................................................................................................ 70
4.3 Usando a AGUIA ...................................................................................................... 71
4.3.1 Acesso normal .................................................................................................... 72
4.3.2 Acesso com sete parâmetros ............................................................................... 74
4.3.3 Acesso com localização e autenticação .............................................................. 75
4.4 Considerações finais .................................................................................................. 76
xiii
5. Trabalhos Relacionados .................................................................................................... 77
5.1 IIPS ............................................................................................................................ 77
5.2 WebML ...................................................................................................................... 79
5.3 OntoWebber ............................................................................................................... 81
5.4 Considerações finais .................................................................................................. 83
6. Conclusão e perspectivas futuras ...................................................................................... 84
6.1 Conclusão .................................................................................................................. 84
6.2 Perspectivas Futuras .................................................................................................. 85
Referências Bibliográficas ....................................................................................................... 86
APÊNDICE I – Artigo gerado pela dissertação ....................................................................... 90
Capítulo 1
Introdução
O Desenvolvimento e manutenção de aplicativos Web estão se tornando cada vez mais
complexos, caro e demorado [1], pois os dados disponíveis na web têm aumentado de
maneira exponencial e, além disso, estes dados têm também uma grande
heterogeneidade de formatos. Isto tem conferido importância significativa às técnicas
que permitam organizá-los de maneira coerente e representa um desafio para a
representação destes de maneira, intuitiva, coerente e amigável para o usuário.
A Web Semântica surge neste contexto para adicionar uma camada de significado na
web. Esta é uma extensão da Web atual, onde a informação tem um significado bem
definido, este significado é dado através de linguagens de marcação semântica como
ontologias e RDF [2]. A adição de significado aos dados permite que os agentes de
software possam se comunicar de maneira mais eficaz e permitir que estes sejam
capazes de realizar tarefas mais sofisticadas para os usuários.
O uso de ontologias permite que os dados sejam representados em uma linguagem
comum e uniforme, sendo assim elas proporcionam um entendimento comum sobre um
determinado domínio de conhecimento.
Ontologia é uma especificação formal e explícita de uma conceitualização
compartilhada, esta definição é encontrada mais freqüentemente na literatura da Web
Semântica, e foi proposta por Gruber [3]. Basicamente uma ontologia é a descrição ou
interpretação de um dado domínio de conhecimento.
Uma das linguagens de representação das ontologias na Web Semântica é o RDF.
RDF é uma linguagem declarativa que fornece uma maneira padronizada de utilizar o
XML para representar metadados no formato de sentenças sobre propriedades e
relacionamentos entre itens na Web. O RDF proporciona uma maneira simples e flexível
de representar o conhecimento, de modo que este seja facilmente interpretado
semanticamente.
1.1 Motivações
A crescente disponibilidade digital de enormes quantidades de fontes de dados e
conhecimentos biomédicos sobrecarregou os pesquisadores e médicos com a tarefa de
gerenciar terabytes de conteúdo semântico, que é, naturalmente, sutilmente
interconectado, e precisa ser agregado e manipulado. Uma vasta quantidade de dados
utilizados para resolver tarefas complexas exige técnicas cada vez mais sofisticadas de
gerenciamento inteligente de informação e conhecimento, aumentando a
interoperabilidade de conteúdos em grandes repositórios apoiados por diferentes tipos
de raciocínio automatizado.
Este desafio tem sido cada vez mais enfrentado por biólogos, pesquisadores de saúde
pública e clínica, economistas da saúde, e também por médicos. Um resultado prático
desses esforços é o surgimento de um conjunto crescente de sistemas de referência
semântica, muitas vezes caracterizados como vocabulários, tesauros, terminologias, e
ontologias [4].
Por esta razão optou-se por armazenar os dados provindos de ensaios clínicos em uma
ontologia construída em uma base de dados semântica S3DB. Assim, estes foram
representados de maneira uniforme e padronizada.
Ensaios clínicos são estudos de pesquisas que envolvem pacientes e tem por objetivo
encontrar o melhor caminho para prevenir, diagnosticar e tratar doenças, neste caso o
câncer gastrointestinal [5].
Para representar estes dados de maneira coerente, genérica e abstrata com a finalidade
de permitir o reuso e economizar tempo e recursos computacionais - tendo em vista que
construir aplicações web estáticas torna-se cada vez mais complexo, consumidor de
tempo e recursos, além de que estas se tornam rapidamente obsoletas - construiu-se uma
aplicação web genérica e que fosse capaz de se montar automaticamente a partir da
disposição dos dados na ontologia.
1.2 Objetivos
1.2.1 Objetivo geral
O objetivo geral desta dissertação é desenvolver um método para a construção de
aplicações web que montam autonomamente a partir de um modelo de ontologia
desenvolvida – para o projeto de ensaios clínicos do departamento de Gastrointestinal
Medical Oncology do MD Anderson Cancer Center – em uma base de dados semântica
– a princípio o S3DB – que gere RDF.
1.2.2 Objetivos específicos
Os objetivos específicos desta dissertação são:
Capturar, gerir e representar aproximadamente 1 milhão de medições
independentes que descrevem um conjunto de 1369 pacientes do departamento
Gastrointestinal Medical Oncology do MD Anderson Cancer Center;
Criar uma aplicação web automática com componentes gráficos que permitam o
gerenciamento destes dados de forma intuitiva;
Identificar um RDF para construir os componentes gráficos da aplicação web e
permitir com que esta aplicação interprete este RDF;
Permitir o reuso desta aplicação para outros projetos, a medida que estes gerem
RDF interpretável por esta aplicação, onde o domínio e a instância deste
domínio estejam discriminados.
1.3 Organização da dissertação
Além da introdução esta dissertação está organizada da seguinte forma: no capítulo 2 a
web semântica e as tecnologias associadas a ela como Ontologias e RDF são
apresentadas.
O capítulo 3 dedica-se a apresentar e detalhar a arquitetura, motivações, o
módulo gráfico e a implementação da AGUIA.
No capítulo 4 é apresentado o estudo de caso desta dissertação, que consiste na
utilização da AGUIA pelo projeto de ensaios clínicos gastrointestinais do MD Anderson
Cancer Center.
O capítulo 5 dedica-se a apresentar os trabalhos relacionados com o trabalho
proposto por esta dissertação. Este capítulo faz uma descrição dos trabalhos mais
recentes e que possuem uma maior similaridade com a AGUIA e ainda realiza uma
comparação de cada um destes trabalhos com a AGUIA.
E, finalmente, o capítulo 6 desta dissertação dedica-se a apresentar a conclusão e
as perspectivas futuras deste trabalho.
Capítulo 2
Web Semântica e Ontologias
Neste capítulo serão introduzidas algumas noções importantes sobre web semântica,
o motivo do seu surgimento, conceitos e linguagens de marcação semântica como
ontologias e RDF. Apresentam-se ainda as definições de ontologias, os tipos de
ontologias, aplicações e os benefícios advindos do uso de ontologias. E por fim,
exploram-se as linguagens de representação da web semântica.
2.1 Introdução
Atualmente, a maior parte dos recursos presentes na Web está disposta em
linguagem natural, de modo que só podem ser interpretados por seres humanos [2].
Mecanismos de busca como, por exemplo, Google e Yahoo necessitam ainda da
intervenção humana para que se possam identificar as respostas que realmente são
relevantes de acordo com a demanda da pesquisa. A web semântica surge neste contexto
trazendo tecnologias, como por exemplo, ontologias, que permitem o cruzamento das
informações provenientes de paginas web, editores de texto e outros, e adicionando uma
camada de significado a estas informações [6].
A seguir será apresentada a definição de web semântica, assim como o objetivo
de sua criação.
2.2 Web Semântica
A Web Semântica é uma extensão da web atual, na qual é dada à informação um
significado bem definido, permitindo que computadores e pessoas trabalhem em
cooperação [7]. Ela permite que computadores sejam capazes de interpretar e processar
essas informações.
A Web Semântica foi criada por Tim Berners-Lee, que também criou o HTML e o W3C
[8] (Consórcio WWW - World Wide Web Consortium). O objetivo da criação da web
semântica foi o de possibilitar que as páginas web contenham significado, através da
adição de semântica as páginas da Web, para tornar isso possível é necessário fazer uso
de ontologias.
2.2.1 Ontologias
O termo ontologia tem sido usado por comunidades distintas, como: Inteligência
Artificial, Representação do Conhecimento, Processamento de Linguagem Natural,
Web Semântica, Engenharia de Software e outras. Por isso encontra-se na literatura
várias definições deste termo, porém todas as definições giram em torno da mesma
vertente.
A definição de ontologia encontrada mais frequentemente na literatura de web
semântica é a que diz que ontologia é uma especificação formal e explícita de uma
conceitualização compartilhada [3]. Nesta definição conceitualização representa um
modelo abstrato de algum fenômeno que identifica os conceitos relevantes para o
mesmo. Explícita significa que os elementos e suas restrições estão claramente
definidos; formal significa que a ontologia deve ser passível de processamento
automático, e compartilhada reflete a noção de que uma ontologia captura
conhecimento consensual, aceito por um grupo de pessoas [2].
Ontologias podem ser definidas também como sendo modelos conceituais que
capturam e explicitam o vocabulário utilizado nas aplicações semânticas. Servem como
base para garantir uma comunicação livre de ambigüidades. Ontologias são a língua
franca da Web Semântica [2].
Os objetivos de se construir uma ontologia são:
Estabelecer um vocabulário comum para proporcionar a comunicação entre
pessoas, sistemas ou ambos;
Representar o conhecimento de forma coerente e categorizada.
A Figura 2.1 mostra um exemplo de ontologia para dados demográficos de pacientes.
Figura 2.1 – Ontologia do domínio de dados demográficos
As ontologias devem prover descrições para os seguintes tipos de conceito:
Classes nos vários domínios de interesse,
Relacionamento entre essas Classes,
Propriedades que essas Classes devem possuir.
Nas próximas seções descrevem-se benefícios advindos do uso de ontologias, os
elementos que compõem uma ontologia, os tipos de ontologias existentes, os passos
necessários para se construir uma ontologia, as aplicações das ontologias e as
linguagens de representação de ontolgias.
2.1.1.1 Benefícios advindos do uso de ontologias
Ontologias são utilizadas em diversas áreas, com o objetivo de organizar a
informação de forma que esta possa ser recuperada e disseminada por vários domínios
de conhecimento. São inúmeros os benefícios advindos do uso de ontologias dos quais
podemos destacar:
Reuso: Após serem desenvolvidas, as ontologias podem ser reusadas. Estas
possuem um potencial enorme de reuso. O conhecimento formalizado na
camada de domínio pode ser especializado em diferentes aplicações, servindo
para diferentes propósitos, por diferentes equipes de desenvolvimento e, em
diferentes pontos do tempo [9].
Livre de ambiguidade: Ontologias fornecem um vocabulário para a
representação de conhecimento. Este vocabulário tem por trás uma
conceitualização que o sustenta, evitando assim interpretações ambíguas desse
vocabulário [10].
Livre de contradições: Ontologias são livres de contradições, pois devido a
linguagem formal da notação usada, a especificação do domínio elimina
inconsistências e contradições [11].
2.1.1.2 Elementos de uma ontologia
Uma ontologia é composta por diversos elementos. Estes elementos são compostos
para facilitar o compartilhamento da informação e a disseminação do conhecimento.
Para GUIMARÃES [10] a ontologia é composta pelos seguintes elementos:
Conceitos: Um conjunto de conceitos e uma hierarquia entre esses conceitos, ou
seja, uma taxonomia. Os conceitos podem ser abstratos (por ex.: força) ou
concretos (por ex.: carro), elementares (por ex.: elétron) ou compostos (por ex.:
átomo), reais ou fictícios. Um exemplo de taxonomia é o conceito homem ser
um subconceito do conceito pessoa.
Relacionamentos: Um conjunto de relacionamentos entre esses conceitos. Um
exemplo de relacionamento entre os conceitos de pessoa e carro é o
relacionamento de ser-dono.
Funções: Um conjunto de funções. Uma função é um caso especial de
relacionamento em que um conjunto de elementos tem uma relação única com
um outro elemento. Um exemplo de função é ser_pais_biológicos, onde um
conceito homem e um conceito mulher estão relacionados a um conceito pessoa.
Axiomas: Um conjunto de axiomas, ou seja, regras que são sempre verdade. Um
exemplo de axioma é afirmar que toda pessoa tem uma mãe.
Instâncias: Um conjunto de instâncias que são um conhecimento prévio
existente na ontologia.
2.1.1.3 Tipos de ontologias
10
Ontologias podem ser agrupadas em tipos, de acordo com as características básicas
comuns. Ontologias podem ser agrupadas quanto ao nível de generalização, quanto ao
grau de formalismo e quanto ao seu propósito.
2.1.1.3.1 Quanto ao nível de generalização
Segundo GUARINO [11] as ontologias podem ser classificadas de acordo com o
nível de generalização. Dessa forma, o autor propõe as seguintes classificações:
Ontologias genéricas: descrevem conceitos bastante gerais, tais como, espaço,
tempo, matéria, objeto, evento, ação, etc., que são independentes de um
problema ou domínio particular;
Ontologias de domínio: expressam conceituações de domínios particulares,
descrevendo o vocabulário relacionado a um domínio genérico, tal como
Medicina e Direito;
Ontologias de tarefas: expressam conceituações sobre a resolução de
problemas, independentemente do domínio em que ocorram, isto é, descrevem o
vocabulário relacionado a uma atividade ou tarefa genérica, tal como, diagnose
ou vendas;
Ontologias de aplicação: descrevem conceitos dependentes de um domínio
particular e tarefa. Estes conceitos freqüentemente correspondem a papéis
desempenhados por entidades do domínio quando da realização de uma certa
atividade.
2.1.1.3.2 Quanto ao grau de formalismo
USCHOLD [12] propõe que as ontologias devem ser classificadas ainda quanto ao
seu grau de formalidade:
11
Altamente informal: expressa livremente em linguagem natural;
Estrutura informal: expressa em linguagem natural, de forma restrita e
estruturada;
Semi-informal: expressa em uma linguagem artificial, definida formalmente;
Rigorosamente formal: expressa com semântica formal, teoremas e provas.
2.1.1.3.3 Quanto ao propósito
As ontologias podem ainda ser classificadas de acordo com o propósito com que
foram desenvolvidas:
Ontologias que permitem a comunicação entre pessoas e a organização;
Ontologias que permitem a interoperabilidade entre sistemas;
Ontologias que servem de apoio à engenharia de software.
2.1.1.4 Construção de ontologias
A construção de ontologias não é um processo trivial. Para desenvolver uma
ontologia de maneira eficaz, é preciso escolher alguma metodologia dentre as inúmeras
existentes. Não se pode dizer que uma metodologia é melhor que a outra, pois a adoção
de uma metodologia ou de outra dependerá do problema que será abordado. A melhor
metodologia será a que melhor atender as necessidades do projeto em questão.
Para construir uma ontologia é preciso basicamente seguir as seguintes etapas [13]:
2.1.1.4.1 Determinar o domínio e o escopo da ontologia
O desenvolvimento da ontologia inicia-se pela definição do domínio e do escopo e
para facilitar esta tarefa existe uma lista com 4 perguntas básicas que são:
Qual é o domínio que a ontologia irá cobrir?
12
Para que estamos usando a ontologia?
Para que tipo de questões a informação na ontologia deverá prover respostas?
Quem irá usar e manter a ontologia?
As respostas a estas questões podem mudar durante o processo de desenvolvimento da
ontologia, mas em determinado momento elas ajudam a limitar o escopo do modelo.
2.1.1.4.2 Considerar a reutilização de ontologias existentes
Antes de desenvolver a ontologia é recomendável buscar ontologias já existentes e
checar se estas podem ser adaptadas e assim reusadas para o domínio em questão, pois a
tarefa de traduzir uma ontologia de um formalismo para outro não é geralmente uma
tarefa difícil.
Reutilizar ontologias existentes pode ser um requisito importantes se o nosso sistema
precisa interagir com outras aplicações que já se comprometeram a ontologias
particulares ou vocabulários controlados. Existem muitas ontologias já disponíveis na
Web.
2.1.1.4.3 Enumerar os termos importantes na ontologia:
É muito útil escrever uma lista com todos os termos que necessitam de
definições ou explicações para os usuários, ou seja, os termos sobre os quais é
importante falar. Inicialmente, é importante obter uma lista abrangente de termos, sem
se preocupar com a sobreposição entre os conceitos que elas representam, as relações
entre os termos, ou qualquer propriedade que os conceitos podem ter.
2.1.1.4.4 Definir as classes e a hierarquia das classes
13
Existem várias abordagens possíveis no desenvolvimento da hierarquia das
classes:
De cima para baixo (“top-down”): A abordagem top-down dá-se da classe
mais geral para a mais específica.
De baixo para cima (“bottom-up”): A abordagem bottom-up dá-se da classe
mais específica para a mais geral.
Combinação: A abordagem de desenvolvimento por combinação é uma
combinação entre as abordagens top-down e bottom-up. Definem-se os
conceitos mais importantes primeiro e depois estes são generalizados e
especializados adequadamente.
2.1.1.4.5 Definir as propriedades das classes:
Define-se nesta etapa a estrutura interna dos conceitos e os atributos das classes.
Atributos são valores assumidos pelos objetos de uma classe.
Figura 2.2 – Exemplo de instâncias da classe carro.
A Figura 2.2 mostra um exemplo de atributos e instâncias da classe carro. Cor, peso
e modelo são possíveis atributos de classe Carro. Cada atributo tem um valor para cada
instância da classe. Por exemplo, o atributo cor tem valor “Vermelho”' na classe Carro
14
A. Em outras palavras, Carro A tem a cor vermelha. Diferentes instâncias de classes
podem ter o mesmo valor para um dado atributo.
2.1.1.4.6 Definir as propriedades dos atributos:
Atributos podem ter diferentes propriedades descrevendo o tipo de valor, valores
permitidos, o número de valores (cardinalidade), e outras características dos valores que
o atributo pode assumir.
Cardinalidade: Definem quantos valores o atributo pode assumir;
Tipo de valor: Define os tipos de valores que o atributo pode conter. Por
exemplo, String, número, booleano e outros.
Domínio e intervalo de um atributo: Tipos permitidos para atributos de uma
classe são freqüentemente chamados de um intervalo de um atributo.
2.1.1.4.7 Criar instâncias:
A última etapa é criar instâncias das classes. A definição de instâncias de uma
classe requer (1) escolha de uma classe, (2) criação de uma instância individual
associada a classe, e (3) preenchimento dos valores de atributos.
2.1.1.5 Aplicações
Ontologias são utilizadas em projetos de domínios como gestão de conhecimento,
comércio eletrônico, processamento de linguagens naturais, recuperação da informação
na Web, de cunho educacional entre outros [14].
2.1.1.6 Linguagens de representação de ontologias
15
Uma ontologia é composta por vários elementos que auxiliam a compreensão do
domínio abordado. Para formalizar estes elementos e permitir o reuso das ontologias
desenvolvidas, foi necessário definir quais linguagens seriam utilizadas e interpretadas
por sistemas e/ou pessoas. O RDF e o RDF-Schema são as fundações da Web
Semântica. Ao longo dos últimos anos foram propostas algumas linguagens para
ontologias baseadas em extensões ao RDFS. São elas SHOE (Simple HTML Ontology
Extensions – Simples extensões de HTML para ontologias), OIL (camada de inferência
da ontologia - Ontology Inference Layer), DAML (Darpa Agent Markup Language),
DAML+OIL e OWL (Linguagem de ontologia da web – Web Ontology Language) [2].
Nas próximas seções serão descritas cada uma destas linguagens.
2.1.1.6.1 RDF
RDF é uma linguagem que proporciona uma maneira simples e flexível de
representar o conhecimento, de modo que este seja facilmente interpretado
semanticamente. Em outras palavras, RDF é uma linguagem de propósito geral para
representar a informação na web [15], tentando proporcionar interoperabilidade diante
da multiplicidade de formatos incompatíveis existentes. RDF representa dado e
metadado de maneira uniforme.
2.1.1.6.1.1 Triplas RDF e grafos
A descrição dos relacionamentos na Web Semântica é feita pelas triplas RDF [10,
16]:
Sujeito: é o recurso, ou seja, o que irá ser descrito. O sujeito pode ser um URI
(Identificador de Recursos Universal - Universal Resource Identifiers) de
referência (cadeia de caracteres Unicode) ou pode ser um nó em branco.
16
Predicado: O predicado RDF é chamado de propriedade que fornece uma
característica descritiva recurso, e por vezes expressa uma relação entre o sujeito
e o objeto. O predicado tem que ser um URI de referência.
Objeto: é o objeto da relação ou o valor da característica descritiva. O valor do
objeto pode ser um URI de referência, um literal ou um nó em branco.
Podemos dizer que o <sujeito> tem a propriedade <predicado> validada pelo
<objeto>[17]. A Figura 2.3 mostra uma ilustração das triplas RDF.
Figura 2.3 – Triplas RDF
A Figura 2.4 mostra uma ilustração em notação N3 (Notation N3 – Notação N3) de
recurso, propriedade e literal RDF, veja a notação a 2.2.1.6.1.4.
Figura 2.4 – Notação N3 para exemplificar recurso, propriedade e literal
As declarações RDF podem ainda ser representadas por grafos. O grafo contém o
sujeito, predicado e objeto, e pode ser chamado de grafo de modelos de dados. Cada
tripla representa uma ligação no-arco-no. Elipses representam os recursos, arcos
representam as propriedades e os retângulos representam os literais, Figura 2.5.
17
Figura 2.5 – Grafo de modelos de dados RDF
2.1.1.6.1.2 URIs
Cada nó pode ser um URI, um literal ou nó em branco (não podendo ser
identificado), isto é, um nó que não é uma referência URI ou um literal. Os predicados
são identificados por URIs e podem ser também representados como nós em um grafo.
Na sintaxe RDF, um nó em branco é apenas um nó único que pode ser utilizado em uma
ou mais declarações RDF, mas não tem nome intrínseco [17].
2.1.1.6.1.3 Literais
Os literais são utilizados em RDF para identificar valores como números e datas
por meio de uma representação léxica. Os literais podem ser o objeto de uma declaração
RDF, mas não o sujeito ou o predicado [17].
2.1.1.6.1.4 Linguagens de representação RDF
XML
XML é um padrão recomendado pela W3C com o objetivo de gerar linguagens de
marcação para necessidades especiais, como troca de dados entre organizações.
18
XML é usado para representar um grafo RDF, ou seja, representar um grafo como um
XML documento. A Figura 2.6 exibe uma representação em XML do grafo de dados
simples em RDF.
Figura 2.6 – Representação em XML do grafo de dados RDF.
N3 [18]
N3 é uma linguagem que é uma alternativa compacta e legível para a sintaxe
RDF/XML, mas é uma linguagem que também permite uma maior expressividade em
relação ao RDF/XML. Os objetivos da linguagem são:
Otimizar a expressão de dados e lógica na mesma linguagem;
Permitir expressar RDF;
Permitir a integração de regras com RDF;
Ser legível, natural e simétrica.
As características da linguagem N3 são:
Descreve um namespace como em XML, porém utiliza o prefixo @prefix
seguido do URI, a Figura 2.7 mostra um exemplo;
19
Repetição de outro objeto com o mesmo sujeito e predicado usando uma vírgula
“,”;
Repetição de outro predicado com o mesmo sujeito usando um ponto e vírgula
“;”;
Sintaxe de um nó B com certas propriedades, basta colocar as propriedades entre
colchetes “[ ]”;
Fórmulas que permitem que gráficos N3 sejam citados dentro de gráficos N3,
basta usar chaves “{ }”;
Variáveis e quantificação para permitir que as regras e outras coisas, sejam
expressas;
Gramática simples e consistente.
Figura 2.7 – Exemplo da declaração do prefixo em N3
Turtle [8]
Turtle é um subconjunto simplificado da linguagem N3. É uma sintaxe textual
apenas para escrever e expressar RDF. Turtle permite que gráficos RDF sejam escritos
em uma forma de texto compacta e natural, com abreviaturas para pardrões de uso
comum e tipos de dados. Turtle fornece níveis de compatibilidade com as N-triplas e
formato N3, bem como a sintaxe de triplas padrão do SPARQL, recomendação da W3C.
A Figura 2.8 exibe uma representação em Turtle do grafo de dados simples em RDF,
este exemplo também é válido para o N3.
20
Figura 2.8 – Representação em Turtle do grafo de dados RDF.
2.1.1.6.2 RDF Schema [15]
O RDF não fornece meios para definir classes e propriedades específicas. RDFS
surgiu da necessidade de descrever estas classes e propriedades que podem ser
utilizadas para descrever classes, propriedades e outros recursos. As propriedades
representam as relações entre recursos. RDF não estabelece mecanismos para descrever
essas propriedades, nem provê qualquer mecanismo para descrever as relações entre
essas propriedades e outros recursos.
RDFS é uma extensão semântica do RDF. Provê mecanismos para descrever grupos de
recursos relacionados e as relações entre esses recursos.
RDFS fornece os recursos necessários para indicar quais as classes e propriedades
devem ser usadas juntas (por exemplo, dizer que a propriedade cargo ocupado será
usada para descrever uma Pessoa).
Em resumo: RDF define como descrever recursos através de suas propriedades e
valores, enquanto RDFS define propriedades específicas, restringindo a sua utilização.
21
Classes
Classes são recursos que estão divididos em grupos. Os membros de uma classe são
instâncias desta classe. Classes são geralmente identificadas por referências URI RDF e
podem ser descritas usando as propriedades RDF. RDF-Schema tem as seguintes classes
[15]:
rdfs: Resource - Tudo que é descrito em RDF é chamado recurso, e são
instâncias da classe rdfs: Resource. Todas as outras classes RDF são subclasses
desta classe.
rdfs: Class - Esta é a classe dos recursos que são classes RDF.
rdfs: Literal - Literal é a classe de valores literais, como caracteres e inteiros.
rdfs: Datatype - A classe rdfs: Datatype é a classe dos tipos de dados.
rdf: XMLLiteral – A classe rdf: XMLLiteral é a classe de valores XML literal,
que são utilizados para a incorporação de XML em RDF.
rdf: Property – A classe rdf: Property é a classe de propriedades RDF.
Propriedades
Como já discutido antes, uma propriedade RDF descreve a relação entre o sujeito e o
objeto das triplas. A classe de propriedades RDF tem as seguintes propriedades [15]:
rdf: type – Esta propriedade é usada para indicar que um recurso é uma
instância de uma classe Figura 2.9.
Figura 2.9– Exemplo da propriedade rdf:type
22
rdfs: subPropertyOf – Esta propriedade é usada para indicar que todos os
recursos relacionados por uma propriedade, também estão relacionados por outra
Figura 2.10.
Figura 2.10 – Exemplo da propriedade rdfs:subPropertyOf
rdfs: range - Esta propriedade é usada para indicar que os valores de uma
propriedade são instâncias de uma ou mais classes Figura 2.11.
Figura 2.11 – Exemplo da propriedade rdfs:range
rdfs: domain – Esta propriedade é usada para afirmar que qualquer recurso que
tenha uma determinada propriedade é uma instância de uma ou mais classes
Figura 2.12.
Figura 2.12 – Exemplo da propriedade rdfs:domain
rdfs: subClassOf – Esta propriedade é usada para indicar que todas as instâncias
de uma subclasse são instâncias de suas superclasses Figura 2.13.
23
Figura 2.13 – Exemplo da propriedade rdfs:subClassOf
rdfs: label – Esta propriedade pode ser usada para fornecer uma versão legível
ao recurso Figura 2.14.
Figura 2.14 – Exemplo da propriedade rdfs:label
rdfs: comment – Esta propriedade pode ser usada para fornecer um descrição
legível de um recurso Figura 2.15.
Figura 2.15 – Exemplo da propriedade rdfs:comment
2.1.1.6.3 SHOE
SHOE foi a primeira linguagem de ontologias voltada para a Web Semântica. É
uma pequena extensão de HTML que permite aos autores de páginas web anotarem seus
documentos com conhecimento legível por máquinas [19].
O objetivo principal da linguagem SHOE é fornecer algum tipo de marcação para
disponibilizar a informações relevantes sobre o conteúdo das páginas, permitindo maior
precisão nos mecanismos de busca da rede. SHOE é menos expressivo que o RDF e
apresenta grandes dificuldades na manutenção do conteúdo das páginas anotadas [2].
24
2.1.1.6.4 OIL
A linguagem OIL foi criada pela necessidade de uma linguagem expressiva que
permitisse a modelagem de ontologias na Web, pois o RDF não provê a semântica
necessária nem formalismo suficiente para permitir suporte a mecanismos de inferência.
A semântica formal de OIL e o mecanismo de inferência se baseiam em Lógica de
Descrição [2].
OIL é um esforço para produzir uma linguagem bem definida para a integração de
ontologias com padrões web (em particular, RDF / RDFS e XML / XMLS). Provê uma
camada de inferência para ontologias usando as construções encontradas em linguagens
baseadas em frames e semântica formal de lógicas de descrição. Foi desenvolvida para
ser compatível com os padrões W3C, como XML e RDF [20, 21].
2.1.1.6.5 DAML
DAML surgiu em agosto de 2000. O objetivo do esforço DAML foi desenvolver
uma linguagem e ferramentas para facilitar o conceito da Web Semântica. A linguagem
DAML foi desenvolvida para ser uma extensão do XML e do RDF [22]. A linguagem
DAML herdou muitos dos aspectos presentes em OIL, por isso pode-se dizer que as
duas linguagens apresentam funcionalidades relativamente similares [2].
2.1.1.6.6 DAML + OIL
DAML + OIL é uma linguagem de marcação semântica para recursos da Web que
fornece primitivas de modelagem comumente encontradas em linguagens baseadas em
frames. DAML + OIL foi construído a partir da linguagem DAML-ONT (Linguagem de
25
Ontologia para a Web Semântica - Ontology Language for the Semantic Web)
combinada com muitos componentes da linguagem OIL. Essa linguagem tem uma
semântica limpa e bem definida [23].
DAML-ONT estende RDFS, capturando relações semânticas que podem ser
interpretadas por máquina através de descrições mais expressivas juntamente com
semântica precisa. Isto facilita a intercomunicação entre os agentes [24].
2.1.1.6.7 OWL
A linguagem OWL foi lançada como revisão da linguagem DAML+OIL. OWL foi projetada
para o uso em aplicações que precisam processar o conteúdo da informação, em vez de
apenas apresentar informações para os seres humanos. OWL “estende” RDF e RDF
Schema fornecendo algumas outras possibilidades para ontologias como escalabilidade,
distribuição, compatibilidade com os padrões (standards) Web para acessibilidade e
internacionalização e extensibilidade [25]. Portanto OWL foi projetada para oferecer 3
sub-linguagens de crescente expressividade [26]:
OWL Lite: oferece basicamente suporte a hierarquias de classificação e
restrições simples (simple constraint features);
OWL DL: oferece o máximo de expressividade sem perda de completude
computacional (todos os vínculos são garantidos para serem computados) e
decidibilidade (todas as computações terminarão em tempo finito) de sistemas
de inferência (reasoning systems). OWL DL é assim chamada devido a sua
correspondência com lógica de descrição (description logics). Lógica de
descrição [27] é um área de pesquisa que estuda um fragmento específico e
decidível de lógica de primeira ordem;
26
OWL Full: oferece a máxima expressividade e a liberdade sintática de RDF sem
garantias computacionais.
Desenvolvedores de ontologia que adotarem OWL devem considerar qual sub-
linguagem melhor atende as suas necessidades. A escolha entre OWL Lite e OWL DL
depende da necessidade de construção de restrições mais expressivas oferecida por
OWL DL [26].
OWL permite uma maior interoperabilidade na Web, seu conteúdo é suportado por
XML, RDF, e RDFS (Esquema RDF – RDF Schema), fornecendo um vocabulário
adicional com uma semântica formal. OWL é uma extensão do vocabulário RDF/RDFS
para expressar ontologias. OWL permite a definição de instâncias e as propriedades
sobre elas, permitindo também a formalização de um domínio pela definição de classes
e propriedades dessas classes. Por fim, permite raciocinar a respeito de classes e
instâncias até o grau permitido pela semântica formal da linguagem [26].
2.3 Considerações finais
Este capítulo apresentou a Web Semântica juntamente com as tecnologias usadas por
ela. O uso da Web Semântica tem-se tornado fundamental para o armazenamento,
gerenciamento e reapresentação dos dados. E esta tem sido cada vez mais difundida na
biologia, medicina, economia e outras.
Um grande e crescente volume de dados, cerca de terabytes, são usados para
resolver tarefas cada vez mais complexas. Por isso, torna-se necessário fazer uso de
técnicas cada vez mais sofisticadas de gerenciamento inteligente da informação.
Além disso, a Web Semântica permite que os dados sejam representados de
maneira uniforme, através das ontologias, e contenham significado. Sendo assim, os
27
dados podem ser mais facilmente interpretados por agentes de software, possibilitando
que estes realizem tarefas de maneira mais eficaz para o usuário.
O próximo capítulo é dedicado a apresentar a AGUIA: gerador semântico de
interfaces , assim como as motivações que levaram ao desenvolvimento deste trabalho,
a arquitetura, módulo gráfico e implementação.
28
Capítulo 3
AGUIA: Gerador semântico de interfaces
Este capítulo tem como objetivo apresentar a AGUIA, gerador semântico de
interfaces, apresentando o detalhamento da construção de sua arquitetura, módulo
gráfico e implementação. Inicialmente será descrita a motivação que levou a construção
de tal gerador e em seguida a descrição das decisões e detalhes de implementação de
alguns módulos cruciais do sistema.
3.1 Motivação
O Desenvolvimento e manutenção de aplicativos Web estão se tornando mais
complexo, caro, demorado e requer um esforço considerável para a integração e
manutenção de dados. Usualmente a construção destes aplicativos não resulta em
muitos componentes reusáveis. Isto ocorre principalmente porque a maior parte do
projeto está embutido em páginas da Web estáticas ou dinâmicas [28].
No desenvolvimento da AGUIA utilizou-se o modelo orientado à metodologia, que será
descrito na seção 3.3, já que este tem sido utilizado com grande intensidade para tentar
simplificar e eventualmente automatizar todo o processo de geração e manutenção de
dados de aplicações web [1]. Na próxima seção será descrita a arquitetura da AGUIA e
os detalhes de cada parte desta arquitetura.
3.2 Arquitetura
29
A arquitetura da AGUIA está mostrada na Figura 3.1. A aplicação web em seu
estágio inicial gera algumas consultas para a ontologia de dados e para o módulo
gráfico, a fim de obter-se a parte estrutural e gráfica destes modelos respectivamente.
Em seguida a aplicação web atinge seu estágio final de montagem através do resultado
gerado por essas consultas. Por fim, também através de consultas, porém somente na
ontologia de dados, a aplicação realiza inserções e atualizações destes dados. Cada
componente desta arquitetura será explorado com mais detalhes nas seções 3.2.1 à 3.2.4.
Figura 3.1 – Arquitetura da AGUIA
3.2.1 Ontologia de domínio (dados)
30
A ontologia de domínio serve como uma estrutura subjacente ao descrever o
conteúdo dos dados na aplicação web, ou seja, ela descreve os conceitos e as relações
destes no domínio especificado. Esta ontologia armazena todos os dados, e por isso,
atualizações, consultas e inserções de novos dados são realizadas diretamente nela. A
Figura 3.2 exibe um exemplo da aplicação web utilizando a estrutura da ontologia de
domínio e manipulando os dados contidos nesta ontologia. Destacado de azul na figura
os nomes dos campos e das abas vêm da estrutura da ontologia de domínio e destacado
de vermelho os dados que estão armazenados nesta ontologia e que serão
posteriormente manipulados pela aplicação web.
Figura 3.2 – Exemplo do uso da estrutura e dos dados da ontologia de domínio (dados) pela aplicação web
3.2.2 Módulo gráfico
O módulo gráfico é responsável por descrever a estrutura gráfica da aplicação
web. Por ser uma aplicação web automática, percebeu-se a necessidade de criar este
módulo para que o layout desta aplicação pudesse ser alterado de acordo com as
31
necessidades do usuário. Sem este módulo a aplicação web seria sempre montada com o
mesmo layout.
O usuário é capaz de controlar alguns componentes do layout da aplicação web, ele é
capaz de definir de que tipo o campo definido na ontologia de domínio (dados) será, por
exemplo, na Figura 3.3 o campo 1 é do tipo texto e o campo 2 é do tipo data, pode-se
criar ainda campos que terão opções, campos que ficarão inativos e outros que serão
melhores descritos na seção 3.4.
Figura 3.3 – Exemplo do uso do módulo gráfico nos campos 1 e 2.
3.2.3 Módulo de consulta
O módulo de consulta é responsável por promover a “comunicação” entre a
aplicação web, a ontologia de domínio (dados) e o módulo gráfico. Esta “comunicação”
é realizada através de consultas S3QL e SPARQL, a consulta S3QL será definida e
melhor detalhada na seção 3.3. Por exemplo, para que a aplicação seja capaz de criar o
nome dos campos que são definidos através da estrutura da ontologia de domínio
(dados), a consulta exibida na Figura 3.4 tem que ser executada. Nesta consulta busca-se
por todas as regras que estão no projeto 123456, que é o projeto da ontologia de
32
domínio (dados). As regras, assim como a base de dados S3DB, serão melhores
detalhadas na seção 3.3, por hora é relevante saber apenas que cada campo (campo 1 e
2, por exemplo, como mostrado na Figura 3.2) é representado por regra que está contida
na base de dados S3DB.
Figura 3.4 – Exemplo do uso de consulta para definir o nome dos campos na aplicação web
A Figura 3.5 exibe um exemplo de consulta realizada para que a aplicação web obtenha
e assim seja capaz de montar sua parte gráfica. Nesta consulta busca-se por todos os
itens que estão no projeto 789101 e que a regra é 12345 tenha o valor hasDate. Ou seja,
esta consulta serve para a aplicação web obter e assim montar os campos de data. Os
itens serão melhores detalhados na seção 3.3, por hora é necessário apenas saber que
cada item é uma instância do projeto 789101, que é o projeto do módulo gráfico. Sendo
assim, quando o usuário irá definir quais campos serão do tipo data, por exemplo, é
necessário que este crie instâncias no projeto do módulo gráfico. Posteriormente a
aplicação web através de consultas como mostrada na Figura 3.5 consegue recuperar
todas estas instâncias e assim monte sua parte gráfica.
Figura 3.5 – Exemplo do uso de consulta ao módulo gráfico, para definir campos de data na aplicação web
33
O módulo de consulta é ainda utilizado pela aplicação web para consultar, atualizar e
inserir dados na ontologia de domínio (dados). A Figura 3.6 exibe uma consulta que está
sendo realizada para que se possa inserir um novo que nome de pessoa na base de dados
S3DB. Neste exemplo, o campo nome é representado pela regra 121212, e a nova
instância de nome ficará no item 132354 e o novo nome inserido será Maria.
Figura 3.6 – Exemplo do uso de consulta para inserção de um novo nome na ontologia de domínio (dados)
3.2.4 Aplicação web
A aplicação web é uma aplicação que é capaz de montar-se automaticamente
através de consultas realizadas na ontologia de domínio (dados) e no módulo gráfico
através do módulo de consulta. Esta aplicação é reutilizável e funcionou até agora para
todos os projetos que foram construídos na base de dados S3DB. A Figura 3.7 exibe
uma imagem da aplicação após ter sido completamente montada para o projeto de
câncer gastrointestinal.
34
Figura 3.7 – Imagem da aplicação web após ter sido completamente montada para o projeto de câncer gastrointestinal
3.3 Implementação
A implementação e desenvolvimento da AGUIA não foi uma tarefa trivial. Pois
a AGUIA não é uma simples aplicação web, ela é uma aplicação web “inteligente”, ou
seja, é uma aplicação que é capaz de montar-se automaticamente frente a qualquer
alteração ocorrida na base de dados. Além disso, a AGUIA é capaz de montar diferentes
componentes de layout da aplicação conforme a necessidade do utilizador.
O desenvolvimento envolveu a construção de algoritmos inteligentes para permitir que
esta aplicação fosse capaz de interpretar o conteúdo que seria alterado. Como já
explorado na seção 3.2, a aplicação monta-se apenas através de respostas obtidas de
consultas.
A Figura 3.8 esboça um exemplo simples e sucinto de algoritmo executado pela
AGUIA. Este algoritmo está mostrado em forma de pseudocódigo. Esta figura explica
de maneira simples o processamento que a AGUIA realiza, seguindo a arquitetura
apresentada na seção 3.2. Foram exibidos nesta figura 3 pseudocódigos à fim de
35
exemplificar e facilitar o entendimento do processamento realizado pela AGUIA para
que a aplicação web seja montada. Primeiramente a AGUIA executa o pseudocódigo1,
que gera uma consulta para buscar a estrutura da ontologia de dados. A resposta gerada
por esta consulta é colocada na estrutura1. Em seguida a AGUIA executa o
pseudocódigo2, que gera uma consulta para buscar os componentes gráficos no módulo
gráfico. A resposta gerada por esta consulta é colocada na estrutura2. Ao obter as
estruturas 1 e 2 a AGUIA executa o pseudo-código3, para unir as informações de
estrutura da aplicação com componentes gráficos e assim gerar a aplicação web.
Figura 3.8 – Processamento realizado pela AGUIA
36
Na seção 3.3.1 serão descritas as tecnologias utilizadas e na seção 3.3.2 será descrita a
base de dados semântica S3DB utilizada para a armazenagem dos dados.
3.3.1 Tecnologias utilizadas
A aplicação web foi desenvolvida utilizando conceitos de DHTML (HTML
dinâmico - Dynamic HTML), que é uma linguagem que descreve a arte de criar páginas
web dinâmicas e interativas. DHTML combina HTML, a linguagem de programação
javascript, o HTML DOM e o CSS (Folhas de Estilo em Cascata - Cascading Style
Sheets) [29].
DOM (Document Object Model – Modelo de objeto do documento) é uma plataforma e
linguagem neutra de interface que permite que programas e scripts acessem e atualizem
dinamicamente seu conteúdo, estrutura e estilo de documentos. O documento pode ser
processado e os resultados deste processamento podem ser incorporados novamente na
página de apresentação. Esta é uma visão geral do DOM materiais relacionados aqui no
W3C e em toda a web [30].
Utilizou-se para auxiliar no desenvolvimento desta aplicação a biblioteca dhtmlgoodies
[31]. Esta biblioteca fornece suporte para o desenvolvimento de alguns aplicativos
gráficos em DHTML, como por exemplo, calendários, abas, árvores e outros. Algumas
das funcionalidades desta biblioteca foram adaptadas para garantir o melhor
aproveitamento da biblioteca, principalmente no que tange à apresentação dos recursos
para o usuário.
A maioria dos navegadores não suportam a tecnologia ActiveX. O uso desta tecnologia
permite que a linguagem de programação javascript seja capaz de fazer a exportação de
seu conteúdo para uma planilha excel. Mas como esta tecnologia não funciona em todos
os navegadores foi preciso utilizar a linguagem PHP para realizar tal exportação.
37
Esta aplicação está hospedada no Google code, que é um site da companhia google para
interesse de programadores em desenvolvimento de softwares. O Google code fornece
suporte para o desenvolvimento de ferramentas, recursos técnicos e contém uma lista de
serviços que suportam a API (Interface de Programação de Aplicativos – Application
Programming Interface) pública do Google e código fonte aberto [32].
Visando fornecer suporte aos dados, uma base de dados semântica foi utilizada por
facilitar a integração da informação e adicionar uma camada de significado aos dados. A
base dados escolhida foi o S3DB é será descrita na seção 3.3.2.
3.3.2 S3DB
A grande quantidade de dados que está sendo acumulada nos diferentes bancos
de dados ao redor do mundo precisa, a partir das informações disponíveis, serem
anotada e interpretada. Para este fim, é necessário que os diversos projetos interessados
em trocar e integrar informações descreva seus dados de forma padronizada, de modo a
possibilitar com consistência a recuperação de informações. Ontologias assumem papel
fundamental nesta integração, viabilizando a interoperabilidade semântica de sistemas
distribuídos heterogêneos, como é o caso de esforços que reúnem consórcios
internacionais [33]. Além disso, os vocabulários reutilizáveis emergentes demonstram
ser úteis na descrição de dados biomédicos de um número cada vez maior de tipos de
aplicação. A captura precisa de conhecimento biológico num meio computacional
permite a criação de sistemas capazes de cumprir exigências severas, como as de
biólogos, pesquisadores da área médica, e médicos: fácil acesso a textos e bases de
dados que contêm dados, informação e sentenças detalhadas; raciocínio estável e
completo; rápido desenvolvimento de sistemas de suporte de decisão para diversos tipos
de utilização, etc.
38
Tendo em vista que uma base de dados semântica pode alcançar
interoperabilidade semântica através de ontologias, e que estas têm sido cada vez mais
utilizadas para o apontamento de dados de pesquisas sobre Biologia Molecular,
Genômica e para dados biomédicos [4]. Optou-se por armazenar as amostras fornecidas
pelo departamento de Gastrointestinal Medical Oncology do MD Anderson Cancer
Center em uma base de dados semântica, pois se tratava de dados de origem biomédica
e estes estavam em vasta quantidade. Esse departamento forneceu-nos
aproximadamente 1 milhão de medições independentes que descrevem um conjunto de
1369 pacientes, como já mencionado na seção 1.2.2. Estas amostras serão melhores
detalhadas no capítulo 4.
A base de dados escolhida para armazenagem dos dados foi o S3DB. O S3DB
foi criado pelo grupo de Bioinformática Integrativa do MD Anderson Cancer Center,
coordenado por Jonas Almeida (mathbiol.org) sendo uma forma de representar
informações sobre a web semântica. Esta base de dados foi escolhida, pois é uma base
de dados semântica que é capaz de gerar dados em vários formatos, incluindo RDF,
XML, Turtle e outros. Além disso, a consulta, inserção, deleção ou atualização nesta
base de dados pode ser realizada de forma bastante simples, através do uso de uma url
de consulta S3QL ou SPARQL. Além disso esta base de dados usa um protocolo REST,
e é de código aberto e domínio público o que facilita o desenvolvimento e divulgação.
Nas próximas seções esta base de dados será detalhada. Será descrita sua definição, o
modelo do núcleo e o modelo de consulta utilizada por ela.
3.3.2.1 Definição
S3DB é uma infra-estrutura de banco de dados distribuída que se baseia em
conceitos da Web Semântica para a gestão de dados heterogêneos. Provê uma ponte
39
entre uma massa estruturada de dados anotados usando ontologias próprias e uma
representação semântica globalmente referenciada para o vocabulário controlado [34].
Em outras palavras, é uma forma de representar informações na Web Semântica. Isto
facilita e otimiza o gerenciamento e a manutenção de dados em uma série de campos de
pesquisa, já que a Web Semântica permite uma melhor integração da informação e
adiciona uma camada de significado aos dados.
A Figura 3.9 mostra a base de dados S3DB.
Figura 3.9 – Visualização do S3DB
3.3.2.2 Módulo de núcleo (Core Model) do S3DB
O modelo de núcleo do S3DB está mostrado na figura 3.10. Em azul, tem-se a
camada que verifica a permissão de um determinado usuário. Este usuário pode ter
permissão para acessar um domínio (em verde) e não ter permissão para acessar um
projeto (em verde). Isto varia de acordo com a propagação de permissões que usuário
pode ter. Em verde, tem-se o domínio e projetos. Um domínio pode armazenar um ou
40
mais projetos. Em vermelho nos temos as coleções, regras, itens e declarações. Coleções
são descritas de acordo com as triplas RDF - sujeito-verbo-objeto, descritas no capítulo
Estes triplos são agrupados em coleções, que são conjuntos de triplos que compartilham
o mesmo sujeito. Regras são o sujeito ou o objeto da tripla RDF. Os Itens contêm todas
as instâncias de uma determinada coleção e as declarações são instâncias individuais de
cada regra.
Figura 3.10 – Modelo de núcleo do S3DB. Este diagrama pode ser lido a partir da unidade de dados mais fundamental, o par de atributo-
valor (símbolos cheios hexagonal e quadrado). Cada elemento do par é objeto de dois triplos distintos, um que descreve o domínio do
discurso, as regras, e os outros vindo de declarações, onde o domínio é preenchida para instanciar as relações entre as entidades. Este
último inclui os valores reais. Em torno desses duas coleções nucleares de triplas, é a resolução da coleção e sua instanciação como item
que define a relação entre os elementos individuais de regras e declarações. A estrutura resultante é então organizada em projetos de tal
maneira que o domínio do discurso, no entanto, podem ser compartilhados com outros projetos, no mesmo ou em um domínio do S3DB
distinto. Finalmente, a propagação de permissões do usuário (linha tracejada) é definida de tal forma que a distribuição das estruturas de
dados pode ser rastreado [35]
3.3.2.3 Modelo de consulta
As consultas permitidas no S3DB são S3QL e SPARQL.
3.3.2.3.1 S3QL
41
S3QL é uma linguagem de consulta de dados relacionais SQL de baixo nível que
usa o serviço web REST (Estado de Transferências Representacional - Representational
State Transfer) para tornar a informação armazenada em qualquer aplicação S3DB
disponível para outros aplicativos. Em outras palavras, é um protocolo implementado
usando REST [36]. Por essa razão, é preciso mais consultas para recuperar todas as
declarações (statements) associadas com um certo número de itens [37].
A Figura 3.11 mostra um exemplo da sintaxe de uma consulta S3QL:
Figura 3.11 – Exemplo de consulta S3QL. Esta consulta obtém todas as regras que estão na coleção 1588680.
3.3.2.3.2 SPARQL
SPARQL é uma linguagem de consulta para a Web Semântica [38]. É um padrão
recomendado pelo W3C para pesquisa de dados em gráficos RDF e é o principal e mais
recente padrão da Web Semântica. SPARQL já está disponível em 14 implementações e
é comparável a linguagens de pesquisas bem conhecidas no mundo das bases de dados
relacionais.
A especificação SPARQL funciona com várias tecnologias de Web Semântica
da W3C. Entre elas estão incluídas o RDF, para representação dos dados, o RDF
Schema, o OWL para a construção de vocabulários e o GRDDL (Coletanto Descrições
de Recursos de Dialetos de Linguagens - Gleaning Resource Descriptions from Dialects
of Languages) para a extração automática de dados de Web Semântica de documentos
[39, 40].
A construção de uma consulta SPARQL se baseia no padrão de triplas RDF. A Figura
3.12 mostra a estrutura de uma consulta SPARQL. Na parte # Prefixo de declarações
42
contém as URIs abreviadas, em # Definição do conjunto de dados indica-se que gráfico
RDF será consultado. A parte # Cláusula do resultado serve para informar quais as
informações serão retornadas a partir da consulta, # Padrão de consulta especifica o que
será consultado a partir do conjunto de dados e em # Modificadores de consulta servem
para cortar e ordenar os dados, ou seja, é uma outra maneira de rearranjar o resultado da
consulta [41].
Figura 3.12 – Estrutura de uma consulta SPARQL [41]
Para fazer uma consulta SPARQL no S3DB basta clicar na aba SPARQL e montar sua
consulta. Existe um facilitador no S3DB que ajuda o usuário com a montagem da
consulta SPARQL, conforme ilustrado na Figura 3.13.
43
Figura 3.13 – Exemplo de construção de uma consulta SPARQL no S3DB.
É possível ainda fazer consultas SPARQL no S3DB através de urls. A Figura 3.14
mostra um exemplo desta consulta.
Figura 3.14 – Exemplo de construção de uma consulta SPARQL através de uma url
3.4 Modelo gráfico
O modelo gráfico é o modelo responsável pela construção da parte gráfica ou
visual da aplicação web. Este modelo foi construído na base de dados para permitir que
o usuário pudesse fazer uso de diferentes tipos de layouts na aplicação web, de acordo
com a sua necessidade.
44
Por este motivo, foi necessário desenvolver um modelo abstrato e prover uma forma de
“comunicação” entre este modelo e a aplicação web. A partir disso, a aplicação web é
capaz de absorver as informações fornecidas pelo modelo e posteriormente construí-las
e exibi-las de forma amigável para o usuário. Na seção 3.4.1 será descrito cada
componente gráfico que pode ser criado na aplicação e na seção 3.4.2 será descrito os
detalhes de implementação do modelo construído na base de dados.
3.4.1 Componentes gráficos
Foi necessário fazer uso e teste em dois projetos com duas vertentes e objetivos
diferentes, para se decidir de forma mais adequada, quais componentes gráficos seriam
permitidos do usuário criar. O primeiro projeto é o de câncer gastrointestinal (estudo de
caso desta dissertação, descrito no capítulo 4), onde conta-se com dados clínicos de
1369 pacientes. O segundo projeto, usado apenas para teste, é de um workshop
realizado na Rice University em Houston-EUA, onde os participantes cadastraram seus
dados pessoais, dados de suas instituições, dados de pesquisa, etc. Após analisar as
necessidades destes dois projetos, decidiu-se que a aplicação web seria melhor
organizada se esta contivesse abas e chegou-se a 11 componentes gráficos que poderiam
ser criados pelo usuário. Este serão descritos brevemente nas seções 3.4.1.1 a 3.4.1.11,
na seção 3.4.2 eles serão melhores detalhados e exemplificados.
3.4.1.1 Componente de data
Este componente é usado para criar um campo de data, logo este componente
conterá um calendário para que o usuário possa entrar com uma data.
3.4.1.2 Componente de texto
45
Este componente é usado com o objetivo de se criar campos de texto, logo este
componente conterá um campo de texto comum para que o usuário possa entrar com um
texto.
3.4.1.3 Componente de texto maior
Este componente é usado com o objetivo de se criar comentários e observações,
logo este componente terá um campo de texto maior para que o usuário possa entrar
com um texto extenso.
3.4.1.4 Componente de condição
Este componente é usado para se criar uma condição para uma determinada ação
acontecer, logo se a condição for obedecida à ação irá ocorrer.
3.4.1.5 Componente de fórmula
Este componente é usado para permitir que alguns campos recebam o cálculo
realizado por uma fórmula, logo a fórmula calculará o valor que será exibido no campo.
3.4.1.6 Componente de restrição
Este componente é usado para inativar campos que obedecem a determinada
restrição, logo se um campo obedecer uma determinada restrição, os outros campos
ficarão inativos.
3.4.1.7 Componente de opções
Este componente é usado com o objetivo de se criar um menu de opções, logo este
componente permitirá que o usuário cadastre várias opções em um mesmo campo.
46
3.4.1.8 Componente de grid
Este componente permitirá que o usuário crie uma grid dentro de uma aba da
aplicação web, logo a aba que contiver este componente exibirá uma grid.
3.4.1.9 Componente de inativação
Este componente é usado com o objetivo de inativar campos em que o usuário da
aplicação não poderá controlar, logo este componente só receberá dados oriundos da
base de dados e não poderá ser alterado pelo usuário na aplicação.
3.4.1.10 Componente de concatenação
Este componente é usado com o objetivo de criar campos que resultam da
concatenação de outros, logo este componente receberá um valor que é resultado da
concatenação de outros campos.
3.4.1.11 Componente para criação de sub-abas
Este componente permite que sub-abas sejam criadas na aplicação web.
3.4.2 Implementação do modelo gráfico na base de dados
Construiu-se um projeto na base de dados S3DB para permitir a implementação
do modelo. Para tornar o modelo abstrato e permitir que este gerasse um RDF que
posteriormente seria interpretado pela aplicação web, precisou-se planejar e pensar em
uma estrutura que descrevesse triplas RDF. Sendo assim, foram construídas duas
coleções no S3DB, a relação entre estas duas coleções permite a geração de triplas RDF.
47
A primeira coleção é a GUI Actions, esta coleção apenas cadastra as ações que podem
ser criadas. Estas ações correspondem a cada componente gráfico descrito na seção
3.4.1, e como esta coleção descreve apenas os grafismos, esta será a GBox.
Gbox é um componente gráfico da base de conhecimento. Segundo MOTIC [42] um
gráfico na base de conhecimento é acíclico se seu GBox é acíclico. Se pensarmos com
este enfoque, podemos perceber que o GBox descreve exatamente e fielmente a parte
gráfica da base de conhecimento e ele contém a parte fundamental para a criação do
modelo gráfico, sendo assim o modelo gráfico descrito aqui pode ser considerado um
elemento integrante da base de conhecimento – um GBox.
A segunda coleção é a GUI Rules, esta coleção tem as regras range, domain, trigger,
action e value. Range (Alcance) – Contém o número da regra que será afetada pela
ação. Domain (Domínio) – Contém o número da regra que comandará a ação. Action
(Ação) – Item que determinará qual será a ação. Value (Valor) – Poderá ser valor(es) ou
literal(is). Esta regra contém o valor que será exibido na regra range ou domain. Trigger
(Gatilho) – Poderá ser valor(es) ou literal(is). Esta regra contém o valor que será testado
em domain. Domain e range são regras que apontam para um outro recurso, sendo
assim estas duas regras são a descrição do domínio na base de conhecimento. Em lógica
descritiva a descrição do domínio em uma base de conhecimento é chamada de TBox
(terminological component-componente terminológico). As regras trigger e value são
literais usados para a atribuição de valores ou teste de valores em uma determinada
regra descrita em domain ou range. Logo são chamados de ABox (assertion component
- componente de asserção).
Estas regras serão melhores exemplificadas pela tabela 3.1 e pela Figura 3.17. Cada
instância feita sobre a coleção GUI Rules descreve uma tripla RDF, Figura 3.15. Esta
figura mostra a relação entre as coleções GUI Actions e GUI Rules. A coleção GUI
48
Actions fornece o predicado da tripla RDF para a coleção GUI Rules. A coleção GUI
Rules então instancia cada componente gráfico e assim compõe uma tripla RDF. O
sujeito da tripla RDF pode ser domain ou o domain combinado com o trigger - valor
que será testado no objeto se o predicado for alguma ação de teste. O predicado
corresponde à ação gerada pela coleção GUI Actions e o objeto é composto pelo range
ou o range combinado value - valor que será colocado nesta regra.
Figura 3.15 – Ilustração da relação entre as coleções para permitir triplas RDF
A Figura 3.16 exibe um exemplo para criação de campos de data. Nesta figura o sujeito
da tripla RDF contém o número da regra que receberá o campo de data, ou seja, o
número da regra que está contido em domain, o predicado corresponde à ação gerada
pela coleção GUI Actions e o objeto é composto por um nó em branco.
49
Figura 3.16 – Exemplo da tripla RDF gerada pelo modelo gráfico para criação de campos de data
A Figura 3.17 exibe o modelo gráfico construído para o conjunto de 11 componentes e a
relação entre as coleções para formar as triplas RDF.
Figura 3.17 – Modelo gráfico construído na base de dados
A Figura 3.18 exibe o mesmo modelo gráfico, porém esta figura detalha as ações
criadas para os 11 componentes na coleção GUI Actions - GBox e a relação entre ela
com a coleção GUI Rules para formar as triplas RDF. Esta figura exibe ainda as regras
criaddas na coleção GUI Rules, mostrando os componentes ABox e TBox.
A figura 3.18 esta diretamente ligada com a tabela 3.1, os componentes GBox, TBox e
ABox são representados pelas colunas na tabela 3.1 e cada instância sobre estes
componentes correspondem a uma linha da tabela. Esta tabela exibe os exemplos da
50
instância de cada componente gráfico e mostra o RDF gerado pela combinação entre as
coleções GUI Rules e GUI Actions.
Figura 3.18– Modelo de Gráfico com um conjunto de 11ações( itens do S3DB (1-11)) e um conjunto de 5 regras S3DB (A-E).
Nº
Tipo de ação
A
B
C
D
E
Domain
Trigger
Action
Range
Value
1
hasDate
1+ Rules
-
1 Item
-
-
RDF
AGUIA:hasDate rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Exemplo
2
hasText
1+ Rules
-
1 Item
-
-
RDF
AGUIA: hasText rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Exemplo
3
hasTextArea
1+ Rules
-
1 Item
-
-
RDF
AGUIA: hasTextArea rdfs:domain s3db:Rule;
aguia:action s3db:Item;
51
rdf:type s3db:Item.
Exemplo
4
hasConditions
1+ Rules
1+ Values
1 Item
1 Rules
1 Value
RDF
AGUIA: hasConditions rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
aguia:value s3db:Value;
aguia:trigger s3db:Value;
rdf:type s3db:Item.
Exemplo
5
hasFormula
1 Rules
-
1 Item
1 Rule
-
RDF
AGUIA: hasFormula rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Exemplo
6
hasRestrictionsActiveFields
1 Rule
1+ Values
1 Item
1+ Rules
-
RDF
AGUIA:hasRestrictionsActiveFields rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
aguia:trigger s3db:Value;
rdf:type s3db:Item.
Exemplo
7
hasOptions
1+ Rules
-
1 Item
-
1+
Values
RDF
AGUIA: hasOptions rdfs:domain s3db:Rule;
aguia:action s3db:Item;
aguia:value s3db:Value;
rdf:type s3db:Item.
Exemplo
8
hasMoreFields
1+ Collections
-
1 Item
-
-
52
RDF
AGUIA: hasMoreFields rdfs:domain s3db:Collection;
aguia:action s3db:Item;
rdf:type s3db:Item.
Exemplo
9
hasFieldInactive
1+ Rules
-
1 Item
-
-
RDF
AGUIA: hasFieldInactive rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Exemplo
10
hasConcatenation
1+ Rules
-
1 Item
1 Rules
-
RDF
AGUIA: hasConcatenation rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Exemplo
11
hasSubCollections
1 Collection
-
1 Item
1+
Collectio
ns
-
RDF
AGUIA: hasSubCollections rdfs:domain s3db:Collection;
aguia:action s3db:Item;
rdfs:range s3db: Collection;
rdf:type s3db:Item.
Exemplo
Tabela 3.1 – Descrição dos verbos especiais que são criados dentro de um projeto especial GUI Rules com o objetivo de possibilitar que a
interface gráfica responda a algumas ações criadas na base de dados. Esta tabela exibe os detalhes dos relacionamentos 11x 5 necessários
para configurar a montagem automatizada da interface gráfica do usuário – AGUIA - pelo navegador baseado em javascript. Cada linha
corresponde a cada uma das11 ações GUI, instanciado por itens S3DB, tabulados contra 5 GUI Rules (colunas), instanciado por regras
S3DB.
A tabela 3.1 exibe as colunas de A até E, que representam as regras criadas na coleção
GUI Rules, sendo que o valor da regra C vêm da coleção GUI Actions, com todas as
53
ações possíveis de serem criadas. Tem-se na linha 1 a criação de campos de data. Para
criar estes campos é preciso apenas colocar no domain o número ou os números das
regras que irão receber campos de data. Por isso o valor contido em domain é 1+ Rules.
Action é um item da coleção GUI Action. Sendo assim, a combinação das duas coleções
produz um RDF que é lido e interpretado pela aplicação web para formar campos de
data. Na parte exemplo da linha 1 tem o campo data de nascimento do tipo data. Sendo
assim, este recebeu um calendário. Os componentes da linha 2, 3 e 9 são similares ao
componente da linha 1, a diferença entre eles está apenas na ação. Na linha 4 tem-se um
componente de condição. Em domain serão colocadas 1 ou mais regras que irão ser
testadas pela condição imposta pelo trigger, em action será colocada a ação
hasConditions, em value será colocado o valor que a regra que esta em range receberá
se a condição for obedecida. Na parte do exemplo da linha 4 tem-se o campo Basenline
TNM descrito em domain, será testado em trigger se este campo contém os valores
TXNXMX, se sim o campo Baseline Stage que está descrito em range receberá o valor
X que está informado em value. O componente exibido na linha 5 é similar ao da linha
4, porém neste componente não há valores a serem testados e nem valores que serão
colocados em algum campo, a ação deste componente é hasFormula. Domain conterá
o(s) número(s) da(s) regra(s) que receberá(ão) a fórmula que esta descrita no range. No
exemplo da linha 6 o campo Age of Presentation at MDACC que está descrito em
domain irá receber o resultado da fórmula colocada em range. Na linha 6 tem-se o
componente de restrição hasRestrictionsActiveFields. Em domain é colocada a regra
que será testada com os valores que estão em trigger, em range serão colocadas as
regras que ficarão inativas se a condição for obedecida. No exemplo da linha 6 o campo
Relapse descrito em domain será testado e se este campo contiver o valor “No”
colocado em trigger, os outros campos (Data of Relapse, Local Distant Relapse e First
54
Site of Relapse) que estão contidos em range ficarão inativos. Na linha 7 está o
componente para criar opções, a ação é hasOptions. Domain contém o(s) número(s)
da(s) regra(s) que receberão as opções descritas em value. No exemplo da linha 7 o
campo Gender que está descrito em domain conterá os valores: Male e Female que
estão colocados no campo value. Na linha 8 está o componente que permite a criação
das grids em determinadas abas, a ação hasMoreFields. Em domain são colocadas os
números das coleções que terão grids. Na linha 10 está o componente de concatenação,
a ação é hasConcatenation. Domain conterá os números das regras que serão
concatenadas e em range será descrito o número da coleção que receberá a
concatenação dos campos. No exemplo da linha 10 os campos Baseline EUS-T, EUS-N
e Baseline M descritos em domain serão concatenados e o valor desta concatenação será
colocado em Baseline TNM, descrito em range. Finalmente na linha 11 tem-se o
componente para a criação de sub-abas, a ação é hasSubCollections. Domain conterá o
número da coleção principal e range conterá os números das coleções que serão sub-
abas da coleção principal. No exemplo da figura 11 a coleção Patient contida em
domain conterá as sub-abas Patient-ID, Demographics, Sample Collection, Personal
Habits and Medical History.
Todos os componentes descritos na tabela 3.1 podem ser criados pelo usuário e
associados a ontologia de domínio para que a aplicação web seja montada. O modelo
gráfico contém coleções e regras, mas estas servem apenas para produzir associações
para que as triplas RDF possam ser geradas e assim possibilitar que os componentes
gráficos sejam interpretados pela aplicação web. Sendo assim vale ressaltar que toda
instância do modelo gráfico que está referenciando o número de alguma coleção ou
regra contidas em domain ou range, colunas A e D da tabela respectivamente, são
correspondentes a números de regras e coleções existentes na ontologia de domínio.
55
3.5 Considerações finais
A associação da ontologia de domínio e do modelo gráfico descrito neste capítulo
permite que a aplicação web seja capaz de montar-se automaticamente. O modelo
gráfico gera triplas RDF que são interpretadas pela aplicação web, isto permite que
todos os componentes gráficos da aplicação sejam montados de acordo com a
necessidade do usuário tornando então possível a composição de vários layouts
diferentes.
No capítulo 4 será descrito o estudo de caso desta dissertação, assim como exemplos
diretos do uso e aplicação da ontologia de domínio e do módulo gráfico.
56
Capítulo 4
Estudo de caso: AGUIA para ensaios clínicos
O estudo de caso desta dissertação envolveu a captura, gestão e representação de dados
clínicos, demográficos e biomoleculares de pacientes. Estes dados foram fornecidos
pelo departamento de Gastrointestinal Medical Oncology do MD Anderson Cancer
Center. Este departamento trata de doenças gastrointestinais, inclusive câncer no fígado,
vias biliares, vesícula, pâncreas, intestino grosso, intestino delgado, estômago, esôfago e
tumores raros [43]. Os dados fornecidos foram oriundos de ensaios clínicos.
Ensaios clínicos são estudos de pesquisas que envolvem pacientes e tem por objetivo
encontrar o melhor caminho para prevenir, diagnosticar e tratar doenças, neste caso o
câncer. Os pacientes que participam destes ensaios clínicos são voluntários. E estes são
muito importantes para o desenvolvimento de novos tratamentos para combater o
câncer. Muitos dos tratamentos de câncer de hoje são baseados no resultado de prévios
ensaios clínicos [5].
Trabalhou-se com aproximadamente 1 milhão de medições independentes,
descrevendo um conjunto de 1369 pacientes, como já mencionado na seção 1.2.2. Na
seção 4.1 será detalhada a forma de obtenção destes dados e como estes foram
importados para a base de dados s3db para formar a ontologia de domínio.
4.1 Formato, importação dos dados e ontologia de
domínio
57
Os dados fornecidos pelo departamento de Gastrointestinal Medical Oncology
foram oriundos de planilhas eletrônicas. Na maioria das vezes estas podem ser uma
fonte perigosa e desfavorável de armazenamento, pois podem fornecer informações
redundantes e que não representam a realidade. A planilha fornecida foi extremamente
extensa e com uma enorme massa de dados. Sendo assim para construir a ontologia –
que conteria os dados no s3db – e iniciar a importação dos dados, foi necessário agrupar
os dados semelhantes e dividir a planilha em 27 planilhas menores, que são: Patient_ID,
Demographics, Sample Collection, Personal Habits, Medical History, Baseline Staging
and Endoscopy, Histology, Tissue, Sample Information, Frozen Sample, Paraffin
Sample, Sample Release, Rx Protocol, Chemotherapy, Chemoradiation, Surgery,
Relapse, Survival, BMI, Baseline PET, Post Chemotherapy, Post CTRT PET,
Abstracter and Verifier, Comments, Study, Slide e GeneExpression. Uma ilustração
desta divisão está mostrada na Figura 4.1.
Figura 4.1 – Ilustração da divisão da planilha grande em 27 planilhas menores
58
A Figura 4.2 mostra um exemplo de agrupamento para a planilha demographics.
Figura 4.2 – Exemplo da planilha demographics
Todas as 27 planilhas representam coleções na base de dados s3db. Com o propósito de
organizar melhor os dados, foram ainda criadas mais 4 coleções, que são: Patient,
Tissue Samples, Treatment e PET. A coleção Patient contém as coleções: Patient_ID,
Demographics, Sample Collection e Personal Habits. A coleção Tissue Samples contém
as coleções: Sample Information, Frozen Sample, Paraffin Sample e Sample Release. A
coleção Treatment contém as coleções: Rx Protocol, Chemotherapy, Chemoradiation e
Surgery e a coleção PET contém as coleções: Baseline PET, Post Chemotherapy e Post
CTRT PET. A seção 4.1.1 descreve como os dados foram importados para a base de
dados s3db.
4.1.1 Criação da ontologia de domínio (dados)
Após ter dividido a planilha em sub-planilhas, foi preciso criar a ontologia na
base de dados. Cada sub-planilha foi denominada uma coleção e como já dito na seção
4.1 foram criadas ainda mais 4 coleções adicionais a fim de agrupar mais claramente os
dados.
A ordem com que estas coleções apareceriam na AGUIA foi denominada através da
adição de um número seguido de underline (_) antes do nome da coleção, por exemplo,
01_Patient e assim por diante.
59
As regras contidas em cada coleção, são correspondentes a cada coluna de cada
planilha, por exemplo, na figura 4.2 as regras da coleção demographics são: Patient
Name, Date of Birth, Age at Presentation at MDACC, Race, Ethnicity, Gender e Marital
Status. Cada uma destas regras na AGUIA respresenta um campo, isto será ilustrado na
seção 4.2, sendo assim a ordem de cada campo também é definida pela adição de um
número seguido de underline(_) na frente do nome de cada regra. Por exemplo,
01_Patient Name.
A Figura 4.3 mostra as coleções e a relação destas na ontologia de domínio.
Figura 4.3 – Ontologia de dados mostrando a relação das coleções
A Figura 4.4 mostra a ontologia com as regras e as coleções. Esta ontologia pode ser
melhor visualizada olhando as figuras 4.5 e 4.6. Nestas figuras foi realizado um corte
longitudinal na ontologia da figura 4.4, as figuras 4.5 e 4.6 se completam.
60
Figura 4.4 – Ontologia de dados do departamento de Gastrointestinal Medical Oncology do MD Anderson Cancer Center
61
Figura 4.5 – Corte longitudinal na ontologia mostrando a primeira parte
62
Figura 4.6 – Corte longitudinal na ontologia mostrando a segunda parte
63
Após ter construído a ontologia, os dados já podem ser importados para a base de dados.
A seção 4.1.2 descreverá o processo de importação destes dados.
4.1.2 Importação dos dados para o s3db
A API do S3DB fornece um arquivo excel de modelo para a importação de dados. Para
fazer download do template basta clicar na coleção correspondente (coleção que irá
receber os dados) e em seguida clicar em rule template, Figura 4.7.
Figura 4.7 – Obtendo o rule template da coleção demographics
Um exemplo de template para a coleção demographics esta mostrado na Figura 4.8.
64
Figura 4.8 – Rule template da coleção demographics
Após ter recebido o arquivo excel com o modelo, basta apenas o usuário popular esta
planilha com os dados, como mostrado na Figura 4.8. A primeira coluna é o s3db UID,
deixe esta coluna em branco. A segunda é a coluna de notas, estas notas serão exibidas
na frente do item ID no s3db. O item id é um identificador de cada instância feita sobre
a coleção. Cada linha da planilha é um item id no s3db, ou seja, todos os registros da
linha 1 terão o mesmo item id. Um exemplo de item id está mostrado em verde na
Figura 4.9. Cada coluna da planilha é uma regra (como mostrado em amarelo na Figura
4.9) e cada registro de cada coluna é um statement (como mostrado em azul na Figura
4.9). A Figura 4.9 mostra a equivalência de cada parte da planilha com o s3db, esta
figura usa imagens do s3db para ajudar na ilustração e no entendimento.
Figura 4.9 – Figura mostrando a equivalência entre cada parte da planilha com o s3db
65
O s3db permite a importação de arquivos do tipo txt separados por tabulação, para criar
este tipo de arquivo basta abrir a planilha no excel e clicar em salvar como e em seguida
escolher Texto (separado por tabulação). Após ter salvado o arquivo basta apenas usar a
API do s3db para importá-lo.
4.2 Criando o projeto de regras gráficas
AGUIA é capaz de montar-se apenas utilizando o projeto de dados construído no s3db.
Se o projeto de regras gráficas não for criado a AGUIA por padrão cria todos os campos
como sendo campos de texto, Figura 4.10. A Figura 4.10 mostra o exemplo do projeto
de ensaios clínicos, mas nenhuma regra gráfica foi definida. Sendo assim a AGUIA
montou apenas campos de texto.
Figura 4.10 – Figura mostrando os campos de texto criados por padrão na AGUIA quando nenhuma regra gráfica é definida
Para criar o projeto de regras gráficas é necessário criar duas coleções, uma chamada
GUI action e a outra GUI rules (Figura 4.11).
66
Figura 4.11– Projeto GUI Rules com suas duas coleções GUI action e GUI rules
A coleção GUI Action conterá apenas itens e cada item representará uma ação. Para
criar as ações clique na coleção e em seguida clique em “Add GUI action”. Em notes
coloque o nome da ação, por exemplo, para data coloque hasDate (Figura 4.12). As
ações que podem ser criadas foram descritas na seção 3.4.1. A Figura 4.13 mostra uma
imagem do s3db com os itens criados para todas as ações permitidas.
Figura 4.12 – Criação dos items na coleção GUI action que serão as ações na coleção GUI rules
67
Figura 4.13 – Esta figura mostra os items criados na coleção GUI Action, estes items representam todas as ações possíveis que
posteriormente serão usadas na coleção GUI Rules.
A coleção GUI rules conterá as regras que receberão as ações. Esta coleção precisará
conter as regras, range, domain, action, value e trigger (Figura 4.14), como já descrito
na seção 3.4.2:
Figura 4.14 –Coleção GUI rules e suas regras.
68
Nas seções 4.2.1. à 4.2.5 serão apresentados exemplos da instanciação de cada uma
destas regras para o projeto de ensaios clínicos.
4.2.1 Range (Alcance)
O valor que a regra range conterá será o número de uma regra existente no S3DB,
que receberá o valor colocado em trigger (gatilho) e será afetada pela action (ação). Por
exemplo, se a regra 1371851(domain) contém o valor N/AN/AN/A (trigger – gatilho),
então a regra 15036 (range) conterá o valor N/A (value – valor que será colocado na
regra que está definida em range - alcance). Ou seja, o range vai ser a regra que recebe o
valor colocado no trigger (Figura 4.15).
Figura 4.15 – Exemplo do uso de range para criar campos qye tem alguma condição
4.2.2 Domain (Domínio)
69
O(s) valor(es) que a regra domain conterá será(ão) número(s) de regra(s)
existente(s) no S3DB. Por exemplo, para criar campos de data, basta colocar o(s)
número(s) da(s) regra(s) que contém data em domain e colocar em action a ação
hasDate. Sendo assim, todas as regras colocadas em domain receberão campos de data
(Figura 4.16).
Figura 4.16 – Exemplo do uso de domain para criar campos de data
4.2.3 Action (Ação)
O valor que a regra action (Figura 4.17) conterá será o número de um item existente na
coleção GUI action criada anteriormente, as ações possíveis foram descritas na seção
3.4.1 e a instanciação delas foi exibida na Figura 4.13.
Figura 4.17 – Exemplo do uso de action para criar campos qye contém uma condição.
70
4.2.4 Value (Valor)
O(s) valor(es) que a regra value conterá será(ão) valor(es)/literal(is). Em value será
colocado o valor que a regra que está em range apresentará. Por exemplo, ainda olhando
para a Figura 4.15, o value conterá o valor N/A que será colocado na regra 15036 se o
valor que estiver no domain(regra 1371851) for N/AN/AN/A e se a ação for
hasConditions.
Veja mais um exemplo de value na figura 4.18.
Figura 4.18 – Exemplo do uso de value.
4.2.5 Trigger (Gatilho)
O(s) valor(es) que a regra trigger conterá será(ão) valor(es)/literal(is). Em trigger será
colocado o valor que será testado na regra que estiver em domain. Por exemplo, ainda
olhando para a Figura 4.15, o trigger contém o valor N/AN/AN/A que será testado na
regra 1371851, em outras palavras a pergunta feita será: A regra 1371851 contém o
71
valor N/AN/AN/A? Um exemplo real seria, se o campo cirurgia na coleção cirurgia
contiver o valor No, logo os outros campos (que estão descritos em range) nesta mesma
coleção se comportarão ficarão inativos (action é hasRestrictionsActiveFields).
Veja mais um exemplo de trigger na Figura 4.19.
Figura 4.19 – Exemplo do uso de trigger
4.3 Usando a AGUIA
AGUIA está hospedada no seguinte endereço
http://aguia.googlecode.com/hg/index.html. A AGUIA pode ser acessada de 3 maneiras
72
diferentes: acesso normal, acesso com 7 parâmetros e acesso com localização e
autenticação.
4.3.1 Acesso normal
Para usar a AGUIA com acesso normal vá para
http://aguia.googlecode.com/hg/index.html, Figura 4.20.
Figure 4.20– Tela inicial da AGUIA
É requerido ter um usuário e uma senha válida na base de dados S3DB em algum
domínio, para acessar esta aplicação. Caso não tenha um usuário e senha válidos em
qualquer domínio do S3DB, pode-se fazer o download no site http://www.s3db.org,
criar os projetos e em seguida acessar o S3DB localmente. Após o usuário ter se logado
na aplicação será necessário selecionar o projeto de dados e o projeto de regras gráficas.
O projeto de regras gráficas não precisa necessariamente estar no mesmo domínio que o
projeto dos dados, e por isso a aplicação permite que outro domínio seja selecionado,
Figura 4.21.
73
Figure 4.21 – Aplicação web solicitando os projetos
Após esta etapa será necessário selecionar a coleção será visualizada, Figura 4.22. O
usuário conseguirá visualizar a coleção escolhida juntamente com suas coleções
dependentes, de acordo com a hierarquia definida na ontologia de domínio, Figura 4.23.
Figure 4.22– Aplicação web solicitando a coleção
74
Figure 4.23 – Aplicação web gerada após a escolha do projeto de dados, de regras gráficas e da coleção
4.3.2 Acesso com sete parâmetros
O usuário pode acessar esta aplicação de maneira mais rápida, para isso basta colocar os
sete argumentos de entrada na url. Para montar a url com os sete argumentos deve-se
seguir os passos abaixo:
Primeiramente coloque a url http://aguia.googlecode.com/hg/index.html;
Coloque o símbolo “?” seguido de “URLData=” e coloque o primeiro argumento,
que deve fazer referência ao projeto de dados;
Coloque o símbolo “&” seguido de “keyData=” e coloque o segundo argumento,
que deve ser a key do usuário no projeto de dados;
Coloque o símbolo “&” seguido de “projectData=” e coloque o terceiro argumento,
que deve fazer referência ao número do projeto de dados;
Coloque o símbolo “&” seguido de “collectionData=” e coloque o quarto
argumento, que deve fazer referência a coleção que se quer representar;
Coloque o símbolo “&” seguido de “URLGUI=” e coloque o quinto argumento, que
deve fazer referência a url do projeto de regras gráficas;
75
Coloque o símbolo “&” seguido de “keyGUI=” e coloque o sexto argumento, que
deve ser a key do usuário no projeto de regras gráficas;
Por fim coloque “&” seguido de “projectGUI=” e coloque o sétimo argumento, que
deve fazer referência ao número do projeto de regras gráficas.
A Figura 4.24 ilustra um exemplo de url com os 7 argumentos.
Figure 4.24 – Exemplo de url com os 7 argumentos
4.3.3 Acesso com localização e autenticação
O usuário pode acessar a aplicação colocando apenas a localização e autenticação de
cada fonte de dados, ou seja, o usuário pode acessar a aplicação entrando com apenas
quatro argumentos. Siga os passos descritos abaixo para montar a url com estes quatro
parâmetros.
Primeiramente coloque a url http://aguia. googlecode.com/hg/index.html;
Primeira localização: Coloque o símbolo “?” seguido de “URLData=” e coloque a
url do projeto de dados. Após isso coloque o símbolo “|” seguido da letra “C” e
coloque o número da coleção que o usuário quer visualizar;
Primeira autenticação: Coloque o símbolo “&” seguido de “keyData=” e coloque a
chave do usuário no projeto de dados;
Segunda localização: Coloque o símbolo “?” seguido de “URLGUI=” e coloque a
url do projeto de regras gráficas. Após isso coloque o símbolo “|” seguido da letra
“P” e coloque o número do projeto de regras gráficas;
76
Segunda Autenticação: Coloque o símbolo “&” seguido de “keyGUI=” e coloque a
chave do usuário no projeto de regras gráficas.
A Figura 4.25 ilustra um exemplo de url com a localização e autenticação.
Figure 4.25 – Exemplo de url com a localização e autenticação
4.4 Considerações finais
Este capítulo apresentou o estudo de caso para o uso da AGUIA. O estudo de caso
envolve os dados fornecidos pelo departamento de câncer gastrointestinal do MD
Anderson Cancer Center. O capítulo mostrou que os dados fornecidos por este
departamento foram usados para se construir a ontologia de domínio e em seguida estes
foram importados para a base de dados.
A partir das necessidades observadas e das requisições deste departamento
foram instanciadas na base de dados as regras gráficas que seriam usadas pela AGUIA
para construir o layout mais adequado para este projeto. Este capítulo mostrou como
construir o projeto de regras gráficas na base de dados e ainda apresentou alguns
exemplos de como instanciar algumas regras gráficas.
No próximo capítulo serão apresentados os trabalhos similares à AGUIA e apresentará
uma comparação destes.
77
Capítulo 5
Trabalhos Relacionados
Os trabalhos relacionados à AGUIA são aqueles que têm o enfoque no desenvolvimento
e geração automática de interfaces do usuário. Foram analisadas algumas iniciativas e as
que são mais recentes e que mais se aproximaram da AGUIA foram o IIPS, WebML e
OntoWebber. As seções 5.1 a 5.3 detalharão cada uma destas iniciativas.
5.1 IIPS
IIPS [1] define um conjunto abrangente de ontologias para modelar a estrutura de
navegação, a estrutura de composição e as interfaces de usuário de web sites, e fornece
um conjunto de ferramentas de apoio à geração, manutenção e personalização de sites.
O framework do IIPS divide-o em 6 componentes principais:
A ontologia de domínio serve como uma estrutura subjacente para descrever o
conteúdo dos dados no site do destino. Ela descreve conceitos e relações no domínio
especificado. Conceitos e sua estrutura hierárquica podem guiar a concepção da
visualização do site e os relacionamentos são muitos úteis para conduzir a
navegação eficiente e recuperação da informação.
A ontologia do site descreve a estrutura de navegação e de composição, e as
interfaces de um web site. IIPS estende pré-abordagens existentes para a modelagem
de sites, em que os modelos de banco de dados não são modelos tradicionais, mas
também web sites. Ele define quatro classes de topo para modelar um web site geral:
78
site, recursos, componentes e layout, e faz uso de uma ontologia de interface para
descrever as principais entidades gráficas usadas em web sites.
O mapeador do site gera exibições predefinidas do site pelo mapeamento da
ontologia do site para uma ontologia de domínio para grupos de usuários pré-
definidos. IIPS predefine quatro grupos de usuários: os desenvolvedores,
webmasters, usuários avançados e usuários em geral. Cada grupo de usuários tem
uma visão local padrão. Vistas do site padrão contêm recursos restritos ao grupo de
usuário. Ela serve como base para os desenvolvedores editarem exibições site para
grupos de usuários ou utilizadores e, para os usuários personalizarem exibições site.
O editor do site oferece suporte a desenvolvedores e web masters editar a
visualização do site, modificar o conteúdo da página, criar páginas web, e estender a
ontologia do site. Os usuários finais também podem utilizá-lo para personalizar um
site para a sua necessidade individual de acordo com o seu direito de acesso
definidos por web masters.
O sistema de execução aceita as especificações declarativas do site como entrada e
gera páginas dinâmicas da web.
O mecanismo adaptativo pretende oferecer exibições do site adaptativo e interfaces
para usuários individuais.
IIPS tem por objetivo prover uma inteligente interface de apresentação e suporte para os
dados. Utiliza ontologias para guiar a geração e manutenção de sites e um conjunto de
ferramentas para mapeamento, edição, geração, personalização e customização de sites.
O IIPS faz uso de um conjunto de ferramentas para conseguir gerar o web site
automaticamente. A Figura 5.1 mostra duas destas ferramentas. Em A tem-se o editor de
ontologia e em B tem-se o mapeador do site. O editor de ontologia serve para definir e
editar a ontologia e o mapeador do site serve para mapear o site através da ontologia
79
definida. O usuário precisa saber usar as ferramentas para se conseguir um resultado
satisfatório na montagem do site, ou seja, o controle e a responsabilidade geração do
web site estão nas mãos do usuário e do uso que ele faz das ferramentas, isto torna o
IIPS bastante diferente da AGUIA, já que na AGUIA o gerador de site funciona como
uma “caixa preta” para o usuário. O usuário apenas precisa definir na ontologia quais
tipos de campos que ele terá e isto é totalmente suficiente para compor o layout da
aplicação web de acordo com a necessidade do usuário. Porém se o usuário não definir
os tipos de campos que ele terá a AGUIA é capaz de gerar um web site com campos
padrão.
Figura 5.1 – Ferramentas que o IIPS usa para conseguir gerar o web site. Em A tem-se o editor de ontologia e em B o mapeador do site [1].
5.2 WebML
WebML[44] é uma notação para a especificação de complexos web sites em nível
conceitual. WebML[1] provê modelos de sites explícitos suporta a automática geração
de sites. O desenvolvimento é interativo e composto de cinco partes (ou modelos) [44]:
80
Modelo estrutural: expressa o conteúdo de dados do site em termos de entidades
relevantes e relacionamentos, ou seja, o modelo estrutural serve para expressar
estrutura de domínio de dados.
Modelo de hipertexto: este modelo descreve um ou mais hipertextos que podem ser
publicados no site. Cada diferente hipertexto define uma chamada da visão do site e
por sua vez é composto por dois submodelos.
o Modelo de composição: este modelo quais páginas compõem o hipertexto e
qual conteúdo faz parte da página.
o Modelo de navegação: este modelo expressa como as páginas e os conteúdos
estão ligados para formar o hipertexto.
Modelo de apresentação: este modelo expressa o layout e a aparência gráfica das
páginas, independentemente do dispositivo de saída e da linguagem, por meio de
uma linguagem XML abstrata.
Modelo de personalização: neste modelo os usuários e grupos de usuários são
modelados explicitamente no esquema de estrutura em forma de entidades
predefinidas chamado de Usuário e Grupo. As características destas entidades
podem ser usadas para armazenar um grupo específico de conteúdos ou mesmo um
individual conteúdo, como sugestões de compras, lista de favoritos e recursos de
personalização gráfica.
Todos os conceitos de WebML[44] estão associados a uma notação gráfica e uma
sintaxe textual XML. Especificações WebML são independentes, tanto do lado cliente,
e da plataforma do servidor usado para vincular dados às páginas. WebML garante um
modelo orientado a abordagem de desenvolvimento de site, suporte a recursos
avançados como multi-dispositivo de acesso, personalização e gestão de evolução. A
linguagem WebML e seu projeto de acompanhamento para métodos de desenho são
81
totalmente implementadas em um pré-competitivo conjunto de ferramentas de design
Web, chamado ToriiSoft.
WebML [1] prevê um modelo de apresentação para expressar a disposição e aspecto
gráfico das páginas. No entanto, ele apenas diz respeito à aparência de páginas web. E
isto o difere bastante da AGUIA. Na AGUIA a interface do usuário é mais do que uma
apresentação dos recursos da página, pois se tem nesta aplicação um modelo e
linguagem semântica por traz da representação da informação.
5.3 OntoWebber
OntoWebber[28] reúne esforços de diferentes áreas como engenharia de software,
banco de dados e ontologias para construir um sistema coerente. A idéia fundamental
por trás OntoWebber é o uso de ontologias como base para a construção de diferentes
modelos necessários para a criação de um site.
A arquitetura do sistema OntoWebber é composta de 4 camadas[28]:
Camada de integração: A camada de integração resolve diferenças sintáticas entre
as diferentes fontes de dados distribuídas e heterogêneas. O ponto-chave para a
integração de informações é converter todos os tipos de dados em RDF usando a
ontologia de referência, e apenas realizar consultas localmente aos dados resultantes
armazenados no repositório central, sem ir às fontes de dados. O sistema suporta três
tipos de entrada de dados: RDF, UML/XML e HTML.
Camada de articulação: A camada de articulação resolve diferenças semânticas
entre as diferentes fontes de dados. Para poder utilizar os dados para a geração local
é preciso relacionar os dados de entrada para a ontologia de referência OntoWebber,
mesmo que estes estejam todos no formato RDF. Isto acontece porque os diferentes
provedores de dados podem utilizar vocabulários diferentes (ontologias) para anotar
82
seus dados. Sendo assim uma ontologia chamada ontologia de articulação ontologia
[28] preenche a lacuna semântica através da criação de regras de mapeamento entre
os conceitos e relacionamentos descritos em ontologias fonte para aqueles que a
ontologia de referência. Em seguida, os dados podem ser consultados com base na
ontologia de referência do sistema OntoWebber.
Camada de composição: Nesta camada, a ontologia de referência e os dados RDF
já estão disponíveis. As ontologias para a modelagem do site são um conjunto de
esquemas pré-definidos usando DAML + OIL, disponíveis também no repositório
central. Modelos de sites podem ser construídos utilizando componentes de software
fornecidos e que são materializados em DAML + OIL. Inicialmente, uma visão
padrão local é instanciada a partir de uma especificação de pré-visualizar o site. E
este é de acesso ao público em geral. Outras exibições do site podem ser criadas
para os usuários específicos ou grupo de usuários.
Camada de geração: Um site navegável pode ser gerado por instanciação da visão
do site com os dados no repositório. Isso é feito pelo mecanismo de consulta, que
consulta a especificação da visão do site para gerar a específica visão do site, ao
mesmo tempo, são realizadas consultas aos dados para produzir páginas da Web no
formato desejado.
A arquitetura do OntoWebber propõe um sistema baseado em ontologias para a criação
de web sites e portais. As Ontologias são utilizadas com o objetivo de proporcionar o
acesso aos dados subjacentes e orientar o processo de modelagem. Este sistema é
similar a AGUIA, olhando pelo ponto de vista que este usa a linguagem RDF para a
geração do site e que faz uso de ontologia para relacionar e mapear os dados. Porém o
OntoWebber não prevê mecanismos de mapeamento explícitos para mapear o modelo
de domínio com o site modelo para automatizar a geração site [1]. E neste ponto ele é
83
diferente da AGUIA, já que a AGUIA provê um módulo gráfico para mapear o layout
do site com o modelo de domínio, descrito na ontologia de domínio.
5.4 Considerações finais
Este capítulo apresentou os trabalhos desenvolvidos que são similares a AGUIA.
Foi feito um levantamento bibliográfico e a conclusão obtida a partir deste levantamento
é que existem poucos trabalhos desenvolvidos com o enfoque de gerar interfaces
automáticas a partir de ontologias e modelos orientados a metolodogia. Dentre estes
apenas três possuíam uma maior similaridade com a AGUIA, que são IIPS, WebML e
OntoWebber. Estes trabalhos foram apresentados e devidamente comparados a AGUIA.
E esta comparação resultou no destaque de algumas vantagens da AGUIA frente a eles:
AGUIA possui simplicidade no uso e a minimização de componentes
controlados pelo usuário, para eximir este do sucesso ou insucesso da geração
automática do web site;
AGUIA possui uma organização semântica dos dados usada na representação da
informação;
AGUIA provê um módulo gráfico mais explícito para mapear o layout do site
com o modelo do domínio.
O próximo capítulo apresenta a conclusão e as perspectivas futuras deste trabalho.
84
Capítulo 6
Conclusão e perspectivas futuras
6.1 Conclusão
Esta dissertação apresentou a AGUIA, uma aplicação web que é capaz de montar-se
automaticamente a partir de um módulo gráfico e uma ontologia de domínio. O modelo
gráfico e a ontologia de domínio foram construídas na base de dados semântica S3DB.
Esta base de dados gera documentos RDF em que os componentes ABox e TBox estão
distintos. A ontologia de domínio foi construída através dos dados clínicos obtidos em
colaboração com o Departamento de Gastrointestinal Medical Oncology do MD
Anderson Cancer Center, que forneceu aproximadamente 1 milhão de medições,
descrevendo um conjunto de 1369 pacientes. Estes dados são oriundos de ensaios
clínicos gastrointestinais. O módulo gráfico é composto pela parte gráfica da aplicação
web, que são triplas RDF. Cada tripla RDF representa um componente gráfico (GBox)
que pode ser criado na aplicação web.
Poucos trabalhos foram desenvolvidos com o mesmo enfoque da AGUIA. E
estes não conseguiram obter sucesso, do ponto de vista que nenhum dos modelos
desenvolvidos consegue captar/identificar problemas de interface com o usuário, tais
como layout e interfaces gráficas do usuário.
Desenvolver a AGUIA não foi uma tarefa trivial, já que a AGUIA não é uma aplicação
web comum e sim uma aplicação web “inteligente”, reusável e capaz de gerar layouts
diferentes de acordo com a necessidade de cada usuário. Para construir esta aplicação
85
foram utilizados algoritmos inteligentes e um modelo semântico para a construção da
ontologia de domínio e geração do RDF.
6.2 Perspectivas Futuras
A base de conhecimento na qual o RDF foi projetado não faz distinção entre os
componentes ABox e TBox, ou seja, não é capaz de distinguir entre o que é domínio do
que é instanciação sobre este domínio.
A aplicação web construída e apresentada nesta dissertação trabalhou com um RDF
produzido pela base de dados S3DB, em que a discriminação entre ABox e TBox é
contemplada.
O objetivo para os próximos trabalhos é permitir que a aplicação web aceite qualquer
documento RDF e faça a distinção entre os componentes ABox e TBox a partir deste.
Ao atingir com sucesso este objetivo, a aplicação web funcionará perfeitamente e
completamente para qualquer base de dados que gere documentos RDF.
86
Referências Bibliográficas
[1] LEI, Y, MOTTA, E, DOMINGUE, J, “IIPS: an intelligent information
presentation system”, Proceedings of the 7th international conference on
Intelligent user interfaces, San Francisco, California, USA, January 13-16, 2002.
[2] BREITMAN, K., Web Semântica: a Internet do Futuro. 1st, Rio de Janeiro,
LTC, 2005.
[3] GRUBER, T., “A translation approach to portable ontology specifications”,
Knowledge Acquisition, v. 5, n.2,pp. 199-220, 1993.
[4] FREITAS, F., SCHULS, S., Ontologias, Web semântica e saúde. RECIIS. Rio
de Janeiro, v.3, n.1, março 2009. Disponível em:
<http://www.reciis.cict.fiocruz.br/index.php/reciis/article/view/249/264>. Acesso
em: 15 dez. de 2009.
[5] MD ANDERSON CANCER CENTER, What are clinical trials?. Disponível
em: <http://www.mdanderson.org/patient-and-cancer-information/cancer-
information/clinical-trials/what-are-clinical-trials/index.html> Acesso em: 04
jan. 2010.
[6] BERNERS-LEE, T., …e ele criou a web. Veja. São Paulo, 2005, vida digital.
Disponível em:
<http://www.coppead.ufrj.br/alumni/informativo/docs/ele_criou_a_web.pdf>.
Acesso em: 31 de out. de 2009.
[7] BERNERS-LEE,T, HENDLER, J, LASSILA, O, “The Semantic Web. A new
form of Web content that is meaningful to computers will unleash a revolution of
new possibilities”, Scientific American, May 17, 2001.
[8] BERNERS-LEE,T., BECKETT, D. ,Turtle - Terse RDF Triple Language.
Disponível em:< http://www.w3.org/TeamSubmission/turtle/ > Acesso em: 07
dez. 2009.
[9] GUIZZARDI,G., Uma abordagem metodológica de desenvolvimento para e
com reuso, baseada em ontologia formais de domínio. Tese de M.Sc.,
UFES/ES, Vitória, ES, Brasil, 2000.
[10] GUIMARÃES, F., Utilização de ontologias no domínio B2C. Tese de M.Sc.,
PUC/RJ, Rio de Janeiro, RJ, Brasil, 2002.
[11] GUARINO, N., “Formal Ontology and Information Systems”, Proceedings of
FOIS’98, Trento, Italy, 6-8 June 1998. Amsterdam, IOS Press, pp. 3-15.
[12] USCHOLD, M. ,“Building Ontologies: Towards a Unified Methodology”,
Proceedings of Expert Systens ’96, Cambridge, UK 16-18 December 1996.
87
[13] NOY, F. N. , MCGUINNESS , D. L., “Ontology Development 101: A Guide to
Creating Your First Ontology”, Stanford Knowledge Systems Laboratory
Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report
SMI-2001-0880, March 2001.
[14] ALMEIDA, M., BAX, M., “Uma visão geral sobre ontologias: pesquisa sobre
definições, tipos, aplicações, métodos de avaliação e de construção”, Ciência da
Informação, Brasília, v.32, n.3, pp.7-20, 2003.
[15] BRICKLEY, D., GUHA,R., RDF Vocabulary Description Language 1.0: RDF
Schema. Disponível em: < http://www.w3.org/TR/rdf-schema > Acesso em: 01
dez. 2009.
[16] KLYNE,G.,CARROLL,J., Resource Description Framework (RDF):
Concepts and Abstract Syntax. Disponível em: < http://www.w3.org/TR/rdf-
concepts> Acesso em: 04 dez. 2009.
[17] CHAMPIN, P., RDF Tutorial. Disponível em: <http://www710.univ-
lyon1.fr/~champin/rdf-tutorial/rdf-tutorial.pdf> Acesso em: 04 dez. 2009.
[18] BERNERS-LEE,T., Notation N3. Disponível em:
<http://www.w3.org/DesignIssues/Notation3> Acesso em: 07 dez. 2009.
[19] SHOE. Simples HTML Ontology Extensions. Disponível em:
<http://www.cs.umd.edu/projects/plus/SHOE/> Acesso em: 10 jan. 2009.
[20] DAVIES, J., Fensel, D., Harmelen,F.,: Towards the Semantic Web: Ontology-
Driven Knowledge Management. 1st, England, Wiley, 2003.
[21] MCGUINNESS,D. ,DAML-ONT and OIL. Disponível em:
<http://www.daml.org/2000/10/daml-oil> Acesso em: 02 dez. 2009.
[22] DARPA. The DARPA Agent Markup Language. Disponível em:
<http://www.daml.org/>Acesso em: 10 jan. 2009.
[23] CONNOLLY,D.,HARMELEN,F., HORROCKS,I.,MCGUINNESS,D.,PATEL-
SCHNEIDER, P., STEIN,L., DAML+OIL (March 2001) Reference
Description. Disponível em: < http://www.w3.org/TR/2001/NOTE-daml+oil-
reference-20011218> Acesso em: 01 dez. 2009.
[24] MCGUINNESS , D., FIKES,R., STEIN, L.A., HENDLER ,J. A., “DAML-ONT:
An Ontology Language for the Semantic Web", Knowledge Systems, AI
Laboratory, Stanford University (KSL-01-08), 2001.
[25] CUNHA, L., Um Framework de Aplicações para a Web Semântica. Tese de
D.Sc., PUC/RJ, Rio de Janeiro, RJ, Brasil, 2006.
[26] MCGUINNESS , D., WELTY, C., SMITH, M., OWL Web Ontology
Language. Disponível em: < http://www.w3.org/TR/2004/REC-owl-guide-
20040210/> Acesso em: 02 dez. 2009.
88
[27] BAADER, F. et al.. The Description Logic Handbook: Theory,
Implementation
and Applications. Cambridge University Press, 2003. 574 p.
[28] JIN, Y., DECKER, S., WIEDERHOLD, G., “OntoWebber: Model-Driven
Ontology-Based Web Site Management”, Proceedings of SWWS'01, The first
Semantic Web Working Symposium, Stanford University, California, USA, July
30 - August 1, 2001.
[29] DHTML Introduction. Disponível em:
<http://www.w3schools.com/dhtml/dhtml_intro.asp> Acesso em: 23 dez. 2009.
[30] DOM. Document Object Model. Disponível em: < http://www.w3.org/DOM/>
Acesso em: 23 dez. 2009.
[31] DHTMLGOODIES: A library of DHTML and Ajax scripts. Disponível em:
<http://www.dhtmlgoodies.com/> Acesso em: 23 dez. 2009.
[32] GOOGLE CODE. Disponível em: <http://code.google.com> Acesso em: 23
dez. 2009.
[33] CAMPOS, M. L. A., Integração de Ontologias: o domínio da bioinformática.
RECIIS. Rio de Janeiro, v.1, n.1, jan.-jun 2007. Disponível em:
<http://www.reciis.cict.fiocruz.br/index.php/reciis/article/view/53/71>. Acesso
em: 15 dez. de 2009.
[34] ALMEIDA, J.S., CHEN, C., GORLITSKY, R., STANISLAUS, R., AIRES-DE-
SOUZA, M., ELEUTERIO, P., CARRICO, J., MARETZEK, A., BOHN, A.,
CHANG, A. et al, “Data integration gets „Sloppy‟”, Nature biotechnology, v. 24,
n.9, pp.1070-1071, 2006.
[35] DEUS, H. F., STANISLAUS, R., VEIGA, D.F., BEHRENS, C., WISTUBA,
I.I., et al.: “A Semantic Web Management Model for Integrative Biomedical
Informatics”. PLoS ONE 2008, 3(8): e2946. doi:10.1371/journal.pone.0002946.
[36] DEUS, H., STANISLAUS, R., ALMEIDA, J., S3QL: protocol for retrieving
experimental data annotated to RDF information systems. Bio-Ontologies
SIG at ISMB/ECCB 2007 Annual Conference, Vienna, Austria, 20 July, 2007.
[37] DEUS, H., Parallel Queries in S3QL. Disponível em:
<http://sites.google.com/a/s3db.org/s3db/parallel> Acesso em: 30 out. 2009.
[38] CLARK, C., FEIGENBAUM, L., TORRES, E., SPARQL Protocol for RDF.
Disponível em: <http://www.w3.org/TR/rdf-sparql-protocol/> Acesso em: 02
nov. 2009.
[39] COMPUTERWORLD. Web Semântica dá passo importante. Disponível em:
<http://www.computerworld.com.pt/content/view/4829/52/> Acesso em: 02 nov.
2009.
89
[40] PRICEWATERHOUSECOOPERS. Compondo um banco de dados Web.
Disponível em: < http://www.pwc.com/br/pt/estudos-pesquisas/technology-
forecast/compondo-banco-de-dados-web.jhtml> Acesso em: 02 nov. 2009.
[41] FEIGENBAUM, L., SPARQL Por Exemplo: Um Tutorial. Disponível em:
<http://www.cambridgesemantics.com/2008/09/sparql-by-example/#(1)> Acesso
em: 02 nov. 2009.
[42] MOTIC, B, “Combining Description Logics, Description Graphs, and Rules”,
Springer Berlin / Heidelberg, v. 5749, pp. 43-67, 2009.
[43] MD ANDERSON CANCER CENTER, Gastrointestinal Medical Oncology.
Disponível em: < http://www.mdanderson.org/education-and-
research/departments-programs-and-labs/departments-and-
divisions/gastrointestinal-medical-oncology/index.html> Acesso em: 16
ago.2009.
[44] CERI, S., FRATERNALI, P., BONGIO, A., “Web Modeling Language
(WebML): a modeling language for designing Web sites”, Elsevier North-
Holland, Inc. 2000, 33: 137-157.
90
APÊNDICE I – Artigo gerado pela dissertação
Os 4 revisores do artigo foram favoráveis a aceitação. O processo de correção final
do artigo para a publicação está em andamento.
[BMC Medical Informatics and Decision Making]
AGUIA - Autonomous Graphic User Interface Assembly - for clinical
trial semantic data services.
Miria Coelho Correa*
1,2
, Helena F Deus
1,3
, Ana Tereza R Vasconcelos
2,4
, Yuki Hayashi
5
,
Srikrishna V Patnana
6,7
,Jaffer A Ajani
5
, Jonas S Almeida
1
1
Department of Bioinformatics and Computational Biology, The University of Texas MD
Anderson Cancer Center, 1515 Holcombe Blvd, Houston, TX 77030, USA
2
Bioinformatics Laboratory, Laboratório Nacional de Computação Científica, Av Getúlio
Vargas, 333 Petrópolis, Rio de Janeiro, Brazil
3
Institute of Chemical and Biological Technology, Universidade Nova de Lisboa, Oeiras,
Portugal.
4
Instituto Nacional de Metrologia, INMETRO, Av. Nossa Senhora das Graças 50 - prédio 6,
25250-020, Xerém - Duque de Caxias, Rio de Janeiro - Brazil
5
Department of Gastrointestinal Medical Oncology, The University of Texas MD Anderson
Cancer Center, 1515 Holcombe Blvd, Houston, TX 77030, USA.
6
The University of Texas MD Anderson Cancer Center, 1515 Holcombe Blvd, Houston, TX
77030, USA
7
The University of Texas Medical School, 6431 Fannin St, Houston, TX 77030, USA.
Email addresses:
MCC: mcoelho@mdanderson.org
HFD: m[email protected]
91
ATRV: atrv@lncc.br
YH: hyuki@mdanderson.org
JAA: jajani@mdanderson.org
JSA: jalmeida@mdanderson.org
* Corresponding author
Abstract
Background
AGUIA is a web application front-end originally developed to manage clinical, demographic
and biomolecular patient data collected during gastrointestinal clinical trials at MD Anderson
Cancer Center. The diversity of methods involved in patient screening and sample processing,
brings in a substantial heterogeneity of data types. Thus, the corresponding data structure must
be based on a Resource Oriented Architecture that captures the associations between the
heterogeneous data elements in a semantic web format, most specifically in RDF (Resource
Description Framework).
Methods
The database chosen was S3DB, because it meets the necessary requirements of generating
RDF, of explicitly distinguishing the description of the domain from its instantiation , while
allowing for continuous editing of both. Furthermore, it uses a REST protocol, it is open source
and in the public domain, which facilitates development and dissemination. Although
comprehensive and flexible as much as a semantic web format can be, it does not by itself
address the issue of representing content in a form that makes sense for domain experts.
Results
The goal of the work described here was to identify an additional set of descriptors that provides
specifications for the graphic user interface. That goal was pursued by identifying a formalism
that makes use of the RDF schema to enable automatic assembly of graphic user interfaces in a
meaningful manner. A generalized RDF model was therefore defined such that changes in the
graphic descriptors are automatically and immediately reflected into the configuration of the
client web browser interface application. This model is the key achievement of the work
described in this report. Its pursuit was driven by the challenges of developing an integrative
data management infrastructure for a gastrointestinal cancer research database describing over
1,369 patients, characerized by a total of over 1 million RDF statements.
Conclusions
Although the design patterns identified reflect, and benefit, from the specific requirements of
interacting with data generated by clinical trials, they also contain clues for a general purpose
solution. In particular, it is suggested that the most useful patterns identified by the users of this
system are portable and are therefore susceptible of being reused in other data sources, namely
for other clinical trial semantic web data services.
92
Background
The goal of developing a protocol that autonomously assembles a graphic user interface for a
datasource has a tradition in web technologies which can be traced as far back as hypertext itself
in the use of HTML elements to manipulate the Web Browser's Document Object Model.
Similarly, the emergence of Semantic web technologies has not entirely overlooked the
assembly of user interfaces either. This is particularly clear in RDF elements such as rdfs:label,
rdfs:comment. Those elements anticipate the need for interface elements by other semantic
models and upon close scrutiny of the specifications, one finds that they are indeed widely used.
For example, in W3C‟s Simple Knowledge Organization Systems (SKOS, [1]), the definition of
the relationship skos:broader [1] comes with the indication that its rdfs:label is “has broader”.
In the work described here, instead of seeking to identify high level graphic relationships to
maximize reusability, the opposite route was taken. First a suite of graphic user interfaces was
developed in response to specific requests from clinical researchers, and only then was an effort
made to identify design patterns that could be captured as a specialized RDF protocol. The
justification for this reverse approach is that starting from a graphic configuration that was
already meaningful to a domain will lead to a set of descriptors that are more easily recognized
– and used – by those domain experts when they engage information management systems.
In spite of the domain-rooted approach followed at the beginning of this work, the clinical trial
driven interfaces also represent the starting point for a more generic formalism-oriented
approach towards goals originally proposed for Intelligent Information Presentation Systems
(IIPS) [2]. That early work found a natural extension in the emergence of eXtended Markup
Languages and subsequently in semantic web formalisms leading to efforts to model Web Site
interfaces such as, respectively, WebML [3] and OntoWebber [4]. However, as noted by other
authors Lei et al. [2], those models mostly ignore key user interface issues such as page layouts
and graphic user interfaces.
Methods
Browser-based application development
AGUIA was developed using DHTML (Dynamic HTML) concepts and technologies to create
dynamic and interactive web pages. Specifically, DHTML combines HTML, javascript, HTML
DOM and CSS [5]. The application delivered with this report makes extensive use of the
dhtmlgoodies library [6], which provides low level support for basic graphic features, such as
calendars, tabs, folder trees and others. This application is hosted with open source in the google
code management system [7] and it is made publicly available at
http://aguia.googlecode.com/hg/index.html. All code is made available in the corresponding
parent directory structure, with the open source project management tools available at the
domain name http://aguia.googlecode.com.
Semantic database web-service
The database web service chosen was S3DB because of its read/write REST S3QL protocol and
automatic generation of RDF [8] – in addition to being open source and publicly available for a
93
variety of operating systems. Additional, non-essential I/O, server-side functionality was
achieved developing small applications coded in the PHP language – for example to export the
application data to excel spreadsheets – as most browsers don‟t offer support ActiveX
technology natively. As noted in the previous section, all essential components of AGUIA are
native to the web browser – that is, they are coded in javascript.
Results
RDF protocol and List of graphic rules
The automatic assembly of the interface relies on two data sources, one being the target
observational data and the other containing the graphic rules to assemble the interface.
Specifically, the web application requires the definition of up to 7 input parameters, three of
which mandatory – one the location for each of the two web services and a third for an
authentication token. The other four parameters will narrow the definition of which data
elements the interface focuses and extend the range of data sources by allowing multiple
deployments and users to be used. The access parameterization is extensively detailed and
discussed in the documentation provided at the open source project hosting of AGUIA (see
Methods).
Both the data source and the graphic rules source are presently expected from be S3DB
databases, accessed using a REST protocol, S3QL (see Methods). As discussed later, this is
more of a reflection of the current lack of standards to write RDF documents than of a narrow
focus on the S3DB prototype. The s3db data acquisition effort described in this report was
pursued at Department of Gastrointestinal Medical Oncology of the University of Texas MD
Anderson Cancer Center. Specifically, over a period of one year clinical and biomedical
researchers in this department submitted to a S3DB deployment a variety of clinical and
biomolecular data totaling over 1 million independent S3DB “Statements”, presently describing
1369 patients. Figure 1 shows the ontology of this project as the graph of user-submitted S3DB
“Rules” [9].
94
Figure 1 – User defined Ontology of clinical trials data project at Department of Gastrointestinal Medical Oncology – MD Anderson Cancer
Center The user describes the ontology by defining “Rules”, which in turn are instantiated by “statements”. The oval node represents the
root of the ontology, the red nodes represent Rule elements that are Collections of Items and the green nodes represent Rule objects that take
literal values.
AGUIA can be pointed to the URI of any of the red nodes in Figure 1 (S3DB Collections) to
start the process of assembling the automated graphic user interface. The graphic rules come
from a second data source, which contrary to the first, comes from a project with a predefined
ontology. More specifically this second data source, for the graphic clues, is a distinct S3DB
web service that instantiates a fixed set of S3DB rules (Figure 2). The RDF model proposed
here was derived from those rules.
The graphic rules project (Figure 2, Table 1) is populated with statements that specify how to
assemble the web application. In other words, by submitting statements that instantiate those
rules, the user is configuring the graphic user interface as modular components. The graphic
model described in Figure 2 corresponds exactly to the set of S3DB rules linking two Object
collections – GUI rules and GUI actions – with, respectively, 5 and 9 literal values. These rules
(the 14 types of values) can be instantiated as many times as required, and in any way needed to
produce the desirable graphical appearance. As highlighted in the Introduction, the
identification of this model was pursued by decomposing a diversity of layouts requested by
clinical researchers such that any of the layouts requested can be automatically produced by
AGUIA from instantiations of this model. Therefore, the translation into RDF schema of the
relationships described by the 15 s3db rules represented in figure 2 is the essence of the
modeling work detailed in Table 1.
95
Figure 2 – Graphic Model as a set of 11 S3DB items (1-11) and a set of 5 S3DB rules (A-E). See Table 1 for a translation into RDF schema
by cross-tabulating the 5 GUI rules by the 11 GUI actions. The type of relationship, S3DB Item for the GUI Actions - GBox, S3DB Rules
and S3DB Collections – Tbox and S3DB value - Abox for the GUI rules identify the type of data that instantiates each of the 16 parameters
of the model.. The7
th
column in the table is a description of the graphic component controlled by each of the 11 GUI Actions.
Nº
Type of action
A
B
C
D
E
Domain
Trigger
Action
Range
Value
1
hasDate
1+ Rules
-
1 Item
-
-
RDF
AGUIA:hasDate rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Example
2
hasText
1+ Rules
-
1 Item
-
-
RDF
AGUIA: hasText rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Example
3
hasTextArea
1+ Rules
-
1 Item
-
-
RDF
AGUIA: hasTextArea rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
96
Example
4
hasConditions
1+ Rules
1+ Values
1 Item
1 Rules
1 Value
RDF
AGUIA: hasConditions rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
aguia:value s3db:Value;
aguia:trigger s3db:Value;
rdf:type s3db:Item.
Example
5
hasFormula
1 Rules
-
1 Item
1 Rule
-
RDF
AGUIA: hasFormula rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Example
6
hasRestrictionsActiveFields
1 Rule
1+ Values
1 Item
1+ Rules
-
RDF
AGUIA:hasRestrictionsActiveFields rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
aguia:trigger s3db:Value;
rdf:type s3db:Item.
Example
7
hasOptions
1+ Rules
-
1 Item
-
1+
Values
RDF
AGUIA: hasOptions rdfs:domain s3db:Rule;
aguia:action s3db:Item;
aguia:value s3db:Value;
rdf:type s3db:Item.
Example
97
8
hasMoreFields
1+ Collections
-
1 Item
-
-
RDF
AGUIA: hasMoreFields rdfs:domain s3db:Collection;
aguia:action s3db:Item;
rdf:type s3db:Item.
Example
9
hasFieldInactive
1+ Rules
-
1 Item
-
-
RDF
AGUIA: hasFieldInactive rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Example
10
hasConcatenation
1+ Rules
-
1 Item
1 Rules
-
RDF
AGUIA: hasConcatenation rdfs:range s3db:Rule;
rdfs:domain s3db:Rule;
aguia:action s3db:Item;
rdf:type s3db:Item.
Example
11
hasSubCollections
1 Collection
-
1 Item
1+
Collectio
ns
-
RDF
AGUIA: hasSubCollections rdfs:domain s3db:Collection;
aguia:action s3db:Item;
rdfs:range s3db: Collection;
rdf:type s3db:Item.
Example
Table 1 – Detail of the 11x 5 relationships needed to configure automated assembly of the Graphic User Interface by the browser-based
(pure javascript) AGUIA application. Each row corresponds to the 11 GUI actions, instantiated by S3DB items, tabulated against 5 GUI
Rules (columns), instantiated by S3DB rules. Note that S3DB is being used as a user-editable representation which is translated into
98
standard RDF in this table. The useful feature of S3DB as a tool, in addition to the user-editing tools, is that the distinction between domain
and instantiation is always explicit [10].
JavaScript Application
A javascript application was developed to autonomously assemble the graphic user interface
using the graphic annotation clues provided by the GUI rules and actions (Figure 2, Table 1).
This means that any project based on S3DB can be automatically accessed through the graphical
user interface assembled by this web application (Figure 3). Note that the absence of any
graphical annotation won't prevent the application from assembling the graphic interface
automatically. The sole difference is that its structure will be based only on the structure of the
relationships between the data elements. Therefore, the graphic annotations provided through
GUI rules and actions can also be thought of as a way of further directing the GUI assembly
process.
Figure 3 depicts a snapshot of AGUIA when it is pointed to the gastric oncology clinical trial
research database at MDAnderson Cancer Center. By comparing this figure with the ontology of
the data store (Figure 1) it is apparent that a substantial number of GUI rules and GUI actions
must be in use for this clinical data service. The list of S3DB rules (RDF describing the clinical
domain) and the list of GUI actions and rules that modulates the assembly of the graphic user
interface are provided as supplementary material , as part of the documentation of AGUIA at the
open source repository (see Methods). An exhaustive discussion of how each GUI action is
interpreted by AGUIA, and examples of its use taken from the gastric oncology case study are
also provided as supplementary material at the same URL.
Figure 3 – Snapshot of the logon screen when AGUIA is pointed to GI Clinical trials S3DB web service, followed by the start page
assembled by AGUIA when configured to target resource “Patient ID”. Selecting another resource, say “Tissue” will produce the exact
same graphic interface as if the initial target had been that resource: the operation of AGUIA is fully based on Representation State Transfer
(REST) calls.
The relevance of the fact that the interfaces illustrated in Figure 3 are assembled in response to
REST calls is that the navigation of the interface itself is a succession of REST calls. For
exemple, the opening page was triggered by the following URL being sent to the web browser:
http://aguia.googlecode.com/hg/index.html?URLDATA=http://some_url/clinicaltrials|C12
99
07734&KEYDATA=xxxxxxx&URLGUI=http://some_url/clinicaltrials|P1588674&KEYG
UI=xxxxxxx
Starting with the domain URL, note that it targets the project hosting document directly,
illustrating the additional feature of javascript applications that by being native to the web
browser this removes the distinction between code hosting and application hosting – they are the
same. This parameterization of the call contains two locations and two authentications. For
security reasons the actual URL and the access keys were replaced with “some_url” and
“xxxxxx”. The first location contains the url of data plus C1207734 that indicates the unique
identifier of resource “PatientID” and the second location contains the url of graphic rules plus
P1588674 which indicates the instantiation of GUI action and rules used for the autonomous
assembly. Note also that the authentication tokens, KeyDATA and KeyGUI, can be distinct,
reflecting the possibility of different users seeing, and configuring, entirely distinct graphic
interfaces for the same data.
Discussion
The knowledge base [11 defined by RDF does not, per se, make distinctions between Assertions
(ABox) and Terminology (TBox) components. In other words, RDF does not by itself
differentiate between what is domain and what is instantiation on a knowledge. This is one of
the two reasons why we resorted to S3DB as a mediator in the creation and management of
RDF. The distinction between TBox and ABox triples corresponds, respectively, to S3DB rules
and S3DB statements [9, 10]. The other reason for resorting to this data service application for
the study described here is the convenience of its REST API, which bodes well with the intent
to produce an application that is native to the web-browser environment and therefore, can be
easily used by a wide variety of domain experts in a number of computational environments.
The AGUIA web application described in this report works with RDF produced by the S3DB
web service. Furthermore, the AGUIA graphic model, composed of combinations of GUI
actions and GUI rules (Figure 2), is itself described by the RDF schema (Table 1). Therefore,
the only fundamental barrier to its applications in the much wider RDF world in general is the
identification of procedures that automatically annotate knowledge bases represented in that
format to recognize its Terminology and Assertion components. It could be argued that RDF
representations are inherently assertive [12] which poses a fundamental obstacle to its use for
elaboration in terminology. However, it is also clear that the view of Semantic Web as a “web
of linked data” [13] is particularly conducive to the universal aggregation required by the
systems nature of both Biological processes and Biomedical infrastructure. Our experience both
with the GI clinical trials initiative described here and earlier work with Lung Cancer research
data [Deus 2008] is that the accumulation of diverse data sources renders the the emergence of
comprehensive terminology all but irresistible.
It is therefore the expectation of the authors that in a domain as fluid as the Life Sciences in
general and molecular biology in particular that process will have to include an iterative tool
where domain experts experiment with the annotation while inspecting a self-assembled graphic
user interface. If that direction is to be taken then the graphic model described here could be
conceived as an integral component of the knowledge base – a GBox [14]. Such a three
component paradigm would argue that the distinction between terminology and assertion will
100
both have an effect and be a function of graphic presentation. It would also follow that because
different domain experts request different graphic representations (GBox) of the knowledge
base they are indirectly stating that they correspondingly place the boundaries between ABox
and TBox differently.
Conclusions
This paper describes a web application that automatically assembles user interfaces for
databases able to generate RDF documents that distinguish between ABox and TBox
components. The tools used anticipate the maturation of technologies that are either very recent
or are still at an incipient stage of development. An example of the former is the strict use of
javascript to develop the application such that it entirely resides on the web-browser. This
anticipates the trend towards using server-side components of computational environments as a
representation omnibus. An example of the latter is the use of W3C‟s Resource Description
Framework (RDF) as read/write representation media. Currently, the W3C query language for
RDF (SPARQL) only specifies the read operation format. In anticipation of the write
component being similarly standardized in the future we have used a research prototype, S3DB,
which allows both read and write operations on RDF-like representations.
By developing the autonomously assembled interface applications in response to specific
requests from a multiplicity of user-domains-platforms involved in gastrointestinal clinical trials
a number of conclusions became apparent. As regards the identification of user-friendly /
domain-aware interfaces, it appears that it is more effective to develop graphic annotations
before settling for a rigid distinction between Assertion and Terminology, in contrast to the
more conventional approach to ontology modeling. As regards the challenge of deploying the
applications themselves, it became apparent that modularizing the interface assembly using
REST protocols is particularly effective, because it does not require a distinction between
Universal Resource Identifiers (URI) that target data elements from those that configure the
assembly of the graphic user interface. In conclusion, the long standing Artificial Intelligence
(AI) challenge of context aware interfacing appears to benefit from the same RDF-based
collaborative annotation behind The Web of Linked Data. The same data-driven user annotation
of graphic rules (Gbox) was observed to benefits the automation of the graphic interfaces used
to interact with those same data elements.
List of abbreviations used
AGUIA: Autonomous Graphic User Interface Assembly; RDF: Resource Description
Framework; S3DB: Simple Sloppy Semantic Database; HTML: HyperText Markup Language;
DHTML: Dynamic HyperText Markup Language; DOM: Document Object Model; CSS:
Cascading Sytle Sheets; PHP: Hypertext PreProcessor; REST: Representational State Transfer;
S3QL: Simple Sloppy Semantic Query Language ; URI: Universal Resource Identifiers; GUI:
Graphical User Interface; TBox: Terminological Component; Abox: Assertion Component;
API: Application Programming Interface; GBox: Graphic Component.
Competing interests
The authors declare that they have no competing interests.
101
Authors' contributions
MCC participated in the design, developed the application, identified the data model,
and drafted the manuscript; HFD participated in the modeling the database; HFD
assisted with the S3DB web service; YA, SVP and JAA provided clinical data and
domain expertise; ATRV and JSA supervised the project and improved the manuscript.
All authors read and approved the final manuscript.
Acknowledgements
MCC acknowledges support by the CAPES Foundation (Brazil) award CAPES/LNCC
31036015. This work was also in part supported by the Center for Clinical and Translational
Sciences under contract 1UL1RR024148 from NIH (CTSA). ATRV thanks CNPq, CAPES
and FAPERJ for financial support.
References
1. SKOS Simple Knowledge Organization System Reference
[http://www.w3.org/TR/2009/REC-skos-reference-20090818/]
2. Lei Yuangui , Motta Enrico , Domingue John: IIPS: an intelligent information
presentation system. Proceedings of the 7th international conference on Intelligent
user interfaces: 13-16 January 2002.
3. Ceri Stefano, Fraternali Piero, Bongio Aldo: Web Modeling Language (WebML): a
modeling language for designing Web sites. Elsevier North-Holland, Inc. 2000, 33:
137-157.
4. Jin Yuhui, Decker Stefan, Wiederhold Gio: OntoWebber: Model-Driven Ontology-
Based Web Site Management. Proceedings of SWWS'01, The first Semantic Web
Working Symposium: July 30 - August 1, 2001.
5. DHTML Introduction [http://www.w3schools.com/dhtml/dhtml_intro.asp]
6. DHTMLGOODIES: A library of DHTML and Ajax scripts
[http://www.dhtmlgoodies.com/]
102
7. Google code [http://code.google.com]
8. S3DB [http://s3db.org]
9. Deus HF, Stanislaus R, Veiga DF, Behrens C, Wistuba II, et al.: A Semantic Web
Management Model for Integrative Biomedical Informatics. PLoS ONE 2008, 3(8):
e2946. doi:10.1371/journal.pone.0002946.
10. Wang X, Gorlitsky R, Almeida JS: From XML to RDF: how semantic web
technologies will change the design of „omic‟ standards. Nature biotechnology 2005,
23(9):1099-1103.
11. Donini FM, Lenzerini M, Nardi D, Schaerf A: Reasoning in description logics. Center
for the Study of Language and Information 1997, 191-236.
12. Semantic Web Road map [http://www.w3.org/DesignIssues/Semantic.html]
13. Semantic Web Road map [http://www.w3.org/DesignIssues/Semantic.html]Linked
Data- Design Issues [http://www.w3.org/DesignIssues/LinkedData.html]
14. MOTIC, B: Combining Description Logics, Description Graphs, and Rules,
Springer Berlin / Heidelberg 2009, 5749: 43-67.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo