EXTENDED FEDERATED SOCIAL NETWORKS IN ENVIRONMENTAL SUSTAINABILITY
Tiago Filipe Rodrigues Eirinha
Orientador
Doutor Luís Ferreira
Trabalho de Projeto apresentado
ao Instituto Politécnico do Cávado e do Ave
para obtenção do Grau de Mestre em Engenharia Informática Este trabalho não inclui as críticas e sugestões feitas pelo Júri.
Março, 2017
EXTENDED FEDERATED SOCIAL NETWORKS IN ENVIRONMENTAL SUSTAINABILITY
Tiago Filipe Rodrigues Eirinha
Orientador
Doutor Luís Ferreira
Trabalho de Projeto apresentado
ao Instituto Politécnico do Cávado e do Ave
para obtenção do Grau de Mestre em Engenharia Informática
Março, 2017
DECLARAÇÃO
Nome: Tiago Filipe Rodrigues Eirinha Endereço eletrónico: a5417@alunos.ipca.pt Tel./Telem.: 914293609
Cartão de Cidadão N.º: 13574524 1 ZY0
Título do Trabalho: Extended Federated Social Networks in Environmental Sustainability Orientador: Doutor Luís Ferreira
Ano de conclusão: 2017
Designação do Curso de Mestrado: Mestrado em Engenharia Informática – Ramo Desenvolvimento de Aplicações
É AUTORIZADA A REPRODUÇÃO INTEGRAL DO PRESENTE TRABALHO APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE.
Instituto Politécnico do Cávado e do Ave, 31 de Março de 2017
Assinatura: ___________________________________________________________
Resumo
Redes Socias Federadas Estendidas na Sustentabilidade Ambiental
A enorme e rápida adesão ao uso das redes sociais, leva-nos a inferir que representam um dos mais relevantes fenómenos ligados à internet e às Tecnologias de Informação e Comunicação (TIC) em geral. Na generalidade dos casos, sempre que um comportamento assenta num rápido “crescimento”, um conjunto de questões serão levantadas. As redes sociais federadas surgiram no seguimento deste fenómeno, procurando colmatar algumas das lacunas identificadas nas redes sociais atuais, nomeadamente ao nível da portabilidade dos dados, da identidade, da referenciação e da privacidade. Após uma análise cuidada, pensa-se que algo mais se pode acoplar a este conceito.
Cada vez mais é essencial perceber o contexto em que as “coisas” acontecem e orientar o desenvolvimento de aplicações no sentido de apresentarem alguma “consciência” ou sensibilidade ao contexto onde são utilizadas, i.e., em vez de trabalharem de uma forma isolada, poderem de alguma forma colaborar entre si. Assim, é possível usufruir de múltiplas aplicações, de diferentes tipos e fornecedores, a interoperarem entre elas e a adaptarem-se ao contexto global, num dashboard comum. Se a isto acrescentarmos a possibilidade de as aplicações serem partilhadas entre membros de uma rede, então teremos uma rede constituída por nodos com capacidade de, autonomamente, reconfigurarem-se e adaptarem-se ao contexto necessário.
Existindo a sensibilidade ao contexto e, consequentemente, a deteção de necessidades, torna-se indispensável a existência de mecanismos capazes de auxiliarem a obtenção de respostas (brokering) com opções viáveis, permitindo resolver “problemas” de uma forma ágil, rápida e eficaz.
A eficácia na colaboração promove a co-decisão e a capacidade de comunicação humano-humano representa a essência neste processo. Nas redes sociais atuais, a existência de múltiplos canais (meios ou serviços) de comunicação representa uma mais-valia, mas a não integração desses mesmos canais, evidencia um sério constrangimento, forçando os utilizadores a estarem presentes em várias plataformas (redes) de maneira a atingir todas pessoas que desejam. É evidente nos dias de hoje a tendência destas plataformas em uniformizar entre si formas de comunicação integradas (chats, videoconferências, outras). Existe assim e ainda, a necessidade de unificar (ou melhor, integrar) a comunicação humano-humano, tornando-a mais próxima dos atuais sistemas telefónicos em relação à sua arquitetura de funcionamento. Neste sistema existem múltiplos provedores de serviço, mas o utilizador não necessita de se preocupar com o “canal” usado. Não está na sua consciência se o recetor para quem pretende comunicar possui ou não um canal (serviço) igual.
Este trabalho propõe uma arquitetura de sistemas e desenvolve um protótipo onde se incorporam componentes que tentam responder às extensões identificadas, nomeadamente uma arquitetura de interoperabilidade de widgets, uma arquitetura comunicacional e um sistema de brokering.
Palavras-chave: Redes Sociais Federadas, Semântica, Context-Aware, Brokering, Reconfiguração Dinâmica, Canais Comunicacionais, Interoperabilidade, Mercado de Recursos.
Abstract
Extended Federated Social Networks in Environmental Sustainability
The huge and rapid use of social networks leads us to infer that they represent one of the most relevant phenomena related to the Internet and Information and Communication Technologies (ICT) in general. In most cases, whenever a behaviour is based on a rapid-growth process, a set of issues will be raised. Federated social networks emerged as a result of this phenomenon, seeking to fill some of the gaps identified in today’s social networks, namely as far as data portability, identity, referencing and privacy are concerned. After a careful analysis, it is thought that something else can be connected to this concept.
It is increasingly essential to realize the context in which "things" happen and guide the development of applications in order to present some "awareness" or sensitivity to context in which they are used, ie, instead of working alone, they can, somehow, collaborate with each other. Thus, it is possible to take advantage of multiple applications, of different types and suppliers, interoperating among them and adapting themselves to the global context, in a common dashboard. If we add the possibility of applications being shared between members of a network, then we will have a network consisting of nodes with the capacity of, autonomously, reconfiguring and adapting themselves to the necessary context.
Given the sensitivity to context and, consequently, the detection of needs, it is indispensable to have mechanisms capable of helping to obtain answers (brokering) with viable options, allowing the resolution of
"problems" in an agile, fast and effective way.
Collaboration effectiveness promotes co-decision and the ability to communicate human-human represents the essence in this process. In today's social networks, the existence of multiple channels (media or services) of communication represents an added value, but the non-integration of these same channels is a serious constraint, forcing the users to be present in several platforms (networks), so that all people are reached. The tendency of these platforms to standardize integrated forms of communication among themselves (chats, videoconferences, others) is evident, nowadays. There is also, and still, the need to unify (or rather integrate) human-human communication, making it closer to the current telephone systems regarding its operating architecture. In this system, there are multiple service providers, but the user does not need to worry about the
"channel" used. It is not in his/her consciousness if the receiver for whom the user intends to communicate has an equal channel or service.
This work proposes a systems architecture and develops a prototype that incorporates components which try to respond to the extensions identified, namely a widgets interoperability architecture, a communicational architecture and a brokering system.
Keywords: Federated Social Networks, Semantics, Context-Aware, Brokering, Dynamic Reconfiguration, Communication Channels, Interoperability, Resource Market.
Agradecimentos
Esta secção é dedicada a todas as pessoas que, direta ou indiretamente, me ajudaram a atingir mais uma etapa importante na minha formação académica. Deixo aqui poucas palavras, mas com um sentimento sincero de agradecimento.
Ao meu orientador, Doutor Luís Gonzaga Ferreira, por toda a disponibilidade, dedicação, paciência, profissionalismo, orientação e apoio. Muito Obrigado!
À minha namorada, Patrícia, por toda a compreensão e companhia, assim como, pelo apoio e incentivo prestados ao longo do desenvolvimento deste trabalho.
À minha família, em especial aos Meus Pais e ao Meu Irmão. Um enorme obrigado por todo o esforço e sacrifício que, paralelamente à minha vontade, permitiram-me atingir este patamar. Espero que, de alguma forma, a conclusão desta etapa possa retribuir toda a vossa dedicação prestada desde o meu primeiro dia. A eles dedico todo este trabalho!
Ao Engenheiro Leopoldo Silva, pela ajuda essencial na revisão deste trabalho, pelas opiniões e questões que estimularam reflexões profundas.
A todos os demais, um Muito Obrigado!
Lista de Abreviaturas e Siglas
AJAX Asynchronous Javascript and XML API Application Programming Interface
CAC Context-Aware Computing
CSS Cascading Style Sheets
CMS Content Managment System
EJS Embedded JS
FSN Federated Social Network
FSW Federated Social Web
FSWCG Federated Social Web Community Group GESC Greenhouses Environmental Sensing and Control
H2H Human-to-Human
HCI Human-Computer Interaction
HMI Human-Machine Interface
HSI Human-System Interface
HTML HyperText Markup Language HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure
IM Instant Messaging
IoT Internet of Things
IRI International Resource Identifier JSON Javascript Object Notation
JSON-LD JSON Linked-Data
M2H Machine-to-Human
M2M Machine-to-Machine
MMI Man-Machine Interface
MQTT Message Queing Telemetry Transport
MVC Model-View-Controller
NoSQL Not Only SQL
OWL Web Ontology Language
P2P Peer-to-Peer
PHP Hypertext Preprocessor, originalmente Personal Home Page
RDF Resource Description Framework
RDFS Resource Description Framework Schema RFID Radio-Frequency Identification
RIA Rich Internet Application
SASS Syntactically Awesome Style Sheets SGBD Sistema de Gestão de Bases de Dados SIP Session Initiation Protocol
SMS Short Message Service
SQL Structured Query Language
SSL Secure Socket Layer
TIC Tecnologias de Informação e Comunicação
TLS Transport Layer Security
UI User Interface
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
UX User Experience
W3C World Wide Web Consortium
WSN Wireless Sensor Network
XML Extensible Markup Language
XMPP Extensible Messaging and Presence Protocol
Índice
Resumo ... i
Abstract ... iii
Agradecimentos ... v
Lista de Abreviaturas e Siglas ... vii
Índice de Figuras ... xi
Índice de Códigos-Fonte ... xii
Índice de Tabelas ... xiii
1. Introdução ... 1
1.1. Enquadramento ... 1
1.2. Motivação ... 2
1.3. Objetivos e Contribuições ... 2
1.4. Metodologia de Trabalho ... 3
1.5. Estrutura do Documento ... 3
1.6. Notas para o Leitor ... 4
2. Estado da Arte ... 5
2.1. Infra-estrutura “Rede Federada” ... 5
2.1.1. Redes Sociais ... 5
2.1.1.1. Social Graphs ... 5
2.1.1.2. Social Media ... 6
2.1.1.3. Social Frameworks ... 7
2.1.2. Redes Federadas ... 9
2.2. Representação da Informação ... 11
2.2.1. Dados Estruturados e Não-Estruturados ... 12
2.2.2. Interoperabilidade de Dados ... 14
2.2.2.1. Modelação Semântica dos Recursos ... 16
2.2.2.2. JSON-LD ... 19
2.2.3. Impacto dos Dados ... 22
2.3. Colaboração e Cooperação ... 24
2.3.1. XMPP ... 24
2.3.2. MQTT ... 25
2.3.3. WebRTC ... 26
2.3.4. WebSocket ... 28
2.3.5. SignalR ... 29
2.3.6. Pusher ... 30
2.3.7. Dashboards ... 31
2.4. Resumo ... 33
3. Os Alicerces de uma EFSN ... 35
3.1. Ubiquidade de Recursos ... 35
3.2. Mercado de Recursos ... 36
3.2.1. Reconfiguração Dinâmica ... 36
3.2.2. Contexto ... 37
3.3. Brokering ... 39
3.4. Interação Eficaz em Dashboards ... 40
3.5. Resumo ... 42
4. Rede Federada “Estendida”... 43
4.1. Problema ... 43
4.2. Solução ... 44
4.2.1. Requisitos da Solução ... 45
4.2.2. Atividades no Sistema ... 46
4.2.3. Coleções de Dados ... 47
4.2.4. Privacidade de Dados ... 49
4.2.4.1. HTTPS ... 49
4.2.5. Encriptação de Passwords ... 51
4.2.6. Dashboard ... 51
4.2.7. Arquitetura de Interoperabilidade de Widgets ... 54
4.2.7.1. Criação de Widgets ... 55
4.2.7.2. Reconfiguração Dinâmica dos Widgets ... 57
4.2.8. Arquitetura Comunicacional ... 59
4.2.8.1. Sincronização de Widgets ... 59
4.2.8.2. Sincronização de Membros na Rede ... 61
4.2.8.3. Canais Comunicacionais ... 63
4.2.9. Sistema de Pesquisa ... 67
4.2.10. Brokering de Recursos ... 68
4.2.10.1. Case Study: Monitorização Ambiental numa Estufa ... 70
5. Reflexão ... 73
6. Conclusões e Trabalhos Futuros ... 77
7. Bibliografia ... 79
Índice de Figuras
Figura 1 - Exemplo de Utilização de um código QR ... 4
Figura 2 - Social Graph ... 6
Figura 3 - Centralização das Redes Sociais ... 10
Figura 4 - Sistemas Centralizados vs Descentralizados vs Federados ... 11
Figura 5 - Base de Dados Não-Relacional orientada ao documento ... 13
Figura 6 - Expansão da Web ... 15
Figura 7 - Grafo de Dados ... 16
Figura 8 - Grafo de dados simples ... 17
Figura 9 - Documento JSON-LD ... 21
Figura 10 - Os 5 V's do Big Data ... 22
Figura 11 - O crescimento da quantidade de dados ... 23
Figura 12 - Estratégia do Big Data ... 23
Figura 13 - Arquitetura Publish/Subscribe – MQTT ... 26
Figura 14 - WebRTC Trapezoid ... 27
Figura 15 - WebRTC Triangle ... 27
Figura 16 - Polling ... 28
Figura 17 - Long Polling ... 28
Figura 18 - Streaming ... 29
Figura 19 - Protocolo WebSocket ... 29
Figura 20 - Conexão Virtual SignalR ... 30
Figura 21 - Integração do Pusher ... 30
Figura 22 - Hierarquias em Context-aware envolvem propriedades físicas e humanas ... 38
Figura 23 - Dimensões do Brokering de Informação ... 39
Figura 24 - Protótipo – Dashboard ... 44
Figura 25 - Arquitetura da solução desenvolvida ... 45
Figura 26 - Ações sobre o Sistema ... 46
Figura 27 - Protótipo – Coleções de Dados NoSQL ... 47
Figura 28 - Protótipo – Implementação de HTTPS ... 50
Figura 29 - Esquema de Colunas ... 52
Figura 30 - "Nesting" de Colunas ... 52
Figura 31 - Adaptação do dashboard a ambientes móveis (responsividade) ... 53
Figura 32 - Constituição de um Widget ... 56
Figura 33 - Processo de construção de um Widget ... 56
Figura 34 - Processo de construção de um Widget Partilhado ... 57
Figura 35 - Reconfiguração Dinâmica do Dashboard ... 58
Figura 36 - Mapeamento de Canais Comunicacionais (H2H) ... 63
Figura 37 - Processo de envio de mensagem de texto ... 65
Figura 38 - Comparação de scores entre pesquisas – Full-Text Search em MongoDB ... 68
Figura 39 - Integração do Broker de Recursos ... 69
Índice de Códigos-Fonte Código 1 - Exemplo de RDF ... 17
Código 2 - Web Ontology Language (Classes, Subclasses e Indivíduos) ... 18
Código 3 - Web Ontology Language (Propriedades) ... 19
Código 4 - International Resource Identifier ... 20
Código 5 - JSON-LD – Nomes Reservados ... 21
Código 6 - Exemplo de Mensagem XMPP ... 25
Código 7 - Pusher – Exemplo comunicação entre cliente-servidor ... 31
Código 8 - Exemplo de documento guardado na coleção “Thing” ... 48
Código 9 - Conexão à base de dados (MongoDB/PHP) ... 48
Código 10 - Inserção de informação na Base de Dados ... 49
Código 11 - Password encriptada através do algoritmo de encriptação bcrypt ... 51
Código 12 - Exemplo de aplicação de esquema de colunas (Foundation) ... 53
Código 13 - Definição de um template em Embedded JS ... 54
Código 14 - Instanciação do template e renderização com dados dinâmicos ... 54
Código 15 - Subscrição de Canal por Dashboard ... 60
Código 16 - Registo da associação entre Widget e Canais (Dashboards) ... 60
Código 17 - Vinculação a Evento Próprio ... 60
Código 18 - "Disparo" de Eventos para Canais associados a um Widget ... 61
Código 19 - Vinculação a um Evento Geral ... 61
Código 20 - Registo de relações entre utilizadores ... 62
Código 21 - Notificação de todas as relações de mudança de estado ... 62
Código 22 - Atualização da variável "status" em relação a um utilizador ... 62
Código 23 - "Vinculação" a evento responsável pela Gestão de Presenças das Relações ... 62
Código 24 - Evento de Atualização de Estado (Online/Offline) ... 64
Código 25 - Evento de Receção de Mensagem de Texto ... 65
Código 26 - Processo de "escuta" de eventos em relação a uma conta de utilizador (XMPP) ... 66
Código 27 - Integração do Serviço Twilio ... 67
Código 28 - Criação de um Índice de Texto sobre a coleção thing ... 67
Código 29 - Sistema de Pesquisa – Pedido(1) e Resposta(2) ... 68
Código 30 - Presença dos atributos "@context" e "@type" num documento da coleção "Thing" ... 70
Código 31 - Tipo de Informação recebida pelo Broker de Recursos ... 71
Índice de Tabelas Tabela 1 - Análise de Serviços/Utilização das Redes Sociais atuais ... 7
Tabela 2 - Principais Características das Social Frameworks ... 8
Tabela 3 - Dados Estruturados vs Dados Não-Estruturados ... 13
Tabela 4 - Podio vs Trello vs Asana vs EFSN ... 33
1. Introdução
Este capítulo apresenta as considerações globais deste projeto. Está estruturado em seis secções: a primeira, que enquadra o tema na atualidade; a segunda, que descreve a motivação que sustenta esta pesquisa; a terceira, que apresenta os objetivos a atingir; a quarta, que apresenta os métodos de trabalho adotados no desenvolvimento deste projeto; a quinta com a estrutura e organização deste documento e, por fim, a sexta com uma nota para orientar o leitor deste documento.
1.1. Enquadramento
As redes sociais atuais limitam-se a gerir relações entre os seus membros. Conseguir abstração na forma/meio de relacionamento entre as pessoas de múltiplas redes sociais (e não só), fazendo com que o conceito se espalhe por toda a web, é ainda um desafio.
A Social Web, por exemplo, não se foca apenas nos relacionamentos, mas também nas aplicações e inovações que podem surgir em cima dos mesmos. As atuais redes sociais têm um grande potencial para facilitar a inovação, mas não conseguem lá chegar sem a existência de padrões abertos em relação à portabilidade dos dados, identidade e desenvolvimento de aplicações. Neste momento, cada rede social está definida/desenvolvida de forma “fechada” e não interoperável, i.e., com as suas próprias implementações (privadas) e, normalmente, apresenta poucas garantias de privacidade dos dados (W3C, 2013). A necessidade de se estabelecerem middlewares assentes em padrões e formas comuns na integração de processos, que permitam aos utilizadores interagirem entre as redes, é evidente. A Social Web terá de seguir padrões idênticos aos dos serviços de comunicação telefónica e e-mail, onde, independentemente do operador/provedor de serviço, os utilizadores comunicam “sem consciência” do canal/plataforma que estão a usar, permitindo aos utilizadores relacionarem-se por toda a web, sempre com controlo sobre a privacidade dos seus dados.
Além da necessária transparência na utilização das tecnologias, a relação humano-humano também se apresenta como algo fundamental tendo em vista a utilização eficiente de sistemas eficazes. As redes sociais atuais demonstram a disponibilidade das pessoas em aderirem a novas formas de interagir/distrair, mas a tradicional perspetiva de desenvolver sistemas de informação, que sustentam o binómio humano-máquina, não promove a relação humano-humano, intrínseca a todo o humano, necessária para conseguir sistemas eficazes com mecanismos de colaboração que potenciam co-avaliação e co-decisão (Eirinha, Ferreira, Putnik, Cruz, &
Lopes, 2015).
A necessidade de perceber e interpretar o contexto com que cada utilizador se depara, em todos os momentos, faz parte do comportamento humano. De igual forma é essencial adaptar e dotar as aplicações com capacidades de reação em relação ao que acontece no seu redor, promovendo uma melhor experiência de utilização – User Experience (UX) e interação.
A existência de “inteligência” nos processos de descoberta de potenciais soluções permite às pessoas decidirem quais aquelas que melhor satisfazem os seus critérios. Num cenário de múltiplos tipos de entidades ou recursos
(pessoas, máquinas, etc.), normal numa rede federada, a existência de processos de classificação e mecanismos de apoio à seleção e decisão são essenciais.
1.2. Motivação
As redes sociais atuais apresentam um conjunto de problemas que estão devidamente documentados. Com o objetivo de responder a esses problemas, surgiu um grupo no World Wide Web Consortium, designado de Federated Social Web Community Group (FSWCG), que está responsável por tentar estabelecer padrões entre as redes sociais existentes, ao nível da portabilidade, da identidade, da referenciação e da privacidade.
Neste contexto e conscientes do estado atual da Social Web, onde um enorme conjunto de recursos não classificados (nomeadamente pessoas) coexistem, entendemos ser fundamental progredir em relação à capacidade de classificação e seleção de recursos para o utilizador, assim como na integração de canais comunicacionais eficazes. Este cenário torna-se muito mais evidente quando destas redes fizerem parte recursos que não pessoas, como máquinas, sensores, sistemas, etc.
É necessário assim “estender” o conceito de rede social federada, que vem sendo trabalhado pelo FSWCG, através da implementação de: i) uma arquitetura que permita o desenvolvimento e integração de aplicações baseadas no contexto (context-aware) e que permita a partilha e consequente colaboração em tempo-real sobre as mesmas; ii) uma arquitetura comunicacional que ofereça uma comunicação eficaz e com ausência de
“consciência” sobre o canal comunicacional que está a ser usado; iii) um sistema de brokering capaz de oferecer ao utilizador um conjunto de recursos capazes de responder às necessidades detetadas no seu ambiente de trabalho.
1.3. Objetivos e Contribuições
O projeto tem como objetivo global a construção de uma arquitetura que suporte o funcionamento de uma comunidade restrita de colaboradores (rede social federada) composta por múltiplos perfis de participação com diferentes formas de colaboração para com os outros.
Este trabalho foi explorado na monitorização e controlo ambiental de estufas agrícolas. Todo o desenvolvimento foi orientado no sentido de satisfazer os objetivos principais em relação à extensão que se pretende aplicar às redes sociais federadas:
⎯ Desenvolvimento de um Ecossistema de Things (ativos e passivos);
⎯ Elaboração de uma Arquitetura de Desenvolvimento e Integração de múltiplas aplicações
“conscientes” do contexto no mesmo dashboard, com a possibilidade de partilha entre os utilizadores da rede e consequente colaboração em tempo-real sobre as mesmas;
⎯ Desenvolvimento de uma Arquitetura Comunicacional eficaz, i.e., com garantia de comunicação e abstração em relação ao canal que está a ser usado;
⎯ Desenvolvimento de um Sistema de Brokering capaz de perceber o ambiente em que o utilizador se encontra e, consequentemente, oferecer alternativas/opções através de pesquisas realizadas sobre a rede com o objetivo de encontrar recursos com capacidade de responder às necessidades.
Destes objetivos deverá resultar um protótipo de uma plataforma web para uma rede federada de colaboradores, onde o dashboard de monitorização é constituído por: i) widgets/aplicações capazes de serem partilhados e atualizados em tempo-real; ii) visualização de colaboradores relacionados e os seus canais comunicacionais e iii) visualização de resultados devolvidos pelo sistema de brokering.
Atingidos os objetivos, procurar-se-á publicar os resultados em conferências através da redação de, pelo menos, um artigo.
1.4. Metodologia de Trabalho
A metodologia de desenvolvimento deste projeto passou por um conjunto de atividades/práticas orientadas ao
“produto” final. Ao longo do seu desenvolvimento existiram diversas reuniões de acompanhamento, tanto para análise de metas a atingir, como para as estratégias a adotar. Isto permitia estar em constante sintonia com o orientador em relação ao caminho a percorrer.
O foco inicial passou pelo estudo de conceitos que estão ligados ao tema. Perceber o que existe e recolher elementos essenciais desse estudo foi fundamental no progresso do trabalho desenvolvido. Esse estudo, por vezes, obrigou ao desenvolvimento prático com o objetivo de testar conceitos/tecnologias.
Quanto à fase de desenvolvimento propriamente dita, começou com um brainstorming. Conforme se iam discutindo ideias, conseguiu-se responder a questões essenciais quanto ao trabalho a desenvolver: o que vai ser feito? como vai ser feito? quando vai ser feito? porque se vai fazer? O que está a ser feito que esteja relacionado? Após esta persistente e longa análise inicial, o trabalho foi avançando, apresentando e discutindo, com o orientador, todas as etapas especificadas. Aqui foi aplicada a metodologia ágil SCRUM.
A nível de ferramentas adotadas para a organização deste projeto, o DropBox1 e o Trello2 foram as eleitas. O primeiro mais orientado à partilha de ficheiros, enquanto que o segundo permitiu definir e registar as tarefas que levaram à conclusão de cada capítulo e de cada fase da parte prática.
Como suporte de acompanhamento de todo o trabalho, foi ainda desenvolvido um website, www.justowork.com/tiagoeirinha/thesis, onde foram publicados diversos artigos sobre os conceitos e tecnologias abordados(as).
1.5. Estrutura do Documento
Este documento divide-se em 6 capítulos, incluindo o atual – Introdução. Neste primeiro capítulo é feito o enquadramento do projeto destacando a relevância da problemática através da descrição das motivações e objetivos.
O segundo capítulo – Estado da Arte – expõe um estudo realizado antes do trabalho propriamente dito, i.e., apresenta o que existe e está a ser desenvolvido em relação à temática deste projeto, a partir de uma análise de conceitos, modelos e tecnologias que coincidem com a área das redes federadas.
1 http://www.dropbox.com/
2 https://trello.com/
O terceiro capítulo – Os Alicerces de uma EFSN – declara conceitos e visões que se afirmam como bases do conceito de Rede Federada Estendida, i.e., componentes essenciais para que a dita extensão de rede federada consiga ser aplicada.
O quarto capítulo – Rede Federada “Estendida” – apresenta o “Trabalho Desenvolvido”, desde os requisitos estabelecidos até à implementação do Broker de Recursos, passando por questões de armazenamento, segurança, arquitetura de widgets, arquitetura comunicacional e pesquisa.
O quinto capítulo – Reflexão – descreve as principais considerações, através de uma reflexão sobre o trabalho desenvolvido, contrapondo os objetivos propostos com os resultados finais.
O sexto capítulo – Conclusões e Trabalhos Futuros – expõe as conclusões sobre o trabalho desenvolvido e apresenta as perspetivas futuras para a evolução deste projeto.
O documento termina com a apresentação das referências bibliográficas consultadas.
1.6. Notas para o Leitor
Durante a leitura deste documento, o leitor irá deparar-se com códigos Quick Response (QR) presentes em algumas imagens. A presença destes códigos tem como objetivo elucidar melhor o leitor sobre o que está a ser apresentado na imagem, recorrendo a vídeo.
Para tal, aconselha-se a utilização de um smartphone durante a leitura, assim como a instalação da aplicação
“QR Reader”, disponibilizada pela TapMedia Ltd, através da Play Store3 (Android) ou App Store4 (iOS) ou Windows Store5 (Windows Phone). Na Figura 1 é possível observar um exemplo da utilização de um código QR numa imagem.
Figura 1 - Exemplo de Utilização de um código QR
Nota: a disponibilidade de acesso ao conteúdo através destes códigos é garantida até um ano após a data de entrega deste trabalho.
3 https://play.google.com/
4 https://itunes.apple.com/pt/genre/ios/id36?mt=8
5 https://www.microsoft.com/pt-pt/store/apps/windows
2. Estado da Arte
Neste capítulo é apresentado o estado da arte sobre temáticas relacionadas com redes sociais federadas. Uma análise ao estado atual das mais populares redes sociais e às frameworks para gerar redes sociais é aqui apresentada. As estruturas de dados existentes, assim como a desejada homogeneização de dados também são abordadas. Por fim, e tendo em vista a essencial troca de dados, há uma exposição de vários protocolos e tecnologias de comunicação.
2.1. Infra-estrutura “Rede Federada”
Desde que surgiu a internet, a sociedade sofre “alterações” com grande rapidez e impacto. Com o aparecimento da Web 2.0, o paradigma da internet mudou, passando os utilizadores a assumirem também um papel de produtores de informação.
“Nesta fase a Web passou a ser encarada como uma plataforma na qual o utilizador comum não se limitava a pesquisar e a consultar informação, mas tinha um papel mais criativo uma vez que podia, ele próprio, criar informação e conteúdos para a Web, tornando-se simultaneamente produtor e consumidor de informação... A filosofia da Web 2.0 torna a Web num ambiente social e acessível a todos os utilizadores, num espaço onde cada um seleciona e controla a informação de acordo com as suas necessidades e interesses.” (Costa et al., 2009).
Esta relação utilizador-internet potenciou o aparecimento das redes sociais. Apesar de se aceitar que já estamos na Web 3.0 e a caminhar para a Web 4.0 (Srivastava, 2014), foi durante a Web 2.0 que surgiu grande parte das principais redes socias, tais como o Facebook, LinkedIn, Twitter, Youtube, GooglePlus, etc.
2.1.1. Redes Sociais
As redes sociais continuam a expandir-se. Oferecem um “espaço” adequado para a partilha instantânea de informação (áudio, vídeo, etc.) com outros membros da rede devidamente associados. Numa outra vertente, ao longo do tempo têm influenciado a forma de comunicação e entretenimento das pessoas. Isto explica a enorme adesão e participação extrema de muitas pessoas na internet, mesmo aquelas que até ao aparecimento das redes sociais não tinham interesse na web (Commission, 2010). Surge agora a necessidade de gerir as relações que, ao existirem naturalmente entre as pessoas, se devem manifestar nestas plataformas. Esquematicamente, os social graphs permitem observar essas relações e comportamentos entre elas.
2.1.1.1. Social Graphs
Os grafos são esquemas matemáticos que permitem representar relações entre coisas. As relações entre as pessoas nas redes sociais são também representáveis através de grafos – social graphs (Figura 2) – onde os nodos e as relações são arquétipos de pessoas (e outras coisas) e comportamentos entre elas, respetivamente.
Instanciados na web, os social graphs oferecem meios de análise de informação correlacionada com contextos, conteúdos e perfis de utilizadores.
Figura 2 - Social Graph (Dickinson, 2012)
As redes sociais vieram permitir aos utilizadores terem a sua página, evoluí-la e partilhá-la, assim como gerar informações enquanto “navegam” na plataforma.
Além disso, e devido à importância de sustentar a aquisição de informação externa para a plataforma, desenvolveram-se Application Programming Interfaces (API) que permitem a interoperabilidade entre instâncias de informação na web. Por exemplo, o Facebook dispõe de uma API, designada de “Facebook Open Graph”6, que permite a integração entre aplicações externas e o próprio grafo do Facebook, oferendo a capacidade de registar informação externa na plataforma (usando “algoritmos de identidade” como o oAuth7 e o OpenID8) (Facebook, 2016).
2.1.1.2. Social Media
Entenda-se social media (Dewing, 2010) como o conjunto de plataformas que promovem a participação, a comunicação e a conexão, ou seja, que permitem aos utilizadores contribuírem e trocarem informações, e que estabelecem algum tipo de ligação a outros websites, recursos e utilizadores. Aqui surge o enquadramento das redes sociais em relação à social media.
Existem diversas redes sociais temáticas que mantêm como principal objetivo partilhar e gerar informação.
Hoje é fácil ter acesso a notícias, opiniões ou ao dia-a-dia das pessoas (conhecidas ou não). É fácil saber o que os amigos almoçaram, jantaram, que atividades realizaram, ou o seu estado de espírito. As redes sociais do momento permitem estabelecer contacto com velhos amigos, com amigos atuais, assim como fazer novas amizades, onde os interesses de cada um se cruzam. Além disso, cada rede social promove uma experiência de utilização e uma abordagem de relações sociais diferentes, consoante uma perspetiva específica.
Expondo alguns números estatísticos, o Facebook apresenta um número de utilizadores em todo o mundo de 1.71 mil milhões e, diariamente, gera 4.5 mil milhões de “likes” e 300 milhões de upload de fotos (Zephoria, 2016). Ao mesmo tempo, o Youtube apresenta mil milhões de utilizadores, 4 mil milhões de visualizações diárias e a cada minuto é feito um upload de 300 horas de vídeo (Smith, 2016). Redes com o intuito de criação
6 https://developers.facebook.com/docs/sharing/opengraph
7 https://oauth.net/
8 http://openid.net/
de relações e partilha de informação como Twitter, LinkedIn, Google Plus e Instagram também apresentam números interessantes.
A Tabela 1 procura mostrar as principais características destas redes sociais no que se refere aos serviços nelas disponibilizados e à utilização que delas é feita!
Tabela 1 - Análise de Serviços/Utilização das Redes Sociais atuais
Facebook Twitter LinkedIn GPlus Instagram Impacto na
Industria B2C B2B/B2C B2B B2B/B2C B2C
Instant Messaging
Aplicação Móvel Eventos
Aplicações
Edição de Perfil
Estas redes sociais, juntamente com outras não mencionadas, são “alimentadas” por informação que o utilizador insere de uma forma ou de outra. Nota-se que certas redes apresentam informação e funcionalidades mais direcionadas a uma certa área, como é o caso do LinkedIn, que se foca na partilha de notícias, de recursos humanos e na discussão sobre a indústria.
Apesar de tudo o que cada rede social oferece e das diferenças entre as mesmas, há um ponto em que quase todas se cruzam: uma identidade em cada uma das redes e não uma única identidade transversal a todas.
2.1.1.3. Social Frameworks
O aparecimento das redes sociais “agarrou” muitas pessoas à tecnologia e o ambiente destas tornou-se algo
“familiar” para os utilizadores. Tendo isto em conta, não tardou a surgirem aplicações que permitem ao utilizador desenvolver a sua própria rede social. Isto traz consigo muitas vantagens porque permitiu o desenvolvimento de “Social Intranets”, redes sociais corporativas e redes sociais privadas. Permitiu, por exemplo, que instituições interligassem os seus membros, não só a nível de partilha de informações como também ao nível do workflow de trabalho, promovendo a comunicação em equipa. Exemplos deste tipo de aplicações são: BuddyPress9, HumHub10, mooSocial11 e Dolphin12, que se caracterizam de seguida:
9 https://pt.buddypress.org/
10 https://www.humhub.org/
11 https://moosocial.com/
12 https://www.boonex.com/
• O BuddyPress consiste num plugin gratuito que se instala no Content Managment System (CMS) WordPress, transformando-o numa plataforma de rede social. Oferece um fluxo de atividades, perfil de utilizador, criação de grupos, rede de amizades, escolha de tema e um blog para cada utilizador. É baseada em PHP – Hypertext Preprocessor (BuddyBoss, 2016).
• O HumHub é um software open-source que oferece ferramentas para uma comunicação e colaboração fácil. Com uma interface amigável, é possível criar uma rede social que se adapta às necessidades que levam à construção da rede (HumHub, 2016).
• O mooSocial foi construído sobre a framework CakePHP13 e o seu frontend apresenta um design responsivo graças à utilização da framework Bootstrap. Permite a criação de múltiplos tipos de rede social, variando de acordo com os interesses/conceito. Disponibiliza ainda uma versão para Android e iOS (MooSocial, 2016).
• O Dolphin oferece controlo total sobre a aparência e funcionamento de toda a plataforma. Tudo é editável através de um painel de administração, mas caso não seja suficiente, é permitido aceder ao código-fonte e realizar as alterações pretendidas. O seu design é totalmente responsivo, permitindo uma ótima visualização em dispositivos móveis. Os utilizadores podem personalizar o seu perfil, partilhar informações, comentar, “reagir” e, através das relações estabelecidas, constroem o social graph da rede, assim como o fluxo da informação. Quanto à conversação, esta é baseada na tecnologia WebRTC14, que estabelece uma ligação peer-to-peer (P2P) diminuindo a carga no servidor (Ltd, 2016).
A Tabela 2 resume as principais características destas frameworks sociais.
Tabela 2 - Principais Características das Social Frameworks (Adaptado de Wikipédia, 2016)
BuddyPress HumHub mooSocial Dolphin
Single Sign-on
OpenID LDAP Active Directory
Facebook Connect GitHub
Facebook Connect Google Account
Facebook Connect Google Account
Twitter Yahoo! ID
Blog Canais Comunicacionais
Calendário
Plugin
13 https://cakephp.org/
14 https://webrtc.org/
Customizável
Plugin
Aplicação Móvel
Comercial/Open-
source Open-source
Enterprise Edition/Community
Edition Comercial Open-source
Numa outra perspetiva, o desenvolvimento de ferramentas “soltas” com potencialidade de desenvolver a rede social com os serviços que se pretende levou ao aparecimento do OpenSocial e Open Web Platform.
O OpenSocial consiste num conjunto de API comuns para criar aplicações sociais para a web com o objetivo de oferecer capacidade aos developers de construir aplicações, indiferentemente das redes sociais que usem e, consequentemente, acelerar a inovação e provocar o aparecimento de mais recursos sociais (Google, 2007).
“The web is fundamentally better when it’s social, and we’re only just starting to see what’s possible when you bring social information into different contexts on the web... There’s a lot of innovation that will be spurred simply by creating a standard way for developers to run social applications in more places. With the input and iteration of the community, we hope OpenSocial will become a standard set of technologies for making the web social” (Google, 2007).
Este investimento na padronização de tecnologias de forma a poder executar qualquer tipo de aplicação social em qualquer contexto, levou ao aparecimento da Open Web Platform, que resulta da fusão da OpenSocial Foundation com o World Wide Web Consortium (W3C). Daqui surgem as normas técnicas e API que facilitam o acesso à funcionalidade social, como o uso da sintaxe JavaScript Object Notation15 (JSON) na troca de dados, uma API do lado do cliente e um protocolo web com o objetivo de federar as informações sociais. Além disso, a formulação de uma estratégia para permitir negócios sociais, assim como federações sociais é um objetivo (W3C, 2014). Tecnicamente, as API expõem métodos para aceder a informações sobre as pessoas (amigos, dados pessoais, etc.) num determinado contexto, permitindo que a mesma aplicação seja executada em várias plataformas sociais e se adapte tendo em conta o seu ambiente, como por exemplo, os seus amigos (OpenSocial, 2013). Exemplos deste tipo de API/protocolos são: oAuth e Activity Stream16.
2.1.2. Redes Federadas
Federação é um termo derivado do latim, que significa “pacto” e/ou “aliança”17. Como um acordo contratual, federação está relacionado com governação, ou pelo menos a adesão a regras. Um governo federado é composto por uma autoridade federal central e vários estados. A autoridade federal tem certos privilégios e funcionalidades que lhe são delegadas pelos estados, enquanto que o resto fica a cargo do estado. Por exemplo, os estados podem delegar a sua capacidade de fazer política entre estados estrangeiros e manter as suas políticas nacionais (Rubin, 2015). O mesmo se pretende desenvolver na web, uma vez que existem múltiplas redes
15 http://www.json.org/
16 http://activitystrea.ms/
17 https://www.infopedia.pt/dicionarios/lingua-portuguesa/federa%C3%A7%C3%A3o
sociais e é necessário criar a ponte entre elas de forma a colmatar problemas como o de um utilizador ter múltiplos registos/identidades.
Figura 3 - Centralização das Redes Sociais (Yeung, Liccardi, Lu, Seneviratne, & Berners-Lee, 2008)
Neste momento existem limitações evidentes em relação à portabilidade do grafo social, à comunicação “inter- comunidades” e ao controlo e privacidade dos utilizadores (Goix, 2012), visto que cada uma das redes sociais atuais funciona como um sistema centralizado (Figura 3), onde todos os utilizadores acedem ao mesmo fornecedor de serviço, enquanto que o conceito de rede social federada (Federated Social Network – FSN) encontra-se mais próximo de uma topologia descentralizada. Em vez de um modelo “cliente-servidor”, uma topologia descentralizada apresenta-se como um sistema P2P, onde todos os nós são tratados de igual forma e é evitada a presença de uma autoridade central (Maka, 2011). No entanto, a topologia descentralizada, apresenta algumas desvantagens:
a) A consistência de dados sofre grandes atrasos devido à utilização de computadores pessoais, que podem não estar sempre ligados;
b) Manutenção superficial, visto que certos nodos podem correr softwares desatualizados, como por exemplo, patches de segurança. Além disso, um sistema deste género não deve exigir qualquer direito administrativo sobre os utilizadores;
c) A identidade de cada nodo requer uma forte criptografia para impedir falsificações.
A partir destas desvantagens surge um modelo híbrido, designado de topologia federada, que é vista através do conjunto de duas camadas: serviços ao dispor do utilizador, que são usados na forma comum (cliente-servidor) e o estabelecimento de uma rede P2P entre os servidores federados (Maka, 2011). Na Figura 4, é possível observar as diferenças entre sistemas centralizados (1), descentralizados (2) e federados (3).
Figura 4 - Sistemas Centralizados vs Descentralizados vs Federados (Maka, 2011)
Na topologia federada cada utilizador passa a ter uma identidade única e, com a utilização de uma ontologia adequada à interoperabilidade de dados entre as redes sociais, é possível que os utilizadores, estando ligados uns aos outros, tenham os seus dados armazenados em locais diferentes, i.e., o armazenamento de dados não- centralizado (Yeung et al., 2008).
Resumindo, as principais vantagens das redes sociais federadas são:
a) Os utilizadores podem comunicar uns com os outros em vários domínios através de identificadores globais (apenas uma conta);
b) A portabilidade dos dados pessoais é mais fácil, podendo escolher a rede social favorita e realizar a migração dos dados;
c) O utilizador terá o direito a ser “esquecido”, visto que poderá remover as suas informações pessoais a partir de qualquer local;
d) O utilizador sabe como e onde os seus dados pessoais serão utilizados com devido consentimento (W3C, 2013).
2.2. Representação da Informação
As plataformas ligadas à social media, como as redes sociais, todos os dias produzem enormes quantidades de dados, o que instigou o desenvolvimento de novas técnicas e metodologias para capturar, processar e analisar dados de grandes quantidades e complexidade. Surge a era do Big Data.
A importância desta análise aos dados prende-se pela capacidade que esta oferece de perceber como as pessoas pensam e agem, permitindo às organizações usar as informações para melhorar a sua tomada de decisão, direcionar produtos e serviços de uma forma mais eficaz, assim como tentar influenciar os comportamentos do utilizador no futuro (Hobbs, 2014).
As bases de dados apresentam-se como uma forma eficiente de armazenar, recuperar e analisar informação.
Em meados de 1960, empresas e governos já usavam bases de dados simples para armazenar e recuperar informações sob sistemas de armazenamento rudimentares. Na década de 70, o modelo de bases de dados relacionais foi desenvolvido e grande parte da linguagem usada na programação de bases de dados hoje foi desenvolvida nesse tempo – Structured Query Language (SQL) (Grad & Bergin, 2009). Atualmente, no mundo do armazenamento e estruturas de dados, existem dois principais tipos de bases de dados a realçar: bases de dados relacionais e não-relacionais. A diferença entre estas está na sua construção, no tipo de dados que armazenam e na forma de armazenamento dos mesmos.
2.2.1. Dados Estruturados e Não-Estruturados
Quando se menciona o termo “base de dados”, normalmente, está englobado todo o sistema de armazenamento de dados, mas na realidade esse só corresponde à coleção dos dados e aos dados propriamente ditos. O sistema que manipula os dados, transações, problemas ou qualquer outro detalhe é designado de Sistema de Gestão de Bases de Dados (SGBD).
Alguma confusão existe, contudo, ao referir bases de dados SQL e bases de dados Not Only SQL (NoSQL).
Esta “confusão” assenta essencialmente no facto de terem surgido bases de dados cujos dados armazenados não estão organizados em tabelas e relações, mas sim em documentos e coleções. E não se trata apenas de termos distintos, trata-se efetivamente de coisas diferentes. Vejamos a diferença.
O sistema de base de dados tradicional segue o modelo relacional. Neste modelo, os dados são armazenados em tabelas inter-relacionadas e dispõem de um mecanismo de indexação que permite a realização de várias operações como a leitura e a execução de consultas (queries) que reúnam dados de várias tabelas (Rautmare &
Bhalerao, 2016).
Se os dados que se manipulam forem todos de um tipo de dados cuja a organização se conhece, é possível criar estruturas que os possam armazenar. Mas se a organização dos dados que se manipula é diferente e, por vezes, não conhecida na totalidade, então as estruturas que os armazenam terão de ter a capacidade de adaptarem a organizações de dados diferentes. Diz-se então que estas estruturas terão de saber lidar com documentos (conjunto de dados) e não literalmente com cada um dos dados que os compõe. Estes documentos podem depois ser organizados e classificados pela estrutura que possuam, em coleções. Estes dados dizem-por isso, não estruturados. Contrariamente às bases de dados relacionais (SQL), as bases de dados que os armazenam dizem-se NoSQL.
Um cenário típico de múltiplas aplicações distribuídas e integradas, assentes em múltiplas fontes de dados heterogéneas (sensores, pessoas, etc.) onde, tanto na estrutura como no tipo (áudio, vídeo, texto, etc.), uma enorme quantidade de dados diferentes existe, proporciona um contexto onde a gestão e processamento de dados não estruturados melhor se aplicam. A necessidade de bases de dados não-relacionais (NoSQL) é por isso uma realidade. Estes sistemas tornaram-se populares devido à facilidade de acesso e à velocidade com que lidam com os dados, assim como à sua elevada escalabilidade (Rautmare & Bhalerao, 2016).
Normalmente, este sistema pode ser apresentado segundo três tipologias diferentes:
a) Chave-valor (Key-value store): os dados são armazenados através do par chave-valor, onde o valor corresponde aos dados e a chave é usada para aceder a esses mesmos dados;
b) Orientadas ao documento (Document store): estendem o modelo “chave-valor” guardando os valores de uma forma estruturada (daí a aplicação do nome “documento”). Ao contrário do modelo relacional, armazenam os dados em documentos que contêm vários campos e um único ID, permitindo que seja possível ter vários dados de um elemento num único documento (Figura 5). Apesar de parecer mais intuitivo, grandes volumes de dados exigem mais processamento e espaço “extra” comparando com o modelo relacional. No entanto, com o aparecimento da plataforma Hadoop18, que se baseia no conceito de computação distribuída e com o objetivo de processar grandes volumes de dados, essa
“lacuna” pode ser preenchida (Wodehouse, 2016);
Figura 5 - Base de Dados Não-Relacional orientada ao documento (Wodehouse, 2016)
c) Bases de dados de Grafos (Graph databases): compostas por nodos e arestas, onde os nodos correspondem às entidades, enquanto que as arestas são a referência das relações entre os nodos.
A Tabela 3 resume as principais diferenças entre dados estruturados e não-estruturados:
Tabela 3 - Dados Estruturados vs Dados Não-Estruturados (Adaptado de Rautmare & Bhalerao, 2016)
Dados Estruturados Dados Não-Estruturados
Modelo Relacional Não-Relacional
Armazenamento de Dados
Dados são guardados em tabelas compostas por linhas e colunas
Dados podem ser guardados de diferentes formas: documentos, grafos e pares chave-
valor
Esquema Esquema fixo e as alterações são difíceis e de evitar
Livre de esquema, permitindo ao utilizador uma mudança fácil do seu esquema de
dados
Novos Campos Implica a alteração do esquema Podem ser adicionados facilmente
Escalabilidade Boa escalabilidade vertical Mais adequado para escalabilidade horizontal
18 http://hadoop.apache.org/
Linguagem de Consulta (Query)
Usa uma poderosa linguagem declarativa
(SQL) Usa objetos de dados JSON
Transações Suporta transações ACID O suporte de transações ACID varia com a solução
Consistência Forte Eventual
Considerando a aquisição e monitorização ambiental – área de aplicação deste projeto – o uso de sistemas distribuídos assentes em redes integradas de diferentes dispositivos eletrónicos (sensores, atuadores, etc.), vulgo Internet of Things (IoT), prevê-se a aquisição autónoma e contínua de enormes quantidades de dados de múltiplos tipos e fontes, contexto típico de dados não-estruturados. Tornar estes dados em informação útil para decisões atempadas requerem sistemas de armazenamento de dados não-estruturados com elevada performance e escalabilidade, complementados com apropriada capacidade de processamento – Big Data.
Além disso, a possibilidade de escalabilidade horizontal (Rautmare & Bhalerao, 2016), a distribuição de dados por vários servidores, arquiteturas típicas em computação na nuvem, está garantida.
2.2.2. Interoperabilidade de Dados
Com o aparecimento da web (University, 2002), o acesso a documentos através de hiperligações, independentemente da sua localização física, tornou-se uma realidade. Algures numa máquina, numa rede informática, num local, o documento passou a estar disponível como nunca o fora antes (Rocha, 2015).
De uma relação inicial passiva – apenas de leitura (static web – Web 1.0) – os utilizadores passaram a conseguir criar os seus próprios conteúdos, assumindo um papel bem mais ativo, participando e interagindo. Surgiram plataformas que promovem relações entre as pessoas, assim como a partilha de informação, contribuindo ainda mais para a criação de conteúdos web (social web – Web 2.0). Esta crescente preocupação de conseguir autonomia no que cada um “consome” e “produz” na web, socializa a web e torna-a mais humanizada, incutindo-lhe semântica para poder relacionar contextos, à semelhança do que acontece entre as pessoas no seu dia-a-dia (semantic web – Web 3.0). E a expansão continua… Web of Things… Web of Thoughts (Figura 6)…
Web of Everything?!
