Uma Proposta de Arcabouço para Implementação de Comunidades Virtuais de Prática no Contexto da Web Semântica

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA MÁRCIO DE SOUZA BALIAN Uma Proposta de Arcabouço para Implementação de Comunidades Virtuais de Prática no Contexto da Web Semântica Goiânia 2007

2 MÁRCIO DE SOUZA BALIAN Uma Proposta de Arcabouço para Implementação de Comunidades Virtuais de Prática no Contexto da Web Semântica Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Ciência da Computação. Área de concentração: Sistemas de Informação. Orientador: Prof. Dr. Cedric Luiz de Carvalho Co Orientador: Prof. Dr. Fábio Nogueira de Lucena Goiânia 2007

3 MÁRCIO DE SOUZA BALIAN Uma Proposta de Arcabouço para Implementação de Comunidades Virtuais de Prática no Contexto da Web Semântica Dissertação defendida no Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás como requisito parcial para obtenção do título de Mestre em Ciência da Computação, aprovada em 03 de Agosto de 2007, pela Banca Examinadora constituída pelos professores: Prof. Dr. Cedric Luiz de Carvalho Instituto de Informática UFG Presidente da Banca Prof. Dr. Fábio Nogueira de Lucena Instituto de Informática UFG Prof. Dr. Hugo Alexandre Dantas do Nascimento INF UFG Prof. Dra. Maria da Graça Campos Pimentel ICMC USP

4 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). Márcio de Souza Balian Graduou-se em Ciência da Computação na Universidade Católica de Goiás. Especializou-se em Orientação a objetos e internet na UniAnhanguera - Centro Universitário de Goiás. Direcionou estudos e trabalho em desenvolvimento de sistemas para a Web e orientação a objetos. Seguindo a evolução da Web, pesquisa e desenvolve soluções que contribuam com o desenvolvimento da Web Semântica.

5 1. Web Semântica. 2. Comunidades Virtuais de Prática. 3. Desenvolvimento de Arcabouços Orientados a Objetos.

6 Dedico esse trabalho à minha esposa, Núbia.

7 Agradecimentos Agradeço à minha maravilhosa esposa, Núbia, pelo amor, carinho, companheirismo e incentivo em todos os momentos. Sou eternamente grato a meus queridos pais, avós e irmãos, que sempre me apoiaram e incentivaram em tudo. Agradeço aos meus amigos do CPD e da PROPE, da Universidade Católica de Goiás, pela compreensão, apoio e paciência nos momentos em que não pude estar presente. Agradeço ao professor Cedric, por acreditar em mim e no meu trabalho, e por todas as orientações e conhecimento dos quais comigo pôde compartilhar. Sou igualmente grato ao professor Fábio Lucena, pelas diretrizes e caminhos que ajudaram na implementação, além da paciência e profissionalismo nas revisões do trabalho. Obrigado a todos os amigos, colegas, professores e funcionários do INF pelo apoio e presteza. Sem dúvida, sem o convívio com todas essas pessoas especiais, a conclusão deste trabalho não seria possível. Por fim, em um plano superior, agradeço ao Senhor Jesus, pois, sem Ele, nada é possível.

8 A coisa mais indispensável a um homem é reconhecer o uso que deve fazer do seu próprio conhecimento. Platão, Filósofo Grego.

9 Resumo Balian, Márcio de Souza. Uma Proposta de Arcabouço para Implementação de Comunidades Virtuais de Prática no Contexto da Web Semântica. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. Esta dissertação relaciona as Comunidades Virtuais de Prática (CoPs) à Web Semântica e descreve o desenvolvimento de um arcabouço a para CoPs no contexto da Web Semântica. Trata-se de um subprojeto do Projeto DWeb, que visa contribuir com a consolidação e o desenvolvimento da Web Semântica, oferecendo um ambiente para estabelecimento de CoPs na Internet a partir dos princípios da Web Semântica definidos pelo W3C (World Wide Web Consortium). Demonstra-se o levantamento de um domínio de aplicações com características em comum para a elaboração do projeto de um arcabouço, o SCOP - Semantic CoPs Framework, modelado a partir de tais características. O arcabouço é classificado como uma ferramenta para construção de ambientes de Comunidades Virtuais de Prática que utilizem de recursos da Web Semântica (idéias, ferramentas e linguagens), auxiliando na construção de sistemas colaborativos baseados em comunidades e sistemas de gestão de conhecimento através de ambientes colaborativos. Por fim, o SCOP é utilizado em um estudo de caso: o desenvolvimento de um ambiente de CoPs baseado em Wiki Web, o ACW. a O termo arcabouço é usado nesta dissertação como tradução do termo framework. Palavras chave Objetos. Web Semântica, Comunidades Virtuais de Prática, Arcabouços Orientados a

10 Abstract Balian, Márcio de Souza. A Framework Proposal for building Semantic Virtual Communities of Practice. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. This work describes the development of a framework to build Virtual Communities o Practice (CoPs) in the Web. It is part of a larger project named DWeb (acronym for Dream Web) that aims to contribute to the development of the Semantic Web, offering an environment to implant CoPs in the Internet. This is possible through W3C (World Wide Web Consortium) Semantic Web principles. It is shown a frameworkdevelopment, the SCOP (Semantic CoPs Framework), that aims to support application development inside a domain: environments for CoPs establishing in a Semantic Web context. The framework can be classified as a tool to build virtual communities environments that makes use of Semantic Web resources (ideas, tools and languages), helping in construction of collaborative systems based on communities and in knowledge management through collaborative environments. Finally, SCOP is used in the development of ACW, a wiki based semantic CoPs environment. Keywords Development. Semantic Web, Virtual Communities of Practice, Object Oriented Frameworks

11 Sumário Lista de Figuras 13 Lista de Tabelas 14 Lista de Códigos de Programas 16 1 Introdução Motivação Objetivos Organização da dissertação 19 2 Organização da Informação Indexação e Recuperação da Informação Padrões e Metadados Suporte à Gestão do Conhecimento 22 3 Comunidades Virtuais de Prática - CoPs Histórico Características Dimensões de uma CoP CoPs em meio virtual 26 Comunidades Virtuais 26 Ambientes Virtuais que oferecem suporte a CoPs 27 4 Web Semântica Web Semântica - Visão Geral RDF - Resource Description Framework RDFS - RDF Schema Classes Propriedades Ontologias O arcabouço Jena A Base RDF O uso de ontologias Inferência 40

12 5 Trabalhos sobre CoPs e Web Semântica Wiki Webs ICOX - Gerenciador de Inteligência Coletiva Semantic Media Wiki / Ontoworld Platypus Wiki OntoShare Second Messenger 49 6 Arcabouço SCOP Arcabouços orientados a objetos Metodologias para construção de arcabouços SCOP - Análise do Domínio de Aplicação Requisitos das Aplicações 55 Ambiente para formar e gerenciar CoPs 55 Wiki semântica 56 Ambiente semântico para compartilhamento de artigos e documentos 57 Ambiente para discussões e ajuda mútua com uso de fórum semântico Requisitos do SCOP Considerações Complementares sobre os requisitos do arcabouço Projeto e Arquitetura do SCOP Manutenção de CoPs e Membros O grafo RDF dos Recursos Ferramentas Organização dos Recursos e Propriedades Domínio de Conhecimento 71 7 Ambiente ACW: um Estudo de Caso Requisitos do ACW Diagrama de Classes do ACW Funcionamento da Ferramenta Wiki Geração de recursos e manipulação da base RDF Ferramentas para o projeto do ACW Interfaces e Códigos do ACW Principais funções do ambiente 80 Adicionando uma pessoa 80 Opções Iniciais 81 Associando pessoas e comunidades 82 Ferramentas da Cop 84 Inclusão de Recursos 86 Incluindo Recursos na Base RDF 86 Interligando recursos 87 Buscando recursos dentro do contexto Observações sobre o uso do SCOP O uso do arcabouço Considerações finais sobre o estudo de caso 90

13 8 Conclusão 92 Referências Bibliográficas 95

14 Lista de Figuras 3.1 Levantamento de ferramentas para suporte a CoPs de Wenger, em 2001 [55] Grafo RDF gerado pelo Código Grafo RDF gerado pelo Código Jena Ontology API - Estrutura interna com importações [24] Fluxo de informações genérico em uma wiki não semântica Exemplo de fluxo de informações em uma wiki semântica Estrutura Ontológica no ambiente OntoShare [9] Arquitetura do Second Messenger [13] Exemplo de reutilização de classes com e sem um arcabouço Esquema do conjunto da aplicações de um domínio Diagrama de Classes do SCOP Classes para Manutenção de CoPs e Membros Classes para Manutenção da Base de Recursos Classes para interação dos de Recursos com um domínio de Conhecimento Diagrama de casos de uso do ACW Diagrama de classes do ACW Interface para adição de pessoa no ACW Interface inicial após autenticação Interface tornar-se membro ou abandonar CoPs Interface inicial após autenticação Tela da ferramenta wiki mostrando o recurso inicial Tela da ferramenta wiki de edição/inclusão de recurso Tela para interligação de recursos da CoP 87

15 Lista de Tabelas 6.1 Atributos e Métodos da Classe Person Atributos e Métodos da Classe Member Atributos e Métodos da Classe CoP Atributos e Métodos da Classe CopResourceBase Atributos da Classe CopTool Atributos da Classe CopResource Atributos e métodos da Classe NameSpace Atributos e métodos da Classe CopProperty Atributos e métodos da Classe CopKDomain 73

16 Lista de Códigos de Programas 2.1 Uso de metatag para referenciar o autor do documento Código Java para criar um grafo RDF usando o JENA Código de exemplo para gerar o grafo de forma persistente, usando o banco de dados MySQL Código para expandir o grafo da Figura Código para percorrer uma lista gerada a partir de um grafo RDF Código para importar e ligar ontologias ao grafo RDF Código para criar e consultar um modelo de inferência Código wiki de um artigo no OntoWorld Código para adicionar uma pessoa no ACW Código para incluir uma pessoa em uma CoP Código para atribuir uma ferramenta (wiki) a uma Cop Código para adicionar um recurso à Cop Código para adicionar um recurso à CoP Código para localizar recursos na CoP 89

17 Introdução CAPÍTULO Motivação O crescimento exponencial das páginas da Internet e algumas limitações tecnológicas, principalmente ligadas à dificuldade de indexação de informações, criaram a necessidade de uma nova abordagem ou extensão do modelo atual da Web: a Web Semântica. A informação na Web atual é direcionada para leitura e interpretação por seres humanos. A ausência de processamento semântico automatizado e a deficiência de suporte ao intercâmbio de conhecimento são alguns dos fatores que motivaram este trabalho. A Web Semântica procura resolver o problema da organização de informações na Web e, com isso, aumentar as possibilidades de uso em termos de organização e recuperação de informações. O desenvolvimento da Web Semântica é possível através da criação de ferramentas e padrões que permitam associar significados aos recursos da Web, de tal forma que possibilite o processamento automatizado sobre tais recursos e estimule a construção de sistemas inteligentes de recuperação de informações. Com esta nova abordagem, pode-se ter ambientes construídos com uso combinado de ferramentas e tecnologias para anotação semântica das páginas e recursos da Web e para o desenvolvimento de ontologias compartilhadas, aproximando a Web Semântica de um sistema de recuperação de informações (SRI) global [41]. O desenvolvimento de ambientes de Comunidades Virtuais de Prática (CoPs), dentro do contexto da Web Semântica, é especialmente interessante por possibilitar o trabalho em um domínio de conhecimento específico. Um dos aspectos primordiais que define uma CoP é seu domínio de conhecimento. A segmentação conceitual deste domínio específico possibilitado pelas CoPs ocasiona um ambiente propício para desenvolvimento da Web Semântica [11]. De forma breve, uma CoP é uma comunidade de pessoas com interesses em comum cujo foco são práticas e trabalhos cotidianos. Ela pode ser vista como uma identidade de um grupo de pessoas. Tal grupo pode se reunir com objetivos de prover

18 1.1 Motivação 17 um meio para a troca de conhecimento e práticas, que pode ser coletado e armazenado para futura referência e recuperação. A globalização e a conseqüente dispersão geográfica das relações de trabalho, aliadas à necessidade de trocas de informações e recursos de forma mais transparente entre grupos que trabalhem em projetos ou áreas semelhantes, sugerem um cenário onde se possa agrupar esses macro-requisitos na implementação de um arcabouço. Diversos ambientes virtuais já implementavam funcionalidades típicas de uma CoP, mesmo antes do surgimento do conceito e estudo das Comunidades de Prática. As comunidades online, de forma geral, se expandiram. Porém, tal expansão se deu nos moldes da expansão do meio que possibilitou seu crescimento: a Web. Uma das características mais importantes de uma CoP é o compartilhamento de recursos, ou seja, dos artefatos produzidos pelos seus membros. Em uma comunidade construída sem preocupações semânticas, as buscas por recursos são puramente sintáticas. Alguns problemas comuns em ambientes de comunidades sem preocupações semânticas incluem: Ambigüidade. Recursos recuperados podem pertencer a um contexto diferente do esperado pelo membro da comunidade. Por exemplo: um membro de uma comunidade cujo contexto seja estruturas de dados busca por documentos com o termo cadeia. É possível que ele localize fontes de informação acerca de presídios, o que não é desejável. Definições compartilhadas. Recursos que tratam de um mesmo assunto ou compartilham definições podem não ser recuperados por não conterem indicadores correspondentes. Por exemplo: um usuário busca por um artigo sobre álcool etílico. Um possível artigo sobre etanol pertencente ao repositório de artigos da comunidade não seria recuperado. Navegabilidade. Se não houver possibilidade de se estabelecer relacionamentos entre recursos, a partir de um documento recuperado, outros pertinentes podem não ser obtidos. Problemas dessa natureza são o foco do projeto DWeb 1 e motivam o desenvolvimento de ferramentas com foco nas melhorias e soluções para os mesmos, dando suporte a ambientes de trabalho colaborativos, como as CoPs, incrementadas com o uso de tecnolo- 1 O projeto DWeb [11] está em desenvolvimento no INF/UFG com a participação de professores e alunos. O projeto visa contribuir com a consolidação da Web Semântica propondo um ambiente baseado em CoPs, onde recursos de informação possam ser tratados semanticamente, agregando inteligência, interoperabilidade e integração ao ambiente Web Existente. A idéia é construir um ambiente intuitivo e universal para compartilhamento de dados, informação e conhecimento de forma transparente e acessível.

19 1.2 Objetivos 18 gias da Web Semântica, que oferecem interoperabilidade de recursos e permitem agregar funcionalidades inteligentes para organização e recuperação do conhecimento gerado. 1.2 Objetivos Organizar semanticamente a informação e possibilitar o desenvolvimento de sistemas em um modelo de comunidades virtuais com interesses específicos e bem definidos de atividades é o foco deste trabalho. Pretende-se apresentar, através do projeto de um arcabouço orientado a objetos, o SCOP (Semantic CoPs Framework), uma estrutura de classes inter-relacionadas que facilite o desenvolvimento de ambientes de CoPs. Estes ambientes são desenvolvidos a partir de uma realidade possibilitada pela Web Semântica, no sentido de viabilizar a delimitação do contexto básico das CoPs, dar sentido e orientação às relações e possibilitar o compartilhamento de informações e conhecimento de forma mais transparente entre seus membros. O desenvolvimento do arcabouço tem como objetivos: Contribuir com o avanço do projeto DWeb, facilitando o estabelecimento das CoPs em ambiente Web, dentro e fora de organizações, através do auxílio à construção de ferramentas de apoio a CoPs; Contribuir com estudos posteriores nas áreas de Gestão do Conhecimento, Ciência da Informação e Trabalho Colaborativo. Facilitar o desenvolvimento de ambientes de interação e colaboração entre usuários e contribuir, indiretamente, com novos requisitos gerados a partir de pesquisas e estudos nestas áreas, que serão paulatinamente incluídos no arcabouço, produzindo extensões do SCOP ou novos projetos que objetivem auxiliar diferentes abordagens de ferramentas. Motivar o uso de conceitos, estruturas e linguagens da Web Semântica em ambientes direcionados para o trabalho com informações, conhecimento e colaboração. É importante ressaltar que este trabalho pretende ser uma contribuição inicial para a o projeto DWeb e para pesquisas relacionadas ao mesmo. Seu foco na metodologia para se alcançar os objetivos acima são prioritários em relação à visão do SCOP como produto para desenvolvimento facilitado e acelerado de ambientes de comunidades. Embora relevantes, tópicos como qualidade de software e padrões de projeto, dentre vários outros, não foram a ênfase deste trabalho que visa estabelecer uma infraestrutura inicial que servirá de referência para esforços futuros.

20 1.3 Organização da dissertação Organização da dissertação O Capítulo 2 introduz alguns conceitos pertinentes à Ciência da Informação e desenvolve a contextualização teórica referente ao trabalho proposto, explicitando os aspectos mais relevantes sobre indexação, metadados e recuperação da informação. Inclui conceitos de Gestão do Conhecimento e os relaciona com comunidades de prática. Adicionalmente, estabelece o contexto onde se localiza o SCOP (arcabouço proposto neste trabalho). O Capítulo 3 é dedicado a comunidades, especialmente Comunidades Virtuais de Prática (CoPs). São estabelecidas as diferenças fundamentais entre os tipos de comunidades, visando a compreensão do domínio de aplicações a ser atendido pelo arcabouço. São discutidos os recursos e ferramentas comuns e desejáveis a ambientes de CoPs, além de apresentados alguns projetos que abrangem CoPs, mesmo sem preocupações semânticas. O Capítulo 4 discorre sobre a Web Semântica e especifica alguns de seus recursos e linguagens relevantes para a construção do SCOP. Inclui informações sobre o arcabouço Java Jena para a Web Semântica. O Capítulo 5 relaciona CoPs e Web Semântica, apresentando alguns projetos e trabalhos incluídos nesta abordagem e que contribuíram com a definição do SCOP. Este capítulo introduz o arcabouço SCOP e o relaciona com toda a fundamentação teórica até então apresentada. O Capítulo 6 descreve etapas e aspectos do desenvolvimento do arcabouço SCOP. Primeiramente, apresenta um levantamento de tópicos importantes para a compreensão da construção de arcabouços orientados a objetos. Em seguida, apresenta e discute a arquitetura do SCOP, propriamente dita. O Capítulo 7 descreve um estudo de caso: o desenvolvimento da aplicação ACW (Ambiente de CoPs baseado em wiki), desenvolvido com apoio do SCOP. Em seguida, apresenta aspectos de uso do arcabouço e observações obtidas do desenvolvimento do ACW. O Capítulo 8 fornece as considerações finais sobre o trabalho, aspectos positivos, contribuições e limitações a serem eliminadas em iniciativas futuras.

21 Organização da Informação CAPÍTULO Indexação e Recuperação da Informação Documento, ciclo documentário, indexação e recuperação da informação são conceitos amplamente conhecidos da Ciência da Informação[15]. Um documento é um objeto que fornece um dado ou uma informação e possui definidas características físicas, relacionadas a material, peso e forma de produção, dentre outras, além de características intelectuais, tais como objetivo, conteúdo, assunto, originalidade e outros. Ciclo documentário compreende as etapas de entrada de documentos, atividades de processamento e produtos documentários. Dentre as atividades de processamento, destaca-se a indexação como um tratamento que visa facilitar a recuperação do documento ou da informação. Indexação é a operação de representar o conteúdo dos documentos, qualquer que seja o método utilizado [39]. Um serviço de indexação deve garantir que determinado documento ou informação seja identificada. O produto gerado pela indexação é o índice, que pode ser disponibilizado em formatos diversos, física ou eletronicamente. Geralmente são inseridos em bases de dados ou estruturas de dados diversas [32, 21]. Com um índice eletrônico, é possível realizar consultas automáticas com o propósito de recuperar documentos e informações por ele referenciado, seja utilizando consultas com operadores booleanos (e/ou/não), ou através de algoritmos que se baseiam em pesos dos termos para ordenação de resultados do índice. Com o crescimento da Web e o conseqüente aumento exponencial das fontes de informação, empresas e pesquisadores têm desenvolvido soluções de indexação e recuperação automática de informações voltadas para a Web. Algumas destas ferramentas atuam como grandes diretórios de pesquisa, que incluem sites em áreas pré-classificadas; outras ferramentas são classificadas como grandes mecanismos de busca, atuando através de agentes de software que percorrem a Internet indexando sites em suas bases de dados.

22 2.2 Padrões e Metadados 21 Além de serviços de busca e diretórios, existem na Web serviços de metabusca. Estas ferramentas trabalham sobre os resultados retornados de outros mecanismos de busca e apresentam tais resultados ao usuário de uma forma mais elaborada, tentando minimizar problemas como a diferença de quantidade e qualidade de informações ao se buscar em mecanismos distintos, ou aplicando técnicas de visualização de informações nos resultados mostrados ao usuário. O mecanismo de busca Google [20] introduziu o operador semântico em 2003, para o idioma inglês. Com isso, buscas retornam, além do termo pesquisado, termos que tenham relações semânticas (por exemplo, sinônimos) com o termo pesquisado. Uma busca pelo termo bike também retorna resultados que contenham o termo motorcycle ou bicycle, por exemplo. 2.2 Padrões e Metadados Voltados para a otimização de páginas na indexação por mecanismos de busca, os metadados (dados acerca de dados) começaram a ser usados. Informações como autor, descrição, resumo, idioma são acrescentadas através de metatags (com uso da tag <meta> em documentos HTML). O Código 2.1 exemplifica a referência ao autor de um documento, objetivando a otimização da indexação por mecanismos de busca. Código 2.1 Uso de metatag para referenciar o autor do documento 1 <!DOCTYPE...> 2 <html xmlns=" 3 <head> 4 <meta name="author" content="fulano de Tal" /> 5 <title>documento exemplo</title> 6 </head> 7 <body> 8 <p>corpo do Documento</p> 9 </body> 10 </html> Atualmente, núcleos (cores) de metadados têm sido formados, de forma a padronizar seus usos e aplicá-los na evolução da Web Semântica. Isto significa que, uma vez bem definidos, os metadados podem ser usados para se estender a Web para uma nova versão, em que os documentos ou recursos em geral possuam significado definido. Tais recursos, acompanhados de tecnologias da Web Semântica, podem ser compreendidos e interpretados por máquinas, sejam mecanismos de busca ou sistemas de informação corporativos. Um exemplo de núcleo de metadados importante na descrição de recursos é a inciativa Dublin Core [10]. No Capítulo 4, são apresentados aspectos da Web Semântica, como o padrão RDF e RDFS para descrição de recursos.

23 2.3 Suporte à Gestão do Conhecimento 22 Descrever recursos, relacioná-los a outros recursos ou a padrões de metadados definidos na Web é um importante requisito do SCOP. O objetivo dessas atividades é permitir a recuperação da informação de maneira eficiente. Espera-se que o usuário possa recuperar documentos relevantes de forma transparente e que este mesmo usuário possa oferecer documentos relevantes de forma organizada e padronizada. Para se conseguir isso é desejável que se delimite o contexto ao qual os recursos se vinculam. Isso é possível especialmente quando pessoas estão agrupadas, buscam informações e compartilham suas experiências cotidianas, gerando conhecimento dentro do domínio de interesse. Pessoas agrupadas em torno dos mesmos interesses formam comunidades que compartilham recursos sobre suas atividades em um ambiente capaz de interligá-los semanticamente. Este é o contexto do trabalho descrito por esta dissertação. O SCOP visa oferecer serviços de alto nível aos seus usuários (desenvolvedores de aplicações), que facilitem a implementação desses requisitos. 2.3 Suporte à Gestão do Conhecimento Tom Davenport e Laurence Pruzac, em [8], definem conhecimento e diferenciam tal termo de dados e informações. Dados e informações estão relacionados à codificação de fatos, métodos, princípios, técnicas, etc. Essa codificação pode ser na forma de um livro, um artigo ou um manual, por exemplo. A definição de conhecimento é mais rica: Conhecimento é uma mistura de experiências, valores, informações contextuais, percepção aprofundada que oferece uma estrutura para avaliar e incorporar novas experiências e informações. O conhecimento se origina e se aplica na mente dos conhecedores. Nas organizações, ele sempre se materializa não somente em documentos ou repositórios, mas também em rotinas organizacionais, processos, práticas e normas. [8] De forma resumida, gerir conhecimento é sistematizar processos para que membros de uma organização detectem, selecionem, organizem, filtrem, apresentem e utilizem a informação. O objetivo de tais processos é a exploração colaborativa dos recursos da organização [8]. Muito do que as pessoas fazem em uma organização ocorre no contexto de Comunidades de Prática. As CoPs são caracterizadas pelo compartilhamento do conhecimento entre os membros. As pessoas compartilham aquilo que conhecem e suas experiências sobre algo inserido no domínio da CoP. Soluções, experimentos, resultados, procedimentos, enfim, valor agregado ao conhecimento de uma organização pode se consolidar através de uma CoP [36]. Percebe-se que uma comunidade de prática bem estruturada, assunto do Capítulo 3, pode ser vista como um ambiente colaborativo capaz de oferecer suporte a sistemas

24 2.3 Suporte à Gestão do Conhecimento 23 aplicados em Gestão de Conhecimento, principalmente se somadas a recursos da Web Semântica, os quais são apontados no Capítulo 4. Estruturar bem uma CoP significa dar suporte a um ambiente que possibilite estimular interação e aprendizado entre os membros, criação de conhecimento e identificação e compartilhamento das melhores práticas. A missão de uma CoP é, resumidamente, alcançar tais resultados [36]. Para agregar valor a uma organização, deve-se facilitar ou tornar possível a identificação, a criação e a gestão de conhecimento. Essas três tarefas fazem parte de uma realidade atual e fundamental para qualquer organização. Ferramentas de Tecnologia da Informação como as que podem ser desenvolvidas com uso do SCOP - e sistemas colaborativos que dão suporte à gestão do conhecimento - contribuem para que estes processos sejam realizados de maneira mais eficiente. O Capítulo 6 apresenta a arquitetura do SCOP e o que esta oferece para a construção de ambientes focados em tarefas como localização e compartilhamento de recursos, os quais, por serem produzidos em um contexto de CoP, expressam as melhores práticas de seus usuários. O SCOP pode ser visto como uma ferramenta para auxiliar na construção de ambientes virtuais de gestão de conhecimento, pois contém estruturas que permitem capturar o conhecimento, organizá-lo e distribuí-lo, sempre considerando uma estrutura hierárquica criada e mantida no contexto da comunidade.

25 Comunidades Virtuais de Prática - CoPs CAPÍTULO 3 Este capítulo oferece uma visão geral das comunidades virtuais de prática, independentemente do meio utilizado para apoiá-las. A partir desta visão, pode-se perceber que os elementos de união dos membros desse tipo de comunidade não são a proximidade ou o ambiente, mas sim as relações entre eles. As características aqui fornecidas estabelecem um contexto onde recursos do SCOP podem ser definidos. 3.1 Histórico O termo Comunidades de Práticas (CoPs) só começou a ser utilizado no início dos anos 90, por Jean Lave e Etienne Wenger para designar o tipo de aprendizado que se fazia através de práticas de trabalhos, embora esta espécie de comunidade já existisse. Por exemplo, um ambiente (apprenticeship) onde os empregados de uma organização aprendiam dentro do trabalho. Embora todos os exemplos de comunidades dessa natureza foram baseados no modelo citado (apprenticeship model), enfatizaram que as CoPs não se restringiam a tal modelo [23]. Lave e Wenger, em 1991, propuseram um modelo de aquisição de conhecimento como um processo social em que as pessoas podiam participar do aprendizado comum em diferentes níveis, variando conforme a autoridade e antigüidade no grupo. Por exemplo, um iniciante atingia o status de sênior à medida que aprendia dentro do grupo (Participação Periférica Legitimada - LPP). Assim, um membro iniciaria sua participação periférica, podendo adquirir o conhecimento do domínio da comunidade e, em seguida inserir-se no contexto de aquisição de conhecimento associada a práticas específicas de trabalho dentro da comunidade. Tais práticas poderiam se tornar mais complexas com o aumento do aprendizado, elevando o grau de autoridade do membro a princípio iniciante. As CoPs de Lave e Wenger atraíram a atenção de pesquisadores e membros de comunidades, que gradualmente foram estendendo a noção das CoPs e aplicandoa no contexto de Gestão do Conhecimento. Desde então têm-se trabalhado muito na observação das CoPs, seus funcionamentos e na identificação de suas características.

26 3.2 Características Características Uma CoP é caracterizada por três aspectos primordiais, também chamados de dimensões: o domínio de conhecimento, a comunidade e a prática [54] Dimensões de uma CoP O domínio de conhecimento é o contexto da comunidade. Ele caracteriza o interesse compartilhado. Cada membro deve possuir um nível mínimo de conhecimento do domínio [54]. Essa característica é essencial para se relacionar as CoPs com a Web Semântica. Esse relacionamento será discutido posteriormente e é fundamental para o projeto do SCOP. Um contexto partilhado é essencial para o desenvolvimento de uma comunidade, pois dá sentido e orientação às conversas que ocorrem e pode ajudar as pessoas a decidir em que direção levar a comunidade. O contexto pode incluir propósito, conteúdo, história e valores, além de tornar explícito o domínio de conhecimento compartilhado, o que pode ser decisivo para o sucesso ou não de uma CoP. Outra dimensão de uma CoP é a comunidade, ou seja, a forma como os membros se mantêm engajados em atividades conjuntas, discussões, ajuda mútua e compartilhamento de informações. A interação é requisito chave para membros pertencerem a uma comunidade. Dessa forma, o funcionamento das CoPs têm seu início na maneira como as pessoas se tornam membros, ou seja, através do compartilhamento de práticas. São ligadas entre si através do envolvimento mútuo em atividades em comum. Este é o acoplamento mútuo que liga os membros de uma CoP como uma entidade social [54]. Outra dimensão que define uma CoP é a produção de seus membros. Concentrase nos repertórios compartilhados, que representam os traços materiais da comunidade. São exemplos: arquivos escritos, procedimentos, documentos, políticas, rituais e idiomas específicos. As CoPs refletem as atividades cotidianas de seus membros. O propósito comum é a motivação chave. Os membros das comunidades têm o mesmo conjunto de metas e propósitos. No caso das Comunidades com foco em prática, tal conjunto de propósitos é centrado na partilha de conhecimento entre um grupo de praticantes e, por essa razão, as CoPs eficazes estão estruturadas principalmente em torno de atividades de compartilhamento de conhecimento. A opção de dar suporte a este tipo de comunidade pelo SCOP está diretamente relacionada às suas três dimensões. Dentre elas, o domínio de conhecimento se destaca por possibilitar a delimitação do contexto compartilhado pelos membros. As dimensões prática e comunidade são possibilitadas pelo uso de ambientes que oferecem suporte ao compartilhamento de conhecimento, possibilitado por atividades como brainstorming, relacionamento e troca de material de leitura, tais como artigos, notícias e relatórios, por exemplo.

27 3.2 Características CoPs em meio virtual A globalização e as relações de trabalho cada vez mais dispersas fizeram com que as CoPs encontrassem uma barreira significativa: a geográfica. Discute-se a possibilidade de dar suporte às Comunidades de Prática de maneira totalmente virtual. Segue-se um estudo sobre comunidades virtuais e mecanismos de suporte às trocas de informações e práticas pela Web, no caso das CoPs. Comunidades Virtuais Existem diversos tipos de comunidades virtuais, que podem ser classificadas em: comunidades virtuais de relacionamentos, as quais são construídas sobre relacionamentos especiais entre pessoas, como por exemplo relações de família, e outras; comunidades virtuais de lugar, baseadas em indivíduos que compartilham o mesmo local; comunidades virtuais de conhecimentos, que ajudam a encontrar pessoas com os mesmos objetivos, valores e concepção sobre determinado assunto; comunidades virtuais de memória, baseadas em um passado compartilhado ou algo histórico e comunidades virtuais de necessidades, baseadas em algum fato ou acontecimento semelhante e que tenham algum fator que afete emocionalmente os participantes [11]. O desenvolvimento acelerado das tecnologias de rede e da Internet veio proporcionar uma plataforma conveniente e flexível e tem acelerado o desenvolvimento de novas formas de comunidades. De Holt [40] define os tipos de Organizações Virtuais: Internas: aplicadas a uma organização para implementar a operação de equipes internas; Estáveis: baseadas na cooperação entre organizações diferentes coordenadas por uma empresa central que contrata e terceiriza as partes do produto; Dinâmicas: caracterizam-se por manter uma cooperação profunda que é sempre temporária e baseada em oportunidades estimuladas pelo mercado; Web-company: conhecidas como organizações ágeis, são redes temporárias de organizações especializadas, apoiadas pela Internet. O compartilhamento e a gestão do conhecimento entre os parceiros é essencial para o bom funcionamento da organização virtual. Em 1998, Barksdale, presidente da Netscape [3], definiu comunidade virtual como como um agrupamento de indivíduos alinhados em torno de um interesse comum, conferindo-lhe a característica de possuir comunicação assíncrona, ou seja, não está limitada a ter todas as partes interagindo ao mesmo tempo.

28 3.2 Características 27 Uma comunidade virtual é caracterizada principalmente pela intensidade de comunicação entre seus membros, que procuram atender a necessidades básicas, tais como interesse, relacionamento, transação ou fantasia. Usando a Internet, um grupo disperso de pessoas pode conversar assincronamente, de acordo com a sua conveniência, durante um longo período de tempo, o que facilita trocas que simplesmente não poderiam ocorrer fisicamente. William e Cothrel [57] estudaram as comunidades online para determinar o melhor caminho para estabelecê-las ou mantê-las. Eles desenvolveram um modelo que identifica as principais atividades a serem realizadas a fim de se conseguir êxito no estabelecimento das comunidades virtuais: desenvolvimento dos membros; gestão do acervo; gerenciamento das relações. O desenvolvimento dos membros se refere à necessidade de crescimento da comunidade e de substituição dos membros que saem. Existe a necessidade de definir claramente os objetivos e a demografia dos membros para que se possa empreendê-la. A gestão do acervo da comunidade diz respeito ao seu conteúdo informacional, alianças e infra-estrutura. Na atividade de gestão do acervo deve-se criar o perfil dos membros, dividi-los em sub-comunidades por tópicos específicos, capturar, disseminar o conhecimento e criar os processos que facilitam o envolvimento dos membros. Já as relações comunitárias devem ser desenvolvidas com base em regras gerais explícitas que ajudam os seus membros, por si próprios ou com a ajuda de moderadores, a solucionar os conflitos que surgem com freqüência. Segundo Nancy White, ferramentas online são uma forma de dar suporte a comunidades. Elas não criam comunidades. Comunidade não se define na base do local onde se encontra, mas na qualidade das relações entre seus membros. Comunidade tem a ver com pessoas, não com tecnologia ou localização [31]. Ambientes Virtuais que oferecem suporte a CoPs Etienne Wenger realizou, em 2001, um extenso levantamento de ferramentas e tecnologias que poderiam dar suporte, pleno ou parcial, às Comunidades Virtuais de Prática [55]. Neste levantamento, ferramentas de mercado foram abordadas e avaliadas de acordo com grupos de caraterísticas relacionadas às CoPs. A Figura 3.1 compila este estudo. Quanto mais um produto se aproxima do centro da figura, mais ele é capaz de oferecer suporte a todos os requisitos ligados às CoPs.

29 3.2 Características 28 Figura 3.1: Levantamento de ferramentas para suporte a CoPs de Wenger, em 2001 [55] Os requisitos avaliados oferecem uma idéia geral do que se espera de um ambiente que dê suporte a CoPs em meio virtual. As características que aproximam um software do centro do gráfico, ou seja, de uma CoP plena, são: Integração entre trabalho e conhecimento - espaço para gerenciar participação em múltiplos grupos; Trabalho - espaços para projetos; Estrutura social - portal da comunidade; Conversação - grupos de discussão; Interações por locais de encontro (síncronas); Instrução - espaços de aprendizagem virtual; Compartilhamento de conhecimento (acesso à experiência dos membros); Documentos - bases de conhecimento. Várias ferramentas foram estudadas e avaliadas de acordo com os mesmos critérios. A estes critérios foram acrescentados os requisitos da Web Semântica nas avaliações de ambientes virtuais.

30 3.2 Características 29 No Capítulo 5, são abordados alguns projetos que procuraram dar suporte a CoPs. Inicialmente, sem abordar aspectos semânticos e, em seguida, aqueles que fizeram uso de estruturas da Web Semântica.

31 Web Semântica CAPÍTULO 4 Neste capítulo, é apresentada a Web Semântica. As relações desta nova Web com as cops são úteis à definição escopo do arcabouço SCOP, assunto do Capítulo Web Semântica - Visão Geral O crescimento exponencial das páginas na Web e algumas limitações tecnológicas, principalmente ligadas à dificuldade de indexação de informações, em decorrência das tecnologias predominantes para implementação, criaram a necessidade de uma nova abordagem ou extensão do modelo atual da Web, à qual se denomina Web semântica. A forma como a Web está implementada dificulta a busca de informações com precisão, não devido à ausência de informações, mas sim pela desorganização e pelas limitações tecnológicas do modelo atual de implementação das páginas da Internet. O W3C [53], através do seu grupo de trabalho Semantic Web Activity Statement, atua no sentido de resolver as limitações citadas acima e desenvolve esforços no sentido de padronizar e evoluir a Web atual para a Web Semântica. A definição de Web Semântica permite várias perspectivas: Web Semântica é uma extensão da Web atual que visa dar significado semântico ao conteúdo das páginas Web, criando um ambiente onde agentes de software e usuários possam trabalhar de forma cooperativa [53]. A Web Semântica não é uma Web separada, mas uma extensão da atual. Nela a informação é dada com um significado bem definido, permitindo melhor interação entre os computadores e as pessoas. [4] Web Semântica é o nome genérico do projeto capitaneado pelo W3C que pretende embutir inteligência e contexto nos códigos utilizados para confecção de páginas Web, de modo a melhorar a forma com que programas interagem com estas páginas e também possibilitar um uso mais intuitivo por parte dos usuários [12]. Com esta nova abordagem, pode-se ter ambientes construídos com novas concepções. Para isso, pode-se usar ferramentas e tecnologias para anotação semântica das

32 4.2 RDF - Resource Description Framework 31 páginas e recursos da Web e para o desenvolvimento de ontologias compartilhadas. Assim, espera-se aproximar gradativamente a Web Semântica de um sistema global de recuperação de informações (SRI) [41]. As próximas seções irão explorar aspectos importantes das estruturas e linguagens da Web Semântica, principalmente com relação à construção do SCOP. 4.2 RDF - Resource Description Framework Pode-se considerar um recurso como uma fonte de informação publicada em um ambiente acessível a usuários da Internet ou a membros de uma comunidade. Um recurso é identificado por um URI (Uniform Resource Identifier). Para esta arquitetura, a natureza do recurso não é prioridade. Um recurso pode ser uma página HTML na Web, uma pessoa cadastrada em um banco de dados, um documento em PDF publicado, dentre outras coisas. O RDF [52] é uma arquitetura que permite representar informações sobre os recursos existentes na Web. Sua utilização parte da identificação dos recursos através de um URI e na descrição desses recursos, através da atribuição de propriedades e respectivos valores, que também podem ser outros recursos. Uma propriedade é uma informação sobre o recurso, tal como autor, para o site S ou idade para a pessoa P, por exemplo. Um valor é o atributo apontado pela propriedade sobre um recurso. No exemplo dado, José é o valor da propriedade autor, que caracteriza o recurso S; 29 é o valor da propriedade idade que caracteriza o recurso P. Pela arquitetura RDF, o valor José pode ser também um recurso, o que forma uma estrutura de grafo. Para simplificar as notações das triplas o agrupamento dos termos utilizáveis, são usados QNames (Nomes qualificados XML) associados a namespaces (espaços de nomes). Por exemplo, o endereço do site P acima é Pode se estabelecer que o namespace é representado pelo QName xyz. Em vez de escrever o recurso com seu endereço completo, pode-se usar a notação xyz:p.html. Isso é válido para os sujeitos, predicados e objetos. Os namespaces são importantes por permitirem padronização de vocabulário. Alguns exemplos de QNames são citados abaixo: rdf: Contém prefixos usados da arquitetura RDF (Ex: rdf:about). dc: Dublin Core Iniciative. [10] Contém prefixos usados para catálogo de documentos (Ex: dc:creator). owl: Ontology Web Language. [47] Armazena os termos da linguagem OWL (Ex: owl:ontology).

33 4.3 RDFS - RDF Schema 32 rdfs: RDFSchema. [46] Armazena os termos usados nesta extensão da arquitetura RDF, assunto da Seção 4.3. Um exemplo é rdfs:class. Dessa forma, os recursos são organizados através de triplas (Recurso - Propriedade - Valor) ou (Sujeito - Predicado - Objeto). Essa arquitetura genérica proporciona a ligação entre os recursos de uma CoP, sejam eles originários de uma wiki, um chat, ou um repositório de arquivos, por exemplo. Com essa estrutura, usando o SCOP, o desenvolvedor de um ambiente que dê suporte a uma comunidade pode, por exemplo, permitir que os membros definam propriedades e liguem os recursos através de tais propriedades. Isso permite o processamento automatizado por máquinas sobre os recursos. Permite ainda, que se utilizem termos consolidados e centralizados em espaços de nomes públicos. Os requisitos e características do SCOP são apresentados no Capítulo 6. Em uma comunidade implementada sem o uso de estruturas da Web Semântica, os recursos só possuem um tipo de relação: o link direto. Não se sabe o significado, o contexto e não se pode localizar recursos inter-relacionados de forma automática. Com as triplas RDF, é possível se inter-relacionar recursos, traçando propriedades que os interliguem, ou propriedades que liguem recursos a valores (literais). Isso é importante para a interoperabilidade da comunidade. Pode-se distinguir sujeitos, predicados e objetos através de processamento automatizado sobre uma base de recursos assim organizada. A base de informações trabalhada pelo SCOP é composta por recursos interligados através de triplas RDF. Dessa forma, o desenvolvedor de um ambiente poderá usar as ligações para facilitar a navegação entre recursos afins ou mesmo para construir mecanismos de busca que possam fazer inferência, facilitando a localização dos recursos da CoP dentro do contexto esperado. Um URI, pela arquitetura RDF, pode identificar recursos, independentemente da natureza ou de possuírem endereço válido na Web (URL - Uniform Resource Locator). 4.3 RDFS - RDF Schema O modelo RDFS (RDFS Schema) estende a arquitetura RDF, permitindo a criação de vocabulários básicos em RDF. Possibilita estruturar os recursos através de classes, hierarquias e propriedades. Um recurso pode ser instância de uma classe através da propriedade rdfs:type. Classes podem se inserir em uma estrutura hierárquica, permitindo o uso de subclasses, através da propriedade rdfs:subclassof para especificar este relacionamento, semelhante à herança do paradigma da orientação a objetos. O modelo RDFS é útil na construção do SCOP, uma vez que este possibilita o agrupamento dos recursos de uma comunidade em classes, subclasses e propriedades,

34 4.4 Ontologias 33 conforme será visto no Capítulo 6. Para melhor compreensão, alguns pontos são abordados abaixo de forma breve e superficial Classes Classes correspondem ao conceito genérico de tipo ou categoria [22]. Isso possibilita estender o modelo RDF, pois as definições podem ser herdadas, promovendo compartilhamento de esquemas e reuso. A propriedade rdfs:class é usada para referenciar as classes, que podem representar recursos de naturezas diversas. Na verdade, nessa arquitetura, todas as classes são subclasses da classe rdfs:resource. Para representar a herança é usada a propriedade rdfs:subclassof. Representa-se uma instância de uma classe pela propriedade rdf:type Propriedades As propriedades permitem expressar as relações entre as classes e suas instâncias ou superclasses. Usa-se a classe rdf:property para representar uma propriedade. As propriedades rdfs:range e rdfs:domain estabelecem restrições (limites) sobre as propriedades de um recurso. rdfs:range é usada para indicar que os valores de uma determinada propriedade são limitados a instâncias de uma ou mais classes. rdfs:domain especifica as classes nas quais determinada propriedade pode ser aplicada, ou seja, limita as instâncias de classes que podem usar determinada propriedade. Um esquema RDF permite a especialização de propriedades. Este relacionamento de especialização entre duas propriedades é descrito usando-se a propriedade predefinida rdfs:subpropertyof. RDFS possui outras propriedades que podem ser usadas para documentação e outras informações sobre o próprio esquema ou sobre suas instâncias, como rdfs:comment, que pode ser usada para descrever um recurso em formato adequado para ser lido por seres humanos; rdfs:label, que pode ser usada para indicar a versão do nome de um recurso; rdfs:seealso, que pode ser usada para indicar um recurso que contém informações adicionais a respeito do recurso em questão, dentre outras propriedades. 4.4 Ontologias O termo ontologia define formalmente as relações entre termos e conceitos. Uma ontologia é uma especificação de uma conceituação. É designada com o propósito

35 4.5 O arcabouço Jena 34 de habilitar o compartilhamento e uso de conhecimentos, de forma a criar compromissos ontológicos, ou definições necessárias à criação de um vocabulário comum [41]. As ontologias se apresentam como um modelo de relacionamento de entidades e suas interações em algum domínio particular do conhecimento ou específico para alguma atividade. Um dos objetivos de sua construção é a necessidade de um vocabulário compartilhado para a troca de informações entre os membros de uma comunidade, sejam eles humanos ou agentes inteligentes 1. Padrões e linguagens para construção e compartilhamento de ontologias na Web estão sendo criados, todos baseados em XML, com algumas diferenças na sintaxe de marcação. Porém, a recomendação do W3C é a linguagem denominada OWL - Web Ontology Language [47]. Basicamente, a OWL é usada para representar o significado de termos em vocabulários e as relações entre estes termos. A OWL vai além do RDF, controlando vocabulário para descrever classes, propriedades e permite o processamento e raciocínio (inferência em uma base de conhecimento, neste caso representada por classes e propriedades), além de possuir mais recursos para expressar significado e semântica, se comparada a RDF/RDFS. Dessa forma, a OWL tem uso especial no sentido de representar conteúdo interpretável por máquinas na Web [50]. A relevância do uso das ontologias para a Web advém da possibilidade de identificação de contexto e da conseqüente redução de ambigüidades. Outro aspecto relevante é a reutilização de ontologias. Uma vez construída uma ontologia sobre um assunto, esta pode ser reutilizada por outros grupos que trabalham sobre o mesmo assunto, sem a necessidade de se desenvolver uma outra. SCOP permite importar ontologias para delimitar o domínio de conhecimento, ou seja, definir o contexto compartilhado por uma CoP. Esta ontologia pode ser percorrida em busca de um conceito que faça parte do domínio. Maiores detalhes podem ser encontrados no Capítulo O arcabouço Jena Jena [25] é um arcabouço para a desenvolvimento Java [1] sobre Web Semântica. Ele foi desenvolvido pelo grupo HP Labs Semantic Web Programme em código aberto. O arcabouço Jena inclui: Uma API (Application Program Interface) para RDF; Leitura e escrita de RDF em RDF/XML, N3 e N-Triplas; 1 Agentes inteligentes são artefatos de software dotados sensores capazes de perceber o ambiente e atuadores para interagir sobre ele. Destacam-se características como capacidade de cognição, aprendizado, autonomia, dentre outras.

36 4.5 O arcabouço Jena 35 Uma API OWL; Armazenamento persistente e em memória; mecanismo de consultas SPARQL (SPARQL Query Engine). As subseções seguintes tratam dos aspectos e estruturas do Jena que contribuem com a construção do SCOP A Base RDF A arquitetura do Jena é centralizada na base RDF. As operações de construção de um grafo RDF sobre os recursos disponíveis e manipulação são consideradas suas operações. A compreensão das classes, interfaces e métodos oferecidos pelo Jena para essas funcionalidades e para percorrer o grafo RDF, dentre outras, fazem parte de sua API RDF. O arcabouço possui classes para representar grafos, recursos, propriedades e literais. As interfaces representando recursos, propriedades e literais são, respectivamente, Resource, Property e Literal. Um grafo é representado pela interface Model. O Código 4.1 pode ser usado para criar um grafo mínimo RDF (uma única tripla): Código 4.1 Código Java para criar um grafo RDF usando o JENA 1 // define variáveis 2 3 static String uripessoa = " 4 static String nomecompleto = "Jose Augusto"; 5 6 // cria um Model vazio 7 8 Model model = ModelFactory.createDefaultModel(); 9 10 // cria o recurso Resource JoseAugusto = model.createresource(uripessoa); // Adiciona a propriedade vcard:fn (first name) JoseAugusto.addProperty(VCARD.FN, nomecompleto); O Código 4.1 gera em memória o grafo representado pela Figura 4.1. É possível persistir este grafo em um SGBD (Sistema Gerenciador de Banco de Dados). O Código 4.2 demonstra a ligação de um modelo RDF a um banco de dados. Com isso, todas as operações realizadas são persistentes. O banco de dados empregado no exemplo foi o MySQL [2]. A escolha deste SGBD para este exemplo e para implementação de serviços de persistência do SCOP se deve ao fato de o mesmo ser relacional, de código aberto e

37 4.5 O arcabouço Jena 36 também devido à disponibilidade de controladores (drivers) eficientes e de uso livre para Java. Figura 4.1: Grafo RDF gerado pelo Código 4.1 Código 4.2 Código de exemplo para gerar o grafo de forma persistente, usando o banco de dados MySQL 1 // URL do banco de dados 2 String M_DB_URL = "jdbc:mysql://localhost:3306/scop"; 3 4 // Nome de usuário do banco 5 String M_DB_USER = "scop"; 6 7 // Senha do usuário 8 String M_DB_PASSWD = "scop"; 9 10 // Nome do motor de banco de dados (para o Jena) 11 String M_DB = "MySQL"; // Driver JDBC 14 String M_DBDRIVER_CLASS = "com.mysql.jdbc.driver"; // Roda o driver 17 try { 18 Class.forName(M_DBDRIVER_CLASS); 19 } catch (Exception e) { 20 // capturar exceções 21 } // Cria a conexão com o banco de dados 24 IDBConnection conn = new DBConnection(M_DB_URL, M_DB_USER, M_DB_PASSWD, M_DB); // Cria um modelmaker com os parâmetros de conexão dados. 27 ModelMaker maker = ModelFactory.createModelRDBMaker(conn); // Abre um model já existente e com um nome definido 30 Model nmmodel = maker.openmodel("modelexemplo"); 31 O código 4.3 exemplifica a expansão do grafo da Figura 4.1. O grafo gerado é representado na Figura 4.2. Em vez de criar o grafo em memória, cria-se de forma

38 4.5 O arcabouço Jena 37 persistente, já que o faz no modelo persistido pelo Código 4.2. A referência é feita ao modelo denominado ModelExemplo, na linha 30 do código 4.2. Código 4.3 Código para expandir o grafo da Figura // define algumas variáveis 2 String uripessoa = " 3 String nomecompleto = "Jose Augusto"; 4 5 // abre o Model persistente 6 Model model = maker.openmodel("modelexemplo"); // cria o recurso 9 Resource JoseAugusto = model.createresource(uripessoa); 11 // Adiciona a propriedade vcard:fn 12 JoseAugusto.addProperty(VCARD.FN, nomecompleto); String uripessoa2 = " 15 String apelido = "Junior" // Cria a propriedade "ex:apelido" 18 Property propapelido = nmmodel.createproperty("ex:apelido"); //Completa o Grafo 21 JoseAugusto.addProperty(DC:Creator, 22 model.createresource(uripessoa2) 23.addProperty(propApelido, apelido)) Figura 4.2: Grafo RDF gerado pelo Código 4.3 As consultas a um grafo RDF são realizadas por métodos que retornam especializações de java.util.iterator. Por exemplo, a interface do Jena ResIterator pode ser usada. Seja o código:

39 4.5 O arcabouço Jena 38 Código 4.4 Código para percorrer uma lista gerada a partir de um grafo RDF 1 // Lista todos os sujeitos do grafo que possuam apelido 2 ResIterator pessoascomapelido = model.listsubjectswithproperty(propapelido); 3 4 while (pessoascomapelido.hasnext()) { 5 6 // ResIterator possui o método nextresource() 7 Resource pessoa = pessoascomapelido.nextresource(); 8 9 // Imprime a URI do recurso corrente 10 System.out.println(pessoa.getURI()); 11 } O objeto pessoascomapelido é uma lista e como tal, pode ser percorrido. O Código 4.4 demonstra uma forma de imprimir a lista resultante. Neste caso, será impresso apenas o URI Código semelhante pode ser usado para listar os objetos das triplas. Objetos podem ser recursos ou valores (literais) apontados por uma propriedade. Dessa forma, deve-se usar NodeIterator ao invés de ResIterator. Ao invés de usar model.listsubjectwithproperty (linha 2 do Código 4.4), usa-se model.listobjectsofproperty. Para localizar, no modelo, os recursos que JoseAugustoJunior criou, pode-se usar: Resource junior = nmmodel.getresource(" NodeIterator recursoscriadosporjunior = model.listobjectsofproperty(junior, DC:Creator); Existe um método para consultar triplas de forma genérica: Model.listStatements(Resource r, Property p, RDFNode n) Qualquer dos parâmetros fornecido pode ser nulo, fazendo com que o método busque qualquer valor daquele tipo de parâmetro O uso de ontologias As ontologias no Jena são separadas da base RDF principal. Elas podem ser importadas e formar um grafo de união. A Figura 4.3 representa a arquitetura da API Jena para ontologias.

40 4.5 O arcabouço Jena 39 Figura 4.3: Jena Ontology API - Estrutura interna com importações [24] Cada ontologia importada é mantida em um grafo próprio. A classe OntModel estende a classe Model da API RDF do JENA, contendo todas as suas funcionalidades e acrescentando métodos para se manipular estruturas em uma ontologia. Quando ocorrem as importações, o gerenciador de documentos (representado pela classe DocumentManager) possui métodos para fazer as ligações entre os grafos automaticamente. A base RDF (grafo RDF) é atualizada quando triplas são adicionadas ou removidas do modelo ontológico [24]. O código a seguir realiza as operações de importação e ligação colocadas acima. Abaixo do código se seguem algumas explicações. Código 4.5 Código para importar e ligar ontologias ao grafo RDF 1 // OntModelSpec.OWL_MEM indica que a linguagem usada é OWL(full), 2 // assume o mecanismo de inferência padrão e que as operações são em memória 3 4 OntDocumentManager mgr = new OntDocumentManager(); 5 OntModelSpec s = new OntModelSpec( OntModelSpec.OWL_MEM ); 6 s.setdocumentmanager(mgr); 7 OntModel m = ModelFactory.createOntologyModel(s); 8 dm.addaltentry( " "file:c:/ontologias/onto_a.owl" ); 9 m.read("onto_a.owl"); Cada modelo ontológico é associado a um gerenciador de documentos - document Manager, que oferece serviços ao processamento e ligação dos documentos de ontologias. A classe OntModelSpec permite controlar o comportamento básico do modelo ontológico (OntModel). Isso inclui o perfil da linguagem de ontologia utilizada, o mecanismo de inferência e as formas de ligação entre os documentos que compõem o modelo ontológico geral.

41 4.5 O arcabouço Jena 40 Uma vantagem do uso de ontologias é que se pode reutilizar trabalhos feitos por ontologistas através da importação de suas ontologias publicadas. Nas importações, problemas como a existência de firewalls que requeiram conexão via proxy http, ou mesmo a indisponibilidade temporária ou permanentemente, podem impor uma demora crítica ao se rodar uma aplicação. Para se resolver estes problemas, o gerenciador de documentos permite um redirecionamento local ou em um site da Web espelhado, fazendo com que uma cópia do documento seja recuperada ao invés da outra. No Código 4.5, o redirecionamento é feito pela chamada dm.addaltentry. O método read da classe OntModel permite ler um arquivo de ontologia. O Código 4.5 considera uma ontologia (ontoa.owl), que se encontra publicada no endereço hipotético e possui uma cópia na máquina local (C:/ontologias/ontoA.owl). Por padrão, ao executar o método read, a ontologia importada passa a agregar o modelo original, completando a ligação. Este processo é realizado de forma recursiva e não há limite definido de ontologias para integrarem o grafo de união Inferência Jena possui um mecanismo de inferência que oferece suporte a diferentes linguagens de ontologia. Seu objetivo é permitir raciocínio sobre uma base de conhecimento, representada, por exemplo, por um modelo RDF e uma ontologia em OWL. Para este caso, um objeto do tipo Reasoner pode ser usado. O código 4.6 é um exemplo de como usar o mecanismo OWLReasoner para gerar um modelo (Model) que resulta da inferência entre uma base RDF e uma ontologia em OWL.

42 4.5 O arcabouço Jena 41 Código 4.6 Código para criar e consultar um modelo de inferência 1 // abre o modelo com a base RDF 2 Model model = maker.openmodel("modelexemplo"); 3 4 // Importa e carrega a Ontologia 5 OntDocumentManager mgr = new OntDocumentManager(); 6 OntModelSpec s = new OntModelSpec( OntModelSpec.OWL_MEM ); 7 s.setdocumentmanager(mgr); 8 OntModel onto = ModelFactory.createOntologyModel(s); 9 dm.addaltentry( " 10 "file:c:/ontologias/onto_a.owl" ); 11 onto.read("onto_a.owl"); // Cria um mecanismo de inferência OWL 14 Reasoner reasoner = ReasonerRegistry.getOWLReasoner(); // Liga o mecanismo de inferência à ontologia 17 reasoner = reasoner.bindschema(onto); // Gera o modelo de inferência 20 modeloinf = ModelFactory.createInfModel(reasoner, model) // Localiza um recurso no modelo de inferência 23 String uripessoa = " 24 Resource recurso = modeloinf.getresource(uripessoa); // Imprime todas as declarações no modelo de inferência 27 // sobre o recurso desejado 28 for (StmtIterator iter = modeloinf.liststatements(recurso, 29 null,null); iter.hasnext(); ) { 30 Statement stm = iter.nextstatement(); 31 System.out.println(PrintUtil.print(stm)); 32 }

43 Trabalhos sobre CoPs e Web Semântica CAPÍTULO 5 Neste capítulo são apresentados alguns trabalhos que se situam dentro da mesma linha do SCOP e que de alguma forma se relacionam ao projeto do arcabouço apresentado no Capítulo 6. Inicialmente, são apresentados trabalhos que procuram oferecer suporte a CoPs, contendo algumas ou várias das ferramentas esperadas neste tipo de comunidade. Em seguida, discute-se trabalhos que tiveram a mesma ênfase, mas que adicionaram idéias, recursos, conceitos ou linguagens da Web Semântica. 5.1 Wiki Webs A partir do levantamento de ferramentas feito por Etienne Wenger, citado no final da Seção 3.2, outras ferramentas que pudessem dar suporte a CoPs foram avaliadas. Wiki Web (ou simplesmente wiki) é uma ferramenta com o objetivo de promover a criação colaborativa de informação e conteúdo, funcionando como um ambiente de hipertexto iterativo. Uma página wiki pode ser criada por qualquer leitor para adição ou revisão de conteúdo. A informação pode ser facilmente reorganizada, novas páginas criadas e páginas existentes renomeadas. Todas as modificações nas páginas são controladas e podem ser resgatadas. Dessa maneira, é fácil verificar quem escreveu o que, fato que indiretamente promove uma cultura de valorização das informações editadas, reduzindo modificações que venham a deteriorar o conteúdo [37]. Uma Wiki Web pode oferecer suporte a uma CoP por ter condições de satisfazer vários dos requisitos das mesmas. Através de sua estrutura, percebe-se a possibilidade de se trabalhar os seguintes pontos: Espaço de trabalho compartilhado para colaboração eletrônica e discussão; Portal com informações do domínio e das atividades da CoP; Recurso para discussões de questões em aberto; Diretório dos membros com informações sobre suas experiências no domínio da CoP;

44 5.2 ICOX - Gerenciador de Inteligência Coletiva 43 Mecanismos de Busca; Possibilidade de formação de subgrupos/equipes de projetos. Existem vários sites wiki na Web, dentre eles o c2.org [7] (um dos primeiros, criado por Ward Cunningham para discussão sobre Design Patterns). Uma das mais expressivas iniciativas em trabalho colaborativo através desta ferramenta é a Wikipedia [19], uma grande enciclopédia online. Essas ferramentas se baseiam em trabalho colaborativo podem satisfazer vários requisitos de CoPs. Dado o caráter colaborativo e a maneira intuitiva de operação, uma wiki pode ser considerada uma ferramenta capaz de servir como plataforma para as atividades de participação mútua em projetos e práticas comuns. Da mesma forma que as wikis, as ferramentas levantadas no trabalho de Wenger também vieram ao encontro dos requisitos de ambientes de CoPs. Todavia, elas não contemplam recursos da Web Semântica em suas implementações. 5.2 ICOX - Gerenciador de Inteligência Coletiva Disponibilizado no segundo semestre de 2006, o site demonstrativo do ICOX, Gerenciador de Inteligência Coletiva [27], permite várias relações com os trabalhos colocados nesta seção. Trata-se de um software livre para gerenciar comunidades virtuais. Visa a troca de experiências entre membros de uma comunidade ou de comunidades distintas. O software pode ser baixado gratuitamente e implantado em uma organização ou mesmo por uma pessoa física em um servidor que execute Apache, MySQL e PHP. O site contém uma demonstração funcional do software. Inicialmente, um usuário pode se cadastrar no ICOX e participar ou criar comunidades. Os níveis de participação são controlados pelo software. O criador de uma comunidade a administra, controlando quais membros podem usar as ferramentas e quais das ferramentas disponíveis a comunidade vai usar. As trocas de experiências entre os membros são baseadas em tópicos e mensagens, moderadas ou não. As comunidades podem usar recursos comuns em sites, tais como fotos, agenda, arquivos e enquetes. É disponibilizada uma estrutura chamada enciclopédia, para que usuários possam incluir verbetes e descrevê-los para toda a comunidade. Membros podem criar e manter blogs 1 pessoais e assinar blogs de outros membros. O SCOP auxilia a construção de ambientes similares ao ICOX, com relação à de gestão de comunidades e membros. Acrescenta-se, com o SCOP, a disponibilização 1 Blogs são sites atualizados e arquivados em forma de relatórios (logs.). Os mantenedores o utilizam de forma semelhante à escrita de um diário, que pode conter recursos de multimídia

45 5.3 Semantic Media Wiki / Ontoworld 44 de classes e métodos para que o desenvolvedor possa ligar as informações geradas pela comunidade de acordo com estruturas semânticas, conforme é detalhado pelo Capítulo 6. Outros trabalhos relacionados com o desenvolvimento do SCOP são o Platypus Wiki [6], OntoShare [9] e Semantic Media Wiki [56]. Todos estes incluem idéias e ferramentas da Web Semântica em seus ambientes. 5.3 Semantic Media Wiki / Ontoworld Semantic Media Wiki (SMW) [56] é um projeto aberto que fornece uma plataforma comum para estender o software MediaWiki 2, de maneira a possibilitar processamento de conteúdo wiki por máquinas. Isso é realizado principalmente através de marcações semânticas especiais. Este projeto é colocado em prática em vários sites, sendo Ontoworld [34] o principal deles, onde se pode trabalhar com a wiki estendida e contribuir com o projeto. Os usuários podem adicionar dados estruturados às páginas wiki através da adição de marcações simples que identificam relações entre páginas ou atribuem valor às mesmas. Dessa forma, os usuários da wiki têm um ganho significativo na localização, organização, avaliação e compartilhamento de informações através das páginas wiki. Em um artigo, um usuário pode adicionar a marcação [[Category:Cities]]. Isto faz com que o artigo seja categorizado como um descritor de uma cidade. Ferramentas de software podem usar tal informação para gerar uma lista ordenada de todas as cidades na wiki, o que facilita ao usuário localizar a informação desejada. O mecanismo trabalha com as categorias relações e atributos para realizar as marcações. O Código 5.1 apresenta um pequeno trecho de um artigo hipotético identificado por Goiânia e auxilia na compreensão do uso das categorias mencionadas no parágrafo acima. Código 5.1 Código wiki de um artigo no OntoWorld 1 Goiânia é a capital de [[capital of::goiás]]. 2 A cidade possui uma populacao de [[population:= ]] 3 de habitantes. Relações são categorias para links. Elas descrevem o significado dos hiperlinks que interligam os artigos. O link da linha 1 aponta para o artigo hipotético Goiás e registra a relação de capital. 2 Software do grupo WikiMedia. MediaWiki é o mecanismo de funcionamento (engine) de diversas wikis atualmente, dentre estas, a WikiPedia [19].

46 5.4 Platypus Wiki 45 Atributos descrevem o significado de valores de dados nos artigos. Por exemplo, o texto na linha 2 registra o valor de sua população. O artigo apresentado ao usuário é codificado em HTML. Visualiza-se o texto com os links, da maneira convencional de um hipertexto. Em uma área separada (Facts About), as relações e atributos são agrupadas. Nesta área, o usuário tem a opção de buscar por artigos que satisfaçam uma mesma relação ou que possuam um mesmo atributo do artigo em foco. 5.4 Platypus Wiki Em uma wiki convencional, a navegação entre conceitos e páginas (recursos de informação) é realizada através de links comuns, em um fluxo que pode ser ilustrado genericamente através da Figura 5.1. LinksPara Recurso LinksPara Recurso LinksPara LinksPara LinksPara Recurso Recurso Recurso LinksPara Recurso Recurso LinksPara Figura 5.1: Fluxo de informações genérico em uma wiki não semântica Já em uma proposta de wiki semântica, como no projeto Platyplus Wiki 3 [6], por exemplo, as páginas wiki podem ser vistas como recursos RDF, ou seja, triplas recursopropriedade-valor. Forma-se então, estruturas conceituais bem definidas, como ilustra a Figura 5.2. Percebe-se que as ligações entre os recursos são propriedades RDF. A proposta do ambiente Platypus Wiki foi a construção de páginas wiki com uso de metadados baseados nas especificações do W3C. Uma página wiki, nesta concepção (sendo um recurso RDF), possui um URI, enquanto uma página wiki convencional sempre possui um URL. As páginas de cada recurso são construídas a partir de uma mescla do 3 O projeto Platypus Wiki não sofreu avanços a partir de agosto de 2006.

47 5.4 Platypus Wiki 46 assunto Documento épartede Tópico temautor Documento assunto Tópico Pessoa moraem Lugar Figura 5.2: Exemplo de fluxo de informações em uma wiki semântica conteúdo HTML puro com barras de navegação, cabeçalhos e rodapés estes formados a partir dos metadados de cada recurso. As páginas são apresentadas em três colunas, a coluna central traz o recurso, a da esquerda traz os sujeitos a ele ligados e a da direita, os objetos dos quais o recurso é sujeito. Isso auxilia o usuário a navegar em recursos que estejam ligados a um mesmo contexto. Os usuários, assim como em uma wiki convencional, podem editar o conteúdo de cada recurso, mas podem também editar os metadados em RDF. Os metadados, como informado anteriormente, são usados inicialmente para navegação. Porém, a idéia chave com este tipo de ferramenta é permitir uma série de possibilidades de aplicações, como por exemplo: Acesso de outros programas à base de conhecimento; Mecanismos de busca semântica; Mecanismos de inferência na base de conhecimento. Tudo isso é possível, uma vez que as informações se encontram organizadas e que a wiki é focada em um contexto específico (domínio de conteúdo) de uma CoP, diminuindo redundâncias de termos e aumentando a precisão. O ganho pode ser significativo em termos de transparência e inteligência do ambiente para o usuário. O ambiente é implementado com tecnologia JAVA, sendo uma aplicação disponível em um Web server e um contêiner, o TomCat [17]. O sistema é construído com base em servlets e páginas JSP [35]. Uma vantagem de JAVA é a possibilidade de uso do arcabouço Jena [25], apresentado no Capítulo 4. No Platypus, o Jakarta Lucene [16] é usado como motor de busca de textos completos ou de metadados no ambiente.

48 5.5 OntoShare OntoShare Davies, Duke e Sure descrevem em [9], o OntoShare, um ambiente de gestão de conhecimento para CoPs que visa oferecer suporte às comunidades, estabelecendo-as de maneira efetiva. Este ambiente permite uma análise da aplicação de recursos semânticos em um ambiente proposto a oferecer suporte a CoPs e exemplifica a utilização das tecnologias citadas da Web Semântica na construção de Comunidades Virtuais de Prática. Oferecendo suporte às Ontologias (de domínios de conhecimento) para as CoPs, o ambiente proporciona acesso natural e intuitivo ao conhecimento pelos membros da comunidade. Por isso ele é classificado como uma ferramenta de gestão de conhecimento. Tais ferramentas devem dar aos usuários a habilidade de organizar informações a partir de módulos controláveis e intuitivos. Para atingir os objetivos, não basta disponibilizar as informações correlatas em um ambiente para um grupo fechado, mesmo que de maneira organizada. Os relacionamentos entre as informações armazenadas são de fundamental importância. O poder das ferramentas de gestão de conhecimento não se resume a ajudar na busca de informações. É significativamente mais abrangente: permite inferência, abstração e ajuda os usuários a compartilhar novas informações, fomentando a comunidade de forma cada vez mais consistente. No momento em que os usuários fornecem novas informações para compartilhamento, o recurso de conhecimento anotado através de metadados é criado. Ontologias são definidas usando-se esquemas RDF (RDFS). Cada usuário possui seu perfil no ambiente. Os perfis são representados como um conjunto de tópicos ou conceitos ontológicos nos quais estão expressos os interesses de cada membro. O perfil é dinâmico e constantemente adaptado pelo ambiente de acordo com as utilizações do usuário de maneira a coincidir da melhor maneira com seus interesses. O ambiente OntoShare permite catalogar e extrair palavras-chave das fontes de informações compartilhadas por um usuário e compartilhar tais informações com os demais usuários da CoP cujos perfis possuam interesses condizentes com tais informações. No modelo de Ontoshare, cada unidade de informação compartilhada está armazenada em ontologias. A Figura 5.3 [9] demonstra um modelo simplificado de ontologia para uma CoP que trabalha com Web Semântica. O conjunto de conceitos nos quais a CoP tem interesse é representado através das subclasses da classe concept. No caso, a subclasse é Web-Semantic. Cada conceito possui um conjunto de subtópicos relacionados, o que forma uma estrutura conceitual. A classe Document representa a informação compartilhada. Um documento gra-

49 5.5 OntoShare 48 Figura 5.3: Estrutura Ontológica no ambiente OntoShare [9]

50 5.6 Second Messenger 49 vado por um usuário possui as propriedades conforme a estrutura conceitual representada, ou seja, um URI, um sumário, um título, um conjunto de palavras-chave, etc. A classe Profile representa as informações do usuário, tais como dados pessoais e os conceitos de seu interesse. No esquema, pode-se ver o perfil instância cuja propriedade nome é John Smith, seus interesses em ferramentas e especificamente na ferramenta Sesame. 5.6 Second Messenger Um exemplo de ambiente que oferece uma ferramenta útil de conversação síncrona usando recursos semânticos é o Second Messenger [13]. Trata-se de uma ferramenta que utiliza reconhecimento da fala, análise semântica e filtragem de palavraschave com uma visualização interativa em tempo real que resume os aspectos mais importantes em uma reunião virtual. A Figura 5.4 ilustra a arquitetura do ambiente. Inicialmente, ocorre a transcrição da fala do usuário. Não é feita uma transcrição total dos diálogos, mas é identificado o conjunto das palavras-chave relevantes. Esta transcrição passa então por uma espécie de classificação (tagging) em substantivos, verbos ou adjetivos. Ela procura remover comentários desinteressantes, tais como confirmações e afirmações simples. A filtragem semântica é o passo seguinte e determina quais textos mostrar ao grupo, tais como comentários que não foram feitos anteriormente e que tenham relações com comentários feitos previamente por outros usuários. Pode-se verificar que a ligação entre os requisitos ligados a CoPs e a organização dos recursos e artefatos produzidos pela comunidade através de estruturas da Web Semântica, juntamente com algumas ferramentas que trabalharam com idéias e ferramentas desta extensão da Web, foram importantes para traçar os requisitos para o desenvolvimento de um arcabouço que contemplasse esse domínio de aplicações.

51 5.6 Second Messenger 50 Figura 5.4: Arquitetura do Second Messenger [13]

52 Arcabouço SCOP CAPÍTULO Arcabouços orientados a objetos Um arcabouço é uma estrutura de classes inter-relacionadas que objetiva formar uma espécie de esqueleto, ou estrutura básica, para auxiliar a construção de aplicações inseridas em um domínio particular. O uso desta estrutura minimiza o esforço para o desenvolvimento de aplicações por permitir que o desenvolvedor se abstraia de preocupações com a definição da arquitetura do sistema [44]. O objetivo de se utilizar um arcabouço para implementar uma aplicação reside principalmente na modularidade, reusabilidade e adaptabilidade oferecidas. Usar um arcabouço na construção de uma aplicação difere da reutilização de classes, na qual o desenvolvedor deve interligar e reutilizar artefatos de software isolados. No primeiro caso, uma estrutura completa de classes inter-relacionadas no projeto do arcabouço é disponibilizada ao desenvolvedor de uma aplicação em seu domínio [14]. A Figura 6.1 ilustra a diferença entre o desenvolvimento com e sem a utilização de um arcabouço.

53 6.1 Arcabouços orientados a objetos 52 Figura 6.1: Exemplo de reutilização de classes com e sem um arcabouço O arcabouço deve ser visto como uma estrutura genérica, flexível e adaptável, que deve fornecer a estrutura de classes básica para o desenvolvimento de aplicações em um domínio. O uso de um arcabouço inverte a ótica da reutilização de classes uma vez que o desenvolvedor deve, inicialmente, compreender o sistema inserido na abordagem do arcabouço para depois seguir com as especializações de suas estruturas visando as necessidades da aplicação a ser desenvolvida. Suas definições geralmente compreendem aspectos de análise, projeto e implementação. Dessa forma, a reutilização pode atingir estas três fases do processo de desenvolvimento de aplicações. As dificuldades da abordagem de arcabouços para aplicações residem em dois

54 6.2 Metodologias para construção de arcabouços 53 aspectos, relacionados, respectivamente, ao projeto do arcabouço e à sua utilização: a complexidade de se projetar um arcabouço que consiga abstrair aspectos de análise e projeto e a dificuldade de entendimento e utilização dos arcabouços projetados [5]. A complexidade de se projetar um arcabouço advém da necessidade de que a estrutura de classes construída seja capaz de contemplar os requisitos de um domínio de aplicação e ao mesmo tempo permitir adaptação às peculiaridades de cada aplicação desenvolvida. Usar um arcabouço exige do desenvolvedor entendimento suficiente de sua estrutura interna para utilizá-lo no domínio de aplicações. A atividade inicial do projeto de um arcabouço é, portanto, a análise do domínio de aplicação alvo. Em geral, suas classes abstratas são empregadas para retratar os conceitos do domínio considerado. Esta etapa consiste na análise de um conjunto de aplicações que possuam um conjunto de características em comum, que devem ser identificadas. Atividades posteriores visam produzir todo o código e outros artefatos, como documentação, úteis ao futuro uso do arcabouço por desenvolvedores. 6.2 Metodologias para construção de arcabouços [14]: Três metodologias de projetos de arcabouços são apresentadas e comparadas em Projeto Dirigido por Exemplo (Example Driven Design) [28]; Projeto Dirigido por Hot Spots (pontos flexíveis) [38]; Metodologia de Projeto da Empresa Taligent [43]. O projeto Dirigido por Exemplo é apresentado em três fases: 1. Análise do domínio de aplicações (exemplos de aplicações existentes); 2. Projeto da estrutura de classes que possa abranger os exemplos; 3. Teste sobre exemplos, avaliando a adequação de cada um deles. O projeto dirigido por Hot Spots foca na identificação e detalhamento dos pontos flexíveis dentro da estrutura de classes de um domínio. As fases são: 1. Identificação de classes (metodologia de orientação a objetos); 2. Identificação dos pontos de flexibilização das classes;

55 6.2 Metodologias para construção de arcabouços Projeto do arcabouço, com uso de padrões (design patterns); 4. Adaptação do arcabouço, até que os pontos flexíveis atendam às necessidades dos usuários. A metodologia de projeto apresentada pela empresa Taligent foca na construção de um conjunto de arcabouços mais simples para serem usados em conjunto para originar as aplicações. Arcabouços menores podem ser direcionados a aspectos mais específicos do domínio. Torna-se mais fácil, por exemplo, o uso de classes concretas (para uso direto na aplicação). As etapas básicas são: 1. Identificação do domínio do problema, caracterizando os arcabouços necessários (já desenvolvidos ou não); 2. Definição da Arquitetura do projeto, com ênfase na interação do usuário com o arcabouço, ou seja, as classes que ele pode instanciar, as que ele deve implementar, etc; 3. Implementação e teste do arcabouço pelos usuários; 4. Desdobramento do arcabouço, documentando-o e atualizando-o constantemente; Não há um padrão ou uma metodologia definida como a ideal no projeto de um arcabouço. Percebe-se que as três metodologias citadas possuem pontos em comum. Para se desenvolver o projeto do SCOP, a metodologia utilizada abrange exatamente estes pontos de convergência, que são: 1. Estudo e aquisição de conhecimento sobre o domínio de aplicação do arcabouço; 2. Projeto da estrutura de classes do arcabouço; 3. Implementação da estrutura de classes e do arcabouço, propriamente dito; 4. Avaliação através do desenvolvimento de aplicações que utilizem o arcabouço; 5. Refinamento e aperfeiçoamento do arcabouço, a partir de novos conhecimentos sobre o domínio. O objeto de estudo deste capítulo inclui os três primeiros itens enumerados acima. O Capítulo 7 traz um estudo de caso que coloca o item 4 em prática, descrevendo e discutindo a construção de um ambiente de comunidades. O item 5 é colocado como proposta para trabalhos futuros.

56 6.3 SCOP - Análise do Domínio de Aplicação SCOP - Análise do Domínio de Aplicação O início do projeto do SCOP (Semantic CoPs Framework) se deu com o levantamento de um conjunto de aplicações e suas características em comum. O domínio de tais aplicações é o de ambientes que dão suporte a CoPs com recursos semânticos, ou seja, comunidades no contexto da Web Semântica. As aplicações identificadas nesse domínio, consideradas neste trabalho, incluem: Ambiente de formação e gestão de CoPs; Wiki semântica; Ambiente semântico para compartilhamento de artigos e documentos em geral; Ambiente para discussões e ajuda mútua com uso de fórum semântico; Requisitos das Aplicações Esta seção apresenta os requisitos identificados por ambiente (aplicação). Ambiente para formar e gerenciar CoPs Gerencia o agrupamento de pessoas em CoPs. Seus principais requisitos foram obtidos a partir dos estudos sobre estas comunidades e de ambientes que oferecem suporte às mesmas, compilados nos capítulos 3 e 5. Os requisitos identificados são: O ambiente deve possuir um ou mais usuários com privilégio de administrador geral; Um administrador geral pode: Criar uma CoP; Excluir uma CoP; Alterar dados cadastrais de uma CoP; Delegar privilégios de administrador de CoP a um de seus membros; Um administrador de CoP pode: Excluir um membro de sua CoP; Moderar interações entre os membros; Delegar privilégios de administrador de CoP a outro membro da mesma; O ambiente deve permitir que uma pessoa se cadastre, fornecendo dados pessoais e uma senha para acesso; Uma pessoa cadastrada pode:

57 6.3 SCOP - Análise do Domínio de Aplicação 56 Tornar-se membro de uma ou mais comunidades; Abandonar uma ou mais comunidades; Um membro de CoP pode: Deixar mensagens a outros membros; Deixar mensagens membros de outras CoPs; Convidar pessoas a participarem do ambiente e de sua(s) CoP(s); Compartilhar documentos através do repositório de arquivos da CoP; Participar de um fórum de sua CoP; Participar de um chat de sua CoP; Participar da wiki de sua CoP; Apresentar uma palestra aos membros de sua CoP e CoPs convidadas; Wiki semântica A definição de wiki e ambientes que oferecem suporte foram explorados no Capítulo 5. Os requisitos estabelecidos para a wiki semântica são: Uma pessoa deve se cadastrar e criar uma senha de acesso; A wiki deve prever um ou mais usuários administradores; Um usuário administrador pode: Acessar um artigo 1 ; Criar um artigo; Editar qualquer artigo da wiki; Criar propriedades e relações para a wiki; Qualquer usuário pode: Acessar um artigo; Criar um artigo; Editar qualquer artigo da wiki; Usar as propriedades e relações para interligar artigos ou associá-los a valores (literais); Marcar semanticamente os artigos, de acordo com uma estrutura ontológica que represente o contexto da CoP. 1 Considera-se artigo qualquer assunto identificado por uma página wiki (wikipage).

58 6.3 SCOP - Análise do Domínio de Aplicação 57 Ambiente semântico para compartilhamento de artigos e documentos Trata-se de um repositório para arquivos que pode ser acessado pelas pessoas que participam do ambiente. Os usuários compartilham entre si documentos, apresentações, planilhas, artigos, ou quaisquer tipos de arquivos digitais de interesse. Os requisitos estabelecidos para este ambiente são: Uma pessoa deve se cadastrar e criar uma senha de acesso; O ambiente deve prever um ou mais usuários administradores; Um usuário administrador pode: Acessar um diretório compartilhado; Criar um diretório compartilhado; Compartilhar um arquivo; Excluir um arquivo; Criar propriedades e relações para serem usadas pelos usuários; Qualquer usuário pode: Acessar um diretório compartilhado; Compartilhar um arquivo; Usar as propriedades e relações para interligar arquivos ou relacioná-los a valores (literais); Marcar semanticamente os arquivos, de acordo com uma estrutura ontológica que represente o contexto da CoP. Ambiente para discussões e ajuda mútua com uso de fórum semântico Os requisitos estabelecidos para este ambiente são: Uma pessoa deve se cadastrar e criar uma senha de acesso; O ambiente deve prever um ou mais usuários administradores; Um usuário administrador pode: Criar ou excluir seções para tópicos; Criar tópicos; Excluir tópicos; Escrever uma mensagem em um tópico; Moderar mensagens de quaisquer tópicos, excluindo ou editando; Delegar privilégios de moderador a outros usuários;

59 6.3 SCOP - Análise do Domínio de Aplicação 58 Criar propriedades e relações para serem usadas pelos usuários; Qualquer usuário pode: Criar tópicos; Excluir tópicos; Escrever uma mensagem em um tópico; Usar as propriedades e relações para interligar mensagens ou relacioná-las a valores (literais); Marcar semanticamente os tópicos, conforme uma estrutura ontológica que represente o contexto da CoP. A partir dos requisitos das aplicações foram definidos os requisitos do SCOP. Para definir os requisitos, o foco concentrou-se na intersecção dos requisitos das aplicações do domínio estudado. O diagrama da Figura 6.2 ilustra um conjunto de aplicações e requisitos hipotéticos. Este diagrama visa apenas reforçar a idéia de que os requisitos na área de intersecção das aplicações devem ser a prioridade para um arcabouço. Isso se deve ao fato de que um arcabouço deve oferecer uma estrutura genérica que atenda as características em comum das aplicações consideradas. Figura 6.2: Esquema do conjunto da aplicações de um domínio O SCOP deve oferecer serviços a desenvolvedores para auxiliar na implementação de ambientes de CoPs com recursos semânticos. Percebe-se, pelos requisitos individuais de cada aplicação, que o foco do arcabouço deve ser ambientes de CoPs para compartilhamento de recursos, usando wikis, repositórios de arquivos, fóruns, ou outras ferramentas para troca de informações, com possibilidade de formar bases de conhecimento, atribuindo relações entre os recursos e/ou significados para os mesmos; Com isso, define-se o conjunto de requisitos em comum das aplicações:

60 6.3 SCOP - Análise do Domínio de Aplicação 59 Devem oferecer suporte a relacionamento entre pessoas, formando e gerenciando CoPs e respectivos membros; Os membros das CoPs podem possuir níveis de participação e privilégios de acordo com esses níveis; Pessoas podem se cadastrar no ambiente, escolhendo uma senha e fornecendo dados pessoais; São baseadas em compartilhamento de recursos referentes às práticas dos membros; Os privilégios de membros determinam se uma pessoa pode realizar tarefas de geração, edição e exclusão de recursos nas CoPs; Os recursos podem ser gerados a partir de ferramentas como fóruns, wikis e diretórios compartilhados de documentos; As CoPs devem formar uma base de recursos persistente; Os recursos podem ser gerados por outras ferramentas que o desenvolvedor deseje construir; Os recursos (artefatos de cada CoP) podem ser classificados conforme um esquema RDF; Os recursos podem ser marcados semanticamente pelos membros, de acordo com relações e propriedades pertencentes às suas respectivas CoPs; Os recursos podem ser relacionados a uma estrutura ontológica, pois uma CoP tem um domínio de conhecimento bem definido; O SCOP deve oferecer serviços de alto nível para que sejam atendidos os requisitos acima. A Seção 6.4 contempla o projeto do SCOP, identificando como o arcabouço oferece facilidades para a construção de aplicações com os requisitos definidos Requisitos do SCOP Esta subseção identifica os requisitos do SCOP. Estes requisitos são derivados dos requisitos comuns às aplicações consideradas do domínio alvo (domínio de atuação do SCOP). Objetos que representem pessoas no ambiente; Objetos que representem CoPs no ambiente; Serviço de controle de participação de pessoas em CoPs; Serviço de controle de níveis de participação e respectivos privilégios de uso do ambiente e de ferramentas das CoPs;

61 6.3 SCOP - Análise do Domínio de Aplicação 60 Persistência para os objetos que representam CoPs e seus membros, uma vez que esses objetos devem ser recuperados em qualquer tempo pelos usuários finais dos ambientes desenvolvidos; Serviços para que sejam criados e editados os recursos nas CoPs, através de ferramentas não definidas; Serviço de persistência para os recursos manipulados através das ferramentas das CoPs, uma vez que eles devem formar uma base de recursos sempre disponível aos membros; Serviços para associação entre CoPs e ferramentas que utilizam, incluindo persistência destas associações; Serviços para criação e manutenção de propriedades RDF nas CoPs, incluindo persistência para estas propriedades; Serviços para inter-relacionar recursos das CoPs, ou para relacioná-los a valores (literais), através das propriedades; Persistência para as relações do item acima; Serviços para criação e manutenção de namespaces no ambiente, incluindo persistência dos namespaces; Serviços para organização de recursos e propriedades através dos namespaces do ambiente; Serviços para importação e exploração de ontologias de domínio codificadas na linguagem OWL, para que contextos das CoPs possam ser identificados. O arcabouço possui outros requisitos ligados à sua expansibilidade e visando motivar contribuições posteriores ao projeto DWeb e outros trabalhos em escopos semelhantes: O arcabouço deve ser de código aberto. Seu código fonte deve ser fornecido a seus usuários; Seu código fonte deve incluir todas as estruturas oferecidas pelo arcabouço Jena, apresentado no Capítulo Considerações Complementares sobre os requisitos do arcabouço O SCOP não esgota todas as possibilidades de ferramentas de troca de recursos ou informações utilizáveis em uma CoP. Em vez disso, fornece uma estrutura básica e

62 6.3 SCOP - Análise do Domínio de Aplicação 61 genérica para que ferramentas desenvolvidas pelos usuários do arcabouço possam gerar recursos a partir da estrutura proposta, independentemente de suas naturezas ou origens. A geração e manutenção destes recursos gerados de forma heterogênea deve formar uma base de recursos RDF para cada CoP e, desta forma, permitir o aumento da interoperabilidade e inteligência dos ambientes construídos. Um chat, um fórum, uma wiki ou uma ferramenta de apresentação de palestras virtuais, dentre outras possibilidades, podem ser encaixadas dentro do modelo de classes do SCOP e, dessa forma, gerar e gerenciar os recursos, os quais são mantidos em estruturas de grafos RDF, formando a base RDF das CoPs. Não é desejável que o arcabouço implemente ferramentas de interação entre membros. O arcabouço não deve sugerir ao desenvolvedor a utilização de definições de ferramentas próprias, garantindo flexibilidade e aumentando as possibilidades de contribuir no desenvolvimento de aplicações com características diversificadas. Ele deve sugerir um conjunto mínimo de atributos e métodos abstratos a serem implementados pelos desenvolvedores na construção de suas ferramentas. O suporte à importação de ontologias na linguagem OWL deve permitir a delimitação de contexto das CoPs. As ontologias podem ser percorridas e servir de referência para se classificar os recursos da base RDF. Um recurso pode, por exemplo, ser classificado como uma instância ou uma subclasse de uma classe localizada na ontologia. Para isso, as classes manipulam as ontologias devem possuir serviços para percorrer e localizar conceitos e relações entre estes conceitos, além de realizar inferência a partir da base RDF e da ontologia. Por exemplo, uma CoP de apicultores possui o artigo Abelha. O desenvolvedor pode utilizar os serviços citados para importar a ontologia apicultura.owl. Na ontologia, podem estar codificados fatos como: abelha é um inseto, insetos possuem 6 pernas, insetos são seres vivos. O arcabouço deverá oferecer serviços que permitam extrair, direta ou indiretamente, as informações de que o artigo Abelha é relacionado a um inseto, ou ainda, que esse artigo trata de um ser vivo com 6 pernas. Para o arcabouço, a ontologia deve ser vista como uma fonte de conceitos (classes) e relações que pode ser consultada ao se gravar ou recuperar um recurso da base RDF de uma CoP, visando a formação de uma uma base de recursos mais expressiva. As ontologias e a base RDF de recursos não devem se confundir. O arcabouço deve oferecer serviços para percorrer e localizar conceitos e relações na ontologia. O uso das estruturas de classes das ontologias deve ficar a cargo do desenvolvedor da aplicação. O desenvolvedor pode usá-las, por exemplo, para a inserção de recursos na base RDF da CoP, guiando o usuário para que o recurso seja adicionado de maneira mais apropriada, correspondendo às relações encontradas nas ontologias.

63 6.4 Projeto e Arquitetura do SCOP Projeto e Arquitetura do SCOP A Figura 6.3 apresenta uma visão geral do diagrama de classes do SCOP e, na seção seguinte, são explicadas suas principais classes e métodos. O diagrama de classes apresentado, usando a UML (Unified Modeling Language) [26], omite propositalmente vários métodos e atributos. Classes e relacionamentos em cinza facilitam a compreensão do arcabouço e são explicadas na Subseção Nesta primeira versão do SCOP, os requisitos de persistência que foram relacionados são disponibilizados apenas para o SGDB MySQL [2]. Tal decisão se deve a dois fatores: Não faz parte dos requisitos do arcabouço contemplar vários SGDBs, uma vez que o foco do trabalho é em serviços oferecidos para manipular comunidades, membros e recursos. Nesta primeira versão, oferecer persistência usando um SGDB é suficiente; O MySQL é um gerenciador de banco de dados relacional de código aberto e com controladores (drivers JDBC) eficientes de uso livre já disponibilizados para a linguagem Java. As subseções que se seguem dividem o SCOP em cinco áreas de interesse. Para cada uma delas é apresentado o projeto correspondente e quais requisitos apresentados na seção são atendidos Manutenção de CoPs e Membros O primeiro aspecto do SCOP é permitir o suporte a Comunidades de Prática. A Figura 6.4 traz a parte do diagrama de classes relacionada com este gerenciamento. Como pode ser observado na Figura 6.4, o SCOP se preocupa em fornecer a estrutura básica para manter membros e comunidades das quais eles possam estar participando. Para isto, o desenvolvedor conta com as classes Person e Member, que estende Person. São fornecidos, no pacote Persistence (Figura 6.3), embora não representadas totalmente no diagrama, estruturas responsáveis pela manutenção dos membros, CoPs e recursos no Banco de Dados do SCOP, uma vez que tais informações devem ser persistentes, conforme os requisitos apresentados. A classe Person possui os atributos básicos dos usuários de um ambiente, além de métodos para adicioná-los, removê-los ou atualizá-los no banco de dados do sistema. Caso o desenvolvedor necessite controlar pessoas que não fazem parte de comunidades,

64 6.4 Projeto e Arquitetura do SCOP 63 Figura 6.3: Diagrama de Classes do SCOP

65 6.4 Projeto e Arquitetura do SCOP 64 Figura 6.4: Classes para Manutenção de CoPs e Membros poderá usar objetos de Person, ou mesmo estender Person para as particularidades de sua aplicação. A Tabela 6.1 descreve os atributos e métodos de Person. Tabela 6.1: Atributos e Métodos da Classe Person Identificador Tipo Descrição id atributo identifica univocamente o indivíduo no ambiente firstname atributo primeiro nome da pessoa lastname atributo sobrenome da pessoa middlename atributo nomes entre o nome e o sobrenome da pessoa atributo endereço eletrônico da pessoa no ambiente password atributo senha para acessar o ambiente adminlevel atributo controla nível de privilégios no ambiente add método adiciona a pessoa instanciada no ambiente remove método exclui a pessoa instanciada do ambiente update método atualiza a pessoa instanciada no ambiente A classe Member estende a classe Person e controla o nível de participação dos usuários e suas relações com as CoPs, possuindo métodos para associar os membros às CoPs do ambiente. O nível de participação é um número inteiro, o que permite que o desenvolvedor controle os privilégios e a evolução dos membros das CoPs. A Tabela 6.2 descreve os atributos e métodos de Member. Person e Member são classes concretas. Dessa forma, todos os seus métodos já são implementados e, além disso, persistem automaticamente todas as operações em banco de dados.

66 6.4 Projeto e Arquitetura do SCOP 65 Tabela 6.2: Atributos e Métodos da Classe Member Identificador Tipo Descrição identifica o nível de participação de um membro participationlevel atributo no ambiente. É usado para controlar o que cada membro pode ou não fazer nas ferramentas do ambiente joincop método associa o membro instanciado a uma CoP leftcop método desliga o membro instanciado de uma CoP increaselevel método incrementa o nível de participação do membro no ambiente decreaselevel método diminui o nível de participação do membro no ambiente setlevel método associa um nível de participação ao membro instanciado Assim com Person e Member, a classe Cop é disponibilizada como uma classe concreta. Objetos Cop, que representam cada Comunidade de Prática, podem ser instanciados pelo desenvolvedor em suas aplicações. Outra forma de utilização é através de herança, estendendo Cop caso o desenvolvedor queira atributos ou métodos diferentes dos originais do arcabouço. A Tabela 6.3 descreve os atributos e métodos de CoP O grafo RDF dos Recursos Esta subseção apresenta o mecanismo através do qual o SCOP propõe a geração e manutenção dos recursos e das relações entre eles. Apresenta-se também as classes responsáveis pelo gerenciamento das ferramentas de uso das comunidades para se trabalhar com os recursos. A Figura 6.5 mostra parte do diagrama de classes do arcabouço responsável pela dinâmica de geração e manutenção de recursos que compõem a base RDF. A classe Cop está ligada à sua base de recursos, representada pela classe CopResourceBase. A cardinalidade dessa relação é 1 para 1. CopResourceBase contém o atributo graph, que representa o grafo RDF criado e mantido pelos membros da comunidade, ou seja, todos os seus recursos interligados através de suas propriedades, formando triplas RDF ligadas, como foi visto na Seção 4.2. A Tabela 6.4 demonstra os atributos e métodos da classe CopResourceBase 2. 2 As assinaturas dos métodos createresource, createproperty, findconcept e findrelated não estão representadas por completo, por razões de adequação da representação gráfica e de pouca relevância para o entendimento do mecanismo geral.

67 6.4 Projeto e Arquitetura do SCOP 66 Figura 6.5: Classes para Manutenção da Base de Recursos

68 6.4 Projeto e Arquitetura do SCOP 67 Tabela 6.3: Atributos e Métodos da Classe CoP Identificador Tipo Descrição id atributo identificador da Comunidade name atributo nome da comunidade description atributo identifica os assuntos tratados pela comunidade kdomain atributo identifica o domínio de conhecimento (contexto) da Comunidade add método inclui a Comunidade instanciada no ambiente (persistindo-a) remove método remove a Comunidade instanciada do ambiente (do banco de dados) getresourcebase método retorna a base de recursos da comunidade (o grafo RDF) addtool método adiciona uma ferramenta existente à CoP (desde que tenha sido implementada) removetool método remove a associação entre uma ferramente e a CoP checktool método verifica se determinada ferramenta existe e é associada à CoP instanciada Tabela 6.4: Atributos e Métodos da Classe CopResourceBase Identificador Tipo Descrição graph atributo representa a base de recursos da CoP (grafo RDF) addresource método adiciona um recurso no grafo removeresource método remove um recurso do grafo findconcept método localiza um conceito no grafo findrelated método localiza conceitos relacionados a um conceito no grafo Cada objeto Cop é relacionado a um objeto CopResourceBase, cujo principal atributo é graph. Este atributo é do tipo Model, que é uma estrutura do arcabouço Jena para armazenar e manipular grafos RDF. Dessa forma, a classe CopResourceBase funciona como uma estrutura capaz de receber os identificadores dos recursos e propriedades da comunidade organizados em statements (triplas RDF interligadas entre si). É também uma classe concreta, o que faz com que possa ser instanciada ou estendida, caso o desenvolvedor necessite de estruturas ou operações adicionais de manutenção e recuperação de sujeitos, objetos e propriedades do grafo RDF. A classe CopResourceBase possui o método findconcept, para localizar um recurso no grafo, útil para localizar conceitos que constem em uma ontologia, conforme será visto posteriormente. A classe também inclui o método findrelated, que traz um

69 6.4 Projeto e Arquitetura do SCOP 68 sub grafo do recurso procurado, com os nós-filhos e pais e suas respectivas propriedades. O desenvolvedor pode usá-lo como uma forma de ajudar os membros a navegar pelos recursos e/ou localizar recursos dentro do contexto pretendido quando uma ontologia for importada e incorporada à CoP. Cada recurso compartilhado, através de quaisquer ferramentas que sejam desenvolvidas pelo usuário do SCOP deve ser persistido na base de dados do ambiente, conforme os requisitos apresentados. Para isso, um identificador unívoco é criado para o recurso dentro do ambiente, através do método createuri da classe CopResource. Com isso, o recurso pode ser ligado a outros identificadores através de propriedades da CoP e, conseqüentemente, fazer parte da base de recursos RDF da CoP Ferramentas O SCOP fornece uma estrutura expansível e genérica para acomodar ferramentas. Dessa forma, é fornecido um hot spot (ponto flexível) explícito no diagrama, direcionando os desenvolvedores de aplicações a encaixarem suas ferramentas na estrutura do arcabouço, beneficiando-se de seu mecanismo de geração e controle da base de recursos RDF. A classe Cop se relaciona à classe CopTool, que é uma classe abstrata. Os quatro métodos representados no diagrama são abstratos, ou seja, devem ser implementados pelo desenvolvedor da aplicação em suas ferramentas. A classe CopTool permite o controle de níveis de privilégio dentro da CoP. O desenvolvedor pode utilizar os níveis para determinar os membros que podem realizar cada operação de inclusão, exclusão ou alteração de recursos a partir de cada ferramenta da CoP. Os métodos que permitem esse controle são memberleveltoview, memberleveltopost, memberleveltoedit, memberleveltodelete. A Tabela 6.5 demonstra os atributos e métodos da classe abstrata CopTool. Verifica-se no diagrama uma subclasse da classe CopTool, em tonalidade cinza, uma representação genérica de classes hipotéticas, referenciadas no diagrama como Tools.... Essa classe representa classes concretas, que devem implementar os métodos de CopTool responsáveis por adicionar, remover e modificar os recursos gerados pela ferramenta proposta, conforme suas particularidades. A classe CopTool funciona como um contrato mínimo a ser seguido pelo desenvolvedor ao implementar nas ferramentas os métodos para adicionar e remover recursos da através das mesmas. Os recursos gerados pela ferramenta (classe hipotética Tool) se relacionam com a classe hipotética ToolResource, bem como demais classes ou estruturas desenvolvidas

70 6.4 Projeto e Arquitetura do SCOP 69 Tabela 6.5: Atributos da Classe CopTool Identificador Tipo Descrição id atributo identificador da ferramenta ex: "wiki", "fórum", "chat" memberleveltoview atributo nível requerido para que um membro possa ler o recurso memberleveltopost atributo nível requerido para que um membro possa criar o recurso memberleveltoedit atributo nível requerido para que um membro possa editar o recurso memberleveltodelete atributo nível requerido para que um membro possa excluir o recurso cop atributo comunidade para a qual a ferramenta instanciada está trabalhando devem ser implementados de forma a addresource métodos inserir recursos, diretamente ou abstratos referenciando a um caminho para um documento removeresource método deve ser implementado para remover abstrato os recursos updateresource método deve ser implementado para atualizar abstrato (modificar) os recursos setcop método faz com que a ferramenta atue para concreto determinada comunidade pelo usuário do arcabouço, representadas no diagrama pelo tracejado descontínuo cinza entre Tools... e ToolResource. ToolResource é a classe desenvolvida pelo usuário do arcabouço para representar um recurso pertencente, ou melhor, gerado por Tool. O importante nesse momento é que essa representação deve estender a classe CopResource, completando os pontos flexíveis destacados em cinza no diagrama. Naturalmente, os pontos flexíveis para o desenvolvedor não são limitados aos explícitos em cor cinza no diagrama da Figura 6.5. Estes foram destacados devido à importância e para compreensão do mecanismo. Outros pontos de flexibilidade podem ser identificados pelos próprios usuários do SCOP ao desenvolverem suas aplicações. Verifica-se que recursos gerados a partir de qualquer ferramenta desenvolvida ou já inclusa no SCOP devem ser representados por uma classe que seja subclasse de CopResource para se beneficiar do arcabouço. A classe CopResource é uma classe concreta genérica para representar recursos gerados pelas ferramentas das comunidades. Esses objetos são persistidos na base de dados do ambiente A Tabela 6.6 descreve as estruturas da classe CopResource que são herdadas por

71 6.4 Projeto e Arquitetura do SCOP 70 ToolResource na implementação do usuário do SCOP. Tabela 6.6: Atributos da Classe CopResource Identificador Tipo Descrição uri atributo identificador unívoco do recurso dentro do ambiente coptool atributo nome da ferramenta de origem do recurso namespace atributo espaço de nomes relacionado ao recurso createuri método cria uma URI e atribui ao objeto setnamespace método atribui um NameSpace do banco de dados ao recurso getnamespace método recupera o namespace do recurso instanciado add método inclui o recurso instanciado no banco de dados remove método exclui o recurso instanciado do banco de dados update método atualiza o recurso instanciado no banco de dados Um objeto CopResource e, por herança, um ToolResource, essencialmente, armazena uma URI e é capaz de persistí-la no banco de dados usando os métodos add(), remove() e update(). Com esta estrutura, o desenvolvedor pode, em sua aplicação, criar novas ferramentas, como chats, instant messengers, softwares para apresentação de palestras, etc. Todas essas ferramentas podem se beneficiar do arcabouço, desde que gerem mensagens e/ou artefatos que sejam encaixados como recursos da CoP, ou seja, que estendam a classe CopResourse do SCOP. Um objeto CopResourse pode ser ligado, através de propriedades, ao grafo RDF da CoP Organização dos Recursos e Propriedades É importante observar o relacionamento existente entre um objeto CopResource e um objeto NameSpace. O recurso pode estar associado a um espaço de nomes, como é explicado na Seção 4.2. A classe NameSpace possui métodos para persistir os espaços de nomes usados pelo ambiente. Objetos NameSpace podem se relacionar com CopResource e CopProperty. A Tabela 6.7 demonstra as estruturas da classe NameSpace. A classe CopProperty representa as propriedades criadas pelo ambiente. CopProperty também possui métodos para persistir as propriedades, uma vez que elas

72 6.4 Projeto e Arquitetura do SCOP 71 Tabela 6.7: Atributos e métodos da Classe NameSpace Identificador Tipo Descrição url atributo endereço válido do namespace qname atributo qname atribuído ao namespace description atributo breve descrição do namespace add método inclui no banco de dados remove método exclui do banco de dados update método atualiza no banco de dados devem ser recuperadas a qualquer momento durante a construção da base de recursos das comunidades. A Tabela 6.8 demonstra as estruturas da classe CopProperty. Tabela 6.8: Atributos e métodos da Classe CopProperty Identificador Tipo Descrição idproperty atributo nome da propriedade. Tipo Property do Jena description atributo breve descrição da propriedade setbydb atributo busca um propriedade no banco de dados e atribui ao objeto add método inclui no banco de dados remove método exclui do banco de dados update método atualiza no banco de dados Domínio de Conhecimento A Figura 6.6 destaca a parte do diagrama de classes do SCOP responsável por interagir com um domínio de conhecimento.

73 6.4 Projeto e Arquitetura do SCOP 72 Figura 6.6: Classes para interação dos de Recursos com um domínio de Conhecimento No SCOP, um domínio de conhecimento é representado por uma ontologia. O desenvolvedor pode usar a classe CopKDomain para carregar uma ontologia que expresse o domínio de contexto de cada CoP. O desenvolvedor tem a opção de utilizar o método importontology para carregar a ontologia, que é representada pelo atributo ontologymodel da classe CopKDomain. OntologyModel é do tipo OntModel, estrutura do arcabouço Jena que estende o tipo Model e consegue representar estruturas próprias de uma ontologia, como é melhor explicado na Seção 4.5. A Tabela 6.9 referencia as estruturas da classe CopKDomain. Na recuperação de informações por um membro, a ontologia pode ser percorrida usando o método findconcept ou findrelated. O resultado pode ser comparado com a base de conhecimento da CoP e o desenvolvedor poderá optar por apresentar os resultados

74 6.4 Projeto e Arquitetura do SCOP 73 Tabela 6.9: Atributos e métodos da Classe CopKDomain Identificador Tipo Descrição ontologyname atributo nome da ontologia instanciada (importada) conceito atual da ontologia concept atributo (classe da ontologia retornada pelo método findconcept) subgrafo da ontologia relacionado related atributo a um conceito (retornado pelo método findrelated) ontologymodel atributo representação da ontologia importada (tipo OntModel do Jena) copreasoner atributo mecanismo de raciocínio (tipo Reasoner do Jena) importontology método importa e carrega uma ontologia de uma fonte externa findconcept método localiza um conceito na ontologia carregada retorna um subgrafo relacionado ao findrelated método conceito informado da ontologia carregada produz um grafo com o resultado da makereasonermodel método inferência do grafo RDF com a ontologia importada conforme os conceitos da ontologia ou modificar a base de conhecimento da CoP seguindo a estrutura ontológica. Conforme os requisitos estabelecidos, a ontologia carregada representa o domínio da CoP. Ela pode ser usada na inserção e recuperação de recursos na CoP. Na inserção, ela pode ser consultada ou servir de guia, para que aquele recurso seja inserido sempre correspondendo a uma ou mais classes da estrutura ontológica. Na recuperação de recursos, ela pode ser percorrida para que o membro da CoP obtenha resultados mais expressivos, mesmo que os recursos tenham sido gravados sem consulta à ontologia carregada (importada). Outra opção do desenvolvedor é usar a inserção de recursos sem consulta à ontologia. Pode ser criada, por exemplo, uma interface que sugira ao membro apenas recursos, propriedades e valores encontrados na própria base de conhecimento da CoP (grafo RDF). Os métodos findconcept ou findrelated podem ser solicitados para localizar nós do grafo (recursos), além de propriedades e predicados do mesmo, possibilitando interfaces de localização e/ou navegação entre os recursos que ofereçam recursos adicionais dentro do contexto ou que sejam relacionadas ao recurso em foco. O desenvolvedor pode obter um grafo com os resultados da inferência padrão

75 6.4 Projeto e Arquitetura do SCOP 74 do Jena para OWL. Esta inferência é realizada através do método makereasonermodel, que utiliza um parâmetro do tipo Reasoner, do Jena e um grafo RDF (no caso, o graph de uma instância de CopResourceBase pode ser fornecido como parâmetro). O atributo copreasoner é carregado pelo método setreasoner, que usa a ontologia importada (ontologymodel) para isso. Como exemplo hipotético, seja um desenvolvedor que tenha se utilizado do SCOP para construir uma CoP com uma ferramenta de compartilhamento de arquivos, onde os membros inserem e recuperam recursos (arquivos) através da ferramenta. Cada arquivo é considerado um recurso. Ao inserir o arquivo, o sistema pode fornecer uma interface sugerindo ao membro classificar o recurso como uma instância de uma classe recuperada da ontologia, ou mesmo ligar o novo recurso a outro(s) recurso(s) recuperados da base de conhecimento (grafo RDF da CoP) através de propriedades também recuperadas da base de conhecimento da CoP. Caso não haja uma propriedade relevante, o desenvolvedor pode prever que o membro crie novas propriedades, de forma a expandir o grafo RDF que inter-relaciona os recursos da CoP. Se o desenvolvedor optou por não guiar o usuário a inserir os recursos conforme localizados na ontologia, ele terá opção de, nas buscas por recursos (recuperação), compará-los à ontologia, fornecendo respostas mais inteligentes e dentro do contexto esperado da comunidade. Apenas informações mais gerais sobre o projeto e sua implementação foram fornecidas neste capítulo. Seu objetivo é permitir a compreensão do escopo e do projeto do arcabouço. Detalhes necessários ao uso efetivo do SCOP estão disponíveis na documentação das classes, em formato javadoc. No Capítulo 7, o SCOP é utilizado na construção de uma aplicação. Este estudo de caso permite que alguns detalhes sobre sua implementação e funcionamento possam ser melhor compreendidos.

76 Ambiente ACW: um Estudo de Caso CAPÍTULO 7 Com o objetivo de experimentar o SCOP, optou-se uma aplicação que se insere no domínio contemplado pelo SCOP. A aplicação gerencia comunidades virtuais de prática e proporciona interações por meio de uma ferramenta wiki. Esta aplicação é referenciada neste trabalho como ACW (Ambiente de CoPs baseadas em wiki). 7.1 Requisitos do ACW Os principais requisitos básicos do ACW são listados abaixo: O ambiente deve prever um ou mais usuários administradores; Administradores podem adicionar e retirar CoPs do ambiente; Pessoas podem se cadastrar e tornar-se membros de uma ou mais CoPs a qualquer momento; Cada CoP possui uma ferramenta wiki; Cada membro pode editar, criar ou excluir páginas da wiki de sua CoP; Cada Cop pode possuir um grupo de propriedades pré-definidas para interligar páginas wiki. As propriedades são controladas pelos administradores do ambiente, através de interfaces para adicioná-las ou removê-las; Um membro de CoP pode ligar uma página wiki a outra, independentemente dos criadores, usando as propriedades RDF disponíveis; As páginas acessadas devem fornecer links para as páginas ligadas a ela, permitindo ao usuário ver a relação (expressa pela propriedade RDF); As propriedades podem seguir padrões consolidados de núcleos de metadados para a Web (são exemplos: Dublin Core - DC [10], Visit Card - VC) [45]; O ambiente deve ser acessível via Internet, a todos os usuários, através de um navegador (browser). Não é recomendável que se forneça módulo ou pacote instalável no cliente.

77 7.2 Diagrama de Classes do ACW 76 A justificativa por incluir como requisito básico a ferramenta wiki como a ferramenta chave para interação entre os membros da comunidade no projeto se dá pelo fato de esta ser uma ferramenta bastante abrangente no contexto de compartilhamento de conhecimento em comunidades, atendendo a vários dos requisitos que constam na Seção 3.2, onde trata-se de ambientes virtuais que oferecem suporte a CoPs; A Figura 7.1 traz o diagrama de casos de uso do ACW. Figura 7.1: Diagrama de casos de uso do ACW Os casos de uso de inclusão, alteração e gravação de comunidades, páginas e propriedades foram agrupados nos casos de uso iniciados por Manter Diagrama de Classes do ACW Inicialmente, os requisitos foram definidos e os casos de uso foram documentados. A partir deste ponto, iniciou-se o projeto e implementação do ambiente. Os detalhes deste processo são relatados neste capítulo. O passo seguinte foi a produção do diagrama de classes do ACW. A Figura 7.2 apresenta este diagrama. Nesta figura, o SCOP está destacado por um retângulo

78 7.2 Diagrama de Classes do ACW 77 pontilhado. É possível notar que foram utilizados os pontos flexíveis explícitos para estender o SCOP e oferecer os serviços que implementam os requisitos do ACW Funcionamento da Ferramenta Wiki A classe WikiTool é concreta e estende a classe abstrata CopTool, implementando seus métodos abstratos, além de seus métodos próprios. Esta classe representa a ferramenta wiki, e conta com classes auxiliares. O diagrama da Figura 7.2 apresenta apenas os métodos mais relevantes para o estudo da ferramenta. Além dos métodos já explicados no Capítulo 6, o método wikitohtml merece destaque. É um método de alto nível que converte o texto do recurso, originalmente salvo em codificação de Wiki em formato HTML. O método wikitohtml utiliza as classes WikiRenderer e ConverterContext, que formam um motor de conversão de textos em formato próprio de uma wiki em código HTML padrão, que é usado nesse tipo de ferramenta para apresentar o conteúdo da página aos membros. Estas duas classes trazem serviços de mais baixo nível que os serviços da classe WikiTool. O método render da classe WikiRenderer realiza o processo de conversão, respeitando o contexto de conversão, representado pela classe ConverterContext, fornecendo o resultado para o método wikitohtml, que tem o foco na visualização pelo usuário final. Ao invés de desenvolver o motor de conversão, foi obtido um já implementado em código aberto. As classes ConverterContext e WikiRenderer estendem classes obtidas do YaWiki Wiki Engine [30]. Este produto foi escolhido por possuir estrutura bastante simples, o que é desejável para os objetivos do ACW como um estudo de caso. Sobre a classe ConverterContext, representada à direita no diagrama da Figura 7.2, os quatro métodos demonstrados definem peculiaridades da conversão. buildlink define como o mecanismo deve converter em link HTML ao encontrar uma wikiword 1. O método supportimages define se tags <img> devem ser removidas, assim como as demais tags HTML são. O método supportdiv define se as tags <div> devem ser ou não removidas. O método getlinkimage define se uma imagem que conste em uma URL externa deve ser recuperada pelo conversor. 1 Uma wikiword consiste em uma palavra escrita de forma a criar uma ligação para uma nova página wiki. Ela pode variar de acordo com o mecanismo de cada wiki, mas, em geral, a palavra deve ser composta por pelo menos duas letras maiúsculas separadas por uma ou mais letras minúsculas. Ex: DissertacaoDeMestrado.

79 7.2 Diagrama de Classes do ACW 78 Figura 7.2: Diagrama de classes do ACW

80 7.3 Ferramentas para o projeto do ACW Geração de recursos e manipulação da base RDF O principal papel da classe WikiTool é gerar os recursos que devem ser persistidos no banco de dados. Tais recursos são representados pelos objetos WikiResource. A persistência é oferecida pelo SCOP através dos métodos iniciados por add, remove ou update da classe WikiTool. Para serem persistidos, estes recursos devem possuir um identificador (URI). O serviço que gera os URI s é disponibilizado através do método createuri, herdado da classe CopResource. Resumindo, ao acionar WikiTool.addResource() a ferramenta persiste o objeto WikiResource, com seu conteúdo e o URI a para ele designada, incluindo o namespace, se usado na formação do identificador do recurso. Como já colocado no Capítulo 6, uma vez persistido um objeto CopResource, ou, mais especificamente, um WikiResource, o desenvolvedor pode usar a classe CopResourceBase para adicionar esses objetos ao grafo RDF da comunidade, bem como removê-lo do grafo. O método, inicialmente, checa se o objeto foi persistido para, em seguida, adicionar sua URI ao grafo. Isso porque não faz sentido adicionar um recurso não persistente a um grafo que objetiva formar uma base persistente e contínua de referências aos recursos. 7.3 Ferramentas para o projeto do ACW SCOP provê serviços de alto nível para os desenvolvedores. Dentre estes serviços, existem os de persistência. Conforme foi dito e justificado anteriormente, esta versão do SCOP oferece a persistência de alguns objetos através do banco de dados MySQL. A versão Server do MySQL Essential foi utilizada. Optou-se pelo desenvolvimento das interfaces usando a tecnologia JSP (Java Server Pages)[35], pois possibilita acessar as classes e métodos do SCOP e as próprias do ACW diretamente a partir das páginas JSP de forma facilitada, através do uso de JavaBeans. O container Tomcat [17] foi a opção de servlet container para executar o código JSP. Tal opção deve-se à total compatibilidade do Tomcat com as diferentes versões do JSP. Foi iniciado um projeto utilizando o ambiente de desenvolvimento Eclipse [18], configurando sua perspectiva Java para uso das tecnologias apontadas nos parágrafos acima. SCOP, assim como as classes próprias do ACW foram acrescentadas ao projeto. Sobre decisões de projeto e implementação, é importante ressaltar, acerca do que consta neste capítulo, que:

81 7.4 Interfaces e Códigos do ACW 80 Todas as opções de ferramentas para o projeto são de uso livre e código aberto; Alguns detalhes de implementação que fogem do escopo desta dissertação são omitidos. São exemplos: questões referentes a design, práticas de programação para a Internet, códigos que rodam no cliente, dentre outros); Todos os códigos-fonte que constam em páginas JSP apresentados na seção a seguir são executados no servidor, uma vez que esses trechos de código são os responsáveis pelas chamadas do SCOP e às classes próprias do ACW. 7.4 Interfaces e Códigos do ACW Esta seção seleciona algumas interfaces importantes e trechos de códigos que rodam no lado servidor (server-side scripts) das páginas JSP relacionados a tais interfaces e às estruturas do SCOP Principais funções do ambiente Adicionando uma pessoa A interface responsável por adicionar uma pessoa no ambiente é demonstrada na da Figura 7.3. O Código 7.1 demonstra o trecho da página JSP responsável por essa inclusão. Figura 7.3: Interface para adição de pessoa no ACW

82 7.4 Interfaces e Códigos do ACW 81 Código 7.1 Código para adicionar uma pessoa no ACW 1 <%@ page contenttype="text/html" language="java" import="java.sql.*"%> 2 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 3 " 4 5 <!-- Usando um Javabean para instanciar um objeto de Person --> 6 <jsp:usebean id="p" class="cops.pessoa" scope="session"/> 7 8 <% 9 // captura variáveis do formulário 10 String rq_id_member = request.getparameter("edt_id_member"); 11 String rq_name = request.getparameter("edt_name"); 12 String rq_ = request.getparameter("edt_ "); 13 String rq_password = request.getparameter("edt_password"); // // Seta os atributos do objeto p 18 p.id = rq_id_member; 19 p.firstname = firstname; 20 p.lastname = lastname; 21 p.middlename = middlename 22 p. = rq_ ; 23 p.password = rq_password; // Adiciona no BD 26 boolean ok = p.add(); 27 // %> Opções Iniciais A Figura 7.4 apresenta a tela inicial de opções, quando uma pessoa se autentica no ambiente. O usuário pode escolher entre participar de uma CoP ou abandonar uma da qual já é membro. Também pode alterar dados de seu perfil. Se a pessoa tiver nível de privilégio de administrador do ambiente, são mostradas as opções da parte inferior da tela, de criar, alterar ou remover uma CoP no ACW.

83 7.4 Interfaces e Códigos do ACW 82 Figura 7.4: Interface inicial após autenticação Associando pessoas e comunidades A Figura 7.5 mostra a interface usada para que uma pessoa do ambiente se torne membro de uma CoP ou abandone uma CoP da qual já seja membro.

84 7.4 Interfaces e Códigos do ACW 83 Figura 7.5: Interface tornar-se membro ou abandonar CoPs O Código 7.2 apresenta o trecho da página JSP responsável pela inclusão de uma pessoa em uma comunidade. Código 7.2 Código para incluir uma pessoa em uma CoP 1 <%@ page contenttype="text/html" language="java" import="java.sql.*"%> 2 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 3 " 4 5 <!-- Usando Javabeans para instanciar objetos --> 6 <jsp:usebean id="mbr" class="cops.member" scope="session"/> 7 <jsp:usebean id="cop" class="cops.cop" scope="session"/> 8 9 <% 10 /* O objeto p (da classe Person) já foi instanciado anteriormente. 11 p é visível nesta página JSP, pois seu escopo é de seção */ // captura variáveis do formulário 14 String rq_cop = request.getparameter("cbo_cop"); // seta o objeto cop conforme a escolha do usuário 17 cop.setcopbyid("copteste"); // faz a atribuiçao da Cop ao membro mbr 20 mbr = (Member) p; 21 mbr.participationlevel = 1; 22 boolean ok = mbr.joincop(cop); 23 //...

85 7.4 Interfaces e Códigos do ACW 84 Ferramentas da Cop A Figura 7.6 mostra a tela inicial de uma CoP do ambiente. A partir dela, o membro participante poderá acessar o ambiente colaborativo (wiki) da CoP, verificar os membros que fazem parte da comunidade e enviar-lhes mensagens por . Se o membro tiver nível de administrador, poderá controlar os espaços de nomes e propriedades utilizáveis por esta CoP, usando os controles da parte inferior da tela. Figura 7.6: Interface inicial após autenticação No momento em que um membro acessa a CoP, seu objeto (cop) é instanciado (com escopo de seção). Ao acessar o link Ambiente Colaborativo, o sistema verifica se existe a ferramenta wiki na comunidade instanciada. Caso ainda não exista, ele cria um objeto wiki com referência ao objeto cop. O Código 7.3 demonstra estas operações. Esse mecanismo é válido para qualquer ferramenta incluída. No caso do ACW, a única disponível é a wiki.

86 7.4 Interfaces e Códigos do ACW 85 Código 7.3 Código para atribuir uma ferramenta (wiki) a uma Cop 1 <%@ page contenttype="text/html" language="java" import="java.sql.*"%> <!-- Usando Javabeans para instanciar mywiki --> 4 <jsp:usebean id="mywiki" class="tools.wiki" scope="session"/> 5 6 <% 7 /* Os objetos mbr e mycop já foram instanciados anteriormente 8 e são utilizáveis durante a seção 9 10 Se existe Wiki para a CoP, aponta o objeto Wiki para 11 funcionar com minha CoP */ ExisteWiki = mycop.checktool("wiki") if (ExisteWiki) { 16 boolean ok = mywiki.setcop(mycop); 17 } A Figura 7.7 apresenta a tela inicial da wiki. O recurso em foco é PaginaInicial. É possível perceber, do lado direito, links referentes a recursos que estão ligados ao recurso em foco, agrupados pelas propriedades através das quais o recurso está ligado aos demais (sujeitos ou objetos das triplas RDF). Figura 7.7: Tela da ferramenta wiki mostrando o recurso inicial

87 7.4 Interfaces e Códigos do ACW 86 Na parte inferior, existem opções para editar o recurso ou ligá-lo a outro recurso. A opção de exclusão é realizada automaticamente, bastando remover todo o texto do recurso. Inclusão de Recursos Em uma wiki, é necessário que os membros conheçam a sintaxe básica de edição dos textos. Para se criar um recurso (página wiki), a maneira natural é inserir um link (através de uma wikiword, por exemplo) no corpo de um outro recurso. Ao clicar no link, o recurso correspondente ao mesmo é criado na CoP, com um texto inicial padrão em seu conteúdo. O criador do link deve, a partir de então, inserir seu conteúdo e salvar. A Figura 7.8 mostra a interface de edição do recurso PaginaInicial, mostrado acima em HTML. Figura 7.8: Tela da ferramenta wiki de edição/inclusão de recurso Durante a edição do recurso, antes de salvar, o editor tem a opção de atribuir um namespace ao mesmo, selecionando um dentre os existentes na CoP, mostrados na caixa de seleção. Incluindo Recursos na Base RDF O Código 7.4 mostra o trecho da página JSP responsável por incluir o recurso na base RDF da CoP.

88 7.4 Interfaces e Códigos do ACW 87 Código 7.4 Código para adicionar um recurso à Cop 1 <%@ page contenttype="text/html" language="java" import="java.sql.*"%> <!-- Usando Javabeans para instanciar mywiki --> 4 <jsp:usebean id="mywiki" class="tools.wiki" scope="session"/> 5 6 <% 7 /* Os objetos mbr e mycop já foram instanciados anteriormente 8 e são utilizáveis durante a seção 9 10 Se existe Wiki para a CoP, aponta o objeto Wiki para 11 funcionar com minha CoP */ ExisteWiki = mycop.checktool("wiki") if (ExisteWiki) { 16 boolean ok = mywiki.setcop(mycop); 17 } Interligando recursos A Figura 7.9 mostra a interface de ligação entre recursos. Um membro pode interligar recursos produzidos por quaisquer outros membros da CoP. Figura 7.9: Tela para interligação de recursos da CoP O Código 7.5 mostra o trecho da página JSP responsável por interligar os recursos em triplas RDF, usando a classe CopResourceBase.