“VisualSPEED:Uma Interface de Interação com o Usuário
para PDMS Baseado em Ontologias”
Por
Andrêza Leite de Alencar
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Andrêza Leite de Alencar
“VisualSPEED:Uma Interface de Interação com o
Usuário para PDMS Baseado em Ontologias”
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Ana Carolina Brandão Salgado
A Deus, que sempre me guiou nessa jornada, A minha Mãe, Querubina, A minha irmã, Andréa.
Agradecimentos
Agradeço...
• À minha família, por ter acreditado no meu sonho e por ter me dado todo o apoio nessa conquista;
• À minha orientadora Ana Carolina Salgado, pela sua confiança e orientação sempre rica de boas idéias e conselhos pertinentes;
• Aos membros do projeto SPEED, por terem criado um excelente ambiente de trabalho, de aprendizado e de companheirismo;
• Aos docentes do Centro de Informática da UFPE, pelos ensinamentos e auxílio durante os anos de mestrado;
• Ao meu namorado Julio, por todos os cuidados, força, suporte e, acima de tudo, pela sua amizade e compreensão nos momentos mais difíceis dessa jornada; • Aos meus amigos e companheiros de mestrado, em especial Talitha Huanna,
Jo-sino Rodrigues, Wilton Oliveira, Carlos Portela e Bruno Leonardo, pelo apoio e motivação nos momentos que mais precisei.
• Aos amigos paraenses, que me receberam de braços abertos e sempre me fizeram sentir o "gostinho de casa"presente na vida em Recife;
• Aos amigos distantes que, de alguma forma, sempre estiveram torcendo por mim; • À vida, que me deu mais esta oportunidade de aprender e crescer;
• A todos os amigos que direta ou indiretamente contribuíram para realização deste sonho.
I open my eyes each morning I rise, to find a true thought, know that it’s real, I’m lucky to breathe, I’m lucky to feel, I’m glad to wake up, I’m glad to be here, with all of this world, and all of it’s pain, all of it’s lies, and all of it’s flipped down, I still feel a sense of freedom, so glad I’m around, It’s my freedom, can’t take it from me, i know it, it won’t change, but we need some understanding, I know we’ll be all right. —S.O.JA. (Open My Eyes)
Resumo
A problemática da interação do usuário para a formulação e execução de consultas vem sendo investigada para ambientes distribuídos e dinâmicos, tais como Peer Data Management System(PDMS). Estes ambientes possuem características como o fato de serem altamente dinâmicos em uma infraestrutura de pontos distribuídos, heterogêneos e autônomos. Muitos destes PDMS baseados em semântica são compostos por pontos de dados cujos esquemas exportados são representados por ontologias. Alguns destes PDMS já propuseram interfaces para interação com o usuário, mas nenhuma das abordagens atende, de forma geral, as necessidades de um PDMS no que diz respeito à interação com o usuário.
Neste sentido, definimos uma interface visual para PDMS que proporciona ao usuá-rio uma interação simples e objetiva com este tipo de sistema. A VisualSPEED foi desenvolvida e validada no ambiente de um PDMS baseado em ontologias chamado SPEED (Semantic PEEr-to-Peer Data Management System). Esta interface apresenta as ontologias graficamente e em hierarquia de conceitos, permitindo a formulação de consultas por meio da manipulação desta visualização da ontologia, selecionando os conceitos desejados para a consulta e combinando-os com operadores da Description Logic(DL).Uma outra opção para submissão de consultas é o uso de templates SPARQL (SPARQL Protocol and RDF Query Language), onde o usuário deve apenas inserir os conceitos desejados para a consulta. Ainda para a execução de consultas, é possível melhorar os resultados obtidos enriquecendo a consulta submetida, com o uso de va-riáveis que representam relacionamentos entre os conceitos da consulta (aproximação, subconceito, superconceito e agregação). Além da formulação e submissão de consultas, a interface possibilita uma visualização organizada dos resultados com informações sobre as correspondências semânticas que os geraram e os pontos de origem identificados em uma topologia gráfica da rede.
A VisualSPEED foi especificada, seguindo técnicas de análise e prototipação, e implementada. Para a avaliação da interface, foram realizados experimentos com dois tipos de usuário (especialista e não especialista) e verificação de conformidade com os critérios de usabilidade. Analisados os resultados obtidos das avaliações, concluímos que a VisualSPEED é uma interface visual que apresenta as funcionalidades e transparência necessárias para interação do usuário com um PDMS.
Palavras-chave: Interface, Interação com o Usuário, Ontologia, Ambientes Distribuídos e Autônomos, PDMS.
Abstract
The issue of user interaction for query formulation and execution has been investigated for distributed and dynamic environments, such as Peer Data Management System (PDMS). These environments have characteristics such that they are highly dynamic in a infras-tructure of distributed, heterogeneous and autonomous peers. Many of these semantics based PDMS are composed of data peers whose exported schemes are represented by ontologies. There are some approachs that have already proposed PDMS interfaces, but none of them addresses the PDMS needs for user interaction.
In this sense, we defined a visual interface for PDMS which provides the user a simple and straightforward interaction. The VisualSPEED was developed and validated in the environment of a PDMS, ontology based, called SPEED (Semantic PEEr-to-Peer Data Management System). This interface presents ontologies graphically as a graph and as a hierarchy of concepts, providing a visual query formulation by ontology manipulation, selecting the concepts and combining them with Description Logic (DL) operators. Another option to submit queries is using SPARQL (SPARQL Protocol and RDF Query Language) templates, inserting just the concepts to be queried. Even for running queries, is possible to improve the results enriching the submitted query, by using variables that represent relationships between query concepts (approach, subconcept, superconcept and aggregation). In addition to query formulation and submission, the interface allows an organized results view with information about the semantic correspondences that generated them, and the results origin peer identified graphically in a network topology. The VisualSPEED was specified, using analysis and prototyping techniques, and implemented. For interface assessment, experiments were performed with two user types (experts and non-experts) and compliance verification with usability criteria as well. Analyzed the evaluations results, we concluded that VisualSPEED is a visual interface that provides the functionality and transparency necessary for user interaction with a PDMS.
Keywords: Interface, User Interaction, Ontology, Autonomous and Distributed Environ-ments, PDMS
Sumário
Lista de Figuras xi
Lista de Quadros xiii
Lista de Siglas xiv
1 Introdução 1 1.1 Motivação . . . 1 1.2 Justificativa . . . 2 1.3 Objetivos . . . 4 1.3.1 Objetivos Específicos . . . 4 1.4 Organização da Dissertação . . . 4 2 Conceitos Básicos 6 2.1 Interfaces Visuais . . . 6 2.1.1 Interação Humano-Computador . . . 7 2.1.2 Projeto de Interface . . . 8 2.2 Peer-to-Peer(P2P) . . . 12 2.2.1 Topologia P2P Pura . . . 13 2.2.2 Topologia P2P Híbrida . . . 14 2.2.3 Topologia P2P Super-Peer . . . 15
2.3 Peer Data Managemen System(PDMS) . . . 16
2.4 Ontologia . . . 18
2.4.1 Resource Description Framework(RDF) . . . 19
2.4.2 Web Ontology Language(OWL) . . . 19
2.5 Lógica Descritiva (DL) . . . 20
2.6 SPARQL Protocol and RDF Query Language . . . 21
2.7 Considerações . . . 22
3 Interfaces e PDMS 23 3.1 Interfaces Baseadas em Ontologia . . . 23
3.1.1 Formulação de Consultas . . . 23
3.1.2 Interação do Usuário . . . 24
3.2 Interfaces de Peer Data Management Systems - PDMS . . . 25
3.2.2 Interfaces de Consulta Baseada em Múltiplas Visões . . . 30
3.2.3 Interface Baseada no Roteamento de Consultas . . . 32
3.2.4 Resumo Comparativo das Abordagens Apresentadas . . . 33
3.3 O sistema Semantic PEEr-to-Peer Data Management System (SPEED) . 35 3.3.1 Arquitetura do Sistema SPEED . . . 35
3.3.2 Geração de Correspondências Semânticas entre Esquemas . . . 37
3.3.3 Conexão de um Novo Ponto . . . 41
3.3.4 Processamento de Consultas . . . 42
3.3.5 Reformulação de Consultas no SPEED . . . 42
3.4 Considerações . . . 45
4 VisualSPEED: Uma Interface de Interação com o Usuário para PDMS Ba-seado em Ontologias 46 4.1 Arquitetura da VisualSPEED . . . 46 4.1.1 Módulo ViewOntology . . . 48 4.1.2 Módulo FormQuery . . . 48 4.1.3 Módulo ViewResults . . . 49 4.1.4 Módulo ViewNetwork . . . 50 4.1.5 Módulo QueryManager . . . 51 4.1.6 Módulo CommunicationManager . . . 51
4.2 Requisitos Estabelecidos para a Interface VisualSPEED . . . 51
4.3 Prototipação da Interface VisualSPEED . . . 55
4.4 Considerações . . . 61
5 Implementação e Estudo de Caso 63 5.1 Implementação da Interface VisualSPEED . . . 63
5.1.1 Submissão de Consultas . . . 64
5.1.2 Visualização de Resultados . . . 66
5.1.3 Visualização da Topologia da Rede . . . 67
5.1.4 Documentação da Interface . . . 69
5.2 Estudo de Caso . . . 69
5.3 Processamento de uma Consulta . . . 71
5.4 Visualização dos Resultados da Consulta . . . 73
5.5 Avaliação da Interface VisualSPEED . . . 74
5.5.1 Avaliação da Usabilidade e Relevância das Funcionalidades . . 74 5.5.2 Avaliação da Usabilidade e Qualidade Ergonômica da Interface 77
5.6 Considerações . . . 82 6 Conclusões e Trabalhos Futuros 83 6.1 Contribuições . . . 84 6.2 Trabalhos Futuros . . . 84
Referências 87
Apêndices 93
A Protótipos de Alta Fidelidade da Interface VisualSPEED 94 B Telas Implementadas da VisualSPEED 97 C Questionário para Avaliação das Funcionalidades da Interface VisualSPEED 98 D Respostas do Questionário de Avaliação das Funcionalidades da
Lista de Figuras
2.1 Processo de Projeto de Interação. Adaptado de (Dix et al., 2003) . . . . 10
2.2 Topologia P2P Pura. (Fiorano, 2011) . . . 13
2.3 Topologia P2P Híbrida. (Fiorano, 2011) . . . 14
2.4 Topologia P2P Super-Peer. (Fiorano, 2011) . . . 15
2.5 Exemplo de Consulta SPARQL Protocol and RDF Query Language (SPARQL). . . 22
3.1 Protótipo da interface de consulta da Query Tool (Franconi et al., 2010) 26 3.2 Navegando para criação de um padrão de consulta do GRQL (Athanasis et al., 2004) . . . 27
3.3 Interface de consulta do SEWASIE (SEWASIE, 2011) . . . 29
3.4 Interface de consulta do Ontogator (Hyvonen and Viljanen, 2003) . . . 30
3.5 Interface de consulta do sistema OntoViews (Makela et al., 2004) . . . . 31
3.6 Interface gráfica do SUNRISE (Mandreoli et al., 2007) . . . 32
3.7 Arquitetura do sistema SPEED (Pires, 2009) . . . 37
3.8 Utilizando uma Ontologias de Domínio (OD) para especificar as Corres-pondências Semânticas (Souza, 2009) . . . 39
3.9 Ontologia de Domínio (Souza, 2009) . . . 40
3.10 Ontologias Comparáveis (Souza, 2009) . . . 40
3.11 Descoberta de clusters semânticos através de comparação ontológica (Pires, 2009) . . . 41
3.12 Cenário das consultas no SPEED(Souza, 2009) . . . 44
4.1 Arquitetura do sistema destacando as camadas e módulos que irão operar nas atividades de interação do usuário com o sistema SPEED . . . 47
4.2 Funcionamento do Módulo ViewOntology . . . 49
4.3 Funcionamento do Módulo FormQuery . . . 49
4.4 Funcionamento do Módulo ViewResults . . . 50
4.5 Funcionamento do Módulo ViewNetwork . . . 51
4.6 Diagrama de casos de uso do sistema SPEED . . . 54
4.7 Protótipo da tela de consulta com visualização gráfica de uma ontologia 56 4.8 Protótipo da tela de consulta com visualização hierárquica de uma ontologia 57 4.9 Protótipo da tela para submissão de consulta SPARQL . . . 58
4.11 Tela de cadastro de um novo ponto . . . 61
5.1 Tela para princípio da submissão de consultas por usuário Usuário Não Participante da Rede (UN) . . . 64
5.2 Tela de consulta com visualização gráfica de uma ontologia . . . 65
5.3 Tela de consulta com visualização hierárquica de uma ontologia . . . . 66
5.4 Tela para submissão de consultas SPARQL . . . 67
5.5 Tela de visualização das correspondências semânticas e feedback . . . . 67
5.6 Tela de visualização dos pontos de origem de um resultado . . . 68
5.7 Tela para visualização gráfica da topologia rede . . . 68
5.8 Tela para visualização do Javadoc da interface . . . 69
5.9 Ontologia O1= LOEdu.owl do ponto de dados PD 2378 . . . 70
5.10 Processamento de uma consulta no sistema SPEED . . . 71
5.11 Resultado das consultas sem uso de variáveis de enriquecimento . . . . 73
5.12 Resultado das consultas enriquecidas . . . 73
5.13 Informações semânticas para o resultado da consulta não enriquecida . . 74
5.14 Informações semânticas para o resultado da consulta enriquecida . . . . 74
5.15 Gráfico com percentuais de avaliação das funcionalidades por usuários especialistas . . . 76
5.16 Gráfico com percentuais de avaliação das funcionalidades por usuários não especialistas . . . 76
5.17 Gráfico com percentuais individuais de adequação aos critérios de usabi-lidade do ErgoList . . . 80
5.18 Gráfico de adequação geral da interface desenvolvida à avaliação do ErgoList . . . 81
A.1 Protótipo da tela principal do sistema SPEED . . . 94
A.2 Protótipo da tela de documentação do sistema SPEED . . . 95
A.3 Protótipo de tela para o princípio da submissão de consultas por usuário UN 95 A.4 Protótipo para visualização das correspondências semânticas que geraram os resultados e feedback . . . 96
A.5 Protótipo da tela de visualização da topologia da rede por usuário UP . . 96
B.1 Tela de cadastro de um novo ponto . . . 97
C.1 Questionário de Avaliação do Usuário(Página 1) . . . 99
Lista de Quadros
2.1 Comparação entre as topologias P2P. Adaptado de (Fiorano, 2011) . . . 16 3.1 Quadro resumo das abordagens apresentadas . . . 34 4.1 Quadro de contribuição da VisualSPEED em relação as abordagens
exis-tentes . . . 62 D.1 Totais de Respostas Obtidas por Usuários Não Especialistas . . . 102 D.2 Totais de Respostas Obtidas por Usuários Especialistas . . . 102
Lista de Siglas
ALC Attribute Language with Complement API Application Programming Interface BA Brokering Agents
DHT Distributed Hash Table DL Description Logic
DAWG RDF Data Access Working Group GUI Graphical User Interface
GRQL Graphical RQL GVV Global Virtual View
IHC Interação Humano Computador IDE Integrated Development Environment NLG Natural Language Generation OWL Web Ontology Language QA Query Agents
QueLo Query Logic
OD Ontologias de Domínio OWL Web Ontology Language
OPDMS Ontology-based Peer Data Management System PDMS Peer Data Management System
P2P Peer-to-Peer
RDF Resource Description Framework RF Requisitos Funcionais
RQL RDF Query Language
RDQL RDF Data Query Language
SEWASIE SEmantic Web and AgentS in Integrated Economies SINode Information Node
SPEED Semantic PEEr-to-Peer Data Management System SPARQL SPARQL Protocol and RDF Query Language SQL Structured Query Language
SRI Semantic Routing Index
SeRQL Sesame RDF Query Language SWT Standard Widget Toolkit
UA User Agent
UFPE Universidade Federal de Pernambuco UI User Interface
UML Unified Modeling Language UP Usuário Participante da Rede UN Usuário Não Participante da Rede URI Uniform Resource Identifier VQS Visual Query System VQL Visual Query Language
WIMP Windows, Icons, Menus e Pointers WYSIWYG What you see is what you get W3C World Wide Web Consortium
1
Introdução
Neste capítulo, será feita uma breve introdução dos aspectos que motivaram e caracteriza-ram este trabalho. Também serão apresentados os objetivos desta pesquisa, assim como a estrutura desta dissertação.
1.1
Motivação
Recentemente, a problemática envolvendo a formulação e execução de consultas vem sendo investigada em diferentes tipos de ambientes, tais como Sistemas de Integração de Dados (Halevy et al., 2006), PDMS (Blanco et al., 2006) e na Web Semântica (Berners-Lee et al., 2001). Estes ambientes, apesar de algumas diferenças, possuem características comuns como o fato de serem altamente dinâmicos em uma infraestrutura de pontos distribuídos, heterogêneos e autônomos. Para facilitar a integração, muitos destes sistemas representam seus esquemas de dados através de ontologias.
Sistemas distribuídos e dinâmicos dispõem de vários meios para que seus usuários possam formular suas consultas. Uns disponibilizam algum tipo de linguagem de consulta, como Structured Query Language (SQL) (SQLOrg, 2012) ou SPARQL (Prud’hommeaux and Seaborne, 2008), enquanto outros fazem uso de interfaces de formulários, Web ou visuais, que tornam a interação um pouco mais amigável (Blanco et al., 2006). Algumas dessas interfaces utilizam modelos de categorias ou mesmo ontologias representando também o domínio de interesse (Hoang and Tjoa, 2006). Contudo, em geral, essas abordagens não trazem grandes benefícios para os usuários, nem permitem a transparência necessária às diversas estruturas presentes nas fontes de dados. Isso faz com que os usuários, muitas vezes, tenham de entender os detalhes sobre a estrutura do ambiente e seus mecanismos de gerenciamento para conseguirem formular as consultas.
con-1.2. JUSTIFICATIVA
sulta comumente encontradas em tais ambientes:
• Os vários níveis de usuários existentes – leigos, semi-leigos ou especialistas – possuem especificidades inerentes aos seus objetivos e conhecimento técnico ou do domínio;
• As linguagens de consulta existentes não são consideradas fáceis de usar, obrigando o usuário a conhecer detalhes técnicos das mesmas se quiser obter resultados satisfatórios;
• O usuário necessita ter amplo conhecimento da estrutura existente nas fontes de dados a fim de conseguir especificar com precisão e sem ambiguidades a sua necessidade de informação independente do nível de conhecimento técnico;s e • A informação quando retornada ao usuário pelo sistema nem sempre satisfaz as
suas necessidades. O usuário pode preferir receber uma resposta aproximada a não receber resposta alguma.
Neste sentido, interfaces de consulta em ambientes distribuídos e dinâmicos baseados em ontologias devem ser desenvolvidas considerando a usabilidade dos sistemas atuais para proporcionar ao usuário uma interação simples e objetiva com o sistema.
1.2
Justificativa
O desenvolvimento de aplicações na Web, com a maior participação dos usuários na produção de informações (Web 3.0), fez crescer a necessidade por novas arquiteturas de sistemas distribuídos. Uma delas é a arquitetura P2P (Peer-to-peer) que vem sendo bastante utilizada para trocas de informações, especialmente arquivos, na Web (Milojicic et al., 2003). O interesse deste trabalho se concentra no problema de gerenciamento de dados, acessados a partir de fontes de dados distribuídas, e a integração dos mesmos para responder às consultas efetuadas nos diversos pontos que compõem um sistema P2P. Os sistemas de gerenciamento de dados P2P ou PDMS (Peer Data Management Systems) representam uma evolução dos tradicionais sistemas de integração de dados.
O termo P2P refere-se a uma variedade de sistemas e aplicações que empregam recursos de maneira distribuída para realizarem suas atividades de uma maneira descen-tralizada (Milojicic et al., 2003). PDMS é uma aplicação peer-to-peer na qual cada um de seus elementos constituintes é um ponto de dados autônomo que pode compartilhar
1.2. JUSTIFICATIVA
seus esquema de dados com os demais pontos de forma total ou parcial (Blanco et al., 2006). Os sistemas PDMS são um exemplo muito comum e importante de um ambiente distribuído e dinâmico. O compartilhamento de dados entre os pontos em um PDMS é feito pela exportação de seus esquemas. Um PDMS possui as seguintes características: compartilhamento descentralizado dos dados; escalabilidade; processamento e armazena-mento de dados distribuídos feitos a partir de pontos autônomos que também armazenam as correspondências semânticas dos dados (Blanco et al., 2006).
Os PDMS representam uma evolução dos tradicionais sistemas de integração de dados, onde o esquema global único é substituído por uma coleção de correspondências semânticas entre os esquemas dos pontos que compõem a rede (Blanco et al., 2006). Tais correspondências permitem que o PDMS recupere dados que são semanticamente similares, mas se encontram descritos por diferentes esquemas e armazenados em pontos distintos.
Muitos desses PDMS baseados em semântica são compostos por pontos cujos esque-mas exportados são representados por ontologias. Muitas definições de ontologia são encontradas na literatura. Uma das definições diz que ontologia é uma descrição formal explícita de conceitos em um domínio do discurso, de propriedades de cada conceito descrevendo atributos ou características, e de restrições dessas propriedades (Noy and Mcguinness, 2002). Outro trabalho considera também que uma ontologia juntamente com definições de instâncias de seus conceitos forma uma base de conhecimento (Guarino, 1998). Os conceitos são as entidades principais de uma ontologia, podendo representar um domínio de aplicação.
Uma grande vantagem dos sistemas PDMS é a de que qualquer ponto pode submeter uma consulta na rede utilizando apenas seu próprio esquema de dados, sem precisar co-nhecer esquemas de outros pontos. Com isso, através dos caminhos semânticos existentes entre os pontos, a consulta original pode ser reformulada (adequada) aos outros pontos do caminho semântico, de acordo com seus respectivos esquemas de dados.
O sistema SPEED é um PDMS baseado em semântica, composto de pontos cujos esquemas exportados são representados por ontologias (Pires, 2009).Para este sistema, foi desenvolvido um módulo de consultas que possibilita: a submissão de consultas em um dado ponto da rede; a identificação da semântica da consulta; o enriquecimento semântico da consulta; sua reformulação ao ser passada para outros pontos da rede; a execução da
1.3. OBJETIVOS
consulta nos pontos requisitados; a integração dos resultados no ponto que submeteu a consulta; e a exibição dos resultados para o usuário. Uma primeira versão do módulo de consultas já foi implementada baseando-se no fato que os esquemas das fontes de dados são representados por ontologias necessitando ainda de uma interface que dê suporte a este tipo de consulta que possa ser submetida nos diferentes pontos da rede.
1.3
Objetivos
O objetivo geral deste trabalho é desenvolver uma interface que proporcione aos usuários uma interação simples e objetiva com PDMS. Para alcançar tal objetivo, será feito um levantamento do estado da arte da interação do usuário em ambientes de PDMS. Esta interface será desenvolvida e validada no ambiente do sistema SPEED.
1.3.1
Objetivos Específicos
• Especificar e implementar uma interface de interação com o usuário para PDMS ; • Melhorar o processo de interação do usuário em ambientes distribuídos e dinâmicos
baseados em ontologias;
• Auxiliar os usuários na formulação e execução de consultas; • Melhorar a visualização de resultados de consultas em PDMS; e • Fazer os experimentos da interface no ambiente do sistema SPEED.
1.4
Organização da Dissertação
Este trabalho está organizado em seis capítulos, conforme a divisão que se segue: • O Capítulo 1 introduz e motiva as idéias principais do trabalho, destacando a
motivação, a justificativa, os objetivos e a estrutura da dissertação;
• O Capítulo 2 apresenta os principais conceitos que fundamentam este trabalho. En-tre estes são apresentados os conceitos envolvidos à concepção e à implementação de interfaces de interação com o usuário em ambientes distribuídos baseados em ontologia;
1.4. ORGANIZAÇÃO DA DISSERTAÇÃO
• O Capítulo 3 apresenta os principais tipos de interface de consulta utilizados em PDMS bem como as abordagens existentes para estes tipos de interface;
• O Capítulo 4 apresenta a especificação de uma interface visual de interação com o usuário PDMS baseados em ontologia, detalhando a arquitetura proposta, definição de requisitos e prototipação da interface;
• O Capítulo 5 apresenta os detalhes de implementação da interface proposta e um estudo de caso detalhando as funcionalidades contempladas, em um cenário definido para experimentação desta. Este capítulo apresenta, também, a avaliação da interface desenvolvida; e
• O Capítulo 6 resume o trabalho realizado, discutindo as contribuições alcançadas e indicando algumas pesquisas futuras para extensão da proposta.
2
Conceitos Básicos
Neste capítulo serão discutidos os principais conceitos relacionados à concepção e à implementação de interfaces de interação com o usuário. Serão abordadas também, as características de sistemas P2P, PDMS, ontologias e SPARQL, inerentes ao escopo deste traballho.
2.1
Interfaces Visuais
As interfaces de usuário, em especial as interfaces visuais, têm a preocupação de aprimorar a comunicação e a interação dos usuários com o computador, constituindo-se em elemento essencial e indispensável nos diversos tipos de sistemas computacionais e nas mais diversas áreas: banco de dados, computação gráfica, inteligência artificial, entre outras. As interfaces visuais estão, aos poucos, sendo usadas em substituição às linguagens de programação tradicionais devido à constante popularização dos recursos gráficos e proporcionarem uma melhor interação do usuário com informações (Silva, 1998).
Visual Query System (VQS), ou sistemas de consulta visuais, são definidos como sistemas para consulta de banco de dados que usam uma representação visual para descrever o domínio de interesse e expressar consultas relacionadas. Estes sistemas tiram vantagem da conhecida largura de banda do campo de visão humana, permitindo o reconhecimento e manuseamento de grandes quantidades de informação assim como a possibilidade de usar o feedback visual para melhorar o diálogo humano-computador. VQS provêem linguagens para expressar consultas de maneira visual e uma variedade de funcionalidades para facilitar a interação entre o usuário e o sistema. Assim, eles são orientados para uma grande variedade de usuários, especialmente usuários que possuem um conhecimento computacional limitado e geralmente ignoram a estrutura interna da base de dados acessada (Catarci et al., 1997).
2.1. INTERFACES VISUAIS
Um VQS é composto de uma, Visual Query Language (VQL), ou linguagem de consulta visual, para expressão de consultas e algumas funcionalidades para facilitar a interação humano-computador (Catarci et al., 1997). A VQL é uma subclasse de linguagens visuais que servem para extração de dados de bancos de dados (Fadhil and Haarslev, 2007). Historicamente, interfaces de banco de dados tem deixado de ser textual (com o uso de SQL, por exemplo) para serem baseadas em formulários, diagramas (Athanasis et al., 2004) e ícones.
VQLs baseiam-se principalmente na idéia de manipular o banco de dados em uma visualização em forma de grafo, selecionando as partes que serão incluídas na consulta (Fadhil and Haarslev, 2007).
Desenvolver uma interface implica em desenvolver um processo de interação com o usuário (Dix et al., 2003). O desenvolvimento de uma boa interface envolve a utilização de técnicas e princípios, que vão desde a elaboração do projeto até análises e testes com os usuários finais. Conforme Dix (Dix et al., 2003), as principais etapas do desenvolvimento de uma interface são: análise de usuários e tarefas, projeto da interação, prototipação e testes (podendo estas etapas estarem envolvidas em um processo cíclico).
Para análise de usuários, Shneiderman (Shneiderman and Plaisant, 2010) recomenda que os projetistas de interfaces levem em consideração os diferentes tipos de personalida-des, isto é, quanto ao nível de conhecimento ou grau de experiência em informática.
Nesta seção, serão abordados os aspectos necessários ao processo de desenvolvimento de uma interface de interação com usuário.
2.1.1
Interação Humano-Computador
A Interação Humano Computador (IHC) pode ser definida como a disciplina envolvida com o projeto, avaliação e implementação de sistemas computacionais interativos para uso humano e os fenômenos a ele relacionados (Dix et al., 2003).
A IHC envolve três fatores fundamentais: a interface, o homem e o computador. A relação entre estes termos é conhecida como interação. O termo interface é aplicado normalmente àquilo que interliga dois sistemas. Tradicionalmente, considera-se que uma interface homem-máquina é a parte de um artefato que permite a um usuário controlar e avaliar o funcionamento do mesmo através de dispositivos sensíveis às suas ações e capazes de estimular sua percepção. No processo de interação, usuário-sistema-interface é o combinado de software e hardware necessário para viabilizar e facilitar os processos de comunicação entre o usuário e a aplicação.
2.1. INTERFACES VISUAIS
máquinas convencionais por exigir das pessoas um maior esforço cognitivo em atividades de interpretação e expressão das informações que o sistema processa (Dix et al., 2003). Norman (Norman, 1994), um dos mais influentes pesquisadores e um dos pioneiros na aplicação de Psicologia e Ciência Cognitiva ao design de interfaces de usuário, enfatiza que a tecnologia deve ser projetada com o objetivo de ajudar as pessoas a serem mais espertas, eficientes e inteligentes. Ele salienta a necessidade da construção de artefatos cognitivos que tornam as pessoas mais espertas.
Para adequar-se a este ponto de vista, o desenvolvimento de sistemas computacionais interativos não pode ser considerado apenas dentro do escopo restrito da Ciência da Computação e de fatores humanos (ergonomia). As habilidades dos usuários, a situação de uso e o domínio de aplicação onde eles estão envolvidos são fundamentais para a usabilidade e devem ser considerados no desenvolvimento de sistemas interativos, pois, de acordo com Dix (Dix et al., 2003), sistemas concebidos sem os conhecimentos necessários das áreas envolvidas acabam fazendo uso da capacidade de adaptação do ser humano para compensar deficiências.
Princípios, diretrizes, regras e padrões são utilizados por especialistas e centros de estudos como instrumento de apoio ao projeto de interfaces de maneira a auxiliar os projetistas. Tais instrumentos têm sido fundamentais a muitos projetistas, principalmente devido à proliferação dos computadores pessoais e à diversidade de usuários, exigindo assim uma atenção maior às interfaces e contribuindo para o surgimento de Graphical User Interface(GUI) e novos estilos de interação (Dix et al., 2003). Como exemplos de estilos de interação pode-se citar: menus, preenchimento de formulários, manipulação direta, linguagem natural, Windows, Icons, Menus e Pointers (WIMP) e What you see is what you get(WYSIWYG).
2.1.2
Projeto de Interface
O projeto de uma boa interface não consiste no uso abundante de recursos gráficos com o objetivo de tornar a interface mais bonita. É necessário utilizar estes recursos com conhecimento de causa de modo que a interface se torne um meio de comunicação efetivo para um maior número de pessoas.
Segundo Foley (Foley et al., 1995), as principais metas de um projeto de interface compreendem: aumento da velocidade de aprendizado; aumento da velocidade de uso; redução na taxa de erros; facilidade de uma rápida revisão de como utilizar a interface e aumento da atratividade para potenciais usuários, sendo estes os fatores cruciais da usabilidade.
2.1. INTERFACES VISUAIS
Dix (Dix et al., 2003) afirma que, independente do padrão de interface ou plataforma que serão escolhidos, é preciso planejar a interface, pois é na fase do projeto que são definidos o comportamento e a apresentação da mesma. A execução de um projeto envolve: tipos de diálogo ou interação; análise do usuário e das tarefas; fatores humanos; dispositivos de entrada e saída; princípios, padrões, regras e diretivas; protótipos e avaliação de sistemas existentes. O resultado do projeto é a especificação do mesmo, geralmente através de especificações formais, protótipos ou ainda documentos informais.
2.1.2.1 Projeto de Interação
Segundo Dix (Dix et al., 2003) interação é qualquer comunicação entre o usuário e o computador, seja direta ou indireta. Interação direta é aquela em que há diálogo, retorno (feedback) e controle das operações realizadas. A indireta, por sua vez, envolve dois pos-síveis tipos de processamento: de fundo ou em lotes. Em ambas, o que realmente importa é a interação entre o usuário e o computador, em busca da solução para alguma tarefa específica. Cabe ao designer de interação a definição de como será a comunicação da interface com o usuário. Isso não implica em somente preocupar-se com os componentes das interações, mas essencialmente com a forma pela qual tais componentes orientam as ações dos usuários (Dix et al., 2003).
Essencialmente, o processo de projeto da interação é composto por quatro atividades básicas: Identificação das necessidades dos usuários, desenvolvimento de alternativas de projeto, construção de versões iterativas e avaliação do projeto. É importante destacar que essas atividades estão inter-relacionadas fornecendo informações umas às outras, podendo ser inclusive repetidas.
O projeto da interação considera ainda três aspectos chaves do processo: foco no usuário, definição de metas de usabilidade e iteração. O foco no usuário é central no processo de projeto, de modo que o processo encoraja este foco e provê oportunidades para a participação do usuário dentro do processo. Os critérios de usabilidade devem ser identificados, concordados e documentados no início do projeto e são especialmente importantes no momento da escolha das alternativas de projeto. Por último, iteração deve estar sempre presente e é por meio dela que se permite o refinamento baseado em resultados de avaliações de versões intermediárias.
2.1.2.2 Processo de Projeto de Interação
O processo de projeto é composto por quatro fases principais mais um ciclo de iteração: (1) identificação das necessidades dos usuários; (2) análise das necessidades dos usuários; (3)
2.1. INTERFACES VISUAIS
desenvolvimento de alternativas de projeto e construção de versões iterativas(protótipo); e (4) implementação do projeto. Estas fases proporcionam um ciclo metodológico onde atividades reconhecidamente importantes para a pesquisa de IHC podem ser adicionadas (Dix et al., 2003). A Figura 2.1 apresenta as principais fases deste processo.
Figura 2.1: Processo de Projeto de Interação. Adaptado de (Dix et al., 2003)
Muitos métodos de projeto de interface foram definidos e, em geral, partem da captura e análise do perfil do usuário e de suas tarefas, análise dos objetivos da interface, definição do projeto das telas, da navegação e teste da interface prototipada. Em muitos aspectos estes métodos possuem similaridade; apresentam diferentes números de fases; são genéricos, por isso algumas ferramentas têm sido implementadas para dar suporte ao processo de desenvolvimento; e, na maioria das vezes, não expõem de fato como ocorre a concepção dos componentes gráficos, dos aspectos estéticos e semiológicos da interface. Também, não prevêem em que momento do processo o desenvolvedor de interface Web irá aplicar os requisitos estabelecidos pelos padrões Web.
O processo de interação tem uma estrutura flexível, portanto, o ciclo metodológico pode ser adaptado a cenários diversos. Assim, foram inseridas atividades específicas com o objetivo de aumentar a qualidade do resultado do processo que é composto por quatro fases. A seguir, cada fase do processo é descrita em conjunto com as atividades propostas a cada fase.
Fase 1 - Identificação das Necessidades dos Usuários
A principal motivação para o estudo do usuário está no fato de que diferentes usuários têm diferentes necessidades e produtos interativos devem ser projetados de acordo com esses desejos e expectativas. Isso exige uma compreensão de quem é o público-alvo do produto ou sistema que está sendo projetado e que tipo de suporte o usuário necessita.
2.1. INTERFACES VISUAIS
Nesta fase do processo as atividades se iniciam com a identificação dos objetivos seguida da definição do público-alvo, da definição das técnicas que serão empregadas e do desenvolvimento dos instrumentos de coleta necessários para uso com a técnica escolhida. Dentre as técnicas usadas para isso em IHC, pode-se destacar: entrevista, gravação e observação dos usuários (etnografia).
A coleta de dados tem por objetivo a busca de informações suficientes e relevantes para a definição de um conjunto estável de requisitos. Para que informações como quais as tarefas dos usuários, quais seus objetivos em executá-las, qual o contexto em que estas atividades são executadas, quais as dificuldades em realizá-las, entre outras informações sejam obtidas, é importante o conhecimento de técnicas de coleta de dados e sua aplicabilidade. A definição dos cenários de interação pode ser feita em conjunto com um método de análise de tarefas, por exemplo.
Existem várias técnicas e a escolha depende do tipo de informação que se deseja obter, dos recursos disponíveis, da acessibilidade dos stakeholders a serem considerados, entre outras razões (Prates and Barbosa, 2003).
Fase 2 - Análise
Enquanto a fase anterior está mais preocupada com o tema, quais os usuários cujas necessidades serão estudadas e com a escolha das técnicas, a fase de análise está mais focada em executar o estudo e analisar os dados. Assim, os resultados das observações e entrevistas precisam ser ordenados de forma a trazer para fora questões essenciais ao desenvolvimento do projeto. Uma vez que a coleta dos dados tenha sido encerrada, tem início a análise dos dados obtidos. O objetivo é iniciar a estruturação e o registro dos re-quisitos (Pires, 2009). Várias técnicas podem ser utilizadas, cada uma contribuindo mais enfaticamente em investigar aspectos diferentes dos dados. Softwares também podem ser utilizados para análise dos dados. O seu uso amplia significativamente o conjunto final de categorias que podem ser identificadas pelos pesquisadores. Um exemplo de software utilizado para análise dos dados de entrevistas é o NUDIST (NUDIST, 2011).
Fase 3 - Projeto
Uma vez que as principais necessidades dos usuários tenham sido identificadas, iniciam as atividades de projeto. O principal objetivo é a busca por ideias que atendam às necessidades identificadas na fase anterior.
Esta fase pode ainda ser dividida em duas outras sub-atividades que são: projeto conceitual, que envolve a criação do modelo do produto; e projeto físico, que envolve os
2.2. P2P
detalhes do produto, tais como telas e menus.
Com a obtenção dos resultados da coleta e a análise dos dados da etapa anterior, são usadas técnicas de projeto que possibilitem a criação de versões que permitam a interação do usuário. Em especial, técnicas de prototipagem rápida e de baixa fidelidade permitem avaliar as melhores soluções mesmo antes de o sistema começar a ser implementado. Quanto mais protótipos e iterações, maiores as chances do produto final ser adequado ao público ao qual ele se destina.
Prototipagem: Para a concepção do produto que atenda aos requisitos estabelecidos, faz-se uso intensivo de prototipação. Os protótipos podem ser baseados em papéis até modelos mais próximos ao produto final. Protótipos permitem que os usuários interajam com um modelo de menor fidelidade que o produto final e possam expor suas primeiras percepções sobre o que está sendo desenvolvido.
A avaliação do protótipo compreende a preparação, aplicação e análise de testes de usabilidade a serem realizados em diferentes versões dos protótipos em desenvolvimento. Estes testes permitem verificar se o produto atende a um conjunto de critérios de usabili-dade e experiência anteriormente estabelecida do usuário na fase de análise. Por ser um processo iterativo, os protótipos evoluem nas atividades de projeto e avaliação num ciclo iterativo de projeto-prototipagem-avaliação e projeto novamente. Para a realização desses testes, avaliações heurísticas podem ser utilizadas (Dix et al., 2003).
Fase 4 - Implementar e Implantar
Nesta última fase, quando se está satisfeito com o projeto, é necessário implementar o produto. Isto envolve a codificação do mesmo. Uma vez codificado, pode-se executar testes de usabilidade e experimentações do produto implementado.
Geralmente esta fase envolve também a criação de documentação, manual e ajuda do sistema.
2.2
P2P
O termo peer-to-peer (par-a-par) se refere a uma variedade de sistemas e aplicações que empregam recursos de maneira distribuída para realizarem suas atividades de forma descentralizada (Milojicic et al., 2003). Em uma rede P2P, as unidades de processamento não possuem um papel fixo para comunicação com outras máquinas, podendo agir tanto
2.2. P2P
como um cliente quanto como um servidor.
A organização de uma rede P2P é descentralizada, ou seja, não existe um gerenci-amento central. Por isso, quando há a transmissão de dados entre dois pontos da rede, a informação costuma passar por vários pontos da rede desde a origem até alcançar o destino pretendido.
As aplicações peer-to-peer possuem características importantes como escalabilidade, volatilidade, autonomia dos pontos, roteamento, entre outras.
As redes P2P foram categorizadas em diferentes topologias de acordo com as diferen-tes organizações e papéis de cada ponto na rede. As principais topologias serão descritas nas seções seguintes.
2.2.1
Topologia P2P Pura
Em uma topologia P2P pura não existe centralização no processamento, todos os peers exercem as mesmas funções na rede, não existindo hierarquia entre os pontos da rede. A Figura 2.2 ilustra a topologia P2P pura.
Figura 2.2: Topologia P2P Pura. (Fiorano, 2011)
Como dito anteriormente, a informação, ao trafegar por uma rede P2P pura, passa por outros pontos até chegar ao destino pretendido. Os outros pontos apenas repassam a
2.2. P2P
informação, quando esta não é direcionada a eles. Uma virtude da topologia P2P pura é a escalabilidade, já que qualquer ponto pode se juntar a uma rede P2P e começar a trocar informações com outros pontos. Essas redes também são tolerantes a falhas, pois se algum peer em particular da rede falha, não ha impacto para o restante do sistema (Fiorano, 2011).
2.2.2
Topologia P2P Híbrida
Na topologia P2P híbrida há a presença de um ou mais servidores centrais para controle da troca de informações mas o fluxo de dados ocorre da mesma maneira que na topologia P2P pura. A presença do servidor ameniza o problema de falta de gerenciamento, presente na topologia P2P pura. O papel principal do servidor é o monitoramento dos outros pontos da rede, garantindo a coerência na informação trocada por eles (Fiorano, 2011). A Figura 2.3 ilustra a topologia P2P híbrida.
Figura 2.3: Topologia P2P Híbrida. (Fiorano, 2011)
Neste tipo de topologia pode ocorrer o mesmo problema que ocorre em um sistema centralizado; caso o sistema central sofra algum tipo de falha, a rede perde a habilidade de gerenciamento e controle da troca de informações. Com o fluxo de informações centralizado este tipo de topologia não é indicado para sistemas que necessitam de uma alta escalabilidade.
2.2. P2P
2.2.3
Topologia P2P Super-Peer
Na topologia super-peer, como mostra a Figura 2.4, a arquitetura é composta de uma mistura entre a abordagem centralizada, com existência de gerenciamento, e a abordagem descentralizada, na busca e troca de dados entre os pontos.
Figura 2.4: Topologia P2P Super-Peer. (Fiorano, 2011)
Alguns pontos podem assumir papéis distintos na rede. Nesta topologia os peers de maior capacidade computacional podem ser eleitos para coordenar um subconjunto de pontos da rede. Esse ponto é chamado de super-peer (Fiorano, 2011).
Em (Fiorano, 2011), são listadas uma série de vantagens sobre a topologia P2P super-peer. A busca nesse tipo de topologia é muito rápida em comparação a outras arquiteturas, já que o sistema possui seu espaço de busca particionado em um conjunto menor de peers coordenados por super-peers, os quais possuem a informação de seus peers indexada.
Essa arquitetura define várias unidades autônomas colaborando entre si. Cada con-junto de pontos sob o mesmo super-peer (também chamado de cluster do super-peer) corresponde a uma unidade autônoma, no sentido de não haver dependência de um servidor central para a troca de informações.
2.3. PEER DATA MANAGEMEN SYSTEM (PDMS)
Os super-peers mais confiáveis e com maior poder de processamento monitoram a atividade de seus clusters. Isso garante um controle contra atividades maliciosas na rede. Nesta topologia, há também um melhor balanceamento das responsabilidades dependendo da capacidade do peer, o que previne uma queda de desempenho graças a uma fragmentação da rede no caso de todos os peers possuírem a mesma responsabilidade e muita carga ficar sobre um peer com pouca capacidade de processamento.
O Quadro 2.1 apresenta uma comparação entre as topologias discutidas, incluindo também a comparação com sistemas centralizados (estilo cliente-servidor), com relação a gerenciamento, coerência da informação, escalabilidade e confiabilidade.
Quadro 2.1: Comparação entre as topologias P2P. Adaptado de (Fiorano, 2011)
Topologia Gerenciável Coerente Escalável Confiável Centralizada Sim Sim Não Não Descentralizada Não Não Sim Sim P2P Hibrida Sim Sim Sim Não Super Ponto Sim Sim Sim Sim
2.3
Peer Data Managemen System (PDMS)
PDMS é uma aplicação peer-to-peer que tem como elementos constituintes peers de dados autônomos que podem compartilhar seus esquemas de dados entre si de forma total ou parcial (Blanco et al., 2006).
Os sistemas PDMS podem ser definidos também como sistemas de gerenciamento peer-to-peerque provêem um ambiente de integração de dados, sendo estes armazenados em fontes autônomas, heterogêneas e dinâmicas (Blanco et al., 2006).
A forma de compartilhamento de dados entre os peers em um PDMS é feita pela exportação de seus esquemas. Um PDMS possui as seguintes características:
• Compartilhamento descentralizado dos dados; • Escalabilidade; e
• Processamento e armazenamento de dados distribuídos em peers autônomos, que também armazenam os mapeamentos semânticos dos dados.
A organização descentralizada é importante para que o PDMS não fique inviabilizado caso algum ponto em particular venha a falhar. Os pontos em um PDMS são considerados
2.3. PEER DATA MANAGEMEN SYSTEM (PDMS)
autônomos devido à sua liberdade de entrada ou saída de uma rede, ou até mesmo sobre possíveis alterações em seus esquemas de dados.
Em um PDMS, um dos serviços mais importantes é o processamento de consultas. Quando uma consulta é submetida em um ponto, o sistema consegue obter dados rele-vantes não só do ponto que recebeu a consulta, mas de qualquer outro ponto que esteja conectado à rede por meio de caminhos semânticos (Tatarinov and Halevy, 2004).
Uma grande vantagem dos sistemas PDMS é a de que qualquer ponto pode submeter uma consulta na rede utilizando apenas seu próprio esquema de dados, sem precisar conhecer os esquemas de outros pontos. Com isso, a consulta original pode ser reformu-lada (adequada) aos outros pontos da rede por meio dos caminhos semânticos existentes, sendo estes definidos de acordo com os esquemas de dados dos pontos.
Por exemplo, se uma consulta Q é submetida em um peer A, o PDMS geralmente retorna primeiro um resultado baseando-se nos dados de A (pode ocorrer também de o PDMS integrar todos os resultados e retorná-los de uma só vez). Tento feito isso, a consulta Q é reformulada para os vizinhos semânticos de A e outros resultados são retornados baseados em outros esquemas de dados. Isso contribui para se obter um resultado mais completo para a consulta submetida.
A escolha do caminho semântico a ser seguido é muito importante pois, dependendo do caminho semântico seguido pela consulta, novas respostas podem ser obtidas. Isso pode resultar em alguns problemas. Alguns desses problemas são citados em (Tatarinov and Halevy, 2004):
• Surgimento de respostas redundantes. Cada reformulação desnecessária degrada o desempenho do sistema;
• Um caminho que encontre um final muito cedo, passando por poucos pontos, ou seja, podado precocemente; e
• Reformulações ineficientes, ou seja, consultas em pontos que poderiam ser melhor aproveitadas (otimizadas, ou enriquecidas) antes de serem executadas.
Os pontos de um PDMS não possuem todas as informações sobre um domínio. Por isso, escolher um bom caminho semântico quando uma consulta é submetida é de grande importância, a fim de se extrair o maior número de informações que possam ser encontradas na rede.
Os PDMS se tornaram grande fonte de pesquisa por serem uma extensão às bases de dados distribuídas no contexto peer-to-peer (Pires, 2009). Devido à grande variedade
2.4. ONTOLOGIA
na representação de dados e na semântica dos peers, um modelo de PDMS baseado em ontologias foi sugerido (Xiao, 2006). Xiao (Xiao, 2006) introduziu uma nova definição para este novo modelo, que possui o intuito de oferecer uma representação de dados em uma notação mais uniforme. Esse tipo de sistema é conhecido como Ontology-based Peer Data Management System(OPDMS).
2.4
Ontologia
Muitas definições de ontologia são encontradas na literatura no âmbito da inteligência artificial. Uma das definições diz que ontologia é uma descrição formal explícita de conceitos em um domínio do discurso, de propriedades de cada conceito descrevendo atributos ou características, e de restrições dessas propriedades (Noy and Mcguinness, 2002). É conhecido também que uma ontologia juntamente com definições de instâncias de suas classes formam uma base de conhecimento (Guarino, 1998).
As classes são as entidades principais de uma ontologia. Uma ontologia pode re-presentar um domínio de aplicação, e várias classes podem ser apresentadas com seus atributos, limitações, características e relacionamentos com outras classes do domínio, como por exemplo, o relacionamento de subclasse e superclasse, muito comuns nas ontologias.
Ontologias são muito comuns na Web, servindo para uma diversidade de propósitos, desde a descrição de sites como de um simples produto comercial. As ontologias definem um vocabulário comum e estruturado para a troca de informações de um domínio entre pesquisadores. Algumas das principais razões para o desenvolvimento de uma ontologia são (Noy and Mcguinness, 2002):
• Compartilhar um conhecimento comum entre pessoas ou agentes de software; • Permitir o reuso do conhecimento de um domínio;
• Melhorar a análise do conhecimento de um domínio; e
• Separar o conhecimento do domínio do conhecimento operacional.
A fim de oferecer uma padronização na representação desse conhecimento da Web, duas linguagens (arquiteturas) surgiram nesse contexto: Resource Description Fra-mework (RDF) e Web Ontology Language (OWL), ambas recomendações da World Wide Web Consortium(W3C) (McGuinness and van Harmelen, 2004), que serão mais bem explicadas nas próximas subseções.
2.4. ONTOLOGIA
2.4.1
Resource Description Framework (RDF)
A Web provê acesso sem precedentes à informação. Metadados (campos descritivos de algum tipo de informação) aumentam o acesso a essa informação, e o RDF surge como um padrão da W3C proposto para definir a arquitetura necessária para dar suporte aos metadados da Web (Miller, 1998).
RDF é uma linguagem para representar informação na Internet. Essa linguagem permite aos computadores representar e compartilhar dados semânticos na Web (W3C, 2004).
A RDF possui um modelo padrão para descrever recursos da Web. Um recurso, para RDF, é um objeto, que possui propriedades. Tais propriedades possuem tipos (numéricos, caracteres,...), e valores possíveis. Os valores de uma propriedade podem ser atômicos ou outros recursos.
A RDF em si é uma linguagem simples que é capaz de fazer relacionamentos entre informações, mas, além disso, é necessário um meio para definição de dados. A RDF Schema(Brickley and Guha, 2000) foi criada, também pela W3C, com essa finalidade.
A RDF Schema (Brickley and Guha, 2000) é responsável por prover mecanismos para declaração de propriedades dos recursos e também definir os tipos de recursos que estão sendo descritos. Pode ser entendido como uma espécie de dicionário onde são definidos os termos que serão utilizados em declarações RDF. A especificação da RDF Schema da W3C fornece os mecanismos necessários à definição de elementos, de classes de recursos, de posséveis restrições de classes e relacionamentos e detecção de violação de restrições.
2.4.2
Web Ontology Language (OWL)
OWL é uma linguagem para definição e instanciação de ontologias na Web. É viável utilizar OWL quando a informação contida nos documentos precisa ser processada por alguma aplicação, ao contrário do que ocorre quando a informação apenas necessita ser apresentada ao usuário (McGuinness and van Harmelen, 2004), sem nenhum tipo de processamento.
A OWL é considerada uma extensão de RDF. Sendo assim, também pode incluir descrições de classes, suas respectivas propriedades e relacionamentos. Assim como RDF, OWL é uma recomendação da W3C, mas possui um maior poder de interpretação e mais recursos para modelar o conteúdo da Web do que RDF ou Extensible Markup Language(XML) (Thompson, 1997), pois a OWL possui um vocabulário mais amplo e uma semântica mais bem definida.
2.5. LÓGICA DESCRITIVA (DL)
A linguagem OWL é mencionada como uma tecnologia importante para a futura implementação da Web semântica (Shadbolt et al., 2006). Esta possui um vocabulário mais amplo para expressar propriedades e relacionamentos, como o de cardinalidade, enumerações, entre outros. A OWL possui três sublinguagens expressivas direcionadas a comunidades específicas (W3C, 2004):
• OWL Lite - Dá suporte a usuários que necessitam de uma classificação hierárquica e restrições simples. Por exemplo, embora suporte restrições de cardinalidade, ela só permite valores de cardinalidade 0 ou 1. É mais simples fornecer ferramentas que dão suporte a OWLLite
• OWL Description Logic (DL) - Dá suporte a usuários que querem a máxima expressividade, enquanto mantém a computabilidade e decidibilidade. OWL DL possui todas as construções da linguagem OWL, porém elas somente podem ser usadas com algumas restrições. Possui esse nome devido à sua correspondência com as lógicas de descrição; e
• OWL Full - Direcionada aos usuários que querem máxima expressividade e liber-dade sintática sem nenhuma garantia computacional. A OWL Full permite que uma ontologia aumente o vocabulário pré-definido de RDF ou OWL.
2.5
Lógica Descritiva (DL)
A lógica descritiva (ou DL, do inglês Description Logic) é um conjunto de linguagens de representação de conhecimento de aplicações, que enfatiza o domínio de uma aplicação de uma maneira formal e estruturada, e que é bem compreendido (Baader et al., 2003).
A DL consegue explicitar e detalhar diversos domínios de aplicações graças ao seu poder de descrição de entidades por meio de operadores bem definidos e quantificadores, e também graças às regras de formação dessas descrições de algum objeto ou situação em particular. Além disso, a DL possui toda uma carga semântica apoiada na lógica matemática.
Os construtores Attribute Language with Complement (ALC) são: (1) ¬C (negação); (2) C u D (conjunção); (3) C t D (disjunção); (4) ∀R.C (restrição universal); e (5) ∃R.C (restrição existencial limitada), onde C e D são conceitos e R é uma propriedade. Nesse sentido, considera-se uma ontologia como uma tripla O = {C, R, I} , onde C é um conjunto de conceitos, R é um conjunto de propriedades e I é um conjunto de indivíduos (instâncias).
2.6. SPARQL PROTOCOL AND RDF QUERY LANGUAGE
Uma consulta formulada utilizando a DL é uma expressão Q = C, onde C é um con-ceito. Esse conceito pode ser atômico ou complexo (inclui propriedades, quantificadores, conjunções ou disjunções) (Souza, 2009).
Um exemplo de consulta formulada em DL é: Q1 = [Teacher u Researcher] t
[Student u Researcher], que procura por indivíduos que são professores e pesquisadores ou estudantes que também são pesquisadores.
2.6
SPARQL Protocol and RDF Query Language
SPARQL é uma linguagem de consulta para documentos RDF, mas que também faz buscas em estruturas de arquivos OWL, ou seja, busca em ontologias em geral. É padronizada pela RDF Data Access Working Group (DAWG) da W3C (Prud’hommeaux and Seaborne, 2008).
As consultas em SPARQL consistem de um padrão triplo (triple patterns): conjunções, disjunções e padrões opcionais de complementação. Essa idéia de tripla se baseia nas estruturas de grafo do RDF. SPARQL foi desenvolvida a partir de linguagens de consulta em RDF anteriores, como RDF Data Query Language (RDQL) (Seaborne, 2004) e Sesame RDF Query Language (SeRQL) (Broekstra and Kampman, 2004), e sua implementação é compatível com uma série de plataformas.
Além da possibilidade de consulta de dados, SPARQL também oferece a capacidade de extração de informações de repositórios a partir de regras de elaboração do usuário, com o auxílio dos construtores reservados de SPARQL: Construct, Ask, e Describe. Um ambiente comum para a prática de consultas SPARQL é o Jena (Jena, 2011) com o auxílio do ARQ (ARQ, 2011), um motor de consulta que trabalha com o Jena.
O Figura 2.5 apresenta um exemplo de consulta em SPARQL, que deseja recuperar de uma ontologia todos os identificadores (ID) de professores.
Detalhando mais essa consulta a respeito da sintaxe da linguagem, tem-se os seguintes itens:
• Prefixos - no início há a declaração de prefixos com a palavra reservada prefix, que associa uma sigla com um Uniform Resource Identifier (URI) específico. Uma consulta pode incluir qualquer quantidade de prefixos desejada;
• Select - palavra reservada que define os itens que serão retornados pela consulta (as variáveis em SPARQL são precedidas de “?” ou “$”);
2.7. CONSIDERAÇÕES
Figura 2.5: Exemplo de Consulta SPARQL.
• Where - indica as condições para o retorno do resultado. Neste caso, como expli-cado, pode-se observar o padrão de triplas do SPARQL. A tripla pode ser entendida como uma construção de sujeito, predicado e objeto;
• ?x - a variável “x” é ligada a conceitos do tipo “Teacher” na ontologia;
• Operador ponto - o operador “.” indica uma concatenação de restrições. A segunda restrição indica que, dado que “x” contém um professor, seu ID deve ser atribuído à variável ID (?ID, que é a variável de retorno da consulta).
2.7
Considerações
Neste capítulo foram abordados os principais conceitos envolvidos na concepção e implementação de interfaces de interação com o usuário. Também foram descritos os conceitos e características de sistemas P2P, PDMS e ontologias inerentes ao escopo deste trabalho. No próximo capítulo serão apresentados alguns tipos de interfaces propostas para PDMS abordando, principalmente, interfaces que fazem uso de ontologias na interação do usuário para formulação de consultas.
3
Interfaces e PDMS
Neste capítulo serão descritos os tipos de interface utilizados em PDMS bem como as abordagens existentes para estes tipos de interface.
3.1
Interfaces Baseadas em Ontologia
Visando classificar as abordagens existentes para consulta baseada ontologias, Hoang (Hoang and Tjoa, 2006) identificou alguns critérios, bem como algumas metodologias, com base em semelhança de objetivos de pesquisa. Dentre estes critérios encontram-se a formulação de consultas e a interação do usuário.
3.1.1
Formulação de Consultas
Muitos tipos de consultas complexas podem ser formuladas como um problema de encontrar um grupo de objetos de determinados tipos que são ligados por certas relações. Isto se traduz em padrões gráficos, mas, embora tais padrões sejam fáceis para formalizar a consulta no contexto semântico, elas permanecem problemáticas porque não são fáceis de formular para os usuários (Hoang and Tjoa, 2006).
Visando auxiliar o usuário na formulação de consultas, Athanasis (Athanasis et al., 2004) e Franconi (Franconi et al., 2010) propõem uma interface gráfica de usuário que apresenta um padrão para construção da consulta baseada em navegação pela ontologia, onde o usuário parte da seleção de uma classe e, por meio de navegação, pode especificar os artefatos para consulta entre as propriedades aplicáveis para a classe selecionada.
Outro padrão que tem se mostrado como um poderoso paradigma de busca é o baseado em visões múltiplas (Makela et al., 2004) combinado com o uso de ontologias (Hyvonen and Viljanen, 2003). Nesta abordagem muitas visões distintas são previstas para os
3.1. INTERFACES BASEADAS EM ONTOLOGIA
dados. Essas visões são criadas por projeção de ontologias usando também vários outros relacionamentos hierárquicos inerentes à ontologia.
A busca por palavra-chave com uso de ontologias também aparece entre as aborda-gens para formulação de consultas baseadas em ontologias. Muitas implementações de expansão e consultas fazem uso de thesaurus como um passo em expansão de consultas como o apresentado por Buscaldi (Buscaldi et al., 2007). Uma dessas técnicas bem co-nhecida é o uso do WordNet (Fellbaum, 1998). Esse tipo de sistema funciona em processo básico onde: primeiro as palavras-chave são localizadas na ontologia, então, vários outros conceitos são localizados depois que os termos relacionados a estes conceitos são usados para ampliar ou restringir a busca.
As abordagens que fazem uso exclusivamente de palavras-chave não serão analisadas neste trabalho por consistirem, geralmente, em recuperação de texto, onde o objetivo é encontrar conceitos relacionados em uma coleção de documentos, mas serão tratadas abordagens que combinam o uso de palavras-chave com a busca baseada em visões.
3.1.2
Interação do Usuário
As abordagens encontradas para interação do usuário em consultas baseadas em ontologia apresentam a interação do usuário no processo de refinamento de consultas. Stojanovic (Stojanovic et al., 2004) apresenta uma abordagem para refinamento de consultas baseadas em ontologias que é fundamentada na interação do usuário durante o incremento e adaptação de uma consulta de acordo com as necessidades do usuário. Estas necessidades são implícitas e provocadas durante o processo de pesquisa pela análise do comportamento do usuário. O intervalo entre a necessidade do usuário e sua consulta é quantificado pela medição de vários tipos de ambiguidades de consulta. Consequentemente, no processo de refinamento o usuário recebe uma lista ordenada de refinamentos sugeridos pelo sistema, que deverão diminuir as ambiguidades.
Além dos refinamentos sugeridos pelo sistema, a abordagem permite ao usuário, por meio de uma exploração mais profunda da ontologia, a detecção de resultados semelhantes que devem ajudar o usuário a satisfazer a sua necessidade.
3.2. INTERFACES DE PEER DATA MANAGEMENT SYSTEMS - PDMS
3.2
Interfaces de Peer Data Management Systems - PDMS
Um PDMS, de uma maneira geral, consiste em um conjunto de peers, cada um atuando como um componente de integração de informação. Consultas submetidas num peer são respondidas tanto com dados locais como com dados de outros peers da rede em que este se encontra. Esses outros peers são alcançados por meio de caminhos e mapeamentos definidos entre os peers na rede.
Diversos autores (Adjiman et al., 2007; Castano et al., 2003; Mandreoli et al., 2008; Montanelli and Castano, 2008) apresentam abordagens para o processamento de consultas baseadas em ontologias para PDMS . Dentre os que trazem proposta de interfaces de usuário na formulação e submissão de consultas foi possível estabelecer uma classificação baseada na metodologia ou técnica utilizada para formulação de consultas. Para esta classificação temos: interfaces de consulta baseadas em navegação; interfaces de consulta baseadas em múltiplas visões e interfaces de consulta baseadas em palavras-chave. Den-tre estas, serão consideradas as abordagens para formulação de consultas baseadas em navegação e múltiplas visões, onde esta última combina o uso de palavras-chave em sua técnica. Além destas abordagens baseadas em ontologias, serão abordadas também um outro tipo de interface que permite ao usuário explorar o caminho mais promissor para o roteamento de consultas na rede.
3.2.1
Interfaces de Consulta Baseadas em Navegação
Como dito anteriormente, algumas abordagens (Athanasis et al., 2004; Franconi et al., 2010; Beneventano et al., 2007) propõem interfaces gráficas de usuário que apresentam um padrão para construção da consulta baseada em navegação pela ontologia, onde o usuário parte da seleção de uma classe e, por meio de navegação, pode especificar os artefatos para consulta entre as propriedades aplicáveis para a classe selecionada. Nesta seção, serão descritas algumas abordagens que propõem este tipo de interface de usuário.
Query Tool(Franconi et al., 2010)
Franconi (Franconi et al., 2010) propõe um framework formal juntamente com um softwarepara formulação de consultas precisas capturando da melhor maneira as informa-ções que o usuário necessite, de modo que o seu uso pode ser feito sem o conhecimento
3.2. INTERFACES DE PEER DATA MANAGEMENT SYSTEMS - PDMS
sobre os sistemas que mantêm os dados. A interface de consulta utiliza técnicas de busca automática através do uso de linguagens naturais sobre ontologias que descrevem o domínio dos dados. A implementação do framework é chamada Query Tool que consiste em três componentes baseados numa arquitetura Web cliente-servidor:
• Query Logic (QueLo) - Módulo responsável por implementar a lógica das consultas sobre as ontologias para o fornecimento apenas de informações relevantes;
• Natural Language Generation (NLG) - A função deste módulo é fazer um mapea-mento de uma consulta com ontologias para uma sentença em linguagem natural (inglês); e
• User Interface (UI) - A interface de consulta fornece um acesso visual para realiza-ção de buscas permitindo a interarealiza-ção entre os módulos QueLo e NLG.
Figura 3.1: Protótipo da interface de consulta da Query Tool (Franconi et al., 2010)
A Query Tool pode ser utilizada por usuários que não possuem conhecimento sobre a organização dos dados ou do vocabulário utilizado na ontologia. Em um cenário onde existe um modelo conceitual descrito por uma ontologia e não se sabe nada sobre o domínio dos dados, a Query Tool é utilizada para mostrar particularidades que permitem descobrir informações sobre a ontologia e o domínio modelado. Inicialmente o usuário pode fazer uma busca em nível bem abstrato e a Query Tool fornece operações que pode-rão ser utilizadas para a manipulação da consulta, sendo: add para adicionar novos termos e relações; substitute para alterar parte da consulta com informações mais específicas ou gerais; delete para excluir partes da consulta; e weaken para tornar parte da consulta o mais geral possível. O protótipo da interface de consulta proposta é mostrado na Figura
3.2. INTERFACES DE PEER DATA MANAGEMENT SYSTEMS - PDMS
3.1.
Graphical RQL (GRQL) (Athanasis et al., 2004)
Athanasis (Athanasis et al., 2004) apresenta uma abordagem para interface gráfica de consulta expressa em RDF Query Language (RQL), uma linguagem de consulta declarativa para RDF, e formulada por navegação. Essa interface recebe o nome de GRQL. Nessa abordagem, primeiramente uma classe na ontologia é selecionada como ponto inicial. Todas as propriedades definidas como aplicáveis à classe na ontologia são então dadas por expansão. Clicando em uma propriedade expande-se o grafo para conter aquela propriedade e move-se a seleção para o intervalo de classe definido por aquela propriedade. Por exemplo, na Figura 3.2, clicando em “creates property” na classe Artistcria o padrão “Artist → creates → Artifact”, e move o foco para a classe Artist, mostrando as propriedades para aquela classe para futuro caminho de expansão.
Além de alongar o caminho, outras operações podem ser realizadas nesse padrão de consulta. Este pode, por exemplo, ser mais rigoroso com relação a algumas subclasses de uma classe, como o artefato “Painting or Sculptures” no exemplo visto anteriormente para “Artist → creates → Painting or Sculpture”. Da mesma maneira, as definições de restrições da propriedade podem ser mais rigorosas em subpropriedades. Consultas mais complexas podem ser formuladas visitando um nó criado anteriormente e ramificações da expressão, criando padrões como o representado na Figura 3.2.
Figura 3.2: Navegando para criação de um padrão de consulta do GRQL (Athanasis et al., 2004)
SEWASIE (Beneventano et al., 2007)
Beneventano (Beneventano et al., 2007) apresenta o SEmantic Web and AgentS in Integrated Economies(SEWASIE), um sistema que implementa um mecanismo de busca avançado que permite o acesso inteligente a fontes de dados heterogêneas na Web via enriquecimento semântico.
