3. Ecossistema de Dados na Web

3.1 Atores e Papéis

A Web de Documentos é basicamente utilizada por dois tipos de usuários: publicadores e consumidores. O primeiro navegador criado por Tim Berners-Lee permitia não só o acesso a um documento, por meio da especificação de uma URL, como também permitia que o usuário editasse a informação e a gravasse, nos moldes da Wikipedia. Dessa forma, uma mesma pessoa, um mesmo ator desse ecossistema, podia ter dois papéis: consumidor e publicador de dados. Porém, como regra geral, temos esses dois papéis desempenhados por grupos de pessoas diferentes: um conjunto de pessoas com a tarefa de publicar documentos e um conjunto de pessoas com o interesse em consumir esses documentos. Esses dois papéis, por sua vez, podem ser especializados em conjuntos de papéis mais específicos.

Para ilustrar a diversidade de papéis em uma ambiente de publicação de dados, vamos utilizar uma analogia entre a Web e o mundo dos livros. Nesse mundo existem dois tipos básicos de papéis: os escritores e os leitores. Para que um leitor possa ter acesso a um texto criado por um escritor, é preciso que esse escritor publique o livro. Teremos então um leque de novos papéis, todos agrupados em um grande papel, que podemos denominar publicadores. Entre os publicadores teremos, além do próprio escritor, pessoas responsáveis por garantir que, a partir de um texto criado por uma pessoa, esse texto possa ser impresso e distribuído a fim de chegar aos leitores. São necessárias pessoas que cuidem da infraestrutura de publicação, da divulgação, da distribuição, designers para a definição da capa, do tipo de papel, da fonte, formatos de publicação, etc., até chegar às livrarias, para a venda ao leitor, o consumidor do livro. É fácil perceber que existem diferentes atores desempenhando diferentes papéis com diferentes competências ao longo desse processo. Do lado do leitor, o consumidor, poderíamos também identificar dois tipos de leitores: um leitor apenas interessado em consumir as informações do livro e um leitor que poderia também ser um publicador. Este estaria interessado em gerar uma nova publicação a partir das informações consumidas no livro.

No mundo da Web, também podemos considerar esses dois grandes grupos: os publicadores e os consumidores de dados. Do lado dos publicadores podemos listar uma série de diferentes atores com diferentes papéis, relacionados à publicação de informações que muitas vezes são definidas por regras ou procedimentos que fogem ao escopo das funções do criador ou do publicador efetivo dos dados. Esse conjunto de papéis pode envolver diferentes atores dentro de uma empresa ou de um órgão de governo, onde diferentes setores podem ser responsáveis pela definição das variadas informações e processos. Podemos citar, entre outros, a definição de licenças, a criação de regras de definição do formato das URIs (um conceito mais abrangente que URL), a escolha dos formatos dos dados e das plataformas para a distribuição das informações, qual o conjunto obrigatório de metadados e documentos, a definição de estratégias para garantir a persistência, a preservação e o arquivamento dos dados, etc.

Do lado do consumidor dos dados podemos identificar pessoas interessadas no consumo direto dos dados (usuários finais), e pessoas interessadas em transformar os dados e agregar algum valor para, então, fazer a publicação de um outro conjunto de dados. Esse segundo grupo de pessoas é formado por desenvolvedores de aplicações intermediárias entre os usuários e esse novo conjunto de dados. Muitas vezes os usuários finais fazem a agregação, de forma manual, de diversos conjuntos diferentes de dados para a obtenção de um outro resultado desejado, em uma tarefa não atendida por nenhuma aplicação específica. A combinação de dados é algo infinito e, dependendo da demanda de um tipo específico de combinação, pode ser útil que se desenvolva uma aplicação particular que possa automatizar esse processo e facilitar o trabalho dos usuários finais.

Na seção seguinte, ciclo de vida dos dados na Web, é possível perceber o conjunto de diferentes papéis e competências necessárias para a realização das diversas tarefas relacionadas à publicação dos dados.

3.2 Ciclo de Vida

Ciclo de vida de dados é o processo de gerenciamento de informações desde a sua fase de seleção até a fase de arquivamento. Esse processo envolve a participação de diferentes profissionais, com competências específicas referentes a cada uma das fases. Como vimos na seção anterior, são diversos papéis que são especializados dentro do grupo de publicadores e consumidores de dados.

Existem diversos modelos que visam capturar todas as fases do ciclo de vida e o relacionamento entre elas. Algumas das fases extraídas desses modelos são listadas a seguir.

• Planejamento ‒ é a fase inicial onde se faz o planejamento da publicação dos dados, o que inclui a seleção dos dados a ser publicados, a identificação de equipes e órgãos que devem participar do processo e as opções de coleta e plataformas de publicação.

• Estruturação ‒ é fase onde é definida a estrutura dos dados a ser distribuídos. Por exemplo, no caso de tabelas, quais os campos que serão expostos e as características desses campos. No caso da utilização de Web Semântica e Dados Conectados, que ontologias serão utilizadas para as instâncias dos dados (seção 5). É também nessa fase que uma nova ontologia será definida, caso seja necessária.

• Criação e Coleta ‒ é a fase de aquisição dos dados propriamente ditos, que incluem dados a ser criados e dados já existentes, obtidos a partir de planilhas, bancos de dados, APIs, Web Services , etc.

• Refinamento e Enriquecimento (Transformação e Integração) ‒ é a fase onde os dados são trabalhados de forma a melhorar a sua qualidade, filtrando possíveis incorreções, agregando ou separando informações e fazendo eventuais conexões com dados relativos a outras bases

• Formatação ‒ é a fase onde os dados a ser publicados são formatados de acordo com a plataforma escolhida para publicação

• Descrição (Metadados, Documentação) ‒ é a fase onde são definidos, criados e coletados os metadados e os documentos que devem ser agregados aos dados, de forma a auxiliar o entendimento das informações.

• Publicação ‒ é a fase em que os dados são efetivamente colocados na Web, na plataforma escolhida para publicação

• Consumo ‒ é a fase onde os dados são consumidos por usuários finais ou por desenvolvedores de aplicações

• Realimentação ‒ é a fase onde são recolhidas informações relacionadas à utilização dos dados, que podem vir, por exemplo, dos consumidores dos dados ou das plataformas de distribuição.

• Arquivamento ‒ é a fase onde os dados são retirados da Web.

3.3 Arquitetura

Na fase inicial da Web, a tarefa básica requisitada a um servidor Web era a de obtenção de uma página estática (identificada na cadeia de caracteres da URL), armazenada em um arquivo, e codificada em HTML. Com a expansão do desenvolvimento de aplicações na Web Programável, essa URL passou a ser utilizada para requisitar a realização de outros tipos de tarefas, como, por exemplo, um pedido de informações sobre preços de um produto em diferentes sites de vendas. Essas informações são construídas de forma dinâmica pela aplicação executada no servidor Web, que pode compilar os dados sobre os preços desse produto a partir das diferentes formas de coleta de dados listadas acima. Em um outro exemplo, a tarefa requisitada poderia ser a transferência de uma quantia em dinheiro de uma conta bancária para outra. Nesse caso, a tarefa requisitada não seria uma tarefa de obtenção de uma página de dados. Seu retorno, provavelmente, sinalizaria o sucesso ou o fracasso na realização da transferência de fundos.

A estrutura de funcionamento da Web é baseada no modelo cliente-servidor, onde temos uma aplicação requisitando a realização de alguma tarefa para uma outra aplicação. O acesso aos dados do lado do servidor é sempre intermediado por uma aplicação. Mesmo a requisição de uma página HTML estática em um servidor, é exposta por uma aplicação do lado do servidor que atende à requisição efetuada pela aplicação cliente. Portanto, qualquer dado que é consumido por uma aplicação executada no lado do cliente, um navegador, por exemplo, tem uma aplicação como intermediário, que tem acesso aos dados e o retorna para o requisitante.

Entre os muitos avanços e tecnologias que têm sido agregados ao funcionamento da Web, três são interessantes em ser ressaltadas, no histórico da manipulação de dados: JavaScript, XMLHttpRequest e Ajax. Como já foi dito, no início da Web todos os dados contidos em uma página exibida por um navegador eram retornados no código HTML resultante do processamento efetuado pelo servidor Web após a requisição de uma URL. Não existia nenhum tipo de programação executada no lado do cliente Web, do navegador, a não ser a interpretação do código HTML para a exibição da página ao usuário. Uma vez que uma página tivesse sido carregada e exibida, qualquer tipo de processamento de dados que fosse necessário tinha que ser feito pelo servidor, fruto de uma nova requisição. Por exemplo, um erro em um campo de formulário só era detectado após o envio dos dados para o servidor e o retorno de uma nova página completa, muitas vezes praticamente igual à página anterior, apenas com uma mensagem adicional informando os erros detectados.

Novas requisições de páginas introduziam todo um tempo de retardo devido à necessidade de uso da rede para uma nova comunicação e transferência dos dados. A introdução da capacidade de executar código do lado do cliente, por meio de uma linguagem inicialmente denominada LiveScript , logo renomeada JavaScript, permitiu que uma série de manipulações pudessem ser resolvidas sem haver a necessidade de uma requisição ao servidor. Com a capacidade de processar código do lado do cliente, procedimentos como, por exemplo, a consistência de campos de formulários passaram a ser executados sem a necessidade de novas requisições. Com a sofisticação das novas especificações do código HTML, a parte do design das páginas também passou por uma mudança, com uma forma mais rica de apresentação, com a ideia de páginas dinâmicas em HTML (DHTML), onde o código JavaScript embutido nas páginas Web passou a manipular a estrutura dos dados apresentados.

Mesmo assim, a programação executada do lado do cliente só podia manipular os dados retornados pelo servidor após a requisição de uma URL. Se fossem necessários mais dados, era preciso requisitar outra página Web pois o código JavaScript executado dentro de uma página não podia se comunicar com o mundo exterior. XMLHttpRequest mudou essa limitação, permitindo que o código JavaScript contido nas páginas Web de um navegador pudesse ter acesso a mais dados do servidor, sempre que necessário.

A Google rapidamente percebeu o potencial dessas novas tecnologias, e aplicações como o Gmail e Google Maps tiraram proveito disso para construir interfaces de usuário mais ricas e parecidas com uma aplicação, uma aplicação Web ao invés de uma página Web. Com o Gmail, por exemplo, a aplicação está continuamente verificando junto ao servidor se há novos e-mails. Se houver, a página é atualizada sem que haja a necessidade de carregar uma nova página. Da mesma forma, o Google Maps permite que uma pessoa inspecione um mapa, e somente as partes necessárias são requisitadas ao servidor.

Esta nova técnica foi denominada Ajax ( Asynchronous Javascript And XML ) ( figura 3.1 ) em um artigo de Jesse James Garrett [8], e o termo foi imediatamente adotado. A técnica passou a ser usada de forma ampla e surgiram diversos toolkits em JavaScript que tornaram seu uso ainda mais fácil e intuitivo.

Esse modelo de construção de uma aplicação a partir da junção de dados pode ser vista como sendo a de uma aplicação fazendo a requisição dos dados a partir da especificação de URLs e tendo como retorno, não mais um código HTML, mas um conjunto de dados que serão manipulados pela aplicação e apresentados ao usuário na forma adequada, dependendo da tarefa requerida pelo usuário. Podemos replicar esse modelo para a construção de aplicações dentro do ambiente de dados publicados na Web, incluindo os dados publicados segundo os conceitos da Web Semântica

A Web pode ser vista como um conjunto de camadas de dados e camadas de aplicações executadas a partir de requisições identificadas por URLs. Podemos considerar que uma requisição a um servidor é uma requisição de realização de uma tarefa, passando uma URL como informação de entrada a ser interpretada para a execução dessa tarefa e para o retorno dos resultados. Os dados resultantes de uma requisição são sempre expostos por alguma aplicação, que pode manipular dados provenientes de arquivos, de bancos de dados, dados extraídos de páginas da Web, dados resultantes de chamadas a Web Services ou chamadas a Web APIs . No caso mais simples, e que deu início à Web, a aplicação do lado do servidor é apenas um servidor de páginas que estão armazenadas em uma estrutura de diretório. Em uma configuração mais dinâmica, essa aplicação pode executar um código que acesse dados de um banco de dados e os retorne formatados em HTML. Num cenário mais sofisticado, essa aplicação pode se comportar como cliente de outras aplicações, e retornar dados resultantes da manipulação específica que faz desses dados, obtidos a partir de requisições efetuadas a outras aplicações ( Web Services e Web APIs ).

Sob a perspectiva das máquinas, podemos desenhar a Web de Dados como uma camada de dados consumidos por uma camada de aplicações. Os dados gerados por essas aplicações, por sua vez, podem ser utilizados como fontes de dados por outras aplicações. Teremos, então, uma nova camada de dados (gerados por aplicações) a ser consumidos por uma nova camada de aplicações. E assim por diante. Temos, assim, um universo de camadas de dados e de aplicações que podem construir novas camadas de forma infinita, com cada aplicação oferecendo um conjunto específico de tarefas. As interpretações dos dados e de seus possíveis significados são de responsabilidade das aplicações, resultantes das relações que estas fazem a partir do consumo do universo de dados dispostos nas diversas camadas.

Sob a perspectiva das pessoas, as aplicações devem prover interfaces onde os dados resultantes das tarefas requisitadas sejam apresentados de forma a ter a sua compreensão facilitada, de competência de designers de interface. Por exemplo, no caso de conjuntos extensos de dados, recursos como a apresentação visual de gráficos e tabelas em diferentes formatos podem vir a auxiliar essa compreensão. Não faz parte do escopo desse guia explorar as diversas formas de expor os dados nas interfaces de usuários.

Temos então uma arquitetura onde existem dados publicados de diferentes formas e um conjunto de aplicações que oferecem um conjunto de tarefas e manipulam esse conjunto de dados para gerar seus resultados. A distribuição desses dados é heterogênea e comporta o acesso a dados contidos em páginas Web, downloads de arquivos armazenados em estruturas de diretórios nos servidores, dados retornados por Web Services e Web APIs . Não existe uma padronização em relação à estrutura e a semântica dos dados distribuídos. Essas questões são resolvidas pelas próprias aplicações. O entendimento da estrutura e da semântica dos dados fica embutido nas aplicações.

A ideia da Web Semântica é definir um modelo padrão para a representação de dados, combinado com um conjunto de vocabulários de uso comum, permitindo que a semântica dos dados possa ser anexada aos dados, de forma a construir um ambiente mais homogêneo nas camadas de dados a facilitar o trabalho dos desenvolvedores de aplicações.

Como veremos na seção seguinte, a Web Semântica (Dados Conectados) acrescenta a essa arquitetura duas novas formas de distribuição dos dados:

• Dereferenciação de Recursos ‒ os dados, recursos representados no modelo de dados da Web Semântica, são requisitados diretamente por meio de uma URI (seção 4.1.2).

• Endpoint SPARQL ‒ um protocolo de acesso e uma linguagem de consulta que permite uma requisição de um conjunto de recursos a partir da especificação de uma consulta em uma base de dados.

Atualmente, o ambiente da Web, como é de sua característica intrínseca, tem uma estrutura heterogênea em relação à publicação e distribuição dos dados. A parte mais importante em relação à abertura de dados é que estes sejam publicados, mesmo que em formatos proprietários e que exijam mais trabalho dos desenvolvedores e dos consumidores de dados. O que os criadores da Web Semântica almejam é que essas diferentes formas possam convergir com o passar do tempo de modo a construir uma Web de Dados, um banco de dados mundial de informações conectadas. Sobre essa Web de Dados, as aplicações poderão construir o seu conjunto de tarefas a fim de atender as demandas dos usuários. Na seção 5.2 são apresentadas cinco fases nesse caminho da abertura de dados.